Mighty Rabbit Studios

5 RPGs that inspired the design of Saturday Morning RPG

Panzer Dragoon Saga –

Panzer Dragoon Saga is one of my favorite role-playing games of all time. I’m one of the few lucky enough to have owned and played through this masterpiece of a game. Although the game is relatively short by RPG standards (my total game time clocked in at a little under 12 hours), it has some fantastic elements that I couldn’t resist borrowing for Saturday Morning RPG. The main element we took from Panzer Dragoon Saga is the way the game ranks the player for each battle.

In PDS, solving battles as quickly and efficiently as possible will garner you a battle rank. The better your rank, the more experience points you’ll receive. Other games have done ranking in this way, but PDS did it in a way that made me feel that obtaining a quick resolution to each battle was critically important. Final Fantasy XIII tried ranking (using stars), but the benefits to obtaining a high ranking just weren’t as clear (a higher ranking would restore TP, which for the better part of the game’s first ten hours is rarely even depleted).

In Saturday Morning RPG, just as in Panzer Dragoon Saga, a higher rank will give you more experience points and allow you to level up quicker. Rather than making the battle rank entirely dependent on speed, SMRPGs ranks are determined through looking at how much damage was dealt and taken by the player, as well as their speed in battle. These stats are then displayed to the user in G1 Transformers tech-specs style, and a rating from F – SSS is dealt out.

Final Fantasy X –

While Final Fantasy X is much maligned by hardcore Final Fantasy fans, I thought the game was pretty excellent. My best memories of the game involve strategically using the game’s visual battle queue, which shows when each person involved in the battle will get to attack next. Since I enjoyed the queue so much, we’ve cribbed it in SMRPG; however, where FFX showed several turns for each battler, SMRPG only shows one turn for each character. This is due to how the game handles attack speeds, and how enemies pick attacks. We can’t preemptively show where an enemy’s attack will land when it hasn’t been picked yet, since queue placement in SMRPG is relative to both the player’s/enemy’s speed as well as that of the chosen attack. In any case, the queue allows players to see when their attack will take place, and it should allow for some degree of strategic choice in battle.

Pokémon –

Everyone played Pokémon, it is the ultimate “casual” RPG. I put casual in quotes because there really isn’t anything casual about Pokémon, it’s a hardcore RPG that somehow managed to break free of the genre’s stigmas and reach a mainstream “casual” audience. There’s two things about Saturday Morning RPG that have been heavily inspired by Pokémon.

First off, while the game is a hardcore RPG by every definition, it doesn’t ever present that to the user. Most of the big choices are autopiloted by the game, stat distribution and all the rules that go with it are hidden beneath the game’s surface. There is a ton of complex rules in Saturday Morning RPG that just like the rules in Pokémon, have been hidden beneath the game’s surface. This allows for a great deal of accessibility that many RPGs don’t afford the player.

Second, Pokémon is all about collectability. Saturday Morning RPG has this in common. In SMRPG you navigate the game world collecting, trading, and buying objects that you can use in battle. Just like Pokémon, these objects have unique abilities and applications in battle. “Collecting ‘em all” is just as applicable and fun in Saturday Morning RPG as it is in Pokemon.

Paper Mario –

Paper Mario is the ultimate “casual” RPG and we’ve borrowed so much from it (and it’s predecessor “Super Mario RPG”, which has unfortunately claimed our acronym) that I’m not even sure where to start. I guess the most obvious place to start is with the battle interface we’ve currently got in the game.  The battle system in Saturday Morning RPG consists of four choices, which are displayed to the player in a d-pad style interface. This pretty much describes the battle system of Super Mario RPG. I don’t think I have to go much more in-depth on that.

Also, in both Paper Mario and Super Mario RPG the player can defend against an enemy attack by pressing a button during a split second interval. This active defense keeps players engaged in the game and helps sate any boredom a more traditional RPG system could create. Saturday Morning RPG offers this same type of system; players have an interval equal to 1/3 of the enemy’s attack time in which they can defend against the attack by tapping the screen.

We also chose to emulate the Paper Mario leveling system, where the player gets to choose what stats to grow, but they are never overwhelmed with options. Players in Saturday Morning RPG will get to choose between three different stats to allocate a point to when they level up. This will ultimately keep people from drowning in the sea of intricacies that typically makes up RPG stat allocation.

Costume Quest –

Costume Quest was actually announced after I started work on Saturday Morning RPG. The minute I saw it, I became worried because it would surely draw comparison to SMRPG. I also knew that it would be a great opportunity to gauge what the market wanted out of a product like ours. I read countless reviews for Costume Quest and it lead me to adding the “Stash” feature in Saturday Morning RPG’s battle system. The number one complaint I saw about Costume Quest was that you couldn’t necessarily heal whenever you wanted or needed to. Saturday Morning RPG was initially the same way, with items only ever being dealt out at random. The stash added three slots that the player could fill with any object, those objects could be accessed at any time in battle and used only once per battle (whereas objects randomly drawn are re-shuffled and re-dealt when possible). This instantly solved the problem. I didn’t see too many other complaints about Costume Quest aside from people saying it was too repetitive (a problem I did not have).

A feature that many people will likely think is inspired by Costume Quest would be our “Trapper Keeper” style inventory system. In Costume Quest players keep track of all the game’s relevant data through a notebook. It’s very similar to what we’re doing with the Trapper Keeper; however, Costume Quest did not inspire our idea – the Trapper Keeper was the only thing that made sense in the context of our game for inventory management.

Designing the Battle System Interface

