Ok fine, I can’t actually teach you how to be funny from nothing. I don’t have that kind of talent. But whatever level of funny you’re at right now, whether in writing or in everyday conversation, I might have a trick or two for wringing out a little more.

1. Move the punchline to the end

Holt: (pretending to be straight) You should have seen Jamie-Lynn. She looked exactly like Maxim Hot 100 honouree Jasmine Sanders.
Guard: It just seems like you want to be with Jamie-Lynn. I mean, you keep talking about her thigh gap.
Holt: That’s my favourite part of a woman. There’s nothing more intoxicating than the clear absence of a penis.
- Brooklyn Nine Nine, S05E02

Humour is intrinsically linked with surprise. Jokes generally have a punchline: a word or handful of words that reveal the surprise. To deliver the surprise, shuffle it to the very end of the last sentence. You might need to contort your grammar, but it’s worth it.

Consider this much worse alternate phrasing:

Holt: (pretending to be straight) You should have seen Jamie-Lynn. She looked exactly like Maxim Hot 100 honouree Jasmine Sanders.
Guard: It just seems like you want to be with Jamie-Lynn. I mean, you keep talking about her thigh gap.
Holt: The clear absence of a penis is my favourite part of a woman. There’s nothing more intoxicating.

See how it just kind of…flops out? After the word “penis” the joke’s been revealed, but you still have a bunch of sentence left to say. You want that reveal right at the end.

Another example:

Luke: [holding a music keyboard] Hey dad, I think I found a place online where I can sell this organ. Can you drive me to the black market?
Phil: I think they mean a different kind of organ, buddy.
- Modern Family, S02E07

I love this joke. It’s a run-of-the-mill lame pun, but by following this structure, its reveal is genuinely surprising and so it works. The punchline here is “different kind of organ”, and it’s gotta go at the end. Pull people through the setup without revealing where you’re going, drop the punchline that reveals the joke and the surprise, then stop talking. Set up, punchline, shut up.

2. Be brief

This is good advice in general, but applies doubly for humour. Humour is leading your audience blind down a garden path. They’re trusting you have something worthwhile to show them at the end, and the longer the path, the more worthwhile it’d better be. Choose a shorter path and you merely have to be funny, not religious-experience hilarious.

Jokes are often interjections. They exist between plot points, or are off-topic diversions in a conversation. The quicker you drop your joke and hand back the talking stick, the less people mind the interruption.

In the same vein as being brief: Don’t linger. In writing, don’t have characters spend a ton of time reacting to the joke, or calling attention to its insanity. Either no reaction or a lightning fast reaction, then move on. Gina’s reaction to the first joke here is about right.

This is also a good defence against a joke not landing. A percentage of your jokes flopping is a certainty, but if the line only took three seconds to deliver, no biggie.

3. Be specific

Son: Dad, why is my sister named Paris?
Dad: Well, your Mom and I were in Paris when your sister was conceived.
Son: Makes sense, thanks Dad!
Dad: You’re welcome, Coachella Outhouse.

If instead you used “You’re welcome, outhouse” or “You’re welcome, backseat”, it’d be the same joke. But the extra specificity calls to mind an image that really adds flavour. A Coachella outhouse flavour. Yum.

Another example:

Holt: Here are two pictures [holds up two photos]. One is your locker, the other is a garbage dump in the Phillipines. Can you tell which is which?
Peralta: [Points at one] That one’s the dump.
Holt: They’re both your locker.
- Brooklyn Nine Nine, S01E02

See that “in the Phillipines” bit? In the name of being brief, you might have considered cutting that. But specific is funnier than vague. Make it concrete, something we can visualize, something we can relate to. It’s worth the three extra words here.

4. Exaggerate to extremes

If you’re The Office and Michael is impressed at the car GPS, don’t just have the GPS send him down the wrong route, have him drive into a lake. If you’re Community, don’t just have a housewarming party go wrong, have it devolve into a fiery nightmare.

Push your jokes as far into the ridiculous as you can. You can always dial it back if you don’t like it, but it usually gets funnier the more ludicrous it is. Foregoing that is leaving humour on the table.

Exaggeration pairs nicely with Be Specific. A specific, visceral hyper-exaggeration is an artform unto itself.

5. Respect your audience

Your audience is smart. I’d rather ten jokes fly over their head than have one joke I over-explained. The first draft of this article pointed out the use of “flops out” above as a penis joke. But I removed that in an edit. Everyone gets it already, and if they don’t, that’s fine too. Besides, this way I can use it here as an example, where I still get to point it out, but now in an acceptable meta way. Win-win.

