chrismcmath

LD33

The Three Knows of GameDev – A LD33 Post-Mortem

I’ve come to revere Ludum Dare as a tri-annual marathon of determination, time management and polymathy. Even so I was not prepared for the turbulence this particular jam would bring. Having just come off work on various side projects I’d entered the weekend brimming with a great sense of energy and ability. How soon those two allies deserted me!

Were I to invent a time machine before I die, I would want to waste no time planning what to do with the technology. So here’s what I’d say to my pre-LD33 self.

I’d say…

‘Know the Three Knows!’


Know One: Know What You’re Making

Design is fun. Especially the bit without the design. Just saying stuff in a stream of ‘What If’-ism; one’s creativity taking flight and pirouetting across the warm canvas of possibility. Down below is cool reality, a series of etched hills and smudgy troughs. Mountains of design so well detailed they seem to implement themselves, but the troughs…

Oh the troughs are all too easy to overlook. In the troughs are shadows, those areas of design the free flight of creativity is blind to. They seem so innocent now, but come the 12th hour, perhaps the 24th, or maybe even 36th and they’ll prove to be your undoing.

‘Beware the design shadows, my son!
The work unseen, the flaws that forsake!’

Here, courtesy of Robin D. Laws, is a shadow we’d all do well to avoid.

So simple, yet it was only on Day II I realised I hadn’t done this, having allowed myself to be transfixed by the procedural features of my game. Now you wouldn’t know it, but there is a conceptually infinite number of planets in The Last Little Monster. Most people who play only see two or three of these. That leaves infinity minus three planets unexplored.

Like a window into another world

Did I need to spend the majority of the first day working on this? And if I did, the question of how to integrate it better into the core gameplay loop should have out-prioritised the implementation of it.


Know Two: Know Your Tools

As a Unity developer of a few years I often assume capability in systems I have little working knowledge of. Complex systems such as the PhysX engine may be conceptually simple, but then so is cooking and I still get food poisoned on a monthly basis. I had a humbling half hour near the deadline with the Unity UI system; where was the box that took CSS?

Er… this one. No wait, that one.

Music and art are notorious time sinks, and one should assume that anything one makes will end up in the final game. Had I truly grokked that notion earlier, perhaps I would have spend five more minutes on this guy.


Know Three: Know Thyself

As a test of polymathy, LD jammers wear many hats over the course of a weekend, and knowing which hat you’re wearing is crucial to fulfilling the related subtasks.

Careful now, I’m going to get all De Bono on you.

The Blue Sky Hat (What Could You Do?)

This is the hat that can get you in trouble, but can also light a fire that will keep you motivated through the weekend. This is the mindset that makes you want this feature, and that one, and how about this? And what if this does this, like in that game and that movie?

This hat really doesn’t care about what any of the other hats think. It’s the T-Rex of the park; it pulls in the punters but can also eat them.

The Design Hat (What Should You Do?)

The design hat is the electric fence to the T-Rex. It is measured and analytical. It is cool and conservative. It is not what is popularly thought of as ‘game design’. It is about reducing complexity, not increasing it. Gawd it sounds like a drag doesn’t it? Well it’s the ying to the Blue Sky’s yang, and without it you end up working on a procedural planet generation system for a day. So heed it well!

The Implementation Hat (What You Actually Do)

The Design Hat may be a downer, but at least it talks to you. The Implementation Hat doesn’t want to be interrupted so no thank-you I wouldn’t like to see whatever thing you were just laughing at. It’s the hat that gives Software Engineers a bad name. It’s the hat the reveals all and every flaw, and is the hat that bears the brunt of that disappointment. It is also the hat that requires the most concentration to wear, and will start to disintegrate as your brain gets tired.

You may have noticed using all of these hats yourself, but perhaps without consciously thinking about it. They are used at both high and low levels; each subtask will contain their own cycle of the hats. Due to the short time limit of Ludum Dare it’ll be difficult to get more than a couple of iterations in for any subtask, but making sure they happen in the correct order can save you from, well, this:

