This is the first post in a series that will reflect on the project from various stages, covering pros and cons of the creative process and implementation of the game. This review is a long time coming, it was originally started right after the 2015 Global Game Jam.

In January I broke a lull by participating in the annual 48 hour Global Game Jam. Prior to this jam, it had been some time since prototyping a game of my own. Game jams in general are a great opportunity to break creators block and start fresh.

I started a project called Out of Phase. The original idea was to create a two player game that involved a series of puzzles contained within chambers, similar to Portal 2. There was a twist, where the environment was slightly different between the two players, requiring them to communicate between each other to solve the puzzles.

At the end of the 48 hour jam, I produced the first version. While not complete, it still gave an example of the general concept with a couple puzzle examples. Two players were supported through a local co-op mode, where chracters were toggled by hitting the tab key.

For this post, I’ll give a general overview of the tools and design ideas that took place at the Global Game Jam.

Framework

It’s a good rule of thumb in game jams not to build your own framework. Your focus is on producing a game, not a toolset. Phaser.io is a real snazzy HTML5 game engine/framework. It comes with a tilemap loader, collision detection, WebGL support, and a plethora of other goodies to make life easier.

Another guideline with jams is to know your toolset so that you’re not wasting time figuring out how to use the tools. I only had a little experience with Phaser.io prior to the jam, so I didn’t follow this one completely. However being very experienced with JavaScript and the concepts that Phaser.io is built on, I was able to get started very quickly and iterate through ideas easily.

One problem I ran into early on was selecting the wrong physics engine for collision detection. This set me back a little, but helped me learn the differences between the P2 and Arcade systems. In Phaser.io, you can actually have more than one system active, so they’re not exclusive to each other.

Map Editor and Event System

To make level design easier, a map editor is essential to have in a 2D game dev tool belt. Tiled is nice tile-based map editor that supports tiles for basic level building, objects for more complex use, and shapes which allows for circles, hexagons, and  triangles.

An event system was built on top of the tile based map format using Tiled to create events listeners. With this system, players were able to interact with tiles, doors, flowers, and barrels in order to progress through the rooms.

In Tiled, object and shape instances have their own custom key-value properties, which are used to tell the game what events they are listening for and what to do once that event is triggered. A majority of the event objects are Tiled objects, though a shape was used in the bottom-right room for detect when a character was in the room so certain trigger tiles would be visible or not.

Creating an event system isn’t the best idea for a game jam, because it would fall under framework/library development and considering I was the only person on my team. I could have taken a different approach where I hard coded the objects, which may have saved some time (debatable). However, it was important to me for levels to be easy enough to manage for a non-programmer in the future, so I took the risk.

I’ll go into the event system in more detail in another post, I’m pretty happy with how it worked out.

The Demo

I had two volunteers try out the game at the end of the Global Game Jam. Game testers are interesting, they can be both predictable and surprising.

The demo test started out as expected, with the players figuring out their controls, environment, and boundaries. One of the players promptly broke the game by pushing the other player through the door separating room one from two, breaking the level. There were other interesting bugs caused by the local co-op switching. Such as switching players while walking would cause the previously active player to walk through everything forever.

Puzzle Design

In the first iteration of the first two rooms, I made the mistake of not keeping the puzzles contained. In the second room one of the characters needs to smell all of the flowers that are accessible, including those from the first room.

The idea at the time was players would be trying to figure out the first room anyway and would likely interact with the flowers, unknowingly beginning the solution to room 2. This is all sorts of backwards.

There’s a few things to take away from this goof.

First, there should be an obvious beginning and end to a puzzle, otherwise the player may skip a crucial part during the first or secondary run throughs. At minimum, the player may need to walk all the way back to the far corners or room 1 to interact with the flowers. And worse, the player would stay in room 2, assuming they aren’t suppose to go back, and quit the game out of frustration.

Second, by compartmentalizing the puzzles, the player is able to have closure with the previous puzzle or area. You don’t want the player to worry about going back to a previous area, unless they have a compelling reason to do so.

The Portal series has an interesting way of separating the rooms by sealing the door to the previous puzzle, representing the end to the previous puzzle. Many rooms in portal have barrier fields that destroy objects the player may be holding which eliminates the question “maybe I should have used that”. These barriers keep puzzles simple and the player confident they have all they need in the room/area they are in.

(Funny enough, when I loaded a save of Portal 2 to confirm my recollection, I was in one of the few chambers they kind of bend this rule. I’ll touch on that in a future post)

In the next iteration of the second room, which was after the Global Game Jam, the flowers were removed entirely. Instead, there was a barrel that could be pushed onto a pressure tile to open the door to the third room.

Dialogue Design

When a player would interact with a flower, a dialogue popup would appear. What text displayed depended on the character interacting with the object. The male character had a different reaction then the female character.

Creating the dialogue system was easy enough, but the dialogue content itself didn’t come to me as easily as I had hoped. The lack of sleep probably didn’t help.

Not enough time was put into crafting the dialogue in a way that communicated to the player what needed to be done, and as a result the players spent much more time interacting with the flowers because their purpose was not clear.

This leads into a couple other issues with the flower puzzle. There should have been some cue to the player that their interaction with each flower did something, and that the flower no longer needed to be interacted with. This was intended to be conveyed through dialogue, but that missed the mark because the statements made by the characters were too vague.

Dialogue could still work, given the statements were crafted properly, but there are other options to consider, such as obtaining an item, increasing the score, or playing a sound or animation.

In addition, the trick to cueing the player is that they may miss the first cue. So it’s important to somehow remind the player what they should be doing or limiting their options so they can intuitively figure out what to do. Going back to the Portal series as an example, the player can figure out what to do by just interacting with the chambers and objects. In the second iteration of the  room 2 mentioned above, the dialogue system wasn’t utilized for this reason.

Conclusion

This game jam session was a blast, and was well needed after a lengthy hiatus. Compared to my previous creations, this game was a progressive step forward, and more advanced then any other game I had created from scratch to date. This was thanks to the Phaser.io framework and Tiled.

I took away some good lessons from this jam that concerned room and dialogue design, and what behavior to expect from beta testers. These are things I’ll keep in mind for future iterations and new games.