We are developing an action RPG and have listed out the following modules/subsystems that we're going to need to make:

  • HUD(Heads-up Display) System
  • EXP/Leveling System
  • Combat and Navigation System
  • Character Controller System
  • Skill System
  • Monsters and NPC (AI)
  • Levels (Missions) System

The combat system is real time and we planned to include a puzzle type game in some (60%) of levels. We also have a game plot. Which modules should we develop first?

  • 7
    \$\begingroup\$ The first one you're going to work with is the one you decide to work with first. I imagine it'll be some combination of a few of them, in very basic forms. Figure out which systems you'll need to get something basic to playtest, then work on those systems first. I consider this question to not be a real question since there's no correct answer. I'm voting to close it. Good luck with your project. \$\endgroup\$
    – House
    Mar 5, 2013 at 14:03
  • \$\begingroup\$ This really is overly broad and smells a lot like a "how do I get started" question in fancy dress (no offense intended!) - likewise I don't believe that there's any possible correct answer here. \$\endgroup\$ Mar 5, 2013 at 21:19

3 Answers 3


As Byte56 said in the comment, whatever you choose to do first, goes first. There is no single rule that everyone should follow when it comes to developing a project. Different teams have different capabilities and needs. You might not have the available resources to do module A, but while you're working on getting the resources, you can do module B and save lots of time. If you build them properly, with a great enough degree of re-usability and independence, it won't be a problem at all.

Since we're pretty much in the same situation (right from the top, down to Unity 3D and Blender), I can tell you a few things. It might not do the job for you, even though it did for my team. And it would be best if you treated them as pieces of advice from someone else out there in the trenches.

  • Build a test level, not related to your actual game content, and work on different module prototypes & features here. See what works and what does not. Only include the things that work in your actual game. If you're not sure about a particular feature, keep on testing it in-between schedules even if the team moved on to other things. Knowing what NOT to add to your game is just as important as knowing what to add to it.
  • Concentrate on most of the player - environment interaction. Get the player's character to respond to the player's commands, and make sure he's able to interact with the world: pick up objects, examine objects, use objects, drop items etc. Unity's editor will help you a lot in this case: before you actually get to work with dynamic content, you can see how things go with static content, inserted via the editor. Basic dialogues go here too. While working on the dialogue system, the player can talk to a rock. It does not matter that much.
  • If you've got a specialized programmer in the area of AI, get him a list of all of the AI behavior you're expecting to have in the game. Then, ask him to prepare a list of algorithms and methods to solve the given problems. While you go on with the player-environment interaction, the AI can be prototyped on paper. Or, as a library, outside your game.
  • Leave the actual storyline and game content for later, when you've got at least a solid base built.
  • This might be obvious: DON'T waste time asking your 3D artists to do extremely good looking models, until you've got the solid base I've been talking about earlier. Use ugly (or somewhat good looking, heh) placeholders for everything. Those X hours you save this way can be used to get yourself and the team to concentrate on other, more important things. Like the solid base.

This is a rough outline to get you started. You're saying that your game is comprised at around 60% of puzzles. Perhaps while someone else is prototyping the AI and combat, you can get those puzzles to be doable in the test level? As an indie developer, this can offer you tremendous advantages: you get to show people a PLAYABLE game, even if comprised only of puzzles and some basic GUI. You can consider getting some financing (on-site donations or kickstarter) this way.

Short version to always keep in mind: split your game in lots of smaller games, or iterations. Every time you add something to the game, try to obtain a playable something from it. You've built some traps? Try to make a real world, puzzle-like level with traps, and see how well they work. You've built a system that combines items? Try to invent a few simple puzzles that require the combination of items, and see how it feels. These are both playable somethings. Or playable parts of your grand game. Furthermore, at any point during development, you'll be having a playable something to look forward to, and a playable something which you built a short while back, that shows your actual progress. It helps with staying focused and keeping the morale of the whole team high.

  • 2
    \$\begingroup\$ Good answer. But there is one thing I would like to add: Develop your components in an order which makes it easy to test them. An admin console with detailed log information and cheats should be the first things to implement, not tacked on later. It really saves development time when you can reproduce a gameplay situation which causes a bug in a minute than an hour. \$\endgroup\$
    – Philipp
    Mar 5, 2013 at 15:37
  • \$\begingroup\$ Ah yes, I should have mentioned that. It hurts my project a little bit that I did not start with an admin console to alter variables. No I have to patch things every so often. \$\endgroup\$
    – user15805
    Mar 5, 2013 at 17:48

I'd suggest focusing on things that allow the game to play tested early... and then continually prioritising on expanding out playable game elements from there.

This ensures effort isn't waisted on elements that are determined to be either not fun or not important to the fun.

A very common curse, especially amongst the enthusiastic, is to get side tracked on the detail rather than the pragmatic overall end effect. (e.g. grand game engine features, overly complex models / textures, rolling symphonies)

This doesn't mean that people can't contribute good design / architecture etc features that will never directly be experienced / noticed by the player... but it has to be as an iterative task in response to what gameplay testing has discovered.


To paraphrase Lewis Carroll:

"Begin at the beginning, go on till you come to the end, then stop."


Not the answer you're looking for? Browse other questions tagged .