Grumpy Gamer

This is a great four-part series about Roguelikes from the GOLDEN KRONE HOTEL website.

Part 1: Burden of Knowledge
Part 2: Identification
Part 3: Terrible Controls
Part 4: Bog Standard Dungeons

Roguelikes are one of my guilty pleasures, although I don’t play a lot of different ones and I can safely say I’ve never heard of most of the games mentioned in this series (my first experience with Rogue was on a UNIX machine when I started at Lucasfilm).

One of my many side projects is working on a roguelike. I’ve never made one before, so it’s a fun exercise. Technically it’s not a roguelike (no random dungeons, no permadeath (not like it’s traditionally used)), but it feels like one. I guess they call these roguelites. Or maybe it’s the other way around?

It’s been fun to try and deconstruct the genera and see what is important and what is just legacy cruft. But much like deconstructing adventure games to “just the fun parts”, it’s easy to boil them down to something that isn’t an adventure game anymore. Not that that’s bad, but don’t call them adventure game (or roguelikes) anymore. Maybe you’ve stumbled onto something new.

Grumpy Gamer announces that Alex Jones has been banned from this site.

A Freddi Fish image mashup I thought I’d never see

Last month (maybe longer) I wrote about one of the top three production mistakes we made in Thimbleweed Park. Today like like to talk about the second one.

Just to be clear, these are production mistakes, not design or programming mistakes (although sometimes the line is blurry).

The first one was not integrating FMOD into my engine. As I wrote, it was a Penny Wise and Pound Foolish decision.

The one I’d like to talk about today is Continuous Integration, but first a little primer.

“What the hell is this witchcraft you call continuous integration!” I can hear you saying and don’t feel bad. I wonder how many indie game devs use it. My guess is a lot fewer than should (a quick poll of friends is standing at 0%).

Continuous Integration (or, CI, as the pro’s call it) is when a separate and often dedication machine is continuously building (compiling) your game whenever you check in code.

This is good for two reasons:

1. If you check in code that won’t compile on one of the platforms (I don’t care how good or careful you are, this will happen to you) the CI machine will let you (and the rest of the team) know. It helps ensure that the game can build at all times. If you can run a battery of unit tests, the CI machine will often do this as well.

2. Since the CI machine is a standalone machine, it’s dev environment is a known quantity, so installing some goofy tool or new version of python on your personal dev machine isn’t going to introduce oddities in the build.

3. Bonus point. You always have a build ready to put into test and then distributed to Steam, Xbox, etc.

I’ve used CI on previous projects and it can be a pain to set up, but it’s a time saver from then on. It’s indispensable and you should always use it!

Did we use CI on Thimbleweed Park? Of course not! That’s why I’m writing this blog entry.

When the Thimbleweed Park engine got to the point where it could actually be used and David was brought on, I thought about CI. Previously I had used a dedicated machine in the office with Jenkins installed. I only ever needed to make a Windows build (or builds that used VS) so it was one machine with a few different flavors of builds.

For Thimbleweed Park I need to make Windows, Xbox, Mac, Android, IOS (and later Switch and PS4) and Linux builds. Without some fancy hoop jumping, this was going to require three machines.

My mind fuzzed over and I said “later”.

Throughout the project I kept revisiting CI, and being overloaded with work, I kept saying “later”. As the end of the project rolled around it seemed pointless since the project was almost over. Of course, I was wrong and we continued doing updates and ports for a year.

At the time I was looking at CI, cloud-based services like AppVeyor and TravisCI either didn’t exist or never showed up on Google searches. Today you can just use these two cloud services to build Windows (or anything that needs VS), Mac (Mac and iOS) and Linux. Android can be built on any of them. If you don’t mind waiting 10 or 15 minutes for the build to start, both services are very reasonable (and free for open source projects).

In the end, I built the Windows, Mac and Linux builds on my local machine. I had the entire process scripted, so it was running a single bash script and all the Mac versions were built. I ran a Windows VM on my Mac and would launch it was run a .bat file to built all the Windows flavors. Same with Linux, boot the VM and do the builds.

Thimbleweed Park was a tad complex because there were two parts that had to be rebuilt (the engine and the game), and while intertwined, they were separate and it was common for one to be rebuilt and the other not. It was also complicated by all the game build tools being on the Mac, so you couldn’t actually build the game code on Windows. This didn’t matter since the game code/files were 100% cross-platform. I could build them on the Mac and they would run on Windows, PS4, Switch, etc.

It makes CI a little more complex because your CI might be building the engine but something had to merge it all together (another CI process). The game code needs to be built first (and you don’t need to rebuild it for each platform), then the engine process could grab it and merge it, or a third process could combine it all, but everyone would have to know when each piece was done (if a new build was needed). My point isn’t that it’s impossible, just that it’s hard and a problem that I ultimately (and unfortunately) didn’t need to solve.

Back when the project started, if I had known about AppVeyor and TravisCI, I would have set them up and ultimately saved me a lot of time and stress.

Next time for sure!!!

No, really, next time for sure.

…the cosmos is littered with time travelers adrift between the stars.

I’m quite enjoying Octopath Traveler. I’m not a big fan of other Square games and generally don’t enjoy the JRPG format, but for some reason, this game has stuck with me for hours and hours. I’ve just hit the first boss I can’t defeat (to avoid any embarrassment, I’m not saying which one).

I’ve beat my head against this boss for quite a while and I’m about ready to just quit. As a game designer, it’s an interesting experience. Players clearly have this problem with the games I design and it makes me wonder if it’s a good experience.