Due to the repeating nature of this process, the implementation of any design needs to be flexible enough so that it can support as many iterations as possible. This could include, or example, exposing your variables so that they’re modifiable in game, or encapsulating your behaviour in such a way so that it can be switched out without having to rewrite any other code.

My greatest error in LD33 was not realising this, which gave birth to a monster. It’s a monster which I’ve heard mentioned and even praised in rapid game development. It is The Prototyping Mindset.

The Prototyping Mindset says that there is no need to even try writing clean, maintainable code, because Hey this is just a prototype and we’re going to throw it away anyway. It is an attempt to avoid ever wearing the Implementation Hat, instead just running with whatever the Design Hat wrote on a napkin.

But design is an iterative process, no matter so irrelevant or hastily made the product. The Implementation Hat already has a rough deal; it doesn’t need The Prototyping Mindset undermining it further. The symptoms of this will slap you when you’re at your lowest. It must have been 2am when I found myself writing this piece of code, possible the worst I’ve ever written.

NSFW

Remember this is the symptom of a poor implementation, a symptom of The Prototyping Mindset. A greater reverence for the Implementation Hat creates a platform for iteration allowing the hats to be greater than the sum of their parts. It also paves the way for code reuse; no more fear of a repository stopping you from turning that Kitten Meow-generator into its own library.

One last note- it’s OK to go crazy. It’s just one weekend. Better to go full throttle and reflect than to phone it in, or even worse quit, and have nothing to learn. It’s a weekend to disregard your emotions and give it your all.

After all, it’s not like you have a time machine to do it again.

If you’d like to play the game that inspired this write-up, click here!

This article has been cross-posted on DevPact.

LD 43

Level Design for Dodos

T-minus 2 hours to the jam deadline and we still had to build the level for our platformer Way of the Dodo.

We had the mechanics and assets all done, now we just an experience that would show them off.

Level design - how hard could it be?

dodo_maker.png


What's in a Level?

The platformer is a mature genre with conventions well established. Nevertheless it can be difficult to understand which conventions give rise to which experiences. As big adventure fans we wanted our sacrificial dodo simulator to have a similar feel to its inspiration Yoshi's Island. How does that game create the feeling of a wild journey in a living breathing world while the Mario games before it felt more like obstacle courses?

Our Lens

Let's examine a couple of famous levels through the lens of objectives. We'll be looking for three aspects:

  • Main Line - this is the player's most direct route to the end of the level (we can think of it as the 'main objective')
  • Secondary Objective - this is any objective just off the main line that provides the player with a reward
  • Secret Area - this is an area that is hidden off-screen and provides an entirely optional and supplementary gameplay sequence. Its existence must be hinted at.

Although secondary objectives help give players a sense of ownership, it is the secret areas that are the true heart of exploration. They are the players' own discovery and so are the experiences those players will hold as their own.

Mario in Review

In these classic first levels from the Mario canon

  • the main line will be shown with a red line
  • secondary areas will be highlighted with a pink box
  • secret areas will be highlighted with a yellow box.
Super Mario Bros.

mario_bros.pngSource

The original Super Mario Bros contains many secondary objectives. If you were to count every question block as one it'd have many many more than are displayed here. The level even contains an area with two equally valid paths just before its centre. It only contains one secret area (which serves the purpose of speeding up progress for seasoned players) but provokes exploration via hidden question blocks. The main line is straight and there are only three 'levels' to the course, all of which are visible at all times on the screen. Others stages in the game will provide secrets (warp zone and vines to the clouds as examples) but these are exceptions rather than the rule.

Yoshi's Island

yoshis_island.pngSource

In stark contrast the first level of Yoshi's Island has four whole secret areas. The main line also changes direction twice during the level, and undulates at lot throughout the rest of the course. Furthermore many areas are off-screen and hinted at via various visual cues and pattern repetitions. The first secret, heavily signposted, informs the player that this is game where going right is not always the only path. This idea is repeated in the fourth secret area, where having climbed the beanstalk the player can go the opposite direction as the signpost to find a Smiley Flower and hidden question cloud in the crevice below. You can really tell that this was designed to be a different experience, something mirrored in the slower pace and expanded move-set of the game.

