Game Design Process: how do you tackle game making?

So, you’ve finally settled for your overall game idea and plot. You’ve created your scope, and you know the general overview of how you want your game to go... my question is what do you do next?

I’ve dabbled in many projects over the years, but many have fallen by the wayside. I try to approach each project differently, but wanted to see what everyone’s process for designing a game was, and what people have found most successful!

My question is, how do you design a game? Do you craft the story out 100% before even touching the engine? Do you work in the database before doing anything else? Do you map everything first, and then fill in things as you go? Do you wing it?

I’m curious to see how everyone approaches things.

Personally, I like to have things out in a game design document, but the draw back is that I sometimes get bored of that, and end up jumping around between databasing, mapping, and in general procrastinating....

Either that or a new idea comes and I get enamored by that :)

I guess the best thing for me is to first draft the entire game - use placeholder maps to lay out the general locations and story. Then perfect it all as I go. I'd leave battles and balancing at the very end.

My successful approach thus far:
1. Hear about IGMC or some other contest that has a limited time frame.
2. Think of an idea.
3. Hammer away at it until submission.
4. Finish near the bottom.

My unsuccessful approach thus far:
1. Think of an idea.
2. Make plugins so I can actually make the game I want.
3. I'll let you know when I finish step 2.

My design process:

1. Create General Story, including Plot Points. Details can and will change later, but the Plot Points and overall story will rarely ever change.
2. Create Characters, their roles in combat, their roles in the story, and use them to fill in some of the Details of the story as well as of the World.
3. Create General Lore. This will have an impact on my Mechanics and the way my Story is told. Details can again be filled in or changed later.
4. Create Base Stats for Characters. Create Their Skills.
5. Create a "Debug Map". The purpose of this map is to test concepts, mechanics, enemies, and Events.
6. Create Elements in Database.
7. Create States in Database.
8. Create Terms in Database.
9. Create Items in Database.
10. Create Weapon/Armor/Equipment/Skill Types.
11. Create Base Weapons/Armor/Equipment.
12. Create Base Monsters for Testing.
13. Work in System Tab of Database.
14. Create Base Events that cover Mechanics so that they can be Copy+Pasted into maps later.
15. Write Dialogue and Opening Cutscenes.
16. Begin work on Opening Cutscene.
17. Begin Map Work.
18. Create Monsters/Equipment as needed.
19. Create Dungeons as necessary.
20. Create Monster Skills as necessary.

That second part seems like it’s my style as well :)

there is no definite sequence, and in most cases it's not a sequence at all.
you start with aspects of an idea, and when implementing it you usually have to get back to earlier steps again and again to add things you didn't know you needed before.

One thing should be handled earlier however: get your scripts and plugins in as early as possibel, because you can neither playtest nor balance with incomplete game mechanics.
It is always possible to add new enemies or quests later if you have all game mechanics, but if you change the game mechanics then you'll have to start playtesting and balancing from zero again.

and here is something else, still available for a few days before the bundles go offline:
https://www.humblebundle.com/books/puzzlecraft-books
https://www.humblebundle.com/books/program-your-own-games-books

As Andar said, you often go back to earlier steps to fill in the gaps. But if I had to do it, I would say that this is the order in which I create my games:

1) Design the battle (I always code my battle systems) alongside with the characters (since they go hand in hand with the battle system, each have their own role and fighting style).
2) Design other battle related systems (example skills and abilities).
3) Code other systems, such as a crafting system, minimap, quest system, custom menu, etc.
4) Create the story and the general geography (I draw a sketch of the world map as I create the story. It helps me follow the party's movement on the world map during the main storyline).
5) Design more specifically every locations (without mapping).
6) Create the lore of the game.
7) Mapping and eventing.
8) Create side quests.
9) Balance.

That's pretty much my step by step general game making process.

Hey Andar, you’re totally right. There is no definite sequence, and that’s why I kind wanted to see how others handled it.

Really nice share on those humble bundle links! I’m definitely going to be digging into those!

I have it down to a pretty good flow for myself at least. I would say you should also always try to mix it up. If you do too much of one thing you'll get burned out. I'm working on two projects now and some days I'll work on project 1's enemies, then the next day I'll do project 2's puzzles, then project 1's story, then project 2's story, etc. Keep it fresh! Take breaks! That's really important to keep on top of things because even if it seems like you have a solid schedule and roadmap set forth, it will crumble if you get burned out.