6. Have a filter

I’m not telling you to censor your hard-hitting hyper-political standup routine. Just know your audience, and make sure you’re actually being funny to them. Humour often lives at the border of what’s comfortable, and it’s okay to walk that line, just maybe run it through your head once before you say it out loud. Different audiences call for different humour.

Besides appropriateness, filter for quality too. Plenty of jokes will arrive in your head half-formed, and if you can’t work it into a proper joke, leave it be. If you want to be known for quality, prune anything that’s only half-funny.

7. Let it go

No joke idea in your head is holy. There is no line that must be said no matter what. If the conversation moves on, if you never get your opening, if the moment passes, let it go. Another opportunity for a new joke will come along, focus your effort on that.

I plagiarized this rule from Colin Mochrie of Whose Line is it Anyway fame. Something tells me he might know his stuff.

8. Break the rules

It’s an unbreakable rule of rule lists that every list of rules has a rule that says to break the rules. Some of the rules above conflict with each other, and you’ll have to decide which to prioritize. Sometimes you’ll see an opportunity for a joke that’s funny, but the rules here don’t seem to improve it. Humour is fickle and unscientific. If you have good reason, break the rules and don’t look back.

To design a good puzzle, first build a good toy.
        -Scott Kim

In puzzle game design, it’s useful to consider how a puzzle or mechanic behaves as a toy.

You can evaluate a puzzle game’s toy by examining how the game would play with the levels and goals removed. Throw the player in a barebones stage with no objective. Is this still enjoyable? Interesting? What can they learn and discover just from playing around? How satisfying is this process?

Think about what this looks like for a game like Portal. In an empty level, you could place one portal on the ceiling and another on the wall in front of you, look down at yourself, then walk through the portal and drop down to where you just were. You could place one in the floor and one on the ceiling and fall forever. Devoid of an objective, Portal’s mechanics are still a joy to tinker with.

Now contrast this with Stephen’s Sausage Roll. In an empty level, you could move some sausages around with a fork. Maybe you figure out you can spear a sausage by pressing it against a wall. Stephen’s Sausage Roll is a fantastic, meticulously designed game. But its mechanics don’t have the same toy-like properties as Portal.

The quality of a puzzle’s toy seems to correlate with how ‘mind-bending’ the central mechanic is. When I solve a puzzle in Portal, I feel like I’m breaking the laws of the universe. Like I’m wrapping my mind around a new way of thinking. When I solve a puzzle in Stephen’s Sausage Roll, I just feel really smart. Still great, but not quite the same.

A puzzle’s toy also makes the difference between an enthusiast puzzle game and one with mainstream appeal. This distinction isn’t just the difficulty of the puzzles. An enthusiast puzzle game often has puzzles and nothing else, puzzles based on mechanics that wouldn’t be much fun to experiment with devoid of a goal. A puzzle game with mainstream appeal can be just as challenging and explore mechanics and ideas the same way, but is practically required to have a good toy.

Put another way: A good toy means a good hook.

Below are a few puzzle games I’ve played, evaluated for how they function as a toy. I’ve picked exclusively outstanding games here, and for a reason: I want to evaluate the quality of the toy independent of the quality of the puzzles. A good toy is far from the only factor in making a great puzzle game, and there are many phenomenal puzzle games with bad toys. But my hope here is to hone this specific lens so we can evaluate our own ideas and make the best possible toys for our games.

Portal

Portal is the best example of a toy I know of. Throw a player in an empty room with a portal gun, and they will immediately start experimenting and trying to wrap their head around it.

Much of the appeal of this toy hinges on some key details:

1. The game plays in 3D first person
2. You can see through placed portals
3. Movement is continuous and momentum is conserved between portals, as if a rift between the two locations in space truly exists

Remove any of these details and it becomes significantly less mind bending:

1. 2D Portal exists, and it’s much less viscerally interesting to play with.
2. Half the joy of portals is peeking through to the other side and seeing what’s there, or seeing yourself from a different angle. Remove this, and suddenly the two locations in space don’t feel seamlessly connected. You can set Portal Render Depth to 0 in the settings to get a feel for how much less satisfying this is.
3. If the ability to look through portals makes them visually convincing, then conservation of momentum makes them physically convincing. It also makes entire classes of interesting puzzles possible (for example, flings).

Stephen’s Sausage Roll

