In this game, you have to survive against hordes of creepy enemies using nothing but a shotgun-like weapon and the ability to spawn strange towers that fire projectiles. It was worked on from the period of October 11th 2023 to October 15th 2023.
You can play it for yourself here.
This post is a bit on the longer side as I had learned a lot of worthwhile knowledge to share from the first project. I imagine that future Game A Week projects would yield more technical insights, while productivity insights would be more refined, and so their posts would be shorter.
Some Background
This is the first game in the new routine I am doing called [Game A Week] which was inspired by the the following two blog posts: Making Small Games, Which Is Fun in Itself and Game A Week: Getting Experienced At Failure.
The format for the Game A Week blogs is inspired by the similar blogs by Adriel Wallick, which can be seen in a post like the one on the Week 39’s game
I used Phaser to develop the game. As Phaser is a framework, I had no fancy editor or anything to work with, but for the games I wanted to work on it was perfect for my workflow.
For this project, it gave me collision detection and some object pooling for free, but otherwise it can be still easy to lag your game up if you don’t understand basic computer science fundamentals regarding creating dynamic memory on the heap. I also appreciated the support for Bitmap Fonts.
What Went Well?
Set a good, small scope early on and executed it with reasonable planning.
I chose to make a game where you have to build towers to defend yourself from horde of enemies and in the end that was what I had made. The game has a beginning, middle and end, with a clear objective and gameplay loop.
Avoided perfectionism and focused on moving onto important features rather than getting stuck on early polish.
An example of this was that I had originally thought it would be pretty cool to have the overlay present arcade cabinet inspired art and more juicy HUD elements indicating your ability to fire and build.
In the end, I chose to prototype with a more simple yet still clean looking text instructions instead and ended up finding it ‘good enough’ to preserve my energy on more important features, such as balancing the gameplay.
I tracked my time and progress well
I had moved this section to its own dedicated blog post here, due to it becoming more detailed and enough to stand on its own.
It is a fairly verbose post that walks through the habits I employed to track my time, using this game as the test case.
I used simple unit tests to catch and fix really annoying bugs before they became real bugs
In game development, at least at my skill level as an undergraduate as of writing this post and working on internships and hobbyist projects, it is often neglected to create solid test cases for gameplay code.
The natural development loop of just testing the feature straight away in the game, along with the simplicity of some tasks, create a natural tendency to neglect unit testing as a tool.
This time, however, I was able to test the functionality of my tower placement systems using simple unit testing, which caught some major bugs and misunderstandings in how I was storing the data for what towers occupied what space on the grid. So I am pretty happy that I bothered to test and avoid potentially hours of less productive debugging.
What Could Have Been Better?
I should have reached the core gameplay loop earlier
As measured in time tracking, the biggest boost in motivation was near the end of the project on Saturday. This was because that was when the game was in its most playable state, with a ‘lose condition’ and a ‘win condition’.
I had neglected to reach this state of the game as early as I should have and instead started with conceptualizing the art and interface. It ended up okay for this project, but that workflow did not match the genre I was developing. The next few paragraphs will explain why.
Mechanical vs Experiential
As discussed in the GDC Talk, From Indie to Fable & Back Again: 30 Years of “Wisdom”(20:52), games that lie on the more ‘mechanical’ scale benefit from reaching a playtest prototype state as soon as possible, reserving polish and artistic features later in development.
In short, experiential games should focus more on the polish, visuals, juice and ‘feel’ upfront in development, as those elements carry the game experience. This is similar to the advice given by Adam Pype in “Getting lots of sleep (and making a game every month) at 5:12” which states to work on all the art and visual stuff first, working on a same project in sequence. This makes sense for his workflow, as he specializes in making short indie horror games, which is a very experiential genre.
In contrast, this means that mechanical games should reach a prototype with the gameplay loop as soon as possible, even if it using nothing but placeholder assets and Gray-box testing.
Earlier in the game’s development, I had misidentified this game to be more on the middle of this scale as I wanted a creepy vibe with the visuals. This meant that I had spent the first day and two working on scoping my color scheme, drawing the art and so on. This left the working on the balance of the game and the core gameplay loop later.
Through playtesting and understanding the genre better, however, I realize that this project was more mechanical than I thought. It would’ve gone much further with the same time commitment if I had prototype and playtest with some simple primitive shapes early on, and spent the last few days really polishing up the visuals and audio instead.
It would also allow me to choose more effective colors and visuals, along with relevant special effects and theming, that complimented the game better. The workflow for the art would also have been much more focused too.
I neglected practicing version control for art assets
While it was not a primary goal, I could have used this project to get more experience with the industry standard version control tool of Perforce for my art assets. This was more of a missed opportunity than anything, as I was focused on getting the work done. Luckily nothing happened that caused a loss in progress, but it was still playing with fire.
What have we learned that we can apply moving forward?
We got useful practice using Firefox’s profiling tools
I was able to get some milage learning how to profile my JavaScript code and successfully identify bugs causing huge performance lag spikes. The final version of the game, hence, does not lag and is using its object pooling and collision detection properly. I am happy about getting that experience, and can see more opportunities to practice it in the following weeks.
One of the main reasons I chose to work in Phaser was because I wanted the ability to optimize my performance for browser games directly, which included being able to profile them in the browser. I was not confident in a game engine’s ability to export WebGL games in a way that I could understand and profile, and rather not spend time researching that for my goals. I also wanted to practice profiling actual JavaScript code directly too.
I got to the point in my god class where I can do some meaningful refactoring
While prototyping the game, I chose to do as much of my code in a god class main function. This allowed very fast initial iteration that is easy to profile and optimize, allowing you to get to prototyping phases faster.
This main drawback, however, is that the technical debt comes in the form of really messy code later on that slowly becomes harder and harder to iterate upon.
Despite this, the mitigation is easy… once it gets to the point where the code gets more messy than it is worth, it is time to refactor. The game just finished at this point near the 4th day. Refactoring at this phase can be done incrementally and in small doses, but it is effective because you know ahead of time why the code is messy and what ways you can mitigate it.
For example, I can organically see that creating new audio sounds or HUD text for use in the game can benefit heavily from a factory class pattern, because I was repeating a lot of code all over the place just to add one of those elements. I know what kind of data I want to pass to such a factory, and what data can be serialized too, through a relevant use case.
Serialize our gameplay variables!
While prototyping, I had defined a lot of gameplay balance variables such as the rate of enemy spawn, health and so on inside the code. This was actually perfectly fine for this project, but it meant that I lose the ability to hot reload new variables when adjusting the balance.
For the next project, having these variables serialized from the start can allow a much more effective sessions balancing the game to be more fun as I could tweak these values in real time and save them to file. I would not have to speculate in advance the features as much.
This is a pretty basic advice, as the first chapter of the first and famous Game Programming Gems starts off on a chapter detailing to serialize as much of your data as possible. At the time this was written, this was to avoid compile times and complexity for a designer, but in the modern day this is still useful for tweaking variables.
It is actually a bit shocking that in modern game engines like Unity and Godot, this ability to tweak variables in real time and save them to a file is not given ‘for free’ to the designer.
Additional code still needs to be written in script files to save, load and apply the changes to every relevant game entity at runtime or at startup and save them to different configuration files in a format like JSON.
This means that, me working with a framework like Phaser or even XNA or SDL, and a developer working in Unity, both start from ‘zero’ in this regard for any new project and have to implement the ability to configure our gameplay relevant variables from a file in real time ourselves.
Additionally, I could also consider ways to display my JSON gameplay variables in a more interactive or visual way. I can look into whether there are third-party tools that can display some variables with sliders or even graphing the rate of change curves (useful for measuring stuff like how fast enemies should spawn).
Create debugging tools!
Similar to the above points, creating some debug tools that allow me to skip ahead game states to relevant sections or adjust visual elements in real time is critical.
This will allow me to be able to select enemies and adjust their size to be perfect, or adjust the placement of HUD elements to be aligned just right.
Create art to engine export tools and plugins. Automate our workflow more!
While working in Krita, there was a lot of manual overhead to cropping relevant images to the correct resolution and file format… and then moving them into the game’s asset folder… and naming them.
If I could automate this process effectively to be a ‘one click’ result, it can allow me to create a lot more assets in a focused workflow. I can create enemy sprites, tree sprites, bullet sprites and whatever else I can come up with and not have to worry about moving these files into the game folder as much.
The same mentality should also be considered for the automation of creating/editing sound effects using a tool like Audacity… or exporting updates of the game straight to a playable Itch.io page without having to click so many buttons or zip up files myself.
This is one hidden benefit for focusing on making completed, finished games and honestly one of the main reasons I underwent the project. Each project presents a ‘fresh blank slate’ for project organization, where we can try out the ideas we learned or tools we developed immediately to further optimize our workflow more and more without the burden of the past project.
This is one of the most neglected parts of the creative process, but one that I am very passionate about. Similar points have been mentioned in the GDC Talk Stress-Free Game Development: Powering Up Your Studio With DevOps.
Conclusion
Yeah the game was fun to make and I learned a lot from it. Thanks for reading this far, I hope that it was interesting to you and maybe even helpful.
Future posts would be very unlikely to be as long as this one, as I imagine a lot of these learning points would be reinforced again by the next games and hence not worth repeating.
I do think that my bias and focus on the project management or ‘producer’ side of making a game does show up in what I choose to write about. I don’t know if that makes me an odd duckling or not, as most creative types are more focused on technical skills rather than meta skills, but I am not ashamed of being more focused on the accountability and management side.
I also think it leads to more interesting content that is easier to learn from reading a post too. Technical skills like coding stuff, design stuff or art stuff really is more internalized from the application of fundamentals, milage and just doing it. More soft skills like project management, however, is more knowledge base and better studied from case studies like this. At least that is my thought.
There is also just so much content and tutorials out there for the coding, art and design side of game development anyways, but not as much for ‘but how do I actually get the thing done on time without wanting to die?’ It is also the most transferable skill to other industries career wise.
Leave a comment if you learned something or if you disagree. Not many people post here so I will read every single one.
Comments powered by Disqus.