1. Get the idea for a gameplay mechanic or game design. For instance, I have a game that is all about stealth and backstabbing, one I'm making that is all about the world and how diverse and dynamic it is so you have a good time exploring it, and one that is a survival horror revolving around watching not your ammo/health, but your energy. This is something Nintendo does, they'll lock down a specific mechanic they want to use in a video game and build the rest of it around that. Splatoon is a great example of this because they knew they wanted there to be ink that was shot to cover a map, and the game for a while just featured white squares as characters. Then they thought, hm, what shoots ink? A squid! So they used squids as the characters. Shooting ink is kind of like graffiti, which is a punk thing to do, so they gave the game a punk aesthetic and soundtrack, mixing in the aquatic elements of the squids. You build upon the gameplay mechanic and things follow suit very nicely.

2. Write the characters. Even details about them that you wouldn't normally think would be necessary for a game. I have a template I got from my English teacher in high school that goes through everything. If anyone wants it, let me know. Eye color, likes, dislikes, career, strengths, weaknesses, clothing style, the whole caboodle. You want to know your characters as well as they know themselves so that you know what they would do in any situation and can further explore their character at any point. For my survival horror game, we wrote out what high school the main character went to and she's in her 30s when this game takes place. The high school was relatively small but produces some of the best students in the nation so that gives us some more insight into what kind of person she is. Think of everything you can for every character and what their place in the story will be.

3. Create the world your story will live in. Since you already know what type of game it will be, making the world will be a lot easier. Come up with the lore of the world, once again even if it won't be actually told in the game. You will come to know the world and know exactly how to formulate the story around it. If you have a rich world, it will feel much more natural for the players to be engrossed in. Along with this step comes creating dungeons and formulating in your head a sort of overarching rough draft for the story, a general idea of where it's going to go. I always create everything on grid paper first and then transpose it into the editor. It is much easier to edit with a pencil and paper than it is in RPG Maker or, god forbid, Unreal.

4. Write the story. Write it around the characters and the gameplay mechanic because it will feel MUCH more natural that way. The story will serve up the gameplay, which is the part of the game that keeps players actually playing, and the inner workings and relationships of the characters, which is the part of the game that keeps players intrigued and connected. You don't have to tell everything you wrote about in the characters' bios and don't feel like you have to. Most of that is for you to basically become the character for a bit, not necessarily for the PLAYER to know everything about them. Only put in what is relevant to the story at the time. People live for decades and decades, but a story in a game will usually only take up a few days/weeks. You can make it feel more natural by only focusing on the relevant info for that time. For instance, we have no idea what Joel from The Last of Us did as a career, how long he was married or what happened to his wife or if he even had a wife or just had Sarah out of wedlock, we don't even know how old he is. It isn't relevant to the story but it helps you as a developer get completely into the mindset of the character.

5. Now we start doing the engine stuff. Create your weapons, enemies, classes, spells, all of that good stuff. Get plugins you know you'll need because you've already formulated how you want the gameplay, characters, world, and story to be like. Then, you can start actually mapping out all of the areas you've drawn out. After that, put in all the events, the story, etc. into your game. Test play the hell out of it so you know it works. Have other people test play it and suggest changes and a critical eye, not just people you know but randoms at the coffee shop or on the internet (most likely here!).

6. Profit.

As far as actual assets go, music and artwork, you can theoretically get those started as soon as you want. I would start doing the art for characters when you have them completely written out at the earliest, and the music should preferably be saved for when you have all of your areas in the engine finalized because you can write the music to help aid the look of the area or moment in question. However, I did write the music for my game after I had drawn out the majority of the grids and had a pretty good idea of what the world was like. This works better if you are making the music instead of having someone else make it for you because you have the image in your head already. A hired musician having no idea what your area looks like or the situation in the game is not helpful and you'll get something that won't fit as well as you would hope.

Super informative! I’m glad people are sharing and engaging. It’s veen helpful to me so far.


I would be interested in seeing that character template if you can PM It to me :).

