Inventing puzzles is one of those things that is seriously difficult and fun at the same time. It’s also satisfying to see a player fiddle with your puzzle for the better part of an hour and get a big smile from finally solving it. After building several of them I really want to make a puzzle game. Maybe I’ll get to that someday. Retrobooster is not primarily a puzzle game, but it contains puzzles so meaty that they are the dominant elements of the levels that contain them. Recently, I decided the puzzles had become substantial enough to warrant adding the “puzzle” genre to the game’s Steam Greenlight page.

This image shows an example of the type of puzzle to expect in Retrobooster. You have to get your ship from one side of the puzzle to the other by shooting the button and navigating the teleporters and force fields. Buttons are used to activate and deactivate force fields and other game elements. Don’t worry, this image doesn’t provide enough information to solve the puzzle. I have intentionally not described the behavior of all the game elements so as to not spoil the experience later. As you may have guessed from the image, I prefer puzzles that are self-contained where all the information needed to solve them is clearly observable. If you were ever frustrated by one of those game puzzles that couldn’t be solved because you neglected to pick up the rope on the other side of the kingdom, there’s a good chance you will agree with this puzzle design philosophy.

The puzzles in Retrobooster are based on:

• Space (arrangement of puzzle pieces and player’s ship)
• Time (the order of events triggered by the player)
• Movement (the way the player shoots and navigates the ship among the puzzle pieces)
• Emergent properties (unintended game mechanics created by the interaction of game elements)

My favorite puzzle elements are the ones that derive from emergent properties of the game mechanics. These are properties that I have observed after toying with the game a lot and have found a way to use in the puzzles. Using an emergent property almost guarantees the player will have to do some lateral thinking in order to find a solution. I wish I could be more specific in describing the emergent properties in Retrobooster, but that would give hints to some of the puzzles. Games with realistic physics tend to have emergent properties, and Retrobooster is no exception. I think this is simply because all the physical interactions come with spatiotemporal side effects.

When first designing Retrobooster, I made teleporters and three types of force fields with the intention that they could be used to control the flow of levels, make interesting flying scenarios, and be used as puzzle pieces. This all worked out as planned. The big deviation from the original plan was the way the puzzles were designed. I started out sketching them on paper, but it was difficult to think about them this way and they usually did not function as intended once I built them. Only one puzzle from these sketches remains in the game. After the game mechanics were nearly final, I started trying to build puzzles by simply laying down puzzle elements in interesting combinations in the level editor. With a little experimentation I was able to find several puzzles that worked well. As a huge bonus, by playing the puzzles in the game as I built them, I was able to see how emergent properties affected the puzzles and exploit those properties to make better puzzles.

Some have asked if the puzzles will just be a boring chore after you solve them the first time through the game. I have been planning for this potential problem from the start. First, the puzzle pieces are designed to be responsive and fun to interact with. This was necessary–not just because they are puzzle pieces–but because they are also used to control the flow of levels in other ways. Players interact with these pieces frequently throughout the game. Second, most of the puzzles come with interesting flying or shooting challenges built in. Once you solve them in your head, they are still challenging to complete. For these reasons, I think the puzzles will have staying power even after they are solved. However, I can’t be certain without a lot more playtesting.

Another question nobody has asked me yet is how the puzzles behave in co-op games with more than one player. As it turns out, this depends entirely on the puzzle. The puzzles are all designed for one player, and I have not yet figured out how to extend any puzzles for multiple players. In the worst case, a puzzle can be completely circumvented by cooperative manipulation of the puzzle elements. This isn’t all bad since it introduces a new type of cooperative gameplay. In other cases, a group effort will serve to get all but one player through a puzzle. The puzzle must still be solved by the last player in order to complete the level.

There is much buzz these days about procedurally generated levels, and sometimes you even hear about procedural puzzle generation. It has me thinking about puzzle generation compared to puzzle design. It would be interesting to try to implement a puzzle generator for Retrobooster. To a large extent this might be possible, though much more difficult than generating Sudoku boards. The part that I can’t imagine how to do is to exploit emergent properties of the gameplay for this or any other game. Perhaps after you observe such a property, you could program it into your puzzle generator. I suspect a more practical approach would be to do procedurally aided design: let your generator build puzzles, and then tweak them to take advantage of emergent properties.

One thing is certain, it would be astoundingly difficult to do pure procedural generation and have the results feel like they were designed by a person. It’s tough to fake imagination.

