Game design steps

I am starting a new game project. It will be a post-apocalypse, open-world adventure game. I was thinking the general look and feel of Fallout, the low-res and low-poly graphics of Borderlands (maybe even more low-poly), and focus most of the game on player-choice, customization, and lots of options.

The last game I made (an offroad vehicle game) didn’t go so well, and I think it was because I didn’t make it in steps or in any structured way.

What would be the steps for making a game like this?

Should I make all the models first, then piece everything together with programming?
Or maybe make placeholders, focus on programming, and then put the final models in place?

How I think it should be done:

  1. Plan it on paper (or word processor/paint etc.); work out how you want the game to play, how you want it to feel, the story, the theme, the objective, the genre etc.
  2. Make the draft base for the game. The base includes the player controller, any AI, dialogue systems, inventory systems etc. Always work a game around its game play, or else it will just be an interactive artwork (which works, mind you, however that isn’t the intention of a game)
  3. Polish up the base. Your meshes will likely still be cubes at this stage.
  4. Do concept art to finalize a style. You don’t want half of your assets looking like fallout and the other half looking like my little pony.
  5. Model and texture assets/maps
  6. Animate any rigs
  7. Work on what the assets are supposed to do (Do they speak? Are they supposed to move like foliage? etc.)
  8. Visual effects (particle effects, graphics etc.)
  9. Repeat 5-8 and alter the base of the game if needed to fit the assets’ needs.
  10. Polish and keep polishing!

MrPutuLips is pretty spot on, I usually block out my levels with basic meshes to see how it flows before getting into the heavy modelling.

However, there are many way to do a same thing! My experience is not exactly an example to give. But I can say that I’m getting close to my objective!

1. Game idea developement
You need to have a clear vision and mission your game.

What should it look like, and why. The game style must be an complement of the game play. Gameplay should allow the player to reach the game goals in challenging and funny way.

The mission of a game is mostly to entertain. But if you add a bit of education, you mission will be much important.
Details of how you are going to make your mission happen will distinguish your game for the others. For the way you play the game, is what makes it fun! Remember that the human brain gets used to tasks and environments very quickly, so, the game needs to stimulate the brain very often, not just with increasingly interesting environments, but evolving way of doing a task (upgrades).
While preparing your mission, you can think of all systems you’ll use in the game.

2. Game systems planning
At this point, you make an assessment of your tools and skills. Can you write your own code? Are you going to use logic bricks only? Is it possible to do any of what I planned with my current assets (tools, skills)? Can someone code for you?
What about models, textures, animation, level design, FX design, sound, documentation, UI, etc?

In my case, I started with logic bricks, but soon it became clear that they were too limited. So, I saw the need to learn python. And now, even though I think I can write any conceivable system, I can come up with, I still am getting experience in ways of doing them. Just to say, it’s not enough to learn how to code, you need experience too!

Core systems:
The main activities performed in the game, make your core systems.
You can test them individually and then in combination. Your programming style will determine how easily and/or seamless they can integrate and work together in your game.

Think about runtime for each system. How often they run? Do they run in parallel with other systems? How much processing time do they take ? Can you centralize data? Will threads be required? Can you polish the code, in order to simplify it?

Make a timeline diagram, with all your core systems, for a game loop(you can use diferent colors for each system, and use a squared lines paper for the timeline). Mark at what time will a system intervene and why (what will it be doing and why?).

Your core systems can be:
Player controls, player/world interaction, world generation, AI, UI, Mission/scores controller.
some can just run once every so often (world generation), others will need to be running all the time (interaction, scores).

Auxiliary system:
They are important as well, but they normally just help the game look and feel better
They may be:
Music, FX (particles, font work, sounds, etc), game menus, documentation, etc

3. Building the game

For me, when you start drawing concept art, you are already building the game. Sketching will help you give life to the vision you have of your game.

  • Preparing: Create your work environment. A physical place where you can work seriously without distractions , where you can hang your best artwork, and diagrams (if you lack that space, use your desktop background, or just a folder). A logical place, a folder with your project. Add folders for documentation (inspiration docs, your notes and logs), textures, sound, assets. I normally compile the game from the start and link my blend game to the compiled one. A to-do list is also a good idea.
  • Programming: I wont type here what should be done, but what I do: I create all the necessary files. Then fill them with commentaries(documentation). That works like function place holders, and if there’s a lot of coding to do, I’ll remember what function does what and where I can put it. then I put the functions headers, with nothing in them. As long as all functions are defined, I can test all others that relie on them without getting a non existance error. As soon as I start writting a function and I call for others, I write them afterwards.
  • Testing: Once your systems are in place, you’ll thoroughly test your game (often with placeholders such as cubes,and shadeless materials).
  • Cleanup : Polish your system accordigly,
  • Implement assets: You may now add your models and animate them.
  • Back to testing and implementing (Sound, FX, artwork, extra code.

4. Finalizing, and publishing your game

Avoid exposing your game excessively before is ready. You can show your progress in the forum, but when it comes to advertising, make sure you are not hasty. Secure you download links, show footage of your game in action. Don’t label your game “Ultra awesome” just because you think so. Let your game take a life of its own.

Keep improving the game. If people and you play, try to remove any bugs that may infest your game.

OK that’s it, sorry for the wall of words. I hope it helps!

Sounds like a pretty feature rich game and yet something you haven’t perhaps planned in great detail yet. To make such game you should know the game engine well, so make sure you have a faint idea on how your asset creation pipelines are going to be and how to implement the features or rather, what they mean in terms of amount of work. Without the knowledge is hard to scale a project properly and consider what is actually feasible.

If you’re doing it the proper file structure from the start (if you aren’t making a proof of concept type of sketch first) is vital for open world game. You can’t put everything in one .blend file, it’s going to involve a lot of linking and libloading with their quirks and you have to know python when it’s necessary but also when to rely on logic bricks for speed.

Like I said, need good expertise on the tools involved.

Also, although it’s important to ask opinions, it’s a good idea to start small. A smaller version of your game, with everything happening in a room can give you an idea of how much work it actually is.
And yes, link various blends to a core one. Each may contain a specific type of asset, for easy editing!

+1000 to this. Start off with a basic prototype, maybe a minigame version of your final product. If you can do that and finish it, then you can move on to making the final product. All games start out like this – even with AAA developers; they need a “pilot” to raise funding and approval for their game.