I’m excited to announce that my first game, Edge of Chaos, is currently in beta! Making this game took far longer than I expected, and it taught me a lot about where my weak points are in regards to project management and productivity. I figured this post of reflections could be useful for someone who is also looking to learn a skill that requires deep work and focus.
Game Development Requires Being Good At A Lot of Things
I underestimated how challenging it would be to make a game that was effective at the level that I wanted it to be. There are some obvious skills needed to make the game such as these (or else paying someone):
- Art
- Music
- Writing
- Math
- Mapping
- Coding
But then there is the broad understanding of what’s needed to make a game fun and engaging. That requires skills such as these:
- Cinematography
- Sound Design
- Technical Writing
- Animation
While the math and coding parts came to me relatively easily, I was previously unaware of all the extra steps added in to make a video game really “pop” as opposed to feel static. It’s a very demanding discipline, but even to this day, I’m never bored in learning more about what makes a video game tick.
Scope Creep Kills Projects
I’m a person that has high ambitions. Sometimes, these ambitions lead to unrealistic expectations, or a lot of extra effort being put into a project for a feature that may ultimately be superfluous.
This is scope creep and has killed countless creative projects, especially video game development projects. Many modern video games take years worth of effort and require hundreds of people working on them. A solo indie game developer can’t hope to compete with a game development studio in regards to graphical fidelity or total features put into a game. It’s far better to make a game that’s focused on doing a couple of things very well instead.
With this project, however, I realized just how prone I was to letting the initial idea I had for a game get out of hand. Initially meant as a simple rescue mission plot, I decided to add in sidequests for each of the non-main characters. And of course, each needed their own unique feel related to them. And with adding sidequests, I wanted to add in player flexibility and let them impact the ending, so I had to come up with endings based on sidequest outcomes.
Those decisions alone took my game from needing a couple of months to make to just over a year. I’m happy with the outcome of those added features, but I completely underestimated the complexity that those design choices caused in my games. Learning this lesson on a starter project was essential, because if I wasn’t aware of this tendency of mine when I worked on my dream project, I would have become overwhelmed and likely burned out.
Organization Matters
I very much made this game by the seat of my pants. I wrote the dialogue as I went. I added features without second though because I thought they were convenient, like skippable cutscenes and character gibberish for the dialogue. I didn’t bother using a Game Design Document (GDD) and tried to remember what I was wanted to do a month or two ago.
Needless to say, this was inefficient. I ended up redoing multiple portions of my game as I learned more efficient methods for getting things done and wanted it to be “just right”. As much as I hate writing things down and planning things out, for a larger-scale game remembering everything in your head is outright impossible.
For my next game, I’m creating a Game Design Document to write down any and all thoughts that are game development related. I also will try and use a tool like JIRA to manage my workflow so I can understand what I need to work on a bit more clearly.
Accepting Good Enough
This was probably my biggest issue with making the game. I wanted to make sure my game was perfect, which is absolutely impossible for a novice game developer’s first game to be. Nobody starts out an expert. However, I felt myself wanting to constantly tinker with various parts of the game to make it improved, even when very few (if any) people beyond myself would appreciate the changes.
But I eventually decided that if I was at least 90% happy with the game, that was probably good enough. Most people are not game developers themselves and would not notice the flaws that I still see when I play the game, and the flaws were not game-breaking occurrences. And given that this was a game meant to help me learn the engine and subsequently released for free, there was less incentive to get the game to be 100% to my liking.
Conclusion
Overall, I’m content with how the game has turned out, and I learned about my current weak spots with managing large projects like this. I look forward to finishing the game and moving onto my next game project!