Stephen’s Sausage Roll doesn’t have a good toy. Pushing around sausages isn’t intrinsically interesting, and the game doesn’t provide notably pleasing aesthetics for doing so. That aside though, it’s a painstakingly designed game that deeply explores the mechanics of this sausage-pushing through a gauntlet of challenging puzzles, which all told took me around 50 hours to complete.

These are classic traits of an enthusiast puzzle game: Amazing puzzles, mediocre hook.

Braid

Braid’s time travel mechanics are a great toy. The passage of time is something we’re all innately aware of and spend plenty of time pondering, and this real-world contextualizing helps its appeal as a good toy. Many of us have discussed with friends or enjoyed fiction about concepts like time travel.

Like Portal, the toy-like feeling of Braid’s mechanics also lean on its aesthetic presentation. Remove the reversed music and the visuals of rewinding objects, and you lose some of the effect. Remove the fluidity and seamlessness of rewinding, and you lose even more.

In the worst case, imagine playing Braid with YouTube-style rewind controls: pressing the left arrow suddenly snaps you one second into the past. This is a much worse toy. The rewinding no longer feels as fun to play around with, even though you could still solve the puzzles like this.

We’re seeing an interesting pattern emerge: The presentation of a mechanic plays a significant role in how good a toy it makes. This isn’t too suprising. But it does help us understand that a good toy doesn’t just come down to the core concept. That concept must also be supported by good execution and visceral communication of the idea.

Snakebird

Snakebird centers around moving several creatures in a manner similar to the classic game Snake, but with gravity. Many interesting consequences emerge from this, but much like Stephen’s Sausage Roll, moving these snakebirds around without a goal is fundamentally not all that interesting.

Antichamber

Rather than having one central toy, Antichamber is more a collection of different toys around a central theme. Some of these toys are fantastic, like the non-euclidean geometry, or the world changing depending on where you look. Some are less so, like the cube gun.

The Witness

The line puzzles in The Witness aren’t a particularly good toy. There’s some toy-like nature to the puzzles with more environmental aspects as you push further into the game, but it’s still minor.

Baba Is You

The very first level in Baba Is You drives home how good a toy it is. You control Baba with the arrow keys, and to pass this level you just need to touch the flag. Easy enough.

But you’ll probably play around a little first. You might disconnect Wall Is Stop, and realize you can now walk right through the wall. And then you might connect Wall Is You and Baba Is Win, and suddenly you’re moving around the level as the wall, and you win when you make the wall touch Baba. This first level is basically the empty level test I described above, and it passes with flying colours.

Remarkably, Baba Is You is creates an outstanding toy with zero reliance on aesthetics or specific visual effects. The previous examples of good toys all rely at least partly on visuals, but Baba Is You proves that fancy visuals are not a requirement for a great toy. The mechanics interact in unexpected ways, and it’s the surprise of turning into a wall, or suddenly filling the entire level with Babas (and winning!) that makes this toy delightful.

Takeaways

1. A good puzzle game greatly expands its appeal by having a good toy.

2. A good toy is a good hook.

3. A good toy usually isn’t something you can polish out of an existing game. You must be evaluating your toy from the start, as the nature of the toy is at least partly intrinsic to your core concept.

4. Effective toys have some combination of:

   • Plentiful and delightful surprises.
   • Contextualization to our lived experience. The more fundamental and relatable the mechanic is to our understanding of the world (eg. space and time vs. how snakebirds move on a grid), the better.
   • An effective presentation to let us viscerally experience the nature of the ideas we’re exploring.

I propose that all software tools adhere to the following motto:

Do your job, then get out of the way.

We all know what it looks like when you don’t follow this rule. You get Nvidia GeForce Experience. Or Visual Studio. You get that tool you downloaded for a one-time filetype conversion, only to find it wanted to scan your entire computer first, chew up 75% of your idle CPU time, set up an auto-updating system, subscribe you to its newsletter, and give you handy-dandy tips every time you open the tool.

Think about all the tools you use that assume they’re the center of the universe. Where it feels like the software takes every opportunity to remind you how awesome it is, and tell you all the amazing things it does that you don’t need.

It sucks, right? Don’t do that.

A good software developer thinks like the user. And users don’t care at all about your software. They just want to convert three PNGs to JPGs so they can email their mom photos of their dog. What is the software that would best allow them to accomplish this goal? Would this person want to read startup tips? Will they wait around for five minutes while the tool scans their filesystem for images?

The best tools I use are very specialized. They have one job, and they do it damned well. If you want to write a good tool, this is a valuable mindset to take. Not only will it make your tool better at its job, but it will help you:

