The Tallest Tower

Development Blog

A Motto for Tools


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.

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.

Post a comment



Comments and Twitter


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.

Post a comment



The Scrapheap


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.

Post a comment



My Stephen's Sausage Roll Epiphany


Screenshot of Wretch's Retreat

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.

Post a comment



A Brief Tour


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.

Post a comment



Welcome!


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.

Post a comment