PLAY

I was excited and nervous heading into this Ludum Dare, as usual. I was excited to see my jam group again, and to with Britt as my graphic artist since he’s been cranking out game projects like crazy for the last 4 months. He did an amazing job our Mini LD submission Terrarium, too. I always go into jams feeling nervous, too – nervous that as a programmer I won’t be able to deliver on the designs we come up with. Time pressure forces tough decisions, and some of my toughest calls during jams so far came while working on our most recent jam, Strider Submerge.

When the theme “Beneath the Surface” was announced, we kicked around a few ideas about being underground, underwater, or beneath the surface of someone’s psyche. The psyche idea was super interesting, but we ultimately decided that it was too abstract for a rapid prototyping exercise. Britt wanted to have something with an underwater bubble city. Having mostly programmed platformers so far, I wanted to expand a bit and try something top-down. Our first night’s build was a sort of shooter where the player commanded a submersible dome city covered in tentacles.

To drive home that you were a moving city, we thought it would be interesting to incorporate resources for the player to manage, including food, oxygen, and energy. We ended up simplifying the resources to only include energy (and health), and threw out the city idea entirely. One of the hold overs from that is that the healing items in the game are fish you have to catch by submerging into the ocean, which is kind of funny when you’re just a spaceship. We were left with a submersion mechanic that expressed the theme strongly enough for us to run with it.

The submersion mechanic itself was something we struggled to make relevant. Most enemies can’t submerge, and so their missiles won’t hit the player if he/she is submerged. We eventually changed mines so that the player could swim under them, and made coral pieces that would allow the player to fly over, but not through them. This worked pretty well with our energy resource limiting how long the player could stay beneath the surface. We also added submerging enemies that could follow the player as they tried to hide, which feels pretty interesting but caused a lot of problems.

We also wanted a reason for the player to kill the various enemies, since submerging and going right past them was a viable option. I’d never made anything resembling a skill/tech tree before, but that was just the thing that would make killing enemies and earning credits interesting. Unfortunately, most players never get to see the upgrade screen – the game has only one level and we had intended for upgrades to happen in-between missions.

The single level that made it into the game was a dummy run intended to demonstrate and test the various enemy behaviors. We had planned out at least 4 levels, but ran out of time before we could implement any of them. Since the one that remained was not really designed with care, it ended up being way too difficult. The tutorial levels preceding it were put in early, which I’m happy about. Unfortunately, the submersion tutorial level is the only place you’ll see the a bridge implemented because, again, we ran out of time to build levels. Part of this reason was performance issues…

When working with Flash, it’s tempting to use color tinting, alpha fading, and crazy particle effects. I worked with Britt previously on a game called Terrarium that made the same mistake – the game looked amazing for about 4 seconds before becoming incredibly choppy. Performance is a major issue in Flash, especially when constantly changing multiple levels of alpha for various actors. The diving enemies gave us a lot of problems. They were animated with the same splashing and color tinting effects as the player, which became an issue when 6 of them popped into the screen. On top of that, enemies would sometimes try to dive on top of coral. This wasn’t normally a problem, but when two pieces of coral are too close to one another to allow the ship to fit between, the ship gets stuck in a collision problem and crashes the game. A couple of methods were tried for detecting coral beneath the diving enemies, and eventually one worked well enough to prevent about 90% of these crashes.

Despite the problems we had, we ended up with a game that I like quite a bit. I enjoy the mechanic and feel like there might be something there. Also, I love that we got voiceover for the boss fight and menus. Will Bucknum nailed the ’80s action hero vibe we were going for. The controls are a bit off, though – I intended to use WASD and force-based movement, but eventually but forgot about that as the weekend marched along. I’ve been working to improve the Strider Submerge’s performance in a separate upload from that submitted for the jam, and intend to build out those levels too. Moving the upgrade screen to right after the tutorial also does a better job of showing off all the hard work I put into making that work, so if you get a chance check out the original upload as Strider Submerge, then go try my current build: Super Strider Submerge.

A week ago I was just finishing up the most ambitious game jam project I’ve done to date. Compared to projects I’ve worked on in the past, Voyage of the Magpie is less immediately rewarding – there’s no jumping, no shooting, and no skill points to spend. There are, on the other hand, coins to pick up, mazes to run, tickets to manage, and click-heavy mini-games. The goal of the project was to create a set of three smaller games that were somehow connected to meet the theme requirement for “connected worlds.” As a secondary (but more obvious) nod to the theme, the game involves navigating a network of interconnected locations all over the world to find lost treasure.

In the over world section of the game, the player flies their zeppelin from location to location by using tickets associated with those destinations. The tickets are consumed, but more can be purchased in cities or found in mazes. Tickets sort of represent leads on where treasure might be. At non-city locations the player will run a procedurally generated maze in either a temple or jungle setting. Gold, scrap metal, and tickets are gathered in the maze, which must be navigated before the sun sets. The more damaged your zeppelin, the less time you have to run the maze. Barriers in the maze are chopped through with the heroine’s machete, which dulls with use. In the third section of the game, the player attempts to repair their zeppelin and machete before setting out again to explore the unknown. The only way to succeed at the game is to be good at planning your moves, navigating mazes, and rapidly completing tasks. These different jobs are supposed to feel like different “worlds” to the player.

What went wrong:

Conveyance

Conceptually, the game was way too ambitious for a 72-hour jam. It was terrifying to work on because you can’t really get a feel for what the final game experience will be like while building THREE GAMES at once. It started to come together at the end of Sunday, but just barely. Though the end product was playable, there was no time to implement a tutorial. Given the complex inter-connection of the game phases, a tutorial was sorely needed – or at least better conveyance of what the connections were so the player could discover it themselves.