I take notes from what i want in my game before hand and then i begin a research about the choosen theme and how the gameplay must be.
Take more notes, start sketching the systems i need and then i choose one of them as the core system. With it in mind all the other systems must be built around the core one. This tells how the progression and other things works in the game. Things that do not work with the core system can be cut off, keeping them is simply luxury and will be a burden most of times.

For story, plot and characters things are more complicated for me. I do not work on this part, i let other people to it for me, this doesn't mean i don't give ideas, hints or even ask about them or demand one or two features. If i don't know how the characters are, how the setting and the plot general idea are i won't be able to translate those characters into the gameplay. Narrative plays a part on gameplay as well and this is undeniable.

All of this is done on "paper", never during the development. You have no time to waste with testing features during mid development and the same can be said from narrative, you don't have time to rebuild the game from scratch because you decided to change the entire plot. Doing this on paper is important to save time, to document and to help you to not rely on your memory. In case you loose your entire project you'll be able to rebuild it from scratch because of this documentation.

The truth is that gameplay features changes overtime, but most of the time you'll stick with what has been decided on paper and test a few before the development begins and many things will be cut as well. Do not be ashamed if it takes you almost 2 years before the real development begins because of gameplay features.

My unsuccessful approach so far.
1. Create a game design. A whole game design including all the formula and all the world building.
2. Create story plot based on it
3. ????
4. Realized all the whole game design were fall apart because time wasted writing all the formula and it didn't fit well in game.

My successful approach so far based on my complete game.
1. Draft the game, up to the point how the game meant to be played. Ignore the detail. You're going to give detail them during the game making process.
2. Known your limit. You can't make x, so don't make it (in my case, I ignored the story).
3. Create actor/skill database first. You'll play the game with those actor, so actor is the first database priority to determine how the game is played
4. Make a random guess on exp/skill learn per level.
5. Make the first stage map.
6. Make the first stage enemies.
7. Test the balance, and see if it is what you have envisioned.
8. If the first stage done, launch demo, or throw it to your betatester. See what are their comments. So you can change something before it's too late.
9. If first stage done, draw the entire stages. Using placeholder is fine.
10. Test the balance, and see if it is what you have envisioned.
11. Release the second demo. Test if the extra stages worked well.
12. Throw it again to your betatester with the same reason. Listen to them if they have something to say.
13. Finishing the game, and there you have it. The core of the game is done.
14. Polish the game even though your game is already completed while waiting for the player's feedback. Eventually replacing placeholders, adding more QoL, and rebalance based on player's feedback.

My next attempt to create my next game, let's see how this turns out to be
1. Create story draft from start to end. Create world building if it's necessary, or if I'm stuck and need a plot device to advance.
2. Draft the dialogue for each scene. It doesn't necessary to be the final dialogue. Change may happen, but it's for guidance.
3. Add every steps from my previous successful approach
4. ????
5. I'll let you know if I could finish my game with this approach.

Let's see!

1. Initial/general story spark--it often (but not always) includes the protagonist and antagonist.
2. Come up with basic world lore to flesh out #1.
   
3. Decide on what sort of gameplay is appropriate for #1 and #2.
   
4. Many things in no particular order* (see below for more details)
5. Fine tune and expand everything created during step 4. Make it prettier.
   
6. Add some weapons, armor, items, etc. Sprinkle shops, treasure chests, etc as necessary
   
7. Balance out items, add enemies, and work with the numbers in general
8. Play through it to make sure parts aren't boring, unbalanced, broken, or just plain lame. Fix as required
   
9. Find someone with enough patience to test it out for me if I plan on sharing it with the world. For personal projects, just call it good and move on.
   
10. Publish, yay!

Regarding #4, I tend to jump around a bit. It's typically a mix of:

• Draft out the story flow in a text file. This is usually just a piece at a time, so that (generic) map creation stays caught up with it.
  
• Create basic maps, including overworld if I decide to use one. And when I say basic, I mean square, empty maps with only the NPCs, transfer events, and equally-generic buildings (if necessary) required to advance the story. NPC dialog is limited to "hi, I'm going to join you/fight you/let you pass if you bring me 12 bear asses!"
  
• Create additional plot-important characters. If a character I created came out of the blue, I try to work them into the plot somehow. Otherwise, they were created because the current area/plot portion I'm working on seemed like a good place to add another character.
• Create character abilities on paper (well, text file) before importing them into the editor. This includes creating scripts for more complex abilities.

