Chris Hazard founder of Hazardous Software, the company that’s in the heat of developing their time travel focused RTS game Achron that I did a piece on last week, took about an hour to sit down and answer any question I threw at him. There was a ton more I wanted to chat about, but just like life doesn’t have a built in reset button it also doesn’t have a built in timeline bar. Until aliens give us time travel, I think we’ll have to be happy with what little nuggets he’s left us while attending to his busy schedule.

While reading the interview, you can head over to their website and snatch the current alpha for Achron on all three major platforms, PC, Mac, and Linux. Like all other community funded alpha releases, this gives you access to all current and upcoming builds as well as the full retail game when it’s released. Personally, I love the game, and I think a lot of people will be wishing they could turn back time to get it when it’s cheaper after the official release date.
To the interview:

DIYGamer: Looking at your website and poking around, you have quite the academic background. That’s uncommon in such a stereotypically young and headstrong industry. Why put your effort into making games?

Chris Hazard: When I was a kid, I had two big interests. The first was studying the world around me, learning how things interacted. I wanted to be a physicist when I grew up. The second interest was being creative and making things, making worlds and unique characters out of Legos, Construx, and similar toys, and even making up games that resembled video games for my younger brother to play.

I learned how to program in high school, and it was quite a revelation. No longer did I have to study the world I lived in, but I could also create it, and that’s my main motivation for game development. I approach subjects very scientifically, and worked on both gaming and academic pursuits simultaneously. A big reason for that is that many of the ideas I have for games are very challenging to code. Achron is the first big one I’ve been able to realize.

Time travel is indeed a challenging subject. Hard to do right, or even think about sometimes. Why tackle time travel first? What are some of the main challenges you ran into?

Time travel seemed to be the right thing at the right time for me. CPUs were getting faster, memory was getting cheaper, but the speed at which you can read and write memory was increasingly becoming a bottleneck. As a game developer, I was thinking about what to do about that. I was also fascinated by the idea of emulation, and the ability to load a save state quickly. That sort of mechanic changes the gameplay considerably. Obstacle courses with deadly pits simply become mazes, and your skill with a controller becomes secondary to the skill of planning.

When I came up with the idea, I knew it would be a few years before CPUs would be fast enough, but I also knew that I’d need to get started perfecting it in the mean time. And you’re right, it was very tricky to code. I’d planned out a lot of the game engine architecture and many of the gameplay mechanics before I even started to code. In doing so, I made some assumptions about how time travel would need to work. It was somewhat close to what we have now in some ways, such as our timewave mechanism, but different in terms of controls, particularly chronoenergy and fastforward, both of which were hugely important for gameplay.

However, some of my initial assumptions were wrong. Particularly about internal engine things, how things needed to be stored and computed. I went through somewhere around 8 or so prototypes when I first started coding that did not work at all. They’d work fine for a short while and then use up so much of the CPU that it’d grind to a halt. I was almost ready to give up, but then decided to throw away some of my initial assumptions about what sorts of things should be stored. And then I had something that started to work!

Through the years, we’ve continually faced engineering challenge after engineering challenge. Our data structures look more like satellite communication protocols than what you normally see in games. And in some ways, our memory limitations with respect to what units can do in the game resemble Dune 2 more than Starcraft 2. So it has been challenging packing advanced gameplay controls into those little slices of memory and CPU.

You’ve hidden that well. In terms of complex gameplay, you’ve opened a door to strategies that commonly make peoples heads hurt. How has balancing such a new field of strategy been a challenge?

Balancing the RTS aspects of the game without time travel are mostly “straightforward” RTS balancing. Now, straightforward doesn’t mean easy, but we’re taking a unique approach to that using empirically validated game theoretic models. This is where my academic side comes in handy. It’s an approach that isn’t widely used at all because you have to have a bit of a math background to pull it off. It’s not a silver bullet for balancing – there really isn’t one given the scope of an RTS – but so far it’s been working well for us.

