Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
Re-imagining JRPG: Designing for Mobile Audiences (Part 2)
There are many ways to consume content in today's gaming landscape. We did our best to reformulate what we love about the JRPGs for Mobile Audiences. A few design concepts were successful.
13 Min Read
This is the sixth post in our multi-part blog on Gamasutra. We're an independent development team focused on burning as bright as we can.
Check out our previous posts on Gamasutra Blog:
We're behind schedule on our posts because we're starting on our next game. We're going to try making a WRPG/Simulation next. After all these articles about JRPGs, we hope make another set based on our experiences making a WRPG. Should be fun.
Also, we're giving away the Nameless soundtrack under Creative Commons BY 3.0. That means you're free to use it in a for-profit commercial product for free! Just a mention would be cool. You can find it here on Bandcamp:
On to design fun!
Nameless: the Hackers RPG for iOS
Mobile RPG banner for Nameless top best ios RPG
iTunes Link: http://nth.box.cat
Free Lite Version: http://nthl.box.cat
Reviews & Mentions: http://box-cat.com/
In our last post, we talked about our design pillars and user experience targets. This helped us focus-in and narrow down on what we want as a final game. For reference, they were:
Touch Specific Interface
Cyberpunk Aesthetic
Bite-Size RPG
The user experience goals were:
Character focused story
Explore close to real hacking culture
Mobile easy to play RPG
Our Kick-off Process
When we began brainstorming, it was easy to blow-up the scope and stuff it with everything we loved. Of course this would lead to very inflated costs and very difficult development. To avoid this, we formalized our feature selection process:
List everything we loved and debate them.
Assign Priorities: "Must have", "Nice to Have", "Not needed"
Evaluation of schedule, costs, team commitment, and feasibility.
It's feasible and everyone agrees? If not, go back and redo Step #2.
Draft a design document. (DO NOT SKIP THIS STEP).
Review document, everything okay? If not, go back and redo.
Start work under one unified vision.
What We Love About JRPGs
We did our best to stay focused and many times we debate for hours to mark singular ideas as either "Must have" or "Nice to Have". Here's a quick example of things we love about JRPGs:
Deep philosophical concepts about morality and existence.
Drama between characters.
Origination stories of characters.
Lore of the world, how it came to be.
Collecting items (Completionist).
Collecting characters
Character friendships
Super secret weapons
Extra difficult non-mandatory bosses (i.e. Emerald Weapon in FF7)
Mini-games that buff your character stats
Unique battle systems
Character tuning (modifications to stats)
Leveling-up, the feeling of getting stronger.
Interwoven stories (like Suikoden III's trinity system)
Multiple endings. Non-linear storylines.
Decisions that matter and change the storyline
Exploration of the world lore (NPC discussions)
Heart wrenching emotional stories
Side quests.
Slow unraveling of events, uncovering conspiracies.
Save the world! A sense of purpose.
The character art
Configurable job classes
Cutscenes
Etc...!
Must Have Features - Being Realistic
This was difficult. We fought for the things we each loved and debated about what we could do without. The most important thing was to stay realistic to schedule and cost. Immediately we made a few "Must have" decisions that would shape our game design:
Linear storyline.
Due to Cost and effort. Mobile games have a much thinner profit margin, unlike consoles or portables. Making a multi-branching storyline would take time and also have complicated the story writing process. We compromised by stating we would focus more on the characters.
Collection mechanics.
At the time, we didn't know how we would do this, but we knew that we wanted to focus on it. Specifically, we felt that this would be more important then other systems like the battle system, the leveling systems, or any mini-games. We also felt that mobile games seem to rely on this more than other mechanics.
Fixed number of core characters, we picked four (4).
Three felt too few, especially if we were to focus on characters. Multiple characters would be nice, but each character was a massive multiplier on production cost. Switchable characters also meant we would have to make branching dialog scenes and differentiated cut-scenes. As our first game, we decided to keep it simple.
visual novel RPG iOS top
Not Needed Features - Identifying the Unnecessary
This is an interesting design hack that we picked up from our previous careers. "Not needed features" are a team-recognized list of what we choose to exclude. It's a coordination trick. By excluding specific features, we can increase the equity/value of the "nice to have" features. This makes our "nice to haves" more valuable and as a team we can also eliminate some scope creeping.
The following where kicked out from our design (unless we had a very good reason to bring them back):
Origination stories of character
We stated we would make some, but we would not share them as in-game content. Instead, we compromised and said we would release them as comics or short stories. We debated over this by drawing parallels with old game manuals. (We miss game manuals.)
Collecting characters
Many JRPGs focus on this. The collection of characters and the unlocking of each one's individual back-story and struggles is a common trope. We made a strong decision early on that we would not be able to support extra characters.
Interwoven stories (like Suikoden III's trinity system)
It was always impressive when a JRPG can tell a story from two perspectives. An entanglement of fate that forces a misunderstanding. We dropped it for complexity reasons, but we would have loved to include it.Multiple endings. Non-linear storylines.
Lots of discussion on this one. Talked about "new game+", replay value, and challenge. We also went into concepts like Kairosoft's Save Game A/B (two saves) concepts. Multiple endings meant we needed to allow multiple save games for save crawling, per story arch saves, and other type of save game player behaviors.Heart wrenching emotional stories
This had more to do with the fact that we were on a mobile platform than anything else. We just couldn't imagine people bawling their eyes out while in-line for Starbucks. This made us more cautious about the mobile platform. In public, players will have their sound off. This makes it extra difficult to elicit emotions since we can't take full advantage of the audio.
Configurable Job Classes
This is definitely a nice to have, but for us we decided to eliminate it. This would then allow us to focus on the other nice to haves.
Mobile Audiences and Consumption of JPRG Content
While attempting to cover multiple design concepts, we began debating about "how" players play JRPGs. Based on our debates we decided on a few concepts:
Focus on skits writing (self-contained) and sketch comedy
Mobile gaming happens in small bursts, we wanted to make sure prior knowledge or prior context was kept at a minimum. This would force us to spend more time to ensure the player had "in-the-moment" context for each scene. We wanted to avoid having the player lose track of the story.
Minimum of two save slots (A/B)
We're not sure how often this happens, but we wanted to make sure someone could hand their phone to someone else and let them start a new game without erasing their current one. We're hoping this would encourage them to show their friends the beginning of the game.Auto-save, with no manual save.
Players are on-the-go, so there will be moments when they get a phone call, text, or decide to stop playing. We didn't want to force a player to manually save their game every time they had to do something. This can also get frustrating when the player loses progress because the phone's operating system decides to unload the App from memory.
No random encounters. Pick your targets.
We felt that players needed full control over their play session. Random encounters felt tedious, even on consoles. We compromised by designing unavoidable encounters instead. Players can pick their targets and each target had an "Accept" or "Cancel" button, but unavoidable targets would not allow you to cancel. We felt this was a good compromise because when a player tapped on an icon, it meant they were actively seeking targets.
Focus on small visual animations, less focus on audio
Audio is very important for JRPGs on console. It sets the mood, gives emotional cues, and can engross the player in awe. Being on a mobile device meant that some players would have their sound off, like during a public commute or playing at night before they sleep. This is probably one of the main reasons why we adopted facial animation portraits like the Tales Series.
Tales style RPG portrait skit
There are more features, but these are the ones we came up with at the beginning of the project.
Design Time! Yay!
I must say, design-time is the most engaging process of making games. I personally find it very enjoyable. We have a ton of high-level concepts and a ton of eliminated concepts, now we can try to craft them into actual game mechanics. This is where we can begin getting creative as a team!
We came up with the following, which made it into the final game:
Players will collect info-cards. These cards will have real technology facts.
Animated character portraits, similar to the tales series.
Cutscene system which will be the main delivery system for story/character content.
World map system, which will be the main interface.
Players can pick and choose contract quests from the world map.
Players can pick when to perform missions quests, which will progress the main story.
Players will get resources and random info-cards from battle.
Each character will have a specialization (Programmer, Distro, Security, Researcher)
Specializations will determine their function and battle attacks.
Boosts will have a real-time duration, to encourage longer play sessions.
Fixed length storyline, not unlimited play.
We came up with the following, which made it into the design document, but did not make it into the final game (more on this later):
Characters can perform passive-progressive training to increase stats.
Enable/disable info-cards (like equipment) to tune the team stats.
Combine info-cards to make new info-cards.
Give your characters "coffee" to increase their energy levels.
Each character has a type they can switch to and diversify the play styles and attacks.
Mini-games.
Early Game Logic and Flow Diagram
This was the early flow diagram for our game. Making one of these helps a lot in any team environment. Once you have a good diagram, everyone knows what needs to be done.
Game design flowchart diagram RPG JRPG mobile game
Draft a Design Document !
Draft a Design Document !!
Draft a Design Document !!!
Coming from an enterprise corporation, I saw many of my collages skip this step. When they did, they suffered for it. It's tedious and tiring, I can understand not having a design document when working alone. If you're in a team however, of any size, it's vital to have at least a draft.
There's a philosophy behind having the design document, it's not meant as a rigid rule set, it's a guideline. The purpose of making one is to use it as a sanity check:
Is this everything?
Does it make sense?
What are the critical concepts?
Can it be done?
Is everyone on the same page?
Why did we make such decisions?
Can you write a post-mortem by looking back at it? *smirk*
The design document doesn't need to be huge. Ours was 17 pages: mostly bullet points, tables, and pretty pictures. It shouldn't be a Detailed Design Document (DDD), these do not work well for creative projects. There's a difference between "design document" and "detailed design document".
The design document is a starting point, some project management philosophies demand that the design document be updated and precision accurate at all times. As our rule of thumb, it only needs to be updated once a year. What if you don't need more than a year for the project? Great! Don't update it.
The team also shouldn't be afraid to challenge the old design. Trying new things and making improvements are what makes a project succeed.
To quickly sum it up:
"If projects were straight forward, you wouldn't need people. But herding people is more difficult than herding cats, people have opinions."
Our final game was not exactly what was in the design document. But the fact that we had one saved us a lot of time and money, allowing us to focus more time and more money on the creative details of the game.
Start Work and More Design!
Everyone knew what they needed to do. We did many things in parallel and were able to focus on the more important unknowns.
At this point, the unknowns were:
User interface specifics
Character personalities / looks
Battle mechanics
Stat / level-up mechanics
Storyline pitch and hook
Formulas
The production pipeline
etc...
As we continued to make smaller design documents that would build consensus within the team on these unknowns.
Next Upcoming Topics
We have the following topics we'll be touching on in next few posts. It takes a while to make these, we'll be posting until we're done.
Re-imagining JRPG: Our Pipeline (Part 3)
Re-imagining JRPG: Coordinating with Free-Lancers (Part 4)
Re-imagining JRPG: (Part 5)
Our personal thoughts on the Premium iOS mobile market
What empowered us to build a mobile game
What we could have done to improve Nameless
What's next?
Check out our website: BoxCat Games
Follow us:
@BoxCatLLC
Facebook Page
Join Our Newsletter
Feel free to ask us anything in the comments. =)
Read more about:
Featured BlogsAbout the Author(s)
You May Also Like
