Hi everyone,

It's been two weeks since my last blog post, and many things have happened in the development of Mr Boom's Firework Factory.

The R&D Department

The game now has a fifth level (not including the tutorial level mentioned below) which is set in the factory's R&D department. The R&D department is a rather dodgy area, very much below board, dealing with radioactive waste (for use in fireworks??? You be the judge!) and toxic gases. As you can tell from the products in use, this place has taken a turn for the worst and isn't what it seemd to be when the player started out on their journey:

The poison gas crates emit a huge cloud of green gas when they explode, which causes the player to lose vision of the game temporarily. If done at the wrong moment, this can be catastrophic:

The radioactive goop crates were previously covered in a past blog post and leave goop stains all over the level, which are destructive to anything that passes over them.

Getting the game on Steam

Next, and most importantly, I have finally set up the store front on Steam, and configured my build process to push builds to steam via Steampipe. This took a little time to get working, and during this time I established a closed beta. Under the offer of free keys for the game, and credit in the game's credits page, many people contacted me asking to take part, and based on the feedback they gave I now have a reasonable sized bug list and feature list on the project's Trello.

The most commonly requested of these was a tutorial, to explain the controls and the basic aim of the game. Each user had to have the basic controls explained by myself (there was no readme, or online help) and the basic aim of the game, as it seems that the game is sufficiently different from most of the puzzle games available on steam as to confuse many new players.

Without further ado, this leads on to the next item on this blog post...

Creating a tutorial level for fun and profit!

To be effective and useful, the tutorial level in my game had to have the following qualities:

1. Be very easy to complete
2. Allow for multiple different choices of input method (e.g. keyboard, gamepad)
3. Have obvious points where gameplay could pause and pop-up hints can occur
4. Still be possible to fail, to try out failure and see what happens
5. Not be easy to break the tutorial flow
6. Be possible to complete the tutorial in under a couple of minutes

I decided to settle on a simple level, with the fewest possible number of usable junctions that can be placed whilst still allowing a crate to bounce  between them in a loop (two), and the fewest number of machines (one). The level would work by popping up a dialog box indicating how machines worked, and how to move the camera, then emitting one crate from the machine, and after it had emitted the crate, popping up another dialog box indicating how to rotate crates. Once this dialog box had popped up the ability to rotate junctions became available, until this point the player can't rotate the junctions to help prevent breakage of the 'scripted' events.

As soon as the player has rotated the correct junction to the correct angle, the next scripted event will trigger, popping up a dialog box to confirm that this was the correct action. There is a short delay of a couple of seconds before the final dialog pops up to explain how crates wait for the grab claw, and then the level ends.

There were two verisons of this tutorial, which only varied based on the text content of the speech bubbles; one for keyboard/mouse usage and one for the gamepad, with different summaries of the buttons to use.

If played efficiently, this takes about one and a half minutes. As far as tutorials go, this is pretty much short and sweet.

First attempt (AKA: How to scare off new players)

The first iteration of the tutorial level had dialog boxes which just contained raw text:

This did work, somewhat, but it had two flaws which required a second iteration be done, these flaws were:

• Each dialog box was a wall of text, off-putting to the new player and hard to digest
• Aligning the dialog text with the rounded speech bubble and having it work on any resolution of screen was proving to be near impossible

Tutorial Trek - The Next Iteration

The next version of the tutorial involved me spending a good couple of hours in GIMP polishing images. Instead of using raw walls of text that are hard to align with a speech bubble and still look good, i decided to draw the speech bubbles as PNG images:

I ended up drawing six of these, two of each of the first two speech bubbles that were controller specific, and two of the last two generic bubbles.

I drew each one with some particular features in mind to make them better than the wall-of-text equivalents:

• Each speech bubble was to make more effective use of the rounded bubble area
• Where a bubble mentioned controller or keyboard controls it would use the expected iconography to indicate what to press
• Names of controls, or important gameplay elements would be highlighted in red, e.g. crate, machine, left stick.
• Actual images of gameplay elements would appear in the bubbles to help the player relate (this way the player knows what a machine looks like as they saw one in a tutorial bubble, most real life factory machines are not square boxes with an exhaust sticking out of them!). These images would sometimes overlap the edge of the bubble by design, to draw attention to them.
• Most importantly: All wordage was to be shortened as much as possible!

I then rolled them out into the game:

And that, as the say, is all he wrote.

Feedback and comments are as always very welcome!