As a brief summary, here’s how the player was intended to see the connection between zeppelin condition and time in the maze: on the over world a zeppelin condition bar is on the far left. When entering a maze the bar on the far left is at roughly the same location but is now a sun icon.

Hopefully they would also see their machete condition lowering as they chopped through the jungle and would notice it improving during the repair phase. The biggest oversight was not adequately showing the player how to use scrap metal. The repair screen features a prominent central symbol that the player is meant to click to extend the timer. Unfortunately, the button is a baked-in image I was unable to give an effect when hovering over. Also, the timer and metal display are so small and far away from the button that even if the player were to press it they would likely not notice what it did.

Conveyance Again

Some minor cuts were item pickup sound effects and walking animations. More seriously lacking was a statement of the overall goal – find the Golden Magpie in the city of El Dorado. Without knowing when the game would end, players got confused. That combined with an ear-piercing sound whenever you try to sharpen your machete made for an unintentionally grating experience.

Yet More Conveyance

The least amount of work went into the maze-running section of the game. I shied away from working on it even though I knew that everyone would see that as the “main” game mostly because I didn’t know how I’d be trying to populate those mazes. In the end it was too big of a problem to tackle last and I ended up with the system you see – one gold piece per room, with either metal or a ticket at each dead end. I didn’t put an explicit end to the maze since I wanted the run to be timed. This was also a problem of conveyance, since the player could explore a really small maze and have to sit and do nothing for about 30 seconds. Pressing Enter will skip to the repair phase when the player is done exploring, but with no visual button I had to try to tell the player in the comments. I intended to auto-transition the scene by counting loot left in the maze, but abandoned this idea due to time constraints.

What went right:

Novel Systems

While working on disparate parts of the game in parallel was scary since the fun couldn’t be seen until much later, it did allow for me to squeeze as much productivity out of myself as possible. Once I was sick of working on one thing I could switch attention to something entirely different, which was nice. Also, despite the lack of tutorial I’m fairly happy with the systems that emerged. They play off each other in an interesting way, encouraging the player to be close to larger mazes to maximize the amount of time they have to explore them, and to plan their ticket usage.

Shops

I’m also happy that I was able to get a shop system implemented. It’s cumbersome to try to buy multiple copies of the same item, but pulling off click-toggled menus wasn’t easy to begin with.

New version

After finishing a jam with a lot left to do, I like to go ahead and make improvements  in a version with “Super” at the start if its name. I’ve tried to address many of the conveyance problems stated above in Super Voyage of the Magpie, as well as recording some sound effects for item pickup. I’ve also color-coded the locations by tier, so that the player knows how close they’re getting to the end. Higher tiers provide better tickets, with El Dorado as a possible drop on the top tier. From lowest to highest, the tiers are white, blue, and purple, with El Dorado a golden/orange color. After checking out the LD30 submission I hope you’ll check out the improved version too!

Pickup Styx

Pickp Styx, my team’s submission for LD31, was certainly the least buggy jam game I’ve been able to crank out and had great music and art to go with it – it’s okay for me to brag since I didn’t touch the music or art. I’m happy with the result overall, but I find myself questioning whether I over-explained the game or under-explained it.

Communication

Communication with you – the player – has always been a challenge for me. This time around, we decided to have a voiced manager feeding you goal and the rules of the game world. You play as Death, who has somehow lost or broken his boat. Still, you’re role as metaphysical ferryman cannot wait and you must deliver souls across the Styx using Frogger-like lane navigation. Some of the more obscure mechanics in the game – like moving around special stones that appear in level 5 – we explain with dialogue, but I’m not sure whether or not this worked. I found myself playing through the game and getting frustrated by the platform spawning and had to step back and remind myself that I could move stones to my advantage. The game became much less frustrating after employing a little underworld magic. Other mechanics went completely unexplained as I tried to estimate player assumptions.

The number of souls you can move around is limited. Nobody tells you that, but the player should be able to see that after they have 3 souls following them no more will join. Additionally, a red soul appears each level beyond the first – also unexplained. Each red soul you collect increases the number of souls you can lead by 1.

I’m not sure if the clarity added by explaining this in the game would outweigh the mystery of not doing so. It makes me think of the film concept of “respecting the audience.” Essentially, spelling everything out for your viewers/players insults their intelligence. Of course, players are in the position of making choices so they need to have enough information to make them fairly.

So did this cross a line? Maybe. A player might spend some time trying to get a fourth soul when they can’t actually add them to their merry band. Hopefully they’d learn from that experience, and the cost of failing to know their soul limit is just a detour. Teaching the player about moving rocks would have been good too, but I’m not sure how I could have forced them to use that knowledge… Also, ahnks = checkpoints for souls.

Design Choices

I tried to mix up the frogger gameplay by adding stepping stones to the river that can be used as resting points for the player, and that divert platforms into different lanes. Different sorts of platforms have different behaviors, and they’re introduced one at a time as you progress through the game’s 12 levels. Each level is 30 seconds long, meaning that you need to play at least 6 minutes to complete the game. This may have been too long for the average jammer. Even so, I’m happy to have been able to program a progression system and difficulty ramp, and view the later content as a reward for those diligent enough to stick with the game.

Whether or not you’re the patient type, I hope you’ll check out my submission, have some fun, and rate it!

PLAY

Also, here’s a post-jam version with a few tweaks: PLAY NEW VERSION

Mankind’s technology has been lost! Travel through time as Jesus to recover ancient technology like… Carpentry?

Also, Jesus is riding a fire breathing dragon. Did I mention that? He’s on a dragon.

Check out all of our whacky hijinks on our submission page, and be sure to rate it!