With lead designer Jeppe Carlson, (co-designer of the well know title Limbo) 140 was created by Carlson Games. Paraphrasing Jeppe, he describes 140 as an old school platformer, where the challenge is in syncing up your moves, and jumps to the music controlled elements.
After a short time with 140 I thought to briefly note my impressions of the game.
Disclaimer – This is not a thorough review, but notes of an impression based on approximately 20 minutes of game play. Everyone is fallible.
On launching 140, the first thing that hit me was its minimalist art style. Its distinctive color scheme made it easy to identify puzzle patterns, and game elements.
In 140, music is at the heart of its game-play with appropriately pulsating background, and game elements used with rhythm based mechanics to make interesting puzzles.
140 relies on players exploration of controls as I noticed no traditional tutorial which can be fine. Although some helpful information based on monitoring of the game state is good e.g explain to jump or move if a player hasn’t moved for a long time.
Like other titles in this area 140 suffers slightly from issues of repetitive music. This issue I believe essentially stems from player progression which is something hard to control. I felt this game handled this issue well by splitting music into short levels.
The difficulty of the game quickly ramps up, likely making it less accessible to the casual gamer. On the other hand though, this meant 140 presented more challenging puzzles, which is delight for some. It’s good that the creators of 140 realized the game difficulty, and employed frequent checkpoints through out the game.
140 bravely deviates off a more traditional pattern of game mastery by transitioning to a hail shooter from a rhythm based platformer at the first boss fight. I found the hail shooter boss encounter to be a disproportionately high increase in difficulty from the challenges before. The encounter left me frustrated (maybe I just sucked bad). Perhaps an easier encounter, or a series of checkpoints through the boss encounter would have been preferable.
Raph Koster said ‘noise is patterns we don’t understand’, and so it felt appropriate that the ‘death blocks’ were static noise. 140s creators took this concept even further during the first boss fight as static noise breaks down into music.
Like other titles in this area of game development, 140 suffers from issues of repetitive music. This issue I believe essentially stems from player progression which is something hard to control. 140 tackled this issue well by shortening levels, and splitting up music into those levels.
I liked how the levels key (item objective) was innately tied to the next level through music. When hearing the keys music was excited thinking about how it would later manifest itself as a mechanic.
All in all I enjoyed 140, being a nicely designed little gem it was a happy little surprise. Budding game designers should definitely give it a play as its a game well focused on how to meld music, and game-play.
Writing a good, feature rich platformer engine takes a lot of work. Building a simple platformer engine is considered a case of ‘reinventing the wheel’. So it makes sense why some choose to find a pre-built engine to plug in to their game.
The trouble with this can be:
Getting it plugged in.
Figuring out how it works.
Finding it doesn’t do exactly what you what.
Seeing as the feature needs for a game I’m building are simple. I instead decided to learn the basics then build such an engine in Game Maker. For now, I’ll briefly run through the resources that helped me build a major part of what I’ve implemented. Collision detection.
Implementing collision detection can be a head ache if your new to ‘game physics’. So to help you on your way here is a good video by Shaun Spaulding which gives an in-depth look into how to create a platformer in Game Maker. I’d recommend watching the whole thing, in particular where he explains the basic concept of collisions at about 22:30.
The system he describes is basically a method of checking several pixels ahead per frame. If a situation arises where two objects intersect, move the moving object to a point where they are next to each other but not intersecting. This is the method I choose; there are many many ways of doing it.