Panic Spiral: Progress Demo #1

Posted on 2025-08-04

Before I jump into the demo, I want to remind you of the tech and game design goals I set myself when I started the project.

Game design:

  • The game is split into 60 second rounds
  • In each round, systems break down and the player has to go to fix them
  • The player moves around the ship using the W, A, S, D keys
  • There should be multiple systems which break down
  • The player should have a score counter which increases every second
  • Fixing a system should increase the player’s score
  • Different systems have different effects – some damage the ship if they’re not fixed, some damage the player, and some stop the player’s score increasing
  • If the ship or player runs out of health, the game is over

Tech design:

  • The game should be made in PixiJS, using NextJS to house the game
  • The site should be published using a cloud service (e.g. AWS)
  • The code should be stored on github, using git for version control

So… let’s see which of those goals I’ve hit so far.

The demo

In this video, we see:

  • The title screen, where the player chooses to start a game. There is music in the background and sound effects both when the player moves their mouse over the Start Game button and when they click it.
  • The start of the game – the screen changes to the ship where the player’s character is in the cockpit, and the background music changes to a different track.
  • After about 10 seconds the engine breaks! The exact time is randomly determined – the earliest it could happen at the moment is 5 seconds into the game. We hear a sound effect, the background stops scrolling, and the engine flame turns off. The engine room also lights up red, and the engine bar in the systems monitor UI turns red.
  • The player then moves to the back of the ship using the W, A, S, D keys. They have to go through the gaps in the walls since walking through walls is impossible.
  • Once the player is at the back of the ship and close to the engine, a popup appears to tell the player that they need to press “E” to fix the broken system.
  • The player presses the “E” button. There’s another sound effect and the engine is fixed! The room lighting returns to normal and the engine bar turns green. The engine flame appears and the background starts to move again.
  • Now the player starts to move back to the cockpit. Unfortunately, before they get too far, the engine breaks again, and they have to go and fix it once more.

And that’s where the demo ends!

Let’s look a little bit closer at each part.

Title screen

The main features of the title screen are:

  • The game title at the top – in red because that seemed thematic.
  • A ship moving up and down the screen with an animated engine flame – the movement helps the title screen feel a bit more alive. Without any movement, it looked a bit boring.
  • A “Start Game” button. When the user hovers over it, this is indicated by a red outline on the text.
  • Background music – a very calm ambient track for the title screen.
  • SFX on the button – I used something that sounded a bit techy for this as I want to add to the sci-fi ambiance.

The title screen is definitely complete enough for the minimum viable product (MVP) version of the game. There’s only one thing I really want to add, which is a settings button so the player can change the volume of the background music and sound effects.

Player movement and collisions

Player movement is done using the W, A, S and D keys. I expect most gamers are familiar with how to move a character using these keys. The W key moves the character up the screen, A to the left, S down the screen, and D to the right.

As you might notice from the video, when the player character hits a wall, they cannot move through it – the animation continues, but the player’s position doesn’t change.

If you’re interested in how these two mechanics were coded, you can read about the movement logic in this post, while the collision logic is covered here.

I think that a quiet footsteps sound effect would be a nice addition to the movement system, but it’s not essential.

Systems and interaction

There are several parts to systems. Firstly, there’s the system monitor UI component.

All systems good!
Uh oh, looks like the engine’s broken!

This UI component sits in the bottom left corner of the screen. It exists to help the player see at a glance exactly which systems are broken.

All systems are currently in good repair.
Looks like there’s a problem in the engine room!

The map itself also updates when a system breaks, and there’s a sound effect to go with it. The room containing the system gains a red lighting effect and the lights in the interaction zone go red. This should guide the player to the correct place to fix the broken system.

The player is told how to repair the broken system

Once the player has moved into the right place to interact with the broke system, they are prompted to press the interaction key to perform the repair. Pressing “E” at this point repairs the system and plays a sound effect to indicate that the player has interacted successfully. The UI and map reset themselves – the system is green on the monitor and the lighting changes back to its original colour.

There are quite a few things that need to be added to make the systems feature complete:

  • Currently the only system is the engine. I need to add the other systems.
  • The breakdown effect does nothing at the moment. This is because I’ve not added the score, or ship health, or player health.

And there are also some things that would be nice to have, even if they’re not essential:

  • Icons for the systems on both the monitor UI component and on the floor of each room.
  • Specific sprites for each system, as I am currently limited by using free asset packs from itch.io.

Technical goals

I’m not going to go into these too heavily. I’m just going to indicate whether or not they’ve been accomplished:

  • The game is made in PixiJS using the NextJS framework for the site. I’m not really leveraging NextJS much, but I’m not too concerned about that.
  • The code is stored on github, using git for version control. I’ve also been using Copilot for code reviews. It’s not the best reviewer, but it does catch simple mistakes and highlights some places for improvement. Overall, it’s been quite useful, even if I wouldn’t use it for anything I want to keep private
  • The game is not yet hosted on a cloud service. I want it to be playable before I host it anywhere.

Game completeness

Overall, I think the game is probably 35% complete.

Several of the basic mechanics are in place – starting a game, player movement, system breakdowns.

However, I still need to add:

  • Score
  • Splitting the game into 60s rounds
  • Multiple systems
  • System effects
  • Ship and player health
  • Game over detection
  • Volume settings

I also need to balance the game, determine if it’s actually fun to play, and then test it afterwards. Ideally I need to let other people test it too – it’s very easy, as a developer, to just test the “happy path” and not actually try to break the game.

I think I can probably reach a feature complete minimum viable product version of the game before the end of August. Whether that’s been properly balanced and play tested is another matter.

But it’s been fun so far. I feel like I’ve made a lot of progress and I’ve learned a lot about PixiJS in the process.

Next week, I’ll go into a technical deep dive of how the systems work and what features I’ve put in place to try and make it easy for other parts of the game to hook into, so check back next week for that!

If you like what you’ve seen, or have any thoughts on how the game’s progressing, please leave a comment here, or send me a message on Bluesky.