Postmortem: ArcherFire Duet of Aces – js13k 2018

ArcherFire: Duet of Aces is a game I made for the js13k 2018 contest, you can check it out here! (and the source code is here)

I decided to write one final piece of text about my second participation on the contest. I already described my journey in detail here and here, and also did a dissection of the source code, but I wanted to record some lessons learned which may come in handy for other people or myself in the future.

afdoa

The story

Whenever I participate in a game jam or contest, I ask myself what is my motivation:

  • Learn a new language or tool
  • Create something cool
  • Win the contest prize

This was the second time I participated in the contest; results from last year had been a bit disappointing (regarding the ranking given by the jurors), and I knew my development time this year was going to be very limited. Still, I aimed to rank high into the lists.

The theme for this year was OFFLINE, as mentioned in my first blog post, I started off with a vague idea of a space… thing… where you could collaborate with other players offline to advance through the game.

20180913_210742

On the first day of dev, I created some foundations work looking forward to having some kind of space sandbox thing with arcade elements (Similar to this entry, which ended up being one of the contest winners). However, given the constraints I had, I decided to follow my own advice from last year’s postmortem and create:

  • An arcade game bringing full action from the first second of gameplay
  • Complete music track

And that’s precisely what I ended up doing! Interestingly, and maybe because of what I set to do and my experience from last year, I didn’t have any issues with the 13KB limit so I didn’t have to cut around any corners. I incorporated the OFFLINE theme by allowing 2 players hot-seat offline play.

