My Second JS13K

This last month, I competed in my second JS13K competition.

Last year I stumbled a bit while learning hard lessons about the degree of serious planning and design required in building a game. This year, those hard-won lessons paid off.

My entry was ParaTec Systems, a puzzle game wherein the user draws a line between points, avoiding obstacles along the way. The contest’s theme was “Reversed,” and my entry integrates that theme by introducing a reflected version of the user’s drawn line that you must also keep an eye on:

Screenshot of core gameplay

Play it for yourself!


Along with the core mechanic of drawing lines, there is a “chat” sidebar on the side:

Screenshot of chat sidebar

At first, this sidebar just provides instructions on how to play the game. However, as the player progresses through stages, a “reply” option is enabled, allowing the player to respond to Otto’s messages:

Screenshot of chat sidebar with dialog focused on instructions

At this point, the player can either reply to Otto by holding down the “reply” button for a short period of time:

Screenshot of chat sidebar with the reply mechanic enabled

Or ignore Otto by just letting the window for responding expire:

Screenshot of chat sidebar with reply mechanic expired

On top of this, a scoring mechanic is introduced in later stages: at the start of each stage, a score total counts down from 1000. When the user completes the stage, the remaining points on this timer are added to their total score.

As you might have noticed, these two mechanics conflict with each other: there is a “reply” option that requires you to stop playing and a score that encourages you to keep playing.

The idea here was to force the player to choose: either you ignore Otto and focus on the tangible measure of success (the score) or you ignore the score and opt for exploring goals that may not have explicit measurements of success (in this case, a conversation with Otto).

While I think the basic pieces for exploring this theme are there, the brevity of the game doesn’t give enough space to really flesh it out.

Worst and Best Decisions

When coming up with an idea for this year’s contest, I wanted to avoid creating a game with levels. I knew it would be a pain to have to first create the game’s engine and then design each of the levels.

But, for some reason, I ignored my own advice and did it anyway.

And, just as Past Logan predicted: the biggest source of Future Logan’s stress was level design.

The last day or so of development was solely focused on creating levels. Not only did each stage require its own process of design, but the way in which stages were ordered also required attention: techniques needed to be taught to the player in manageable steps, difficulty needed to ramp up gradually.

Luckily, I made the decision upfront to make stage creation easy; I created a terse syntax for laying out stages. For example, the following…


…is parsed by a function that sets up the following level:

Screenshot of stage generated by syntax

This allowed me to store all of my levels in an organized file that I could manage separately from the rest of my game’s code.

Lesson Learned

Overall, the thing that held me back those most this time around was my lack of experience. Instead of waiting for a contest to come around, I just need to get out there and make some more games.