I’ve resited hint systems in my adventure games for almost ever and had to be beaten down by the rest of the TWP team to add one, but in retrospect, it was the right decision and should have been in there from day one.

The point of a game is to enjoy it and if a little hint, nudge or one-shot can often help someone do that. The danger for a designer is that the hint system becomes a crutch and it becomes how people play the game and they have a shitty experience because they spent most of there time looking up (or calling for) hints.

I severely run the risk of not picking up Octopath again. I’d love a way to circumvent bosses, even if it took me a little grinding to do so. Maybe there is and I just haven’t found it yet.

Hint systems are good, but they do need a little friction.

All I want to do is pass a #define on the command line to msbuild. Why does MS make this so hard? Why not have a simple /DFOOBAR option? This kind of pointless complexity drives me crazy. I’m sure some nerd at MS was super pleased with their wicked powerful solution… fine… but provide a simple solution for the thing 90% of people want to do.

Sorry, I just needed to vent.

P.S. Apparently you can do the following kludge:

set CL=/DFOOBAR

Before you call msbuild.

Yeah, but does it run GraphicsBASIC

I have a Git question. I kind of know how to do this but in a horrible brut forced way and I’d like to know if there is a “better” or more “elegant” way to do it.

The letters A-I are misleading. The actual repository has around 600 commits (and close to 1000 files/directories).

I have a master branch (A-F) and I created a new branch (G,H,I) and have been actively working on it. The master branch has had a few commits since the branch, but not a lot.

What I’d like to do is create a 2nd repository that only includes E,G,H and I. The old repository is getting huge and the new branch (G,H,I) has become significantly different from the master branch.

Is there a clean way to do this? I assume it involves –rebase, –reset, –hard, –or-your-fucked flags. I really love Git, it’s amazingly powerful and equally as confusing.

Given there are hundreds of commits and close to a thousand files and directories, I want something that doesn’t involve me having to interact with each commit or rechecking in files. The history from E-I is important to keep (and is way more than 4 commits).

Not sure where the phrase “penny wise and pound foolish” comes from. I suppose I could look it up on the internets, but that seems like too much work. As a kid, this phrase made no sense to me, it was only later when I realized that a “pound” was a form of English money that it kind of fell into place.

We did a lot of things right when building Thimbleweed Park. We also did a few things wrong. It goes with “making games”.

One of the things I messed up on was not integrating FMOD. For those of you not in-the-know, FMOD is a cross-platform music and sound middleware engine and it’s quite impressive.

When Thimbleweed Park started, one of the decisions I had to make was what to do about sound. I was using a thin layer of SDL to create windows and pass along input events (rendering didn’t use SDL for performance reasons). SDL also has a minimal sound system called SDL Mixer. It was bare bones, but it got the job done for the simple prototypes I was working on at the time..

When Thimbleweed Park pre-production started, I looked into sound systems. The two big choices were Wwise and FMOD. At the time, FMOD was charging $5000 for the first platform and a few thousand for each additional platform. They did have Indie pricing where the first platform was free if your budget was less than $500K.

Since we raised $560K+ on Kickstarter, this was just out of reach. I suppose I could have fuged the budget, but I don’t like to do that kind of stuff (and the Kickstarter amount was very public), plus I always knew there was the possibility that we might raise more money. $5000 + the additional platforms would bring the licensing cost of FMOD to just over $10,000. I was pretty paranoid about the budget and not having enough money to finish the game. I really didn’t want to be one of those Kickstarters that runs out of money due to poor planning or scope creep.

So I made the decision to stick with SDL Mixer. It got the job done. I was being penny wise.

SDL worked great on Windows, Mac, and Linux, but when we started the Xbox/Win10 port we began to run into issues and ultimately decided to ditch SDL for that port. Along with ditching the main part of SDL we also lost SDL Mixer. In the beginning, it didn’t seem like too much work to recreate the simple backend sound system of SDL Mixer and like most things (about to get crazy fucked up), it was up and running pretty quickly.

On the PC side, David and I started to build the game and with that came wiring in sound effects. In the beginning, it was pretty simple, but as we proceeded we got a lot cockier and wanted more complex features in the sound system. So I added them. And added more. And then added more.

Evolving the sound system became a large chunk of work for me and each time I did that, we needed to make sure the Xbox/Win10 version was on par. This was the beginning of warning signs I should have caught, but like boiling that frog (which is a myth, btw) before you know it, the water is boiling.

There were a couple of times I thought about FMOD but figured integrating it at that point would be too much work (how wrong I was).

When we raised some investor money to do new ports, we also had a little extra money so we hired Elise Kates to create sounds. This only complicated matters because her sounds were a lot better than our “programmer sounds” and she wanted to do more complex audio. So I added to our homespun sound engine. More work for me (and everyone else).

Then we started the Switch and PS4 ports, neither of which could use SDL out of the box, so we had to get the sound engine working on those new platforms.

Yeah, in the end, we spent way more than $10,000 on sound coding. Penny wise, pound foolish.

A month ago I was bored (when I run into creative blocks, I build tech) and thought “Hey! I’m bored. I’ll integrate FMOD into my engine. It took me two days and FMOD was fully functional.

Plus… FMOD changed their license, so it is now it’s a flat $5000 for all platforms (and still free if your indie budget is less than $500K). Not only would FMOD have saved us a bunch of money, we would have had much better SFX too boot.

If I look back on the three big things I regret about Thimbleweed Park production, not integrating FMOD is one of them.