• Fight scope creep
• Eliminate features that aren’t truly needed
• Keep the UI simple and focused
• Keep your software lightweight and trim (and fast)

There’s nothing wrong with having many sharp, specialized tools, each finely-tuned for one particular job. I’d rather that over one tool that does a mediocre job at many things. I call this collection of tools my programmer’s toolbelt. There’s a reason carpenters carry a hammer, and a drill, and a nailgun, and a saw, and a framing square, and a level, and a tape measure…

My go-to case study for this philosophy is the search program Everything.

You hit a hotkey, a window opens. You type until you see what you want, then select it. The file opens. Everything closes, because its work is now done. It does its job, then gets out of the way.

Everything’s adherence to this motto makes it a joy to use, and it’s been part of my programmer’s toolbelt since my first job in the industry.

Some updates:

1. The website now supports comments! Please post thoughts, questions, and bug reports to your heart’s content. I promise to read them all.

2. The Tallest Tower is now on Twitter! Follow us, and tweet at us with great vigour.

I just wrote what I’m calling the “scrapheap” to supplement the D garbage collector. It’s basically just a linear allocator:

• A 16 MB pre-allocated chunk of memory, acquired from the OS on startup and never released
• Other code can allocate into that chunk using a dead simple bump-the-pointer stack
• The stack is reset at the end of each frame, therefore “freeing” the 16MB and making it available for use again

It’s very desirable to be able to allocate small amounts of short-lived memory without having to think too much about it. For example, when parsing string input, I might do the following:

bool DoesItMatch()
{
    string[] optionWords = optionText.strip().removechars(".,!'").toLower().split();
    return optionWords == someOtherThing;
}

Being able to do all that string manupulation in one line is really nice. I don’t have to manually allocate buffers or anything, it’s all taken care of. In D though, normally this allocates several times via the GC, even though once this function returns, I don’t use any of the allocations ever again.

Enter the scrapheap.

To enable it, I add one line to the beginning of this scope:

bool DoesItMatch()
{
    mixin(ScopeScrapheap!());
    string[] optionWords = optionText.strip().removechars(".,!'").toLower().split();
    return optionWords == someOtherThing;
}

This mixin tells the GC that from now until the end of this scope, every allocation should be redirected to the scrapheap. Now all the allocations in this function are effectively free (just the cost of bumping a pointer), and deallocation is free (resetting the pointer at the end of the frame). As long as I’m not expecting any of the allocations to outlive the frame, I’m in the clear.

For use cases like this, a scrapheap allocator the best of both worlds. Convenient-to-write code, without any allocation or deallocation overhead or contribution to future GC pauses. And these use cases make up a significant portion of the allocations that occur in the game each frame.

We use a stack to keep track of the currently-active allocator. That way we can switch to scrapheap mode for a large function, but then inside have a single function call that switches back to GC mode, and then inside of that have a subsection that uses the scrapheap, and so on. Switching to GC mode is what you’d expect:

mixin(ScopeGC!());

Each thread gets a separate scrapheap and allocator stack, albeit with a much smaller allocation size if they’re worker threads.

The scrapheap also eliminates the need for stack allocations via alloca(). Anywhere you’re allocating dynamically on the stack, just use the scrapheap instead. The allocator stack model also means we can easily write additional specialized allocators if we decide to in the future.

The idea of a per-frame linear allocator for throwaway memory is not even remotely new. Despite this, when discussing memory management, I still sometimes hear the refrain that “Allocating is always going to be expensive.” If you use the right allocation schemes in the right places, this doesn’t have to be the case.

It’s said that after experiencing a great creative work, you’re a different person at the end than when you first began. I just experienced this, in a game where you roll sausages around with a fork.

Stephen’s Sausage Roll is one of the most challenging and well designed puzzle games I’ve played. Give it a try before reading on, because I’m about to spoil one of the levels.

I’m a programmer by trade, so it’s no surprise I like puzzle games. And because of the whole programming thing, I probably have above-average grit when it comes to puzzles. I generally don’t look up hints until I’ve spent three or more hours on an individual puzzle, completely stumped.

There’s a puzzle in Stephen’s Sausage Roll called Wretch’s Retreat. I spent six hours on that level. Two were mapping out all possible avenues that might lead to a solution. The other four were checking and re-checking my reasoning, retrying my attempts to figure out what I could possibly be missing. In these four hours, I made virtually no progress.

Eventually I gave in. I turned to the internet to find the tiniest clue to nudge me in the right direction. I found this Steam discussion, which turned out to be the perfect hint.

