One of my favorite game jams is the legendary Js13kGames competition, where participants have one month to make a web browser game that fits in a 13 kilobyte zip file. To put that into perspective, a floppy disk from the before times could hold 1.44 MB, enough to fit over 100 JS13K games!
In 2021 the contest celebrated its 10th annual event. The theme was “Space” and there were an impressive 223 games submitted. It was my third year participating in the contest. That was a few years ago and I am back now to share with you the story of how my entry was made. Better late then never!
My game, “Space Huggers” is a run and gun roguelike platformer with procedurally generated environments and a pixel art style. I was inspired by games like Broforce, Metal Slug, and Contra. The engine was written from scratch in pure JavaScript and has since been open sourced under the name LittleJS. It’s a great little engine with many nice features packed into a tiny footprint with clean well documented code.
In this post I will explain how my game works and the design process I went through while developing it. We will not go into detail about the code here, but it’s all available on GitHub for you to check out. Also, there is now an improved version on Newgrounds with some bonus features like medals, a final boss fight, and even support for mobile devices.
Making Tiny Games
For several years I’ve been studying the strange art of writing tiny programs. Back in 2019, after a long career in mainstream games, I found myself somewhat burnt out from working with giant code bases. I wanted to get back to basics and try something radically different. So on a whim I decided to make a tiny ski game in C++ and found it to be one of the most fun experiences of my career.
Thirsty for more I stumbled across the JS1k competition which happened to already be in progress. I knew immediately that I needed to participate, so learned JavaScript on the fly. After 2 weeks and a few all-nighters, I submitted 6 demos to the contest. It was clear, I was hooked on writing tiny code!
Over the next the few years I honed my JavaScript skills by making games, tools, art, and other experiments. On a website called Dwitter I released over a thousand tiny programs that push the boundaries of a 140 character limitation. I also released a few longform generative art projects using only vanilla JavaScript. All this was drastically different from what I had been doing for the past 20 years while programming in C++ at major game studios, but it fees like I finally discovered my true calling.
Enter JS13K
In subsequent years I’ve entered JS13K several times. The first time I received 2nd place with a Bounce Back, my Link’s Awakening homage, which also has a lengthy writeup. The next year NoteCraft, my cellular automata music creator, won both the Audio and Innovation categories. That same year I released OS13k, a tiny JavaScript operating system that won the Super Special award given by the organizer of the contest. I open sourced OS13k on GitHub and have continuing adding apps to it. My most recent entry to JS13k was in 2022 when I submitted Egg Time Rewind.
This time I wanted to take things to the next level, by building a new game engine suitable for high quality low size games. There are already some tools of this sort available, like Kontra and Tiny-Canvas, but none with extensive feature set I required. So when the contest started on August 13th, my first step was to make the engine before I could begin working on a game.
Building The Engine
This primary goal of this engine is to be as small as possible while delivering the most powerful features. Using what I learned from making Bounce Back, I reworked everything to create even tighter and cleaner code. I eventually released the engine on GitHub as LittleJS with an open source license and still continue to improve it.
At its core, the engine uses an object oriented architecture that’s easy to build games with. For graphics it uses WebGL to render a massive amount of sprites at 60 FPS. The audio system uses ZzFX to procedurally create stereo sound effects. The input system handles keyboard, mouse, touch, and analog gamepads. I even wrote a small 2D physics system and collision solver.
I have talked a lot about LittleJS before so we won’t go into details here but it took a long time to get all that working. About half the contest had flown by before I was ready to move on to any real game design or art.
Game Design
The run-and-gun genera doesn’t get as much love now as it did when I was growing up. I’m not sure why games like Contra and Metal Slug have declined in popularity. Maybe because first person shooters and metroidvania style games overtook the genre. Still, occasionally there are a few gems that get the formula right. One of my favorites is Broforce by Free Lives.
The original Broforce came out in 2015 and has since seen many updates and ports to consoles, I highly recommend giving it a go. You may not know that the original Broforce prototype was made in only one weekend for the Ludum Dare game jam under the title Rambros. To gather research for my game I spent a few hours playing both Broforce and the original demo while taking copious notes.
I would need to distill this concept down to its core in order to pack as much gameplay as possible into the size limit. I decided to use procedurally generated levels to save space and add replay value. Instead of adding a lot of extra content, I focused on creating fun and polished core gameplay. To give myself an extra challenge, I wanted this game to support up to 4 player cooperative play, a first for JS13K!
Art and Animation
Because space is so limited, designing the art requires careful thought and planning. With most modern games, the art takes up a significant portion of the storage space. For this game I wanted to mimic the look of classic 16-bit games, so it uses a pixel art style sprite sheet.
Most tiles are 16×16 pixels in size with a few smaller 8×8 tiles. Some of the tiles are gray so color can be applied at run time. Limiting the number of colors also allows the image to be compressed better. The entire sprite sheet is only a 16 color 128×48 image as seen here…
When designing the sprites for my game I looked at the sprite sheet for Broforce as a guide to help understand the character art. Broforce actually has a ton of sprites and animation frames, but I was able to distill it down to just two frames of animation for everything! This includes standing, running, jumping, climbing ladders, flipping, rolling, and dying. For some of those actions like rolling the sprite is rotated to animate it without requiring any extra art.
In my sprite sheet the heads are separate from the body. That allows the characters to have procedural animation with the body bobbing up and down during the run cycle.
The player’s eyes are also animated procedurally and will randomly blink to make the character seem more alive. When the player dies the sprite closes its eyes and rolls over sideways. It’s kind of dramatic!
The level art is also created using tiles from the sprite sheet with random coloring applied. This includes both the outside ground and enemy bases interiors. Outlines around the level geometry are added procedurally to make the edges stand out and give a more polished look. By combining all these elements together, it is possible to do a lot with a little!
Player Design
For the look of the player character I wanted something alien but humanoid. The colors were chosen to contrast with each other and pop out from the background so the sprite is visible as possible. I always try to make gender neutral player characters so it’s easier for more people to identify with. After experimenting with different concepts I settled on a design only slightly inspired by Greedo from Star Wars. I was surprised how many people called me out on it!
The game design for the player was informed by retro platformers like Mario, Contra, and some modern indies like Broforce. Something I love is how these games have single hit kills but also abundant extra lives, it makes for really exciting gameplay. Because my game is essentially an action roguelike, I made sure to supply the player with a variety of abilities to get out of any situation they find themselves stuck in.
The player has a classic platformer movement package including the ability to break blocks and climb walls by jumping. All of the physics code was written from scratch for this game. I used a similar physics solution to the system I developed in 2013 for Sifteo Cubes. One of the toughest things to implement was the way ladders are interacted with. After the end of the contest I had to submit an emergency fix because of a glitch allowing the player to pass into collision by jumping into a ladder from the wrong angle!
The player also has a multi functional roll ability that provides a boost of speed and brief window of invulnerability. It has many uses including dodging bullets, double jumping, putting out fires, and knocking out enemies. This roll recharges after only a few seconds with a little flash so the player notices that it’s available again.
The primary weapon is a gun that not only kills most enemies in one hit but also destroys objects and level geometry. It has limited range so players will need to get in close to hit anything. For a little extra fun players also has 3 grenades that denotate with a large explosion destroying, pushing away, and lighting everything on fire. It’s a fun way to soften up a room!
Enemy Design
The enemies all use the same base code as the player, so their AI works more like a bot then a typical videogame enemy. At a high level they send control inputs to the shared character class the same way as the player. This approach allows for interesting and complex combat encounters while reducing how much code is needed.
The pixel art for the enemies was inspired by the Spartans in the Halo series. I thought it would be fun to subvert the concept space marines by making it about aliens fighting to defend their home planets against a military invasion. All of the enemy types use the same sprite but with a different tint and visor color to differentiate them.
There are 5 enemy types, from easiest to most difficult…
- Recruit (Green) – A bit shorter then normal, hesitant to attack, dies in one hit.
- Soldier (Blue) – Average height and ability, takes 2 hits to kill.
- Captain (Red) – Can climb walls and jumps more often, takes 3 hits.
- Specialist (White) – Jumps and rolls often like ninjas, takes 4 hits.
- Demolitions Expert (Purple) – Throws grenades and can’t catch on fire, takes 5 hits!
There is also a small chance of any enemy type being spawned as heavy weapons variation. These mini boss enemies are larger with double health and shoot in fully automatic mode.
The enemy AI uses a pretty complex state machine since they can do all the same actions as the player. In addition to patrol and search behaviors, they will also engage in some surprisingly varied combat maneuvers. Giving each enemy type a unique theme helped inform me about how to design their AI. I love making enemies that can keep the player on their toes!
Object Design
One of my favorite things about playing games is causing unexpected chain reactions. This kind of emergent behavior is often facilitated by a fire propagation system, something I’ve implemented in many games before like Psi-Ops which I worked on at Midway Games.
This time I streamlined the design to use only a few objects that combine to create complex behaviors and fun scenarios. Some of these objects are able to catch on fire, and send heat events to nearby objects, eventually catching them on fire. Other objects are able to explode which damages and pushes away nearby objects while also setting more things on fire. There’s even a water barrel that can put out fires!
All of these objects use only 3 sprites: a crate, a barrel, and a rock. By using different tints and additive colors it’s possible to represent many different types of objects…
- Wooden Crate (Brown) – Burns easily and breaks when fully burnt.
- Metal Crate & Barrel (Gray) – Hard to destroy and can’t burn.
- Explosive Crate & Barrel (Green) – Burns and explodes after a few seconds.
- High Explosive Barrel (Red) – Explodes quicker with a larger radius than normal explosives.
- Water Barrel (Blue) – Puts out fires and pushes away objects.
- Rock (Grayish) – Heavy and very hard to destroy, can’t burn, and crush enemies.
- Lava Rock (Glowing Orange) – Anything it touches is lit on fire!
Extra Game Design
The only other game object that the player interacts with are checkpoint flags that can be activated just by touching them. This system allows players to respawn closer to the action when they die. The flag also has a special function in co-op multiplayer mode because when a player dies, the remaining players need to get to a checkpoint to respawn their buddies.
The final thing I squeezed into this game was a radar system that appears along the bottom of the screen. It’s a simple but effective way to show where all the enemies are in relation to the player. I added it after experiencing some frustration while tracking down the last few enemies!
Level Design
The levels are procedurally generated so they are different for every playthrough. This can be a great way to cut down on file size for JS13K while also giving players an unlimited amount of content to explore. The real trick is generating levels that are interesting and fun for players.
To give structure to the level design, there are enemy bases composed of different rooms that follow a specific set of rules. This includes both the level geometry as well as placement of enemies and objects. It is probably the most complex part of the game and I was very proud of the result with some super interesting procedurally generated levels. This is definitely something I want to experiment more with in the future.
The bases include some special things like partially transparent windows that allow the background to show through and energy doors that can be shot to break them open. To create extra variation the bases are sometimes made to look like caves and underground mines.
The ground around the bases uses a random noise algorithm. A few deep chasms are also created that allow enemies or the player to fall to their doom. Checkpoints are placed across the map at roughly regular intervals.
Background Effects
In the background there’s a layered sky system. The parallax mountainscapes are generated using an algorithm I’ve been working on that creates interesting looking landscapes with just a tiny bit of code. Behind that is a gradient with stars and suns that move in the sky to help emphasize the otherworldly feeling of being on another planet.
Some levels even have precipitation effects like rain and snow. This is a great way to demonstrate the particle system and collision physics. More importantly it adds a layer of atmosphere to the game that helps each level feel like a more unique and interesting place.
Sound Design
All of the audio is played using my open source sound effect tool ZzFX. It’s a tiny self contained sound effect player that generates audio samples from a set of 20 parameters. I was happy to see that many other JS13K games used ZzFX that year including 5 of the top 10 games!
In total Space Huggers uses 11 different sound effects and it took a lot of tweaking to get those sounding right. My favorite sound in the game is the footstep sound used by the player.
To achieve an atmospheric sound when there is wind or rain, a quiet noisy effect plays every few seconds, overlapping itself with some randomness. I was inspired to give this a shot after hearing it done in another great JS13K game, The Wandering Wraith by Mateusz Tomczyk.
Making a Build System
This is the first year that I fully automated my build process and it was well worth the effort. Previously there were too many manual steps necessary to build the final zipped project. This was especially a problem towards the end of the jam, when the size gets near the limit and it becomes necessary to build more often to check the final size.
My build system is nothing fancy. I just made a windows bat file, but in the click of a button it does the everything I need…
- Combines all js files together.
- Runs Google Closure, Uglify, and Roadroller on the code.
- Combines the minified code into a single html file.
- Zips the html with ECT.
For projects of this size I don’t do a lot of hand minification but instead rely on tools like Google Closure so the source code can remain clean and easy to work with. Though I’ve found Closure to be the best first pass minifier, running Terser or Uglify seemed to squeeze out a few more bytes. Overall I’ve been very impressed at how good Closure is at removing dead code while minifying everything else.
That same year Kang Seonghoon introduced a new tool called Roadroller that was a total game changer. It uses a neural network to pack JavaScript code significantly better into a zip file, enough to fit several more kilobytes of code! At first it doesn’t seem possible, but I can assure you, it works like magic. People started joking that JS13K has now become JS15K. This kind of thing really makes me wonder what else will be possible in future years of the contest.
This was my first time using Efficient Compression Tool (ECT) to zip a project. After experimenting with various other options I found it to be the most efficient at both zipping files and compressing images. You’d be surprised how many extra bytes of cruft are in an average zip! For large files it probably doesn’t matter much but for small files like this it can make a huge difference.
Areas for Improvement
After submitting the game I already knew there were some things that could have been done better. In general my game was just very thin on content and lacked an overall sense of progression. There was no end to the game or even a proper beginning. While what I had was very fun, it was also super minimal and felt more like a tech demo then a complete game.
One of the biggest features I would have cut is 4 player cooperative gameplay and probably all gamepad support as well. While multiplayer can be a lot of fun, almost no one actually gave it a try which means all that code was just wasted space.
I wanted to fit in a variety of weapons and upgrades for the player which would have added a lot of fun and variety to the gameplay. These could also have been used by enemies to create more diverse combat scenarios. I chose to cut this not only for space limitations but also because keeping things simple allowed me to polish everything before the deadline.
Unfortunately I was also not able to fit any music, things were just so tight. This is a huge missed opportunity to inject another layer of immersion and I definitely plan to have some kind of soundtrack in my next JS13K game!
The Results
Space Huggers did not win JS13K but it did pretty well, placing 8th out of 223 games in total. It also received 2nd place in fun and gameplay categories!
Additionally Space Huggers was picked by 2 experts as their favorite JS13K game! Thanks so much Lee and Christer. Here’s what they had to say…
“As someone who’s sunk hours into Broforce and loves retro games, Space Huggers checked all the boxes for me. Procedurally generated levels that I can play in my browser?!? SHUT UP AND TAKE MY MONEY!” – Lee Reilly
“It is an impressive game engine AND an extremely fun game! Most things are one or the other.” – Christer Kaitila
Possibly the most amazing thing of all is that we got a half page writeup in Linux Format magazine! It’s beyond awesome to see my game showing up in print media.
Newgrounds Enhanced Edition
After JS13K I took some time to polish up the game a little more and released it on Newgrounds. I also reworked the length of the game so it can beaten in around 10 minutes. Here are some of the new features I added to this enhanced version…
- Limited game to 5 levels with the final level being the smallest but most dense.
- Final boss that can crash through walls and throws objects at the player.
- Intro screen with a music track I composed using FL Studio.
- Mobile support with a virtual on screen touch gamepad.
- Medals and Scoreboard with the fastest times.
- Many other small tweaks and improvements.
I am proud to say that the game now has over 100K plays on Newgrounds and maintains a solid 4/5 score with over 600 votes! Also, there are 26 pages of comments from people that have reviewed the game. This feedback was a great way for me to continue improving gameplay while chasing down any remaining bugs.
I want to give a special shoutout to a few amazing players. The first is lewdev who was an early supporter of Space Huggers and is also one of the best players, holding the world record speedrun for a long while. I’d also like to congratulate KyRzYg on Newgrounds for having the current fastest speed run at a lightning fast 7 minutes 29 seconds!
Also a big thank you to WOWdotStudios for sending me the first piece of fan art I’ve ever received, this super cool high resolution art of the player from Space Huggers. You might also recognize it as my profile image on Newgrounds!
Wrap Up
That’s the story of Space Huggers… for now. Thank you for reading! I hope you learned something from my crazy programming adventures. Follow me on twitter for all the latest updates on my experiments!
The next JS13K competition is just about to begin and if you’re interested you can use the same engine I used to make Space Huggers as a starting point! That game engine is now called LittleJS and there is special example project for JS13K that builds to a 7KB zip leaving tons of room to pack with your art and gameplay. I can’t wait to see what you make with it!
I’ll leave you with this video from a 4 player co-op game of Space Huggers I played with a few friends and it was a blast. Let me know if you give it a shot at your next game night!