No single feature in Saturday Morning RPG has changed as much as the game’s battle system user interface. As someone who is really interested in the design side of things, I really love it when developers explain the choices the made and why they made them. As such, I’m going to post a slew of screenshots depicting our battle system from its earliest and ugliest stages to a much more current stage – although, I’ll probably still manage to find something wrong with it and decide it needs to be changed.

This screenshot was actually created prior to receiving any funding on the project, it was really just created as a way for me to show my co-founders the picture I had in my head for the battle system. The initial concept for battles in SMRPG were to be one on one affairs. As you would have probably guessed: there really isn’t much strategy or fun to be had in passing attacks back and forth between one enemy. I didn’t scrap the 1v1 concept just yet, though.

Also, this early design shows some of the early options that were to be included in battle: Attack, Defend, and Recharge. When the player first entered battle, the empty pane to the side of the menu was going to be hidden, upon choosing attack it was going to slide out showing the player’s available objects. This was ultimately a pretty ugly and bland menu system. It also didn’t leave much of the screen open for Marty and it left too much space for the enemy. I learned later on that symmetry is a very important thing to consider when designing UI. If the HUD elements aren’t placed symmetrically and properly balanced, something will just always look plain wrong.

These three images are all concept renders for the next iteration of our UI. Due to the urging of co-workers, I wound up settling on a variation of the first concept of the three. The large text would make choosing options simple and would allow me to display the names of objects in large text after the user chooses to attack. I had asked one of my co-workers which design of the three he liked best and he leaned strongly towards the first concept as well.

I’m not exactly sure why he did not like the second or third concepts, I’m assuming it has to do with symmetry as the text and buttons in those concepts are more left-justified and less balanced. If the image doesn’t make sense, the idea behind the second concept was sort of like a cover flow: when an action is selected it gets bigger and the other options shrink (tapping a second time confirms the option). The health bars are RTS inspired and were to be displayed for both Marty and the Enemy.

The third concept was to be entirely icon based. If the detailed description at the bottom is any indication, I was actually leaning towards this concept when I drew it up. In the end we wound up coming back to something similar to this (more on that later).

This is what resulted from the chosen concept that was shown above. Instead of plain text, buttons were used for the options. This UI system was actually in place for a good four months and it was the first one to support up to three enemies.

One thing to note is that this is the last UI to include an option for “Defend”. In the initial battle system, when a player wanted to recharge their MP, they would have to choose between “Recharging”, which was quick but left them completely vulnerable, or “Defending”, which was slow but negated a large amount of damage. In the end absolutely no one understood that. Of the 20 people who played the game at this stage, about 75% of them defended immediately at the start of the battle. Seeing as there is no need to use that option at that point (Marty’s MP is full at the start of the battle), they would just waste a turn. It was ultimately a completely pointless option. In hindsight, there’s really no use for “Defend” in most RPGs anyway – most of them are just “Skip a Turn” buttons.

After coming to this realization we decided that defense should be an active action rather than a passive one. Now instead of wasting a turn to defend, players could tap the screen in timing with an enemy attack (indicated by an exclamation point above Marty’s head) to defend against some of the damage (and recover MP in the process!). This actually made the battles several magnitudes more exciting. When people play the game now they do the right thing and attack the enemies. The simple fact that people now understood what to do proved that we were on the right track for our UI.

This button based UI did have a number of drawbacks, though, the most important being that it made really poor use of the touch screen. Since the menus were all button based, players would have to traverse a labyrinth (three different buttons needed to be chosen to lock in an attack) of selections to confirm an attack. This was not visually pleasing and to some players it just didn’t make sense. Players constantly tried to select the target of their attack by tapping the enemy on screen rather than their corresponding button. This is something we rectified in our current and (hopefully) final iteration of the UI, which is leaps and bounds better than all the prior interfaces.

The first thing you will notice is that the screen is well balanced and (mostly) symmetrical. Both Marty and the enemies have an equal amount of headroom. Both of these things make for an immediately visually appealing UI. You’ll also notice that we abandoned text based buttons entirely. The UI is entirely icon based, the fist is “Attack”, the battery is “Recharge”, the deck of cards is “Deal”, and the burlap sack is Marty’s “Stash.” The stash was an option that was added late into the game to introduce more strategy into battles (which is why it is absent from previous concepts). Once you click “Attack” the buttons will spin around revealing the three objects on hand to attack with, a cancel button also appears as the bottom option. Selecting an object will press the button behind it to an in state, displaying that it is selected. The player then touches the enemy he wants to target with the attack. The enemy turns red when selected. Tapping the enemy a second time locks the attack in. Stash items work the same way, while recharge and deal require only a tap on a confirm button to lock in.

While on the topic of the “Deal” option, we really struggled with that one (and we still are). This particular option is used when you want to be dealt three new objects to attack with. It was initially called “Redistribute”, which made no sense to anyone. We then changed it to “Deal”, and then ultimately “New Objects.” When it came time to transfer “New Objects” to an icon, we went back to the card term “Deal” from before and settled on a deck of cards. It isn’t the most obvious icon, and we will certainly change it before release – it has just been rather difficult figuring out how to represent that action.

This is the current UI we have in place for battles, it operates the same as the last iteration but it now is fixed at a 16:9 aspect ratio to give battles a more cinematic quality. There is also now a place under the battle queue for displaying the Scratch N’ Sniff stickers that are currently affecting Marty. The biggest change, however, is that all enemies now display health in the upper right rather than just the currently targeted enemy. This should make things a little more clear to players as to where they stand in battle.

All in all, we really iterated on the battle UI a lot and every day we are tweaking the finer details of it. We’re really striving to make sure the game you get in your hands is the best possible game we can make – in order to make that a reality it is imperative that we nail the UI. It has to be simple, accessible, and functional – not a small order for a first-time game developer.