Moving from Proof of Concept to Prototype

Another week, another blog post! Definitely didn’t miss a post last week. Certainly not.

In all seriousness, I realized very shortly after posting that 2 weeks ago that I was absolutely going to miss the next one as the following Sunday, October 6th, was my sister’s wedding! It was a great time, but that plus my tendencies to stress about things lead to that whole week being relatively unproductive for me, so I decided to hold off on making post until this week.

The main thing I’d like to talk about this week is where I’m currently at with the second game I talked about in my last post; the game I’m currently calling Maintenance Crew. Right now, this game resides in an Unreal Engine 5.2.1 project on my PC titled “SpaceMining”. I made this project as a sort of staging ground to mess around with the proximity voice chat plugin I had just bought and I named it after a very vague idea I had in my head for a game to make with it. That game has pretty much been entirely scrapped or repurposed for Maintenance Crew at this point, so the project name doesn’t really fit anymore. On top of that, this project file has several folders and assets in it that are vestigial of that original, unplanned idea. Finally, the dungeon generator I made (that was based on/inspired by this tutorial, if you’re curious) has several parts about it that I’d like to rework. Obviously since the original implementation came from a tutorial, it’s not exactly suited toward my game specifically, and as I’ve started to dive into the specifics of what this game would be, I’ve started to narrow down the kinds of requirements the generator needs to have in order to work for my game. Ultimately, these factors all combined has lead me to decide to create a new project file with this game in mind from the beginning so that everything can be built to work for it. Now, lets get into some more of the specifics of that, shall we?

First things first, I’ve had a (small) change of heart in terms of the game being infinite. I think that the game should have some kind of main objective that the players are working toward. Having an objective, even if they don’t learn about it until half way through the run, really helps drive players to keep pushing. I can foresee a problem with the game as it stands right now where the players play a few rounds, maybe push a little deeper, but then eventually stop, deciding they’ve seen everything the game has to offer. Having a main objective can allow me to hook the players in once I’ve got their attention. That said, the theming of the game, also allows for the game to have a sort of post-game to it. Lets say once the player finishes this main objective, they’re allowed to keep diving deeper and deeper into the facility to go for a “high score”. This creates a very useful divide for me as a developer. The main problem I’ve been wrestling with in my head is how the generation of the dungeon and the objectives you encounter would scale infinitely. This solution lets me slap a big warning sign on this post-game content, explaining that it’s very experimental and probably not balanced. Additionally, it lets me set realistic goals for myself. The prospect of having a game go infinite is really daunting, especially when you’ve never developed a full game from start to finish before, let alone an infinite one. Having a set number of floors to tackle is a much more approachable goal. I think the best example of such a philosophy in my brain comes from Bloons Tower Defense, specifically Bloons Tower Defense 6. In that game, the normal game modes will only take you to round 100 in order to win, and the rounds are only hand crafted up to round 140 (with a handful of others sprinkled in at notable numbers). Outside of those rounds, the rest are randomly generated and the player will eventually lose just by merit of how the numbers work out. That said, this works because everything at this point in the game is an extra challenge after you’ve already won. This makes it really easy for me to either further segment my work into chunks or extend it down the line.

With all of that out of the way, I’d like to paint a picture for you of what this game is, in a little more detail than the short couple-sentence pitch that was in my last post, presented as a sort of narrative primer.

You’ve just been hired on as a maintenance worker for a company that deals with containing the anomalous, the unexplained, and the eldritch. While this company operates dozens if not hundreds of facilities world-wide, you’ve been assigned to the division that works with worst one — damage control. Several years back, one of the facilities operated by this company had a site-wide catastrophe that rendered the site unusable. However, the nature of this incident is an ongoing problem. If left alone, the problem would spiral out of control. The company can’t be bothered to make a more sincere effort to fix the problem permanently, so they created damage control to keep putting bandages on it either until one of those crews manages to fix the problem by chance or they run out of people on the planet. Crews of maintenance workers go into that facility and never come back, and if they do somehow return, it’s always without a pulse. The worst part is due to its nature, the facility in question is highly classified — the victims of damage control hardly realize they’re preparing to participate in a silent genocide — once you go in, they don’t expect or want you to come back.

As you might be able to tell, this game is heavily inspired by games like Lethal Company, Content Warning, GTFO, Iron Lung, and the SCP community. Now, lets move on to some general gameplay loop. In the game, the elevator is your home. Every floor begins with you exiting the elevator and ends with you returning to it (or dying trying). The first floor you reach is relatively small (though still maze-like) and has an objective (or multiple, at deeper floors) for you to complete. As you delve deeper, you’ll find the floors are getting larger and are in greater disrepair, influenced by the anomalies the facility once intended to contain. In a theoretical “complete” version of the game, eventually your crew would be able to contain whatever it is that’s keeping this facility so dangerous and put an end to the damage control division entirely, though in my prototype version I’ll probably be targeting some earlier milestone in the players’ journey and giving myself room to add more story as development progresses.

Now that we know how we win, lets talk about how we lose. Obviously in a game like this, it’s very possible and even likely that you’ll die. Not to worry, death isn’t the end — not unless you all die. If all players are dead at once, the game ends and the players lose. That said, the players have 1 inherent tool to combat this: emergency departure charges. The elevator has a special device built into it that, upon activation, will take itself and any alive player inside to safety. Functionally, this restarts the particular floor the players use it on. So, for example, if used on floor 14, the dungeon generator would generate a new floor 14 for the next level instead of a floor 15. The players would start with 3 of these, giving them a chance to save a run by pulling the lever. That said, someone still has to pull the lever, so if everyone dies before pulling it, the run is over, even if they still have charges left. Assuming at least 1 person survives the floor, all dead players will respawn in the elevator for the next floor (reinforcements from the surface).

Over the course of the game, the players will also receive “money” from the company. They can spend this in the elevator’s built in company shop to purchase tools and other items that will help them more efficiently and safely carry out their tasks. The players might also find certain items or other helpful discoveries throughout the facility itself. Also in their explorations, they’ll stumble upon monsters that have breached their containment, hazards & traps, and other anomalous dangers.

As you can see, a lot of real thought has been put into this concept recently as I gear up to create a new project file. Admittedly a lot of this was already planned when I wrote the last blog post, but I think writing it down here is a good way to start this next step of the project. In terms of actual, tangible work I’ve done this week, the main thing I’ve been doing is making a gameplay loop flow chart to better organize my understanding of what needs to happen for this game to function correctly. As you can imagine, this game simply being multiplayer can sometimes take up the majority of my brain’s problem solving capability, so writing down exactly how the game needs to work before I have to dive into networking can really help to keep me on track. Next week, I hope to be able to show off the completed version of that flow chart as well as maybe the first steps of the new project file as I work to re-establish some of the systems I have in the current project file!