Negative Space - Thoughts and Development Process

Getting Started

Hello, and welcome to a brief post-mortem of the development of a game in 10 days!  Today we'll be going through a brief overview of the approach I took when developing Negative Space.  Without further ado, let's get started!

Development Process

The first thing on the agenda was to select a type of game to build.  Since this was the '90's, my first thought went back to games like R-Type and Gradius - side-scrolling shooters.  This got me thinking of some other top-down games like Asteroids - from a development standpoint, top-down felt a little easier to build.  Since the game jam didn't really enforce a theme beyond "throwback to 1990", it was time to dive in to some construction.

Where to Start?

First thing to do was to pick an engine.  Since this was going to be a 2-D game, I needed to find something that was focused on 2-D.  I originally started with a rendering library called two.js: I'm pretty familiar with three.js, and the way the rendering engine was used would likely end up being similar.  About a day into development, I stumbled across Phaser when looking for a particle engine that could work in a 2-D environment.  After some reading, I decided to switch to (and commit to) Phaser for this jam.

Next was to start the actual game development.  Since I was solo, I needed to split my time between sound, music, coding, and art.  For art, I used Pixel Studio on a battle-tested Galaxy Tab to put together prototype scenes (that weren't drawn terribly well but got the point across), with the intent to go through and polish them up with Gimp a little later.  For sound, I used the tried-and-true sfxr to build sound effects and the free application SunVox to build the music.  I've used both before and have zero complaints about how they work.

For the development itself, I elected to use VS Code.  It's my favorite editor, and served me well for development purposes here, too.  From a language standpoint, it has excellent support for web development and Javascript.  I used Vite for my frontend tooling.  Beyond that, all source is available on github for those who might be interested in looking through it.

Okay, but why Javascript?

I used to write in Javascript quite a bit, but hadn't used the language in a while.  Javascript was high-level enough that it would likely work easily for rapid game development, and it also allowed me to brush off some of the rust that comes with extended disuse.  Web games also tend to be most  accessible for game jam audiences to play.  Thus, Javascript won the language selection.

Not saying I haven't done rapid development work in C(++) before, only that A) it's hard and B) I'm lazy.

On Using Phaser

Since this is a post-mortem, it's worthwhile to spend a few minutes talking about my first experience with the Phaser 3 engine.  Generally, it was simple to work with as long as you were willing to use inspector to figure out what was going on.  Certain things were a little odd, like the inability to use simple polygons as physics objects.  This led me down the path of doing my own hit detection for projectiles and the like instead of using the arcade physics that came with the engine.  Matter.js would've been an option for better hitboxes, but felt like overkill for what I was trying to do here - there are only so many cycles, and I preferred to spend them on game processing and not physics.

Particles were especially powerful.  The engine's default particles do pretty well - they can slow down as they start to hit thousands (which, in certain situations, my game has that many projectiles on-screen at once).  If I spend more time developing the game, I think the major change I'd make is to use larger textures for the projectiles so that I can reduce the number of particles they emit, which would likely greatly improve performance on smaller devices (e.g. tablets and the like).

Speaking of which, I did actually test this game on a Samsung Galaxy Tab, and it worked surprisingly well ... up until the point where large numbers of projectiles showed up on screen, at which point it turned into lag city.  Thus, I think that fixing that is definitely a priority ... and avoiding making a similar mistake in the future is on the short list of lessons learned from this project.

On Development Moving Forward

One of the things I'm uncertain about is whether development on the game should continue.  I'd like to try some different genres and learn a little more about how to build games in those veins (e.g. simulation, strategy, that kind of thing), so I doubt much will happen with this game in the short term.  Still, it was a fun little shooter, so there's a chance I could pick it back up when I get frustrated with other projects and want to work on something with more immediate gratification attached.

Conclusion

I think that about wraps up my thoughts / process on developing this game.  In the event you've made it this far: thank you for reading, and see you next jam!