The puzzles in Retrobooster have turned out to be genuinely difficult. There are currently thirty-three levels. Seven contain puzzles, and some other levels have elements that are puzzling but not outright puzzles. Judging from the playtesting so far, the puzzles alone will probably take most players between four and eight hours to solve. This isn’t just a shooter; you’ll really need to think to finish this game.

VG247 posted a video article about Retrobooster this morning. They put it together from footage they took at Indie Press Day and commentary they got from me afterward. This explains Retrobooster well and is a good introduction to the game.

It’s always a treat to see a YouTuber play my game. Snowy’s Indie Quicklooks 7 starts of with a few minutes of Retrobooster play. He seems to really enjoy it, especially igniting the little people on the ground.

Yesterday I was at IGN recording this demo with Justin Davis. Thanks Justin! This was a great opportunity to get some more eyeballs on Retrobooster, facilitated by the organizers of Indie Press Day.

Version 0.6.5 of the playable demo of Retrobooster is now available from the downloads page. There are some gameplay improvements and a big update to level 4. Here is the full list of changes:

• Bug fixed: Terrain tile warping was distorting some terrain in strange ways. This is mostly a cosmetic improvement.
• Bug fixed: Invalid shaders were sometimes causing an ugly first frame when starting a new level.
• Bug fixed: Fixed rare crashing bug (only saw it about once every 3 months during development).
• Heavy remodeling of Level 4 to introduce some better flying challenges.
• Reduced enemy weapon damage values and increased amount of enemy fire.
• Added mini tokens that restore 10% of health or shields.
• You cannot be crushed by small enemies anymore, only larger ones that do not appear in the demo version.
• Automatically switch to Ion Bolts (default weapon) when other primary weapon runs out of ammo. Good idea, Derek.
• Added splash damage to most explosions. Made a few exceptions so, for example, player’s missiles do not destroy one another.
• Score multipliers are now increased by doing damage and destroying enemies. Before they were only increased by destroying enemies.
• Added visual and audio feedback for score multipliers so that you know if you are about to go up or down a notch.

The big gameplay change in this update comes from increasing the amount of enemy weapon fire, decreasing its damage, and adding mini health and shield tokens. The idea is to create a better tug-of-war for health with enemies trying harder to drag it down and more tokens to boost it up. I don’t yet know if this has made the demo more or less difficult. More player testing will need to be done to tune these new features. Honestly, though, this effects later levels more; early levels focus on learning to fly while later levels have much larger battles.

The modifications to score multipliers also affect these new gameplay changes. The higher your score multiplier, the more likely it is for tokens to appear.

Finally, I added some big gears to Level 4. This gives a better sample of the flying challenges you’ll find in later levels. This change is fallout from the ongoing level design process that has been keeping me busy lately.

In other news, Retrobooster will be shown at Indie Press Day on May 22nd in San Francisco. If you are a member of the press I hope you come and see all the games.

It’s update time again. I’m still full-time on Retrobooster, working hard on getting a complete set of levels built. By “complete set” I mean that I’m trying to bring enough levels to a state of functional completeness that I can say I have enough content for a full game. Once I get to that point, the levels will be playable but incomplete cosmetically. Then I’ll be able to polish art assets and other details while testers run through the game and find all the playability problems. At current count, there are twenty-six functionally complete levels. The plan is to build six or eight more. These remaining levels range in completeness from a jumble of ideas in my head to mostly built.

There is no way for me to look at this game objectively anymore, so I have no idea if I’m making the right number of levels. I’m hoping testers will provide some good input on that matter.

On the surface Retrobooster is a shooter and caver-flyer, but many of the levels require the player to beat more interesting challenges. One of my favorite tasks over the past few weeks has been designing puzzle levels. Right now there are seven levels with puzzles and a few other levels that have elements that are fairly puzzling. The spatiotemporal nature of the puzzles in Retrobooster seems to make them considerably more difficult to design than to solve. Testers have spent between five minutes and two hours on some of the puzzles, but I spent much more time building them. Without revealing too much, the puzzles mostly involve interacting with and manipulating force fields and teleporters. I always thought these game elements would make good puzzle pieces but didn’t get around to designing the best puzzles until recently.

It would be pleasant to concentrate on nothing but making levels, but things never seem to work out that way. I have been making new enemies and fixing code along the way. Each level seems to require some random new improvement. Collectively, these things take a lot of time.

Another big milestone I’m working toward is submitting Retrobooster to the game competition at IndieCade. Maybe this game can win some more exposure.