Click here to play the game (browser)

I am making a-game-a-week(ish).

These will be short prototypes, very unpolished, probably broken.

A traditional arcade platformer to start.

• Made in ~3.5hrs in flowlab.io
• Using assets built into the engine.

Notes:

This is the first of a series of rapid protoype games, short dev times, aiming to create one-a-week(ish). The purpose of trying out a variety of tools and rapidly get to grips with the dev process.

The game:

A super-simple, traditional arcade game, inspired purely by the assets the game engine provides and to chose something simple for the first game.

The engine:

Flowlab is one of a number of game engine offerings where coding is entirely visual. Code 'blocks', each with a series of inputs and outputs are connected together by dragging connecting 'pipes' between them. The result, for a handful of blocks, is quite elegant, but more than half-a-dozen blocks and it starts to become a confusing mess of blocks and connections.

Many of the pros / cons of flowlab apply to any such visual codings systems. They allow ease of access, without the off-putting abstractness of coding, and all the syntax headaches and other annoyances that coding comes with when starting out. By limiting the user to a set of predefined functions, all with well defined inputs and outputs, any mistakes are usually mistakes which can immediately be seen, and the process of adding, changing, iterating becomes very straightforward.

Flowlab's style does provide one welcome addition to the visual coding genre, which is that 'blocks' can be arranged in such a way that parallel processes actually appear parallel to one another. This takes a bit of planning when designing, as moving one block moves all other blocks attached to its outputs, which makes re-arranging a pain, but, if done with a bit of care, can lead to quite intuitive layouts.

Despite the use of visual coding, flowlab decides to go with more technical terminology in some places. Movement and physics relies upon 'motors', 'impulses' as well as pure positional changes, which are not immediately intuitive.

There's no obvious debugging or logging system. Although, due to the format, most issues are readily visible, I found that collision detection seems to be all over the place. I was never able to work out whether this is a limitation in the engine or (more likely) a problem with how I built the game, and without clear debugging and logging, I was unable to track this down.

Even so, it's a powerful system. A working(ish) game in just a handful of lunch breaks, albeit very bare-bones, without proper progression or much diversity. Even so, just the same amount of time again to fix that collision detection add some polish and some kind of progression, and this proves just how powerful simple game development kits have become now.