However, the results were even less encouraging this year. Despite receiving good feedback from the jurors, the game didn’t even end up in the top 100. (Last year it ended up #40 overall and ranked well in the Community and Social lists). Since this was the first year where some constraints were put on the prizes model (only top 100 entries would get prizes) that meant that effectively I lost the contest. There was a total of 270 entries, and mine ended up ranked #105.

Screen Shot 2018-10-18 at 6.35.57 PM

Unlike last year, this time I don’t really have some big factors I think led to this result. I contented myself in thinking that the jurying process is not perfect, and there may have been very good entries this year. Still, here’s what I think worked and didn’t work.

What went right

  • Seeded Procedural Generation: Managed to create an infinite, increasingly harder, top-down shooter level which was the same every time you played (So, in theory, the more you play the game the more likely you are to memorize the hazards and get farther)
  • Pseudo 3D Effect: Everyone loved how cool the ships looked when soaring around.
  • Straightforward action-packed: The game is pretty responsive and quick, with lots of action on screen. No need to explain anyone how to play because it’s obvious!
  • 2 players hot-seat mode: I couldn’t test this much because I have no friends, but I saw some people have fun and yell at each other afterward.
  • A solid, finished entry: No bugs, no feeling of being an “incomplete game”, it is what it is and it doesn’t break.
  • Music: One of the game highlights, and I didn’t do it myself 😀 it was all thanks to Ryan Malm. I just gave him a reference and some ideas, and he came up with the track. Thanks again!

What went wrong

  • Floaty Controls: Since my foundational work on a simple physics engine had support for acceleration, I stuck to the end with the idea of the ships being “hard to control” as a “challenging aspect” for the player. I knew it was frustrating, but I waged on the players trying harder to learn how to control it. In the end, it ended up being too hard and too different to the standard. A model where the ships had less inertia would have been much more playable and enjoyable. Maybe I need to start making easier games!
  • Balancing: Some people reported the game was a bit too hard. In part, this may be closely related to the controls, but also could have lessened the hit points of the enemies or made the difficulty curve less step.
  • Lack of theme: Yet another space shooter, no plot, maybe went too much into the arcade direction? So that aspect was pretty uninteresting. There were also too few types of enemies, mainly because of the time constraints I had.
  • Graphics too simple: I am not an artist, and the game had high-resolution vector art. Unlike last year where I could go around that by using shadows in the darkness, this year I went for colors and maybe it didn’t look too nice. One thing that could have worked would have been using WebGL filters to post-process the bare graphics, which has worked great for other games in the past.

The Future

This is not the end of the story for Duet of Aces… I plan to make it evolve into a more complete game, keeping the core design but adding better art, sound effects, more music, a complete plot and more importantly, adapting it to social media mobile platforms. More info soon!

Also, some things I want to do next year:

  • An easy game, rewarding players without requiring lots of skill.
  • Gorgeous visuals.

ArcherFire: Duet of Aces, js13k 2018 source code dissection

JS13k 2018 has gone by! this is the third of a series of posts detailing my journey, as well as the structure of the game I built. You can play it online here!

afdoa

Links to the full series: part1, part2, postmortem

The full source code of the game (github repo), uncompressed and unminified, is 43136 bytes for the single javascript file, plus 349 bytes for the html file. This includes a lot of comments and code that could be written in a more optimal way, which reflects that my biggest restriction this year was not the size, but the time I could invest in the project.

Screen Shot 2018-09-21 at 10.02.50 AM

Following is a summary of the 43136 bytes, which of course could be laid out in a much better, modular way, but were thrown together in a huge file for the sake of reducing overload from webpack for having multiple modules.

So, why do I think this may be relevant? Well, I believe this may be a bare minimum setup to have an arcade game up and running; understanding how these components work together to create the game experience might be helpful to create a more organized structure, without falling on the mistake of over-engineering (start small and simple!).

Also, having them all in a monolithic block creates an implicit graph of dependencies, where the more general purpose components are (generally) defined first, then other code uses them. Here’s a first stab at translating that to a component / class / object diagram.

Screen Shot 2018-09-21 at 10.50.36 AM

With each segment of the source code, I’m including a short description which may give you an idea of the types of components in play for the game, here we go!

  • Soundbox player (11879 bytes): Pasted from here, this is the code that interprets the song “script” and transforms it into a WAV stream.
  • Theme song (5148 bytes): Created by Ryan Malm, it’s exported from Soundbox online player.
  • SFXR player lib (2637 bytes): Minified form of the original source code here, this code allows playing SFXs based on a list of settings
  • Initialization function (466 bytes): Creation of the music player and the WAV stream from the song script.
  • Sound data for SFXR (484 bytes): 5 different sound effects represented by SFXR instructions (Explosion, Bullet, Missile, Super Explosion, Start Game Beep)
  • SFX playback functions (359 bytes): Preload Audio objects from SFXR sound data and allows easy playback.
  • pRNG functions (719 bytes): Functions to generate random numbers, including the seedable pRNG.
  • Keyboard input routine (533 bytes): Some hooks around keypress and keydown to allow polling for the state of a key or add a listener function.
  • Shape renderer (1765 bytes): Given a canvas rendering context, a set of “shape instructions”, a position and a scale value, translate the simplified instructions into Canvas 2D API operations.
  • Mob class (887 bytes): Model the basic things moving around in the world, every Mob has an appearance, speed, and position in the x and y axis. This class also includes functions to update the mob, destroy it and check collisions with other mobs, as well as the creation of explosions.
  • RAF function (401 bytes): Function that allows hooking other functions into an animation frame, doing the fundamental calculations for the elapsed time between frames which are used to (try to) keep things running at a constant speed regardless of where they are run.
  • Collision functions (177 bytes): Simple collision checks based on the Manhattan distance between two mobs and their size.
  • Game Loop (1952 bytes): Keeps tracks of different list of mobs, used for both updating them on each animation frame, as well as rendering them on screen. It also keeps tracks of the animation-based Timers
  • LCD-like number rendering (805 bytes): Allows drawing any number as an LCD-like display.
  • UI Rendering (1371 bytes): Depending on the current state of the game, might draw the loading message, or the title screen, or the HUD including the scores and the current wave, or the Game Over message.
  • Enemy Factory (2318 bytes): Contains the stats for the different kind of enemies, as well as function to create groups of them in a given initial setup. For example you can request the factory to create 5 mines in horizontal formation at y = 200
  • Player Ship class (2356 bytes): Extends Mob, has special checks on its update function to simulate inertia as well as handle the practical “3d” effect when moving around and keeping the player ships on-screen. Of course, it also includes functions to control the movement of the ship using the keyboard (the actual keys that are used are received as a parameter, which means there could potentially be more than 2 players on screen). Also allows firing missiles, and keeps track of a player’s score.
  • Enemy class (1208 bytes): Extends Mob, has a simple “reaction” model which allows it to potentially fire a bullet at the player each x milliseconds. The speed of the bullet on each axis is calculated using the arc-tangent between the target and the enemy. The target is selected from the list of players (the closest one)
  • Star class (304 bytes): Extends Mob refining the destroy class so that a new star is created at the top when a star is destroyed.
  • Planet class (366 bytes): Extends Mob defining a special render function which draws a circle filled with a gradient based on the 2 colors and rotation of the planet.
  • Explosion class (928 bytes): This class is similar to Mob, but explosions have no speed (just a position). It’s designed to progressively draw an explosion on screen, based on the “run time” and “size” parameters, the size and color of the circle to be drawn are determined by the “progress” of the animation (a value growing from 0 to 100, based on the accumulated render time and the total run time). When fading, it substracts from the drawn circle creating a growing “hole” inside of it.
  • Shape definitions (2487 bytes): A dictionary of lists of drawing instructions to be interpreted by the Shape Renderer, all Mobs have a reference to a shape definition, used in the game loop
  • Game Start function (683 bytes): Plays the theme song, creates the player ships and starts a timer for wave generation. Called by the title screen and the enter key handler (for restarting the game)
  • Enemy Wave Generation (1947 bytes): Several functions containing the logic to create a new “wave” of enemies. Levels are made of waves generated every 3 seconds, this component decides what enemies will be spawned on each wave, and under what behavior. Makes extensive use of the seeded pRNG, as well as the Enemy Factory. Also creates the planets.
  • Enter key handler (320 bytes): Used to control the game state from the title screen and game over status, into the “in game” status.
  • Game state machine control functions (628 bytes): Transitions into the different game states (title, game over and “in game”)

Coming up next, final postmortem and future of the game!