The author itemized their assumptions about the rules and logic of this level, along with each potential solution and why none were viable. I nodded along as I read this, these were the same assumptions I had come to. Then, in a reply to their own post, the author wrote:

Nevermind, I solved it. Unbelievable. Stuck on it for so long, as soon as I make a post it hits me. If anyone is wondering, the error was assumption (#2).

After reading this, I solved the puzzle in thirty seconds.

The hint hadn’t told me what the solution was, or what I should try next, or what about my assumption was wrong. All it told me was that one of my assumptions was wrong. Which, of course it was, otherwise I would have solved the puzzle already. But simply being told the faulty assumption was enough to make me question it in a way I clearly had not yet, and arrive at a solution immediately.

If I had itemized my assumptions in the same way, and mechanically gone through them one by one actively trying to disprove them, I would have arrived at the solution on my own. If I had told myself “Okay, let’s pretend for five minutes that this thing I’m certain is true is actually false, and try to demonstrate why”, I would have found the hole in my reasoning. I’ve done a lot of problem solving in my life, and don’t think I’ve ever explicitly needed to do this before.

Thanks to Stephen’s Sausage Roll, I’ve added a new tool to my problem-solving tool belt.

As an aside, it’s also fun to see the poster of that discussion discover rubber-duck debugging, a well-known problem-solving technique in the realm of programming.

For those with a more technical leaning, here’s the rundown on what I’m using for the game:

• Custom 3D engine written in D
• SDL2 for windowing, events, and other utilities
• D3D11 for 3D rendering
• FMOD for audio
• dear imgui for debug UI and in-game development tools
• msgpack-d (ie. MessagePack) for serialization (save games, debug game state snapshots, dialogue database)
• Python for build tools and miscellaneous scripts

I’ll dive into each of these in more in detail at a later date. For the prototype, I’m using SFML for 2D graphics, windowing, and events. This will be tossed out in favour of the above once the prototype is complete.

Aren’t custom engines a terrible idea for indies?

Rolling a custom engine is a huge undertaking, and can be risky if I’m not careful. However I decided to go with it because:

• I’m picky about my tools. Writing my own engine lets me handcraft custom tools to create efficient workflows.

• I’ve been bitten many times by closed-source libraries and engines that exhibit bugs, poor performance, or crucial missing features that I have no recourse for fixing. If I’m serious about shipping a robust game, I always need the ability to dive in if needed and make things work right.

• I come from a programming background, specifically rendering programming. I have some familiarity with the lower-level workings of games and a head start on the knowledge required to build a 3D engine. This won’t stop it from still being a ton of work though.

• I can better leverage my strengths as a programmer to work around my weaknesses (like art). For example, I have total control over the shading pipeline, and can build one that supports a visually pleasing look without requiring enormous amounts of high-fidelity art. I can spend time writing a good lighting model that makes even simple coloured cubes in a grey room look good.

• To make an engine, I don’t have to reimplement all of Unity or Unreal. The tech I build only needs to drive my game alone. I can make enormous simplifications based on assumptions that hold true for the particular game I’m developing.

• Writing a game engine is fun

Where possible I try to give myself total visibility into any source code used in the game, since this allows me to add features and fix issues in library code I’m using. And there are always issues. In its prototype stage, I’ve already made source modifications to SFML, imgui, msgpack-d, and even the D language runtime and standard library. I anticipate making many more as work continues.

I spent a while evaluating other audio libraries, but none of them had all the features I was looking for. BASS was close, but they don’t sell a source code license. Wwise was another contender, but it appears you’re forced to work from within their designer tool. Using FMOD for audio makes me a little nervous since it’s really the only place I’m using an opaque DLL with no available source code. However I’ve heard positive reviews of FMOD and its API, and so far my experience has been great. If all else fails, they do sell an (expensive) source code license.

Welcome to the development blog for The Tallest Tower!

Over the last few years, I’ve been doing some thinking about stories and conversation in games. I have a lot of thoughts about a particular kind of game I’d like to see made, and how story can be entwined into the experience in interesting ways. When I look around, I see the occasional game with bits and pieces of what I’d like in this hypothetical game. But no game yet has captured the entirety of what I have in mind.

So, I’m going to make it.

Currently I have the basics of an engine and the first parts of the game up and running. It’s only a simple prototype at this stage, but that will change as the game grows and evolves over the coming years.

The name “The Tallest Tower” will change before the game is done, but I need some sort of working title. No guarantee of any towers appearing in the final game, tall or otherwise.

In any case, welcome. I’m glad you’re along for the ride.