If you've played these games this makes a lot of sense. The earlier Mario games feel 'more hardcore' akin to later masochistic platformers like Super Meat Boy, N++ or Oco, while later games like Yoshi's Island and the 3D platformers feel more like grand, accessible adventures.

Way of the Dodo

As we wanted Dodo to feel less like an obstacle course and more like an adventure, we wanted to ape this latter style, and so...

  • We needed a main line that changes direction
  • We needed a consistent flow secondary objectives (present in both styles of platformers)
  • We needed many secret areas

Level Designers' Toolkit

So we know what aspects we need in our level, but how we can create them? The original Super Mario Bros. uses coins, lives, power-ups and shortcuts to act as goals for their secondary objectives. Yoshi's Island additionally uses red coins, sunflowers and health, all of which unlock additional content for the game. The greater the rarity of a collectable however, the more restrictive their placement becomes. With this in mind, let's look at the most common of collectables, the 'coin'.

The Purpose of Coins

Coins (in our game, bolts) are so versatile they have become a fixture of the platform genre. When I first started laying out the level, I was placed them all along the floor like breadcrumbs. It wasn't engaging. Why not? Why is it that in most 2D platformers coins are very rarely placed directly on the 'main line'?

Because when they're on the main line they add nothing but a juicy particled dopamine hit on collision. Their placement needs purpose and fortunately for coins they can have several. This can sometimes lead to their placement appearing haphazard, but knowing why a coin is somewhere firms up the visual language of the level, making it easier for the player to parse.

Here are three reasons behind coin placement.

Posing Optional Objectives

This is the bread and butter of coin systems both in 2D and 3D; they provide a low-effort secondary objective just off the main path. Players can decide whether to engage and collect them (they are, of course, rewarded with coins) or ignore the objective altogether. This may not be as explicit as a secondary objective in an RPG or other, but the player nevertheless has the same choice, and can organically move in and out of the objective without much effort. As a trivial example, think of coins placed just above the main line, forcing the player to jump. It's short, simple and entirely optional.

Providing the Player Hints

As secrets are often hidden off-screen, it is important for a level designer to give the player opportunity to discover them. This can be achieved through object placement, set dressing, or even coins. Here for instance, we used a bolt at the top of the screen to indicate the presence of a secret area above.

dodo_bolt.png

Leading the Player Forward

This is closest to bread-crumbing and can easily be overused, but sometimes the player might need an extra incentive to drive them forward. This might be because of a convention being broken (i.e. moving left instead of right) or a challenging hurdle (yes, you can make this jump!).

The Purpose of Better-Than-Coins

collectables.pngOur collectables: bolts and eggs

One issue you may have noticed in the original Super Mario Bros. is a secondary objective or secret area's payoff can sometimes be out-of-proportion to its buildup. A secret pipe only leads to an small increase in coins, a trip to the clouds perhaps a few more. Beyond extra lives (and the rare but mind-blowing warp-zone) there is little the level designer has to dangle in front of the player. It's no wonder then that each subsequent game added more and more rewards to complement coins.

As we wanted to give the player a big(-ger) payoff for discovering secrets we made a second, rarer currency in the form of eggs.


How'd We Do?

Here's a look at how the level turned out.

dodo.png

As you can see the main line is anything but straight forward, going up, left, right and down in different places. We used bolts to create secondary objectives that allowed players to practice new mechanics, hint at new areas and provide forward momentum. We also created four secret areas, three of which feature an egg as a reward.

We also tried to teach the player the mechanics in an intuitive and pressure-free way, but that didn't go quite as planned!

So ends this non-exhaustive review of our approach to level design. If you have any thoughts or criticisms on the topic we'd love to hear from you, and if you'd like to read about our inspiration for the game my partner-in-jam @pilchard did a great write up here: https://ldjam.com/events/ludum-dare/43/way-of-the-dodo/way-of-the-dodo.

And if you'd like to give it a spin you can play the game here: https://ldjam.com/events/ludum-dare/43/$133195

Thanks for reading!