Balancing the time manipulation aspects is a little easier in general, mostly because it’s symmetric across players. All players can have the same amount of causality on the timeline, as determined by chronoenergy, and the same controls are available.

The trickiest part about balancing time manipulation and time travel aspects is the edge of the time window. At the distant edge of the time window (timeline), the world state is irrevocably committed. Given our timewave gameplay mechanic, this creates a discontinuity, where paradoxes and changes to the past aren’t always caught. There are a few ways that this can be exploited that make gameplay less fun. The most notable is something we call “permacloning.”

Permacloning is where a unit goes back in time and stands next to it’s earlier self. Once the unit’s arrival back in time falls off the timeline, that is, irrevocably committed, you simply undo the command for the unit to go back in time. Now you have two units with no loss of resources.

There are a number of ways of fixing this issue in gameplay, but most of the obvious ones make the gameplay mechanics far more inconsistent. Instead, we opted to use an economic route, such that permacloning is expensive and difficult to do. We put in an area on the timeline that is too expensive to issue commands, and also added a delay before which units can’t chronoport again. These, coupled with a measured cost for unit time travel, make it more expensive than it’s worth to try to permaclone armies.

With such new and seemingly difficult strategies, what are you doing to ease the gameplay learning curve?

Time manipulation is something that is really new in gaming. Achron is the first to have it, so people aren’t used to it. The same thing happened with Portal; a new gameplay mechanism was introduced that was like nothing else out there and people didn’t have mental models for how it worked.

In Achron, the player starts off without time travel; Humanity is just on the brink of discovering it. So, you learn along with the characters in the game. (This is for the as-of-yet unreleased single-player campaigns.) Once people sit down and play it, many of them tell us that the system is actually very intuitive.

I’ve noticed that myself.

You’ve just played the last 5-10 minutes of the timeline, so you know what happens during that time very well. You click on the timeline and then go change something. Easy.
When you start sending objects through time, then things get a little more complicated. However, players soon learn that it’s better to plan out what you’re doing than to randomly send things around the timeline. It allows you to remember what’s going on.

Independent studios seem to function in similar ways to stay afloat, and a culture has developed around these business models and practices. It would seem that Hazardous Software has adopted a few of these practices, such as Alpha access and an in-depth community forums. However, you’ve called your game a AAA indie, and are using a more traditional business approach than what most indies are doing. What does that mean from a development perspective? It seems like a tough balance, and one that I know a lot of new or struggling game developers would like to know about.

When a lot of people hear “indie”, they often think of a game that two people made in a moderate amount of time. It may be really fun, but usually doesn’t have tons of content. If it does have tons of content, it is usually all procedurally generated.

The heart of Achron was mainly developed by a few people, but our team spans over 30, including all the contractors who did various pieces of it. The scale and scope of Achron actually prevents us from participating in some of the indie game competitions. We have several industry veterans, who have run big projects and won awards.

It is very tough to balance, however. We obviously don’t have the budget of the big studios, so there are some things we can’t do as well. Take pre-rendered cutscenes, for example. Those are expensive, and if you don’t do them well, it’s almost worse than not having them. Instead, we use other forms of storytelling, both in-game and between levels.

We’ve been entirely self-funded, which is hard to do. Many of us have held jobs or saved up money to create Achron. But, we believe in the product and are willing to take the risks.

That right there seems to be the key to making games, and succeeding at life in general. In lieu of time, is there anything else you’d like to say? Any advice? Shameless plugs?

Haha. For budding game developers, my biggest advice is to come up with a neat idea no one else has done before and make it happen.

I think times are changing a bit, now that gamers are growing up and starting to come into positions that have influence. I think sometimes game designers who grew up with games have different ideas and assumptions about what games are and should be than those game designers who grew up before video games existed. And given that, I expect to see games applied in more and newer places, both for entertainment, and for serious purposes.

Thanks a bunch Chris. I really appreciate your time

Thank you for having me.

[Achron]