So, I forgot this past week was a holiday until literally the day before Thanksgiving. As a result, I wasn’t able to spend nearly as much time building, testing, and refining; instead, that time was spent visiting family and eating way too much food. But as I did make a non-zero amount of progress, here’s where I stand leading into the final week before my self-imposed one month deadline.
Catching up
This project started when I decided to spend November making a game. The game would be a first-person shooter in the style of the 90’s classics Doom and Quake, for a handful of reasons. Check out November 1st’s article for more details on these decisions, and my initial thoughts on the project’s direction. One week of progress determined that building everything around a central rhythm beating in time with the background music was a feasible approach, though doing so certainly brought its own challenges. For more details on how we got there, give November 8th’s article a glance. The next step was to figure out what I wanted to include in the game, begin the process of programming everything so that I could test it, and eventually, invite others to test it. For more details on what I wanted to include and why, take a minute to read November 15th’s article. From there, I took everything I had created and used it to build a rough draft of a level, more details about which can be found in November 22nd’s article. Which brings us to today.
Tweaking the Map
My early playtesting of the level revealed a few flaws in my initial level layout. Since I’m restricting the amount of time the player is able to spend in the level via song length, I need to be mindful of how much I require the player to do in a given area. The high ground for the second main combat encounter presented a problem in this regard; the space was too large once the enemies were defeated, forcing the player to use valuable time to traverse too much empty terrain. I will need to keep this particular problem in mind as I continue moving forward with playtests, level refinement, and encounter creation.
Additionally, I began adding health and armor pickups to the level. These provide opportunities for the player to recover from mistakes made during the combat and/or give them the resources necessary to survive longer combat encounters. I’m providing these resources as rewards for the player exploring the map and discovering secret areas. This should encourage players to play through the level multiple times, discovering more of the secrets scattered throughout; however, this could also become a source of frustration if players regularly run out of time because of their dedication to discovering these secret areas. The only way to find out which of these scenarios rings truer is to have other people playtest the level, which is something I hope to do soon!
Adding Menus
As is the case with the overwhelming majority of games currently available, players don’t launch immediately into gameplay after opening the game. A player’s first stop is generally at the main menu, where they are given the opportunity to adjust settings, manage saved games, and manage a plethora of other options. This main menu is also an early opportunity to begin introducing the player to the game’s world, thematics, and what kind of experience the game is hoping to provide.
With the limited time I have remaining, my main focus this past week was just getting a functional menu working. This meant implementing:
A play button that launches the player into the (for the time being) only level.
A settings menu that allows the player to adjust the difficulty and volume (the latter of which I’m still working on).
A controls menu that shows the player the various buttons used to play the game, and eventually, change those controls to suit their personal preferences.
A quit button so that the player isn’t forced to use alt+f4 to quit the game.
I also successfully incorporated most of these elements into a pause menu, so that the player can check the controls or quit the game at any point during gameplay. However, adding this came with several unexpected hiccups. My first attempt at pausing the game while this menu was open successfully paused most of the gameplay while the level’s song continued playing in the background. Since I'm planning on implementing some sort of fail state once the song ends if the player is still in the level, this defeats the purpose of having a pause screen. Once I fixed this, I discovered that pausing and unpausing the game caused the events of the game to frequently desync with the downbeats of the song - a disastrous outcome for a game built around everything happening in time with the music. After a lot of pulling my hair out and discussing the problem with whatever inanimate object was in earshot, I finally isolated the issue. Unpausing the game exposed a flaw in the logic I was using to differentiate between the downbeats and the eighth notes, so that every time the game was unpaused, the game confused the two. Updating that logic to something a little more robust finally fixed the issue, and left me with a functional pause menu - a task that I had initially assumed would be a much simpler affair.
And that’s where things stand moving into the final week of development. This last week is certainly going to be a busy one, and I have a lot of turkey and stuffing to work off. In the meantime, I’ll see you next week with a playable demo (I really, really hope)!
-Mark