Due to some real life shenanigans, I need to focus my spare time on my web dev skills rather than just tinkering with my main game project. It’s unfortunate, but I’ve decided that I can combine my interest in making games with my web dev skills. So today I’m introducing a side project – Panic Spiral.
In Panic Spiral, the player is the owner of a bargain bucket spaceship. The ship is a bit of a mess – nothing really works properly, and it probably costs more to keep the ship running than it would to just buy a new one. Systems break down regularly and it’s the player’s job to fix them so the ship can keep going just that little bit longer. And maybe, just maybe, you’ll get home with the ship intact.
In this post, I’m going to talk mostly about the minimum viable product version of Panic Spiral. I have ideas for extra mechanics that would be fun to add, but the reality is that I need to have this project up and running as quickly as possible so I can show it to potential employers.
So let’s start with some technical considerations, that will feed into the game design considerations.
Tech stack
With Panic Spiral, I want to show off my existing skills, dust off some older skills, and take the opportunity to learn some new skills that are pertinent to my role. With that in mind, Panic Spiral is going to be a browser game which loads up game settings from a database. High scores will also be stored in the database and will be viewable on a leaderboard page.
If you’re not particularly interested in the technical jargon, you might want to skip the next section and jump straight to the Game Design section.
Website
I intend to build Panic Spiral using PixiJS. PixiJS is an open-source JavaScript library that uses WebGL technology to render 2D graphics on an HTML canvas. It’s an excellent library for creating games, animations and other interactive media projects. I’ve used it before in a professional capacity to turn incoming data from a football game into an animated pitch so that users could follow the game in real time.
The PixiJS app will be hosted in a NextJS React app. React is the primary framework I use in my current job, so I’m very familiar with how to structure a React app. NextJS, on the other hand, is something that I’ve wanted to try for a while, but haven’t had the opportunity to do so. I don’t think this project is truly going to take full advantage of NextJS, but I want to try it anyway.
Backend
Along with the website, I want to demonstrate that I have some skills at building the backend for a system. My skills here are rather rusty – I’ve been in a purely frontend job for over 5 years now. With that in mind, I’ve picked languages and frameworks that I’m relatively familiar with, if a bit outdated. I’m using C#, which was my main language when I was a full stack developer at previous jobs. I’ll use ASP.NET Core with a GraphQL endpoint to serve up game difficulty settings from a PostgreSQL database.
I’ve decided to keep the game information in a database and have the game web client request it because this will allow me to make changes to game balance and add in new difficulty settings, or other game options, without needing to change the game code. And not having to change the game code means that I don’t have to redeploy the code as often.
Devops – working practices and deployment strategy
I intend to use Git for version control. It’s use is widespread in the software development industry, and I already use it for everything else. I use it for my main game, although I’ve not specifically mentioned it. Since I’ll be putting the git repo on Github, I might have a go at configuring some Github actions for the project. That’s probably a future goal though.
To make sure that the game (and supporting API and database) can be easily deployed anywhere, I’m going to make sure that they are all Dockerised. Docker is another incredibly powerful tool that lets developers define the configuration for a virtual computer on which their software is then run. This means that it is significantly less likely that the software doesn’t run when deployed due to environmental differences.
Finally, I intend to run this site using Amazon Web Services (AWS). The main reason for this is that AWS is a big buzzword in the industry at the moment, so having some experience is good, even if I don’t care for it much myself.
Game design
So, what kind of game is Panic Spiral?
You’ve already read my quick introduction. The player owns a spaceship which is constantly falling apart and needs repairs to keep going.
The initial version of the game is going to focus entirely on that gameplay loop. The game will be split into 60-second rounds, during which one or more of the ship’s systems will break, with increasing frequency. The player will need to move around the interior of the ship to whichever system has broken. Once there, they will need to complete a short task to fix the broken system. The faster a system is fixed, the higher the score the player receives for fixing it. If there are systems broken at the end of the round, the game is over. This repeats, with breakdowns happening faster as the player advances through the rounds, until the player is overwhelmed and the ship breaks down for good, ending the game.
Let’s have a look at each part of that in a bit more detail.
60-second rounds
I’ve chosen to split the gameplay into short rounds for a few reasons:
- This allows me to introduce new systems to the player as the rounds go on. So round 1 will have one, maybe two systems. Round 2 will see another one introduced, and so on until all the systems are in play. This means that the player will get a chance to learn each system one at a time rather than just being thrown in the deep end.
- The intensity in each round can start off low, and ramp up throughout. As rounds progress, the intensity at the start should increase per round, but be less than the end of the previous round. This will help the player have some breathing room.
- The end of each round will give the player a natural break point. High intensity gameplay the whole time gets very tiring!
- Some of the future mechanics I have planned will kick in at the end of a round. Making rounds integral to the game will help me slot these mechanics in if and when I get around to them.
I’m not set on the round duration being 60 seconds. I might have it so that the first few rounds are shorter and increase the duration in later rounds. This is something that I expect I’ll need to tweak during playtesting.
Movement around the ship
Movement will be done using WASD or arrow keys, and interactions will be handled with E or the return key. I considered point and click movement, but I feel like letting the player directly control their character will fit the game better.
There are pros and cons of this approach.
Pros:
- I don’t have to implement a pathfinding algorithm. While I don’t think this would be hard since I already understand and have implemented the A* pathfinding algorithm in C#, it would mean I have to set up some sort of pathfinding grid
- Mistakes made trying to get to the right system are entirely on the player. This should help to add to the sense of being overwhelmed, which fits the theme of the game quite well
Cons:
- I have to set up collision shapes and make sure it’s properly handled so that the player doesn’t accidentally phase through a wall, or find their way outside the ship. There’s probably a library or function for this in PixiJS though, so I’m not too worried.
Multiple systems breaking down
Having multiple systems that break down allows me to do a few things:
- The player is forced to move around to each one rather than just sitting in one spot clicking on things
- With different systems there can be different effects when each one breaks. Maybe the player’s score doesn’t increase while the engine’s broken. If life support breaks, the player might need to fix it before the oxygen runs out.
I have a few ideas for systems and the effects when they break, but I’m not 100% settled on these yet:
- Engines – the player’s score doesn’t increase until the engines are fixed
- Life Support – the ship’s oxygen doesn’t replenish
- Hull – if the hull breaks, the oxygen levels on the ship rapidly decrease. Since oxygen is ever so slightly necessary for the player character, running out of oxygen will end the run
- Shield – while the shield is broken, hull breaches are more likely
- Reactor – if there’s a reactor malfunction, the player has to fix it quickly before it goes critical and explodes, ending the run
Score
The goal of the game, in its first iteration, will just be to survive as long as you can. Then, once the ship breaks apart, or the player dies from lack of oxygen, the final score will be displayed and can be entered onto the leaderboard.
The player can increase their score in two ways:
- The score increases by one point every second, except when the engines are broken
- When a system is repaired, the player will earn points based on how quickly they fixed the system
This version of the game will therefore be a bit arcade-esque. That’s fine for the first pass though, and it will mean I have an endless mode ready to go for any players who enjoy that sort of thing.
Parting words
While I’m not pleased that I’ve had to take this detour from my main project, I am actually quite excited to make Panic Spiral. My intention is to finish the minimum viable product in about a month. As a reminder, that version will have the following features:
- The game takes place on a ship which constantly breaks down
- The player must move around the ship to the site of each breakdown and repair it by completing a short task
- Gameplay is split into short rounds, during which the intensity ramps up
- The player’s score increases every second they survive, and additional points are earned for fixing the broken systems
- The game ends if the ship is broken at the end of a round, or if the player dies due to lack of oxygen, or a reactor meltdown
- When the game ends, the player can enter their score into the leaderboard
Once that’s done, I’ll share the link to the game and the github repo.
It’s not the dream game I truly want to be working on, but it will be a finished game that’s out in the big wide world. I’m going to make it something I can be proud of.