I am currently preparing not one but two GDC talks, and someone asked for tips on giving presentations, so I figured I would write a quick blog post about how I approach this.

Note that I don't know if I give great talks - I find it hard to get truly useful feedback - but generally I get decent ratings and am invited back to events.

First, I come up with an idea. I write a pitch and convince someone I should give a talk. This is worth its own blog post but it's not this one. Then I start to actually work on the presentation.

Then I feel I am not the right person to give the talk, or my argument is stupid, or I am not capable of giving it. I panic and consider cancelling the talk, changing my name, and living in the forest. That's a normal part of my process and I just need to push through it.

Read more…

I recently gave a private presentation on how to implement save games. This is the blog post based on that. I wrote the presentation pretty quickly, so this is not the best structured blog post ever, but hopefully it's useful to someone.

Should you listen to me?

I don't consider myself an expert on save games, but I have worked on them at various stages in my career.

Amberstar, Ambermoon, and Albion, the first three games I worked on, were big CRPGs. The first two games saved to floppy disk, Albion only saved to hard drive. The logic wasn't very complicated, because these games did not use dynamic data structures. The save game consisted of fixed data structures and simple arrays.

As part of my work on the mission systems in Watch Dogs: Legion I also worked on the save games. I did not work on the save game system itself: that was legacy code. But I did spend a lot of time on the code for saving and loading mission data. My number one worry on Legion was something going wrong with the save games. If you mess up mission save data, you can erase enormous amounts of progress, or create corrupted or stuck save games. This actually happened on Amberstar, and back then I had to explain this directly to players, on the phone.

Quite recently I designed and implemented a save game system from scratch. The game that it's a part of has not been released, so it's hard to say if it would survive the crucible of shipping. But it did work during development, and, most encouragingly, other programmers used it, and said nice things about it.

Assumptions

Here are my assumptions for the rest of this blog post:

• You've got a decently complicated game, with multiple programmers working on multiple systems over a period of years.
• You want console support and online support.
• Your game is multiplayer.
• Your game is open world.
• The game supports auto-saving.
• The whole save game fits in memory.
• Your engine has some kind of system to serialize and deserialize arbitrary data structures to something saveable. In the rest of this blog post I am going to assume we're using JSON, but it doesn't have to be that.

Read more…

Back on the Atari ST and Amiga illegal copies were a big problem. It's impossible to stop, but it was often worth trying to at least make it hard for copies to get cracked and distributed.

For some reason, we suspected press versions might be a source of leaks. So for Ambermoon, I implemented a fingerprinting mechanism. And lo and behold, it helped us identify a leak!

And now that I've released the source code, I can more easily show how I did it.

Read more…

For some time I had thought all of the source code of Amberstar, Ambermoon, and Albion were lost or inaccessible.

Back then we simply didn't do rigorous backups after finishing games. The shipping data and source code of Ambermoon were on my Amiga 2000, the shipping data and source code of Albion were on my 486 PC, I put both of those on a shelf at Blue Byte, they were moved to the office basement, I quit the company, now they are effectively lost, much to the regret of myself and fans who were interested in working on fan projects and remakes.

I did have some data here and there from the 90s. For instance, I had what looked like the source code of Amberstar, but sadly it was saved in GFA Assembler's proprietary tokenized .IS file format. I was able to find tools that convert GFA Basic's similar format, but nothing for assembly. I started rolling my own but at some point I would have needed a functioning ST emulator with GFA Assembler to generate the token table, and that's when I abandoned the process for a while.

After recording a podcast episode on Ambermoon, I decided to dig into my 90s backups again. And lo and behold: I found things.

Read more…

I first met John Podlasek almost 30 years ago when we both worked at Blue Byte Software: he in the U.S. office, me in Germany. We lost touch a bit over the years, but last year he contacted me and asked me to be interviewed for his Game Dev Advice podcast.

It was a fun interview! I talked about how I got into the industry, and how I almost removed the sex and violence from GTA Vice City that one time. I hope I was also able to give some advice.

Read more…

I've been playing Marvel Snap quite a bit since it came out, and I'm currently using a deck based on MODOK that I'm quite happy with.

This is what that deck currently looks like:

It's built to have multiple ways to deliver a ton of power in rounds 5 and 6.

It's not built to react to an opponent. I have a reactive deck, and it's fun, but I tend to lose because I can't generate enough power with it.

I don't win every single game with this and it has its vulnerabilities, but it works well, and I've never quite seen anyone use MODOK this way against me.

Here is a detailed explanation.

Read more…