This is exactly it! It's a post I could've written! However, I will say this: You can always test new ideas on old backups. Just make sure they ARE old backups! Sometimes you can get a new game out of it. That's the only difference!

1. Write out the idea for the game, and as much story as possible. Be open to change as you implement it.
2. Start making the game. Pick an easy to implement point. It does not have to be the beginning. In fact, in my game I started about 30 minutes into the game when I first started, then went back and added the beginning and intro later as it fleshed itself out in development.
3. Once you have an hour or so, post a demo for feedback. I feel this is critical as it is not too early to change core ideas at this point in the process if it is not working.
4. Make the rest of the game. Don't be afraid to do placeholder areas or zones here, but the important thing is to get the story implemented so you can see it all together.
5. Implement any placeholder zones for real.
6. Add final graphics and sound to the game.
7. Balance.
8. Playtest until you can't playtest anymore, then playtest 3 - 5 more complete run-throughs.

Here's how I usually go

1) Make a draft of the general idea of the game
2) Think about what systems I NEED
3) Create those systems
4) Start making the intro
5) Do database stuff that needs to be there at the start
6) Continue working on the story while doing additional database stuff as needed

And lots of playtesting and bug fixing during each part

My method is to first after acquiring a general story idea or a general character concept is to want to know where I'm going with the story of the game; I want to know how it ends before I begin and what type of characters my main characters would need to run into to meet their goals or advance their motives in the world. I'm not 100 percent with storytelling always; I don't know every little detail but I know where I want it to go and who I want in it. If anything its usual the middle of my story I'm unsure of the most when I start and flesh out in concept as I make the game.

As far as actually making, I found I work best making things in the exact order it needs to be done (for the most part), I don't touch aspects I don't need to implement yet; I don't go and map areas that aren't relevant yet, etc...(its just what works for me, I know others can do fine jumping around). I usually do something like Map, event, add artwork if necessary, implement battle aspects, playtest, balance tweaks (then repeat playtest until happy) then move on to the next area or map and repeat. Occasionally there is a moment in between steps where I might go look for a new resource or something like a song or etc...

After I'm happy with the game and feel its done; then I do self playtest runs multiple times and look for common errors I might have overlooked. With my last game I also looked for testers and felt that was a good addition to the process and helped find new flaws to adjust. Then I ran some more of my own playtests again til I felt like it was the game I wanted to make.

I just ride the Chaos! I'm kidding or am I? Even I'm not sure...

Besides @Frogboy 's 1st method, don't always finish at the bottom though.B)

This is what I did for my last game/demo

1. General, loose idea. For instance, I want to make a space sci fi horror game.

2. Study. Read a few tips on writing in that genre. Read some tropes of similar creative works. Watch movies of same genre. Maybe even read some Wikipedia and articles about specific things that could be incorporated. I.e. Watching ALL of the alien movies and playthoughs of Alien Isolation. Heading over to tropes to see what people expect from a horror game. Read creative writing articles about good horror.

3. Inventory. I go through the assets that I do have and what's available and make sure it's feasible. I personally love PV Games Assets and already own just about everything out so far and make some test characters, maps, recoloring, whatever, until I think I can pull something off.

4. Prototype. The last one bleeds into this one. I start a new project in the maker and play around with game mechanics, plugins, what nots. So far my track record is not good for getting past this part.

5. Storyboard. So at this point the Game is starting to take shape and the story is trying to write itself and I find that I have no idea where I'm really going with it. So I start making rough outlines notes lore yada yada yada.

6. Hammer on the game. I database as I go and it's a horrible idea too because now stuck trying to make or find icons too. I love mapping though but 1 map could take me most of a days worth of development time.

7. Release demo at a good 1-2 hours of game play. Write down notes from feedback bug reports all that "dev" stuff.

8. Check the Ego. Get over myself and throw stuff out change things add stuff revisit the storyboard. Try to change some stuff graphically and get over my head.

9. Seista. Take a break, tinker around with small projects. I Don't know why but it helps me try out some mechanics or visit a side of writing that's different. Like most things, the more you do it, the better you get at it.

10. Finish the game???