Alright…be warned…this is my super long essay on how to approach a gamedev project, large or small. It comes from my experience playing games, following development of games…and…well…coding one. I’ll have a far-less-long-winded TL;DR at the end, don’t worry.
The super-long-winded essay that took me almost an hour to write
Typically you want to come up with a base foundation and idea for your game. What are the rules? How hard do you want the game be for an average player? Will there be a story? (don’t write the story at this stage, just decide whether you want one or not.) etc. Once you get the base idea, write it down. Write all the ideas you have for the game down…no matter what they are. At this point you’re basically writing a game design document. This is where you start to define exactly how the game will work…how it’s played, etc. Then you have something to refer to when you want to add new features down the line. (So you don’t start accidentally losing focus on what your game’s all about).
Once you’re near satisfied with all your ideas, share the doc around with friends. Get feedback from them and adjust based on their feedback. At this point you do NOT want to let negative criticism get to you personally (I’ve fallen into that trap. Not fun.), because negative feedback will help make your game better for more players.
Decide based on the feedback you get what features should stay, what needs adjustment, and what needs removal. For example, if you’re making a first-person shooter and you decide wall running is a good idea and everyone else says that’ll completely break the game…you probably wanna think twice about adding it. (Heh, that’s a nice Call of Duty burn right there.)
After that stage, it’s time to start coding. Do not focus on artwork. Focus on functionality. It doesn’t matter if your buildings are simple cubes/rectangular prism meshes. It doesn’t matter if all your UI text is in Microsoft Sans Serif or Comic Sans. Just make your game playable. This is what a tech demo or prototype is. Doesn’t exactly look good, but it shows off the core gameplay. That’s what you want. It’s a lot easier to approach when you just focus on core gameplay. At this stage it is okay to use low-poly meshes, ugly textures, royalty free music/SFX, etc. These are temporary assets and you’re just using them to convey certain things to the player. If they know it’s an early prototype, temp assets won’t be a point of criticism.
Send that prototype out to a group of people for testing. (Hell, go ahead and slap it on itch.io as a prototype and slap that link in Showcase on here so we can all try it out :P). Much like the original idea for your game, you want to get feedback on this prototype build. Is it playable? Is it too hard? Are things unfair? etc. Take this feedback into consideration and adjust and refine your game as necessary. Then, you can release this new prototype build and repeat the process until you stop getting negative feedback and people start to really like playing your game.
This is what I’m doing with Peacenet Weekly Releases. Weekly protptype builds with early demos of different gameplay mechanics and each build improves on the last one based on feedback from here and on our own Community Site.
Once you’ve finished refining your prototype builds, now you can start focus on things like artwork, the storyline, etc. Start replacing your temp assets with better, higher-quality ones. But, do note, this is the Alpha development stage. It’s okay if things are still crusty around the edges. The Alpha stage is when your final game really starts to take shape. Look at Minecraft for example. Its early prototypes started out with Notch’s core ideas being implemented - being able to build, being able to destroy. Alpha was when a lot of the rest of the gameplay was implemented, world generation was refined, etc.
Just keep on collecting feedback on your alpha builds and refining them as well. You’ll want to keep doing this for every development stage.
Then once you’re satisfied, move to beta. This is where you start to really worry about your artwork and fixing as many issues with your game as possible. Most of your gameplay mechanics are in by now, you want to focus on patching things up as much as possible. The more stable your beta builds get, the closer you get to RC. Though, if players really want a new feature, this is still the perfect time to add it - because it’s okay if it’s a little buggy at the start. Later builds will fix it up. Beta is also a good time to start thinking about advertising and marketing your game to get as many players as possible.
Once you get to RC, kick it into high gear with patching, bugfixing, performance optimization, etc. RC stands for “Release Candidate”, effectively meaning “This build could very well become the final release.” So every single RC build needs to feel more and more like the final release.
Once you’ve exhausted basically all the issues on your bug tracker, you’ve got a final release. Celebrate with fanfare…because you just saw all your hard work come to fruition.
You have two choices at this stage… you can either start iteratively improving your game until you’re out of ideas and keep your game active as long as possible, or you can sit back, relax, get another idea for a game, and start this entire process all over again until you’ve released two awesome games.
TL;DR
- Come up with the base idea.
- Write it down.
- Write all your ideas down.
- Get feedback on your ideas.
- Refine your ideas based on feedback.
- Go back to step 4 until you’re satisfied.
- Code up a prototype.
- Release said prototype, get feedback, refine it
- Repeat step 7 and 8 until satisfied.
- Now do it for the alpha stage, while improving your artwork, storyline, etc
- Now do it for beta, while getting as many people on board as possible.
- Now start hammering down on those pesky bugs and performance issues for your RC builds.
- You’ve just released a full game.
- Go back to step 1 if you come up with another idea for a game. Or keep improving your current one. Or do both!
.
