• 
• 
  • Achron’s Backstory
  • Anachronisms
  • Development Calendar
  • Achron in the Media
  • Achron Wiki
• 
  • Gameplay Videos
  • Wallpapers & Screenshots
  • Achron & the Grandfather Paradox
• 
• 
• 
• 
• 
• 

Bug in Balancing Fixed

Mike and I are working on another balancing pass in Achron, and we started putting in the new resource processor changes. Based on the great feedback we've gotten on our forums about the start game, we came up with some changes that should help improve the balance between strategies.

Resource processors are the fundamental backbone of Achron's economy, and so changing them changes the entire economy. We were putting the new values in and experimenting with minor adjustments to see how they would affect things.

On the forums, people have been talking a bit about how marines in Achron aren't very useful against any other units because they're too expensive. This surprised us. According to our analysis, they should be strong against a few tactics, especially air-based attacks and late-game mech rushes. However, our gut intuition from playing Achron agreed with the sentiment of the forum posts.

The importer supplies the Humans with reserve soldiers, needed to make marines or to pilot any ship or vehicle. We decided to see how changing the importer costs would affect things; maybe our model's abstraction had some inaccuracy. I went into the spreadsheet, made the importer cheaper and... it actually made the reserve soldiers more valuable. That was completely wrong behavior - it should have gotten cheaper.

I dug in further and found two columns with nonsensical equations buried deep in a spreadsheet on the economic foundation of Achron. I must have been really tired when I made that calculation because the math in those two columns was incomprehensible and not documented as I usually do. Because the results of the math were generally plausible, it wasn't until now that we found it.

I reworked the math in a very straightforward manner and that bug in our balancing process has been fixed. The result of the bug was that reserve soldiers were valued considerably less than they were worth. For the more expensive units, this change in value was not much more than a big rounding error, but for the least expensive units that used reserved soldiers, namely the marine and special op, the balancing is off considerably.

In this next balancing pass, we've also decided to apply a different rounding approach to resources to be more consistent and to reduce the magnitude of numbers. This does mean that many of the unit costs will change, some of them quite dramatically.

Outside of the aspects of this balancing bug, do you have any comments or questions about Achron balancing? Discuss on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1531

 

Developing a Performance Test Suite Using Replays

If you're making a AAA title you may want to squeeze more detail into a scene. If you're making a casual game for a mobile device, you might want to improve responsiveness on the slowest device or reduce the battery drain of your game.

Normally, developers run the game engine using a profiler to see how the code is performing. Profilers are commonly used development tools that tell you which parts of your code are running what percentage of the time. Profiling is an essential skill every developer should have, only a few pegs behind being able to debug effectively. Part of the skill is knowing what to profile.

The first pass on profiling is to simply sit down and play some of the game yourself with the profiler running in the background. You take a look at the profiler results, and it tells you that 30 percent of the time is spent doing some task like collision detection. You look at the code, figure out a way to make it better, and test it functionally. It works! Now, how do you know it performs better?

If you play the game for more profiling, you can't exactly compare your previous results. Even if you were in the same area in the game when you play again, your results won't be the same. Maybe you missed a jump your second time around, or your fingers were a little slower, or you play through faster. It's difficult and time consuming to ensure the same scenario, so it's better to automate it.

Having a replay framework either in your game engine or in your development environment does not just offer major benefits for reproducing bugs, but it also helps with profiling. You can play through several areas of the game, ideally with different play styles by different people, and now you have a suite of performance tests. Every time you run your regular testing for code or content changes, you can run your profile suite.

Another strategy is to use your AI against itself. Each random number seed you use to kick the game off is another test case. The obvious risk here is that human players won't use the same playstyle as the AI, leaving your performance results biased.

In software testing, there's the idea of code coverage. That means that you make sure your tests run through every functional area in your code. You make sure that every part of code that checks constraints, triggers an action, etc. is run. It's impossible to test every case, but the goal is to make sure that all of the code is tested at least once. In performance testing, an analogous case is to make sure you've gone through all the major use cases of the game. Do your automated replays go through the area with the biggest number of bad guys, the biggest number of lights, and that mini-game you so cleverly designed by hacking around the game mechanics?

The game my company is currently working on, the time travel RTS Achron, is very performance intensive on the CPU. The motivation for this blog post came from a recent discovery. We had a small battery of performance tests that we'd always run, and we depended on its results. Recently, one of our users made a custom map that was quite large and complained that the performance on his map was so bad that it eventually became unplayable. My initial reaction was to think that he was using a slow CPU or that it'd be some issue we couldn't fix, but because he'd posted his save game (which, in Achron includes most of the game replay), I decided to profile it. It turned out that he had hit upon a performance case that was not included in our suite: a large battle as it moves off the timeline. Over 20 percent of the CPU was being spent checking to see if a set of resources could be freed, a function that had never even appeared on the list of the top 100 most time-consuming functions. All I had to do was reduce the frequency that the engine attempts to reclaim those resources. By checking only one twentieth of the amount of time, I was able to reclaim 19 percent of the CPU, and the only drawback was that certain resources on average took a few hundred milliseconds longer to be reclaimed.

Are you a developer who has had interesting experiences profiling? Share it on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1485

 

Indie vs Goliath

Being an indie developer making an RTS, I'm often asked about how I think the release of Starcraft 2 will affect our game. With Blizzard's hundred million dollar development budget, unrelenting pursuit of polish, and entrenchment in esports, how could we possibly stand a chance to be relevant?

The RTS genre has been a little less prominent in the past few years, but all the buzz behind Starcraft 2 is igniting it. Some people who haven't played an RTS game since the original Starcraft feel renewed interested in the genre. I personally don't think Starcraft 2 could come out at a much better time for us. By the time many people have played a lot of Starcraft 2 and are looking for new challenges, Achron will be coming out.

I think every indie developer looking to succeed in the business of making games needs to reflect upon the question, "why should people play my game instead of a big budget game?" There's a notion in mathematics (originally stemming from economics) called the Pareto frontier. If a product is on the Pareto frontier, then that means a customer can't choose another product that is better in every way, price included.

By simply having multiplayer time travel, Achron is already on the Pareto frontier. Even beyond that, both Starcraft 2 and Achron have very different feels even when time travel is excluded. Achron has command hierarchies instead of unit groups, and is focused on hard science fiction rather than the more fantasy-based science fiction of Starcraft, with all of the things like psionic energies. Conversely, Achron won't have the gorgeous cutscenes or all-encompassing matching service that Blizzard can provide.

A big studio can easily spend millions in marketing to sell a large number of copies of a game that may not otherwise be on the Pareto frontier. With significant marketing, you could argue that they've moved it to the Pareto frontier simply by providing name recognition. You can stand out by having significant innovation, excellent gameplay, unique graphics, or a great mod community, just to name a few. You don't need to be the best at any one aspect, you just need to be the best for your combination and niche, however large your niche may be. For example, Blizzard focuses on game polish over innovation, as they openly admit. If your game is about ninja animals, is the sequel to a game that fans love, has a strong community, and your company is reaches out to the community, then you're most likely squarely on the Pareto frontier. However, if you're an indie making another first person military shooter without laudable gameplay, graphics, or a compelling story, you're most definitely not. Business people often call being clearly on the Pareto frontier as "best in class" or "best of breed".

This isn't to say that you can't make money by offering "me too" type games. On the one hand, you're competing for attention from fans, and if you have an inferior game, you probably won't sell as many. On the other hand, if there are two games, people can play both, and the added attention to the type of game can benefit the sales of one or both games. If you can produce a similar game for a tiny fraction of the cost of the original, you've moved yourself back on to the Pareto frontier with respect to cost.

Discuss what you would do on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1313

 

Would You Help Your Clone?

The past week has been quite an active week on the Achron forums, partly due to a newcomer named Kron who came in and stirred up a lot of old discussions with new ideas. One of the active threads, titled "If you were a soldier from Achron...", examines what it would be like in the game if you weren't an achron yourself, and knew that someone could be changing the past on you. For example, would you be more likely to march off to certain death if you knew that your death could be undone? Would you help out another you from another point of time if it meant that helping the other you would cause the current version of you to no longer exist once the next time wave came by (and afterward only a different version of you with different experiences would exist)? Or would you only be concerned with the current you?

How far does the concept of "you" extend? Parents typically help their kids as much as they can, and identical twins sometimes are very close, but what if we take it a step further. Suppose you were able to instantly have 5 perfectly identical clones of yourself starting right now. The clones would be perfectly identical down to every subatomic particle at this instant, not like the movie Multiplicity where each copy was less accurate. Each of you would think that you are the original "you". However, you all will start to diverge.

What would the lot of you do? Would you stick together or separate? Would you take on different specialties? Would you share everything or nothing? Would you all try different things, or would you all try to be the same? Would you get jealous of or angry at the other versions of you? Which one of you would spend time with your significant other? If one of you got rich, would you share your wealth?

I've asked some of my friends this question and have gotten very different answers. Many of my friends were also quite sure of what the outcome would be. After all, you generally know yourself pretty well. But how would you react to you?

Myself? I've thought about it quite a bit. I'd probably coordinate with the other versions of me, specialize, and share the fruits of our labor.

Discuss what you would do on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1253

 

Military Communications

In addition to my work on Achron, I also do research as part of a large Army initiative on the science of "quality of information". The idea is that they have information coming from a variety of sources (sensor networks, soldiers on the ground, local people, international forces, etc.), and they want a system that can combine the vast quantities of information and determine what is trustworthy and correct. This is obviously a very complex problem, which is why there are over 100 researchers on the grant from dozens of universities across the USA, spanning a wide range of disciplines such as game theory, networks, graph theory, and social networks. The 100 researchers does not even include their many PhD students and post docs! An academic grant of this scale in computer science is quite rare.

I generally keep my two activities of research and Achron very separate, but our meeting today here in Cambridge, Massachusetts had a point that I thought was particularly relevant to discuss here. (If you're curious about my work on the other area, my dissertation can be found here: http://www4.ncsu.edu/~cjhazard/cjhazard_dissertation.pdf.)

One of the neat things about working on this grant are the number of really smart and interesting people you get to work with. Major General Nick Justice, who oversees this grant, was talking about the effects of communication on military forces (yes, he has a cool name, and he also thinks Achron is really cool from a strategic/game theoretic perspective). One of his points was how simply having a 5 kilobit per second channel completely revolutionized warfare, even though those 5 kilobits per second had to be shared over 1000 nodes in the network! Prior to that, military forces would need to perform operations and then regroup, perform operations and then regroup. He likened it to war formerly being like plays in gridiron football, but now it's more like soccer. The constant stream of data allows them to continually adapt without having to pause. Imagine trying to play gridiron football against an opponent that never had to stop when the whistle was blown (but your team still had to).

Now the US Army has far more bandwidth, but now they have more data than they know what to do with. That's one of the main reasons for the grant: to figure out how to get useful information out of vast quantities of data where that data could potentially be compromised or manipulated.

In Achron, the humans not only have massive AIs that can process this kind of data, but they have virtually instant communication across vast distances by using their teleportation networks. That would be amazingly impressive. However, when faced against an opposing force that can not only see the future but affect the past, the difference is would be even more stark than having that 5 kilobit per second channel when your opponent has no such communication channel.

Being able to see the future means that you're no longer reactive; you're proactive. On the Achron forums, pdyxs linked to a recent blog post of his discussing some of the philosophical aspects of time travel on combat. If you can communicate across time, one strategy is to march your troops to their doom in order to get your opponent to reveal their weapons, then go back in time, undo marching your troops in, and then systematically target only their biggest weapons from a distance. In this case, all of your troops eventually survive. But they are defeated once first.

Suppose that you were in a military force and you had time travel. Would you be willing to follow orders that you lead to instant death simply to learn about your enemy, assuming that your commander promised that he'd do his best to revise history and undo your death? Discuss this or other topics related to military communication on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1215

 

Achron Wiki Launch

We just opened our wiki for Achron today! Because Achron opens up so many new strategies with time travel and people have many ideas to create mods, we thought a wiki would be a great repository for all of that information, in addition to details about Achron itself.

The wiki is publicly viewable and editable by anyone who has preordered Achron. The wiki will also be automatically backed up with the rest of our data (online and offline) to multiple regions of the USA, so the data won't be lost like the unfortunate incident with the fan-hosted wiki on chronofrag.com several months ago.

Feel free to contribute to the wiki here: http://achrongame.com/wiki. Feel free to discuss the wiki on the forums as well: http://achrongame.com/forums/viewtopic.php?f=73&t=1201

 

Path Planning Update

Path planning, that is, figuring out how a unit should move to arrive at its destination quickly, is a very tough problem in making RTS games. You not only need to solve an optimization problem, but also handle the uncertainties related to other units moving around and unknown elements in the environment (such as an unforeseen wall blocking one path). I've known people whose entire PhD dissertations were focused on the topic of path planning in robotics. Path planning in Achron is much more difficult than most RTS games because time travel puts significant constraints on memory and available CPU.

One of the major results from this last week is that we've made some progress on improving path planning in Achron. Our main change largely involves a new way of caching some path planning results. So far, we've been able to approximately double the area that units search when planning a path for the same amount of CPU throughput, at least on our preliminary tests. The new path planning seems to work well.

This path planning improvement will be helpful with our upcoming addition of units only being able to climb slopes less than their maximal values.

What games have you played that you felt had particularly good or bad path planning? What situations in RTS games is having good path planning most essential? Discuss on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1187

 

Spiking the Audience

I've been thinking a lot lately about where the "Big Hollywood Sound" comes from. We like our games full of this sound, because it has almost a chemical familiarity to it, and it's really only in the last 10 years that such a thing has really been a possibility. As many of the bigger budget games are going to full orchestra, I've had some mixed feelings on the matter. On one hand, it's a wonderful development, but like many other advances, it's also a guilty pleasure that can stand to be moderated.

This is tangentially related to the broader conversation of giving the audience the experience that they want. I'm vaguely familiar with a concept in public speaking where the experienced speaker will learn to push the audiences buttons with certain voice inflections and choices of words that he knows will sort of tug at them, shake them awake, or get them fired up, generate a predictable response, and may be particularly effective with a certain cultural segment. The crazy thing is that it works. If a speaker "spikes" the audience too often, especially with less compelling subject matter, it can be reduced to a cheap parlor trick, getting a rise out of you over nothing in particular.

Composers can do the same thing! We can choose certain sounds which bear familiarity to the listeners in another context. We can also use cymbal rolls and those monster Wagner bass drums to make things feel big. The great thing about writing for games is that gamers are well versed in various forms of popular and anthropological culture, especially core gamers. This gives a composer many angles by which to find the soft spot of a segment of the audience.

It's just like any other kind of art or skill. Know when to play to the audience, when a thrill becomes a cheap thrill, when even a cheap thrill can be the right thing, when you've overthought the decision making process, and when to stop a run-on sentence. I think about these things every time I produce.

Here is the Achron track we are including with the upcoming release. Hopefully it's fun for all of the right reasons.

Frozen Over Theme Download (mp3)

Discuss this track or other Achron music on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1137

 

Update on Tool Development

These last couple weeks have been quite crazy with regard to Achron development. Coding up a level editor from scratch is no small feat, but it's been moving along nicely. It won't have every bell and whistle imaginable in the first release, but the core functionality will be there. Plus, we'll be using it ourselves, so we'll be fixing and improving things.

The Mac port is nearly done as well. All but two things work perfectly. The first is the automatic router configuration for multiplayer (which currently causes an odd crash) and the other is support for wav sound files due to the ALUT library being deprecated and broken on OS X (we're debating solutions). Ogg files work just fine.

We're looking to make the next Achron release sometime near the extended weekend (it's a holiday weekend in the USA through Monday), depending on how everything goes. This will be by far the largest single release of functionality we've made since the January 1st release (though the functionality is mostly tools rather than gameplay).

We're making good progress on the art and content for the single player game as well, which will be released later on in development. We will be including another one of Achron's songs into this next release though.

Which interests you more, the Mac port or tools? Discuss on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1123

 

Symmetry Violations in Physics

The physics of the universe is full of interesting oddities like time being affected by gravity, "spooky action at a distance", and symmetric rules of the universe. As we're creating a game around the idea of time travel, we like to keep up to date with what's going on in physics.

Some interesting results have been coming out of Fermilab recently that could offer a little bit more explanation to one of the big questions in physics: why are we made out of matter and why is there so little antimatter in the universe? (Antimatter is matter's evil twin, and the two "explode" into energy on contact.)

Imagine that you're adding together a huge list of numbers, each with a lot of decimal places, on a calculator. You add 3829.23428923 to 19.4819231, then add 4.2333871, and so on. At the end, you take the sum and start subtracting all the numbers you just added together. When you're done, you end up with something that isn't zero! That's because the calculator was doing rounding. (That's why, at least in computer science courses on numerical analysis, they teach you to sort the numbers and to always add the smallest numbers first. That technique minimizes this error.)

This isn't all that dissimilar from the issue of the universe: the matter and antimatter quantities should be equal if things were symmetric. There are three things that physics is often concerned with being symmetrical: charge, parity, and time. Colloquially speaking, charge is the positive or negative property of a material that causes a force on other opposite materials, and can create voltages and thus electrical currents. Parity is a bit more of an obscure idea, but you can imagine it to being analogous to whether something is spinning clockwise or counter-clockwise with respect to the direction it's traveling. Time symmetry means if you reverse time, you get things in reverse.

As presented in a recent talk, some folks at Fermilab have found that there's quite a lot more "rounding error" in the universe than they expected in some cases. It could explain why there's so little antimatter.

What other ideas or results from physics have surprised you the most? What other theories might prove to be approximations to some exotic or elegant underlying principle? Discuss on our forums: http://www.achrongame.com/forums/viewtopic.php?f=73&t=1103.

 

Level Editor Revamp Progress

We have an old level editor that we've been using internally, but it desperately needs to be revamped. This past week I've spent quite a bit of time working on the new editor, which we're aiming to be released in a couple weeks. Why does our old level editor not get much love you may wonder? Well for starters, it's an archaic application that Chris originally put together reusing some old code from previous editor projects he wrote in undergrad. We're talking about code thats over a decade old and hasn't really been changed since. It started out being a small paint-like application with a few edit modes, providing several options for each mode, but we kept adding more and more options as Achron and Resequence grew. It's very tied to the Windows platform and uses some old ways of rendering things. Driver changes in the past couple years by ATI and Nvidia have made it particularly slow to render, to put it kindly. Everytime I change edit modes I have to wait 5 seconds for the windows to redraw. It's like using a photo editor over a modem connection (of the old telephone kind). Though the level editor is fully functional, it's buggy and the user interface wasn't well-planned from the start.

Old level editor in action

Instead of rewriting the current level editor from scratch as a desktop application and then porting it to the different platforms, we instead decided to reimplement it using the in-game engine. Besides the fact that this new in-game editor will readily work on all platforms we intend to support, it will allow the user to see the level exactly as it will appear in game while they edit it. This should vastly improve usability and enable us to continually add more functionality much easier and faster. I should also mention that it makes it a lot more fun to use, shoving around units by actively editing terrain and evelation is like watching a volcano ripple up under them on the fly. Because it is being implemented in-game, the user interface for the level editor is now simply a different skin that I am in the process of writing using our skin language. The benefit of having the interface be a skin is it makes improvements in appearance and functionality trivial to add. Do I need to add a toggle to switch to a different brush shape? Write a few lines of code specifying what to toggle and where to display it and boom, it's there on the interface.

In the meantime, in order to make the skin within the game itself, Chris has been busy exposing many of the controls to the skin language. Starting the game engine in edit mode enables the skin to access these different controls. Personally I am looking forward to finishing this new level editor so we can finally stop using the old one.

If you have any thoughts or comments on the level editor, feel free to discuss it here: http://achrongame.com/forums/viewtopic.php?f=73&t=1077.

 

Development Calendar Update

Estimating software development timelines is tricky due to the amount of uncertainty. Sometimes you get lucky. Back when I worked at Motorola, I designed one project that entailed a development effort of several tens of person-months, and my initial estimations for time and lines of code both only had about 3 percent error. Sometimes you're not so lucky. In designing a warehouse management system for the Chicago Public School system a few years ago, the development was about 30 percent larger than I estimated.

So far things have been mostly on track for Achron. I updated the calendar for what we're aiming to accomplish at the end of the next two months.

We're pushing the level editor back into late May for two reasons. The first is that April ended up being a crazier month than I anticipated. I needed to devote more to managing art production than I anticipated, and my PhD defense had to be delayed as my advisor was stuck in Europe for a week due to that infamous Eyjafjallajökull volcano in Iceland. The second reason is that a couple of development tasks I had originally scheduled for early summer would make creating the level editor significantly easier, so I decided to work on those before the level editor.

We are planning another release next week that may include the ability to create new environments for levels via an XML file (textures, terrain objects, etc.), which are stored in the ".til" files. The new level editor itself is well on its way. At the moment you can paint the terrain and terrain objects nicely. The main remaining tasks are integrating the editing controls, adding the ability to place and modify playable units, and to add the controls to save, load, import, and export. We've decided to change the way game mechanics are specified, moving away from our overly-complex and poorly designed dialogue boxes to a more flexible XML specification, so this will be coming soon as well.

We're also going to be releasing our skin compiler for making your own UI at the end of the month, and Mike is working on implementing our first (of many) balancing pass on the humans. I'm also going to go buy a Mac to start porting to that platform.

If you have any thoughts or comments on our schedule, feel free to discuss it here: http://achrongame.com/forums/viewtopic.php?f=73&t=1013.

 

Automatic Production Hierarchies

Earlier in Achron's development, one of our developers really wanted factories (and other production facilities) to automatically put units in hierarchies based on their production order. If I recall correctly, this was also before we had dispatch points.

However, now that we've been having a wider range of people play Achron, we see that this feature does not live up to our expectations of usefulness. We are planning to remove it; if you want your units to automatically enter a hierarchy, you can dispatch them to a particular location and enable autohierarchy using a comm center.

We were considering making units default to not be in a hierarchy when produced at a factory and give each factory a toggle such that you can turn this feature on. However, when we thought about it, we really couldn't come up with a good use case of why this automatic linear production-based hierarchy would be preferred over manual management or autohierarchy. Further, managing which factories have this feature enabled and which don't seems like another mental burden for the player.

Before we remove this feature, we want to hear any objections. If you strongly believe that having this feature is worth keeping, please let us know that you do, let us know why you think it should be kept, and also how you'd use it. If you think this factory-specific auto-hierarchy should be kept in a modified form, let us know that as well.

Remember that there is always a "cost" associated with keeping controls; each button we have makes the game appear more complex to a new player, so we don't want to keep features that don't significantly add to the gameplay.

Should we keep these automatic production hierarchies? Is there a better solution? Give us your feedback: http://achrongame.com/forums/viewtopic.php?f=73&t=1003.

 

Chronoenergy Recharge Rate

An interesting point regarding chronoenergy and micromanagement has been brewing on the forums for quite some time that we have been meaning to address. The point is that, based on the current chrononenergy (CE) recharge rates, viewing the past is technically not "free" because CE recharges at a slower rate than it does at the present. If more time is spent in the present instead of the past, more CE is recharged enabling the player to issue more orders. In effect, the cost of viewing the past is you losing the potential to issue more commands; you will not be able to issue the same number of orders as if you were viewing the present because your CE will not have been recharged as much.

One of the reasons we are willing to explore a uniform recharge rate is because we do not want players bouncing around back and forth between the present and the past solely to increase their CE regeneration rate. As mentioned on the forums by several users, experienced players would be driven to use this exact tactic. Such behavior is undesirable from a game design perspective and can be categorized as user interface micromanamegement. We want the players to concentrate on the strategy of the game rather than focusing on playing the user interface.

Our primary goals in designing chrononergy usage are to limit players from camping out at the furthest playable point in the past and to promote strategic decision making in altering the timeline. The current mechanism for preventing camping out in the past increased CE cost of commands issued further in the past, reducing the player's ability to micromanage units and shifting the focus to strategic changes. Along with this current mode of increasing CE cost of ordering commands, a uniform CE recharge rate would allow players to remain at any point on the timeline while still limiting their ability to issue multiple commands. Players are still rewarded for playing closer to the present with decreasing CE costs, increasing their ability to micromanage. We think this may be a good direction for CE recharge rates, but before we commit to this change across the board we will try it out on a couple of levels. This trial will provide us with useful feedback to drive the decision for standardizing a uniform chronenergy recharge rate.

Share your thoughts on the forum here: http://achrongame.com/forums/viewtopic.php?f=73&t=987.

 

Guest Post on Wolfire Games' Blog

For any of you who follow indie games and don't know about Wolfire Games' blog, it's packed with tons of usefull stuff through the years related to indie development, much of it following their upcoming title, Overgrowth. A little while back, I was honored when John asked me if I'd write up a guest post for their blog. I decided to write it on something useful across nearly every game genre: feedback in game design. Check out my guest blog post here: http://blog.wolfire.com/2010/04/Feedback-In-Game-Design.

 

Triangle Game Conference 2010

The Triangle Game Conference was a good time last week. As with last year, there was a great showing of talent from the many the game companies in the triangle area in North Carolina. I didn't bring a camera with me, but Jason Della Rocca posted some pictures on his blog here: http://www.realitypanic.com/archives/432. After the conference, it was also rather amusing that Jason and I were on the same flight to Washington, DC at 5:45am Friday morning, given that neither of us are from Washington DC nor had a layover. I was going to the University of Maryland for a research meeting, and I believe Jason was going to visit friends.

I've posted the slides of my talk on my personal website here: http://www4.ncsu.edu/~cjhazard/publications/cjhazard_TGC_2010_04_07.pdf. The slides by themselves are fairly sparse, but can provide some reminders for those who saw my talk. It was filmed by both the The Escapist and also Wake Tech, so hopefully it'll be online sometime in the not-too-distant future. I plan to write some articles based on my talk sometime in the next year, and I'll post announcements when I do.

Share your experiences at TGC or thoughts on my talk here: http://achrongame.com/forums/viewtopic.php?f=73&t=949.

 

When Units Get Bored and Attack

Last week I posted about working on improving units' attack logic. Actively attacking enemies is one core functionality, and being defensive while the unit has not been assigned an objective is also an important aspect of attack behavior. A stationary unit that is waiting for orders is idle and is essentially on defense since it should attack any enemy targets that may show up, even if this unit happens to be idling inside an enemy base. This specific case can occur when the player attack-moves units to the enemy's base and those units return to idling after destroying all the targets at the selected destination. In this scenario they should be more offensive-minded since their intention is to keep attacking all the nearby enemies, bringing up up the challenge of figuring out when should your idle units engage the enemy.

We don't want idling units simply engaging any enemy that's just appeared on the edge of their vision because it's possible that this enemy unit is a lure that will set you up for an ambush. Alternatively maybe this enemy unit is just passing through and coincidentally skimmed by the edge of your unit's visibility radius, so we don't want to automatically follow since having idle units leave their defensive positions would probably make the player go "why are my guys moving away for no reason?". Units that have long-range firing capabilities are able to shoot the target right away, but for units with shorter range weapons our goal is to design the logic such they won't completely leave their outposts but will be willing to move a reasonable distance in order to engage the enemy units.

In the process of updating and improving idle-attack logic, I fixed an issue where units could become indecisive in selecting which target to attack next when idling inside an enemy base. This left them doing nothing instead of continuing their attacks. While working on this code I also found and fixed a long-standing and hard-to-reproduce bug where in certain specific situations units froze and would not follow their commander's orders until that commander returned to idle.

Share your thoughts on the forum here: http://achrongame.com/forums/viewtopic.php?f=73&t=941.

 

Reversibility of Physics

I'm giving a talk tomorrow for North Carolina State University's philosophy department on time travel in games, particularly as they pertain to Achron. Dr. John Carrol is hosting my talk as part of his class on the philosophy of time travel. If you're in the area, it will be in the Park Shoppes building, room 200, at 7:00 PM.

In addition to the various time travel mechanisms in Achron and games as a whole, I'll briefly be touching on some of the dynamics of time travel from a computational perspective, which spills over into the realm of physics. Perhaps one of the most interesting aspects of physics to me is what happens when you reverse time. Some attributes, such as position, acceleration, force, and electric field stay the same in both directions, whereas other attributes are negated, such as velocity, momentum, and magnetic field. Further, what happens if matter goes back in time? Does it become antimatter, or even dark matter? One of the principals of reversible computing is that a lot of the energy involved in computing is simply the destruction of information (specifically, power loss of switching).

Share your thoughts, curiosities, and questions about reversibility on our forum here: http://achrongame.com/forums/viewtopic.php?f=73&t=915.

 

Keyboard Hand Stance

Back when I played football in high school (the gridiron type for those of you not in North America), I once sprained my right thumb. Every day before practice, one of our trainer's assistants would put a layer of bubble wrap on it and then wrap it up. For our team's style of play, playing defensive end means that you need to line up in a three-point stance with 1/3 of your weight resting on your hand. It was too painful for me to put that much weight on my thumb, so I started lining up using my nondominant hand. It actually was a much more comfortable and natural stance for me, and I was able to start faster. I started lining up for track that way too.

While using a nondominant stance probably doesn't work for most people, assuming a stance I wasn't used to happened to offer beneficial results. Several of us at Hazardous Software, including Mike and myself, have been typing exclusively using the Dvorak layout for many years (12 years for me, 9 years for Mike), and have enjoyed using Dvoark far more than QWERTY.

So what does all this have to do with Achron? How you use the keyboard is a very important part of playing many PC games. When you type, most peoples' fingers usually hover on or near the home row. When you play a game, your hand may hover above the WASD keys (AOE. keys for us Dvorak users), over the arrow keys, or elsewhere depending on the game.

When we started deciding the keyboard layout for Achron, one of the first questions was whether we wanted to have the shortcuts be positional or mnemonically driven. Positional had the benefit of never having to move your hand, but also had the dueling drawbacks of varying keyboard layouts (particularly in Europe and ergonomic keyboards), the shape of the keyboard necessitating a wide layout (keyboards are very wide), and the difficulty to naturally find your home position when you need to hit a key outside of the area (like the bumps on the f and j keys or separation of the F-keys).

We're frequently asked why the ctrl is used instead of shift for enqueueing commands to units. The main reason we chose it to be ctrl in the first place is due to the initial hand stance we started using, which consists of using fingers for the F5-F12 keys (time bookmarks and time speed), backspace, 7-0, and delete (and also home/end before we added mouse wheel zoom). Ctrl is used frequently for bookmarking times and units, and on most keyboards, ctrl is easier to find and press than shift due to it being a corner key. Shift is a longer key than ctrl, so if you are liable to hit it quickly on the side, it takes more force on many keyboards than ctrl. The extra force required is a drawback for a commonly used key. Also in this stance, I tend to use the quick icons (the radial menu) more often than the shortcut keys, and so I don't need to move my hand across the keyboard very often.

The ctrl-key was also chosen because it is consistent in doing one thing: it selects another. It selects another unit, it selects another position to move to, it selects another command.

We understand that other games do things certain ways. However, we try to evaluate ideas on merit, and not just do them because that's what everyone else does.

The space key is used to issue priority commands, and is big and easy to hit. Due to the layout of the keyboard, it's also easy for your hand to find the aforementioned stance.

Shift is currently used to set the mouse at a particular height level. It's less important now, but it was more important earlier on in development, and might be slightly relevant once we start integrating more artillery style attacks.

We are planning to add keyboard customizations in the not too distant future.

All that said, some people play using a laptop keyboard, and other people have some different layouts as well.

What hand stances have you liked or disliked in games and why? Do you have any ideas for a keybinding layout you would put in place when we make it available? Share your ideas on our forum here: http://achrongame.com/forums/viewtopic.php?f=73&t=897. If we get some good suggestions, we may add them.

 

Upcoming Talks in April

I'm giving two talks in the upcoming weeks related to Achron and game development. The first talk will be on time travel with respect to gameplay and and philosophy. It's being hosted by John Carroll for his class on the philosophy of time travel at North Carolina State University. My talk is at 7:00pm, on April 5th in the Park Shops building room 200. Shortly after my talk, they'll be showing the movie Primer.

My second talk is titled "What Every Game Designer Should Know About Game Theory", and I'll be giving it at the Triangle Game Conference which runs April 7th and 8th. Here's the abstract:

Effective game design is both an art and science, but too often, the science part is neglected. How do you know whether your multiplayer game will remain balanced and fun for new-comers and seasoned players alike after people have learned its secrets and devised new strategies of gameplay?

In this talk, I will go over what every game designer should know about game theory. This talk will not just be a crash course on game theory basics. Instead I will focus on those aspects of game theory, both beginning and advanced, that directly apply to practical interactive game design. I will cover diverse examples, such as how to automate your game balancing to ensure that weapons in a shop in an MMORPG are priced properly and how drafting strategies in a racing game can be modeled as a repeated prisoner's dilemma. I will go over different design templates from game theory beyond rock-paper-scissors that can be applied across genres for single player, cooperative, and competitive games.

 

Attack Behavior

This past week I have been working on the logic of idling units, specifically how they decide to attack enemies, trying to improve the existing heuristic. Our current strategy that seems to work well (and some people have really liked) is that units first look for attack-capable enemies and target those easiest to destroy first. Units automatically team up on those weaker targets for faster reduction of total enemy numbers in order to reduce the total damage per second your opponent is producing. The attackers then progress onto the harder-to-destroy targets as the weaker ones are eliminated. If no attack-capable enemies are found, your units then look for passive enemies (buildings). We found that this logic reduces micromanagement and disincentivizes cannon-fodder strategies such as sending Resource Processors into battle in order to soak up damage (since they'll be ignored if attack-capable targets are present).

One strategy to utilize this behavior is to send in a weak unit to soak up the initial fire, followed up by strong units behind it. This will force the idle defending units to use their first volley on the weak initial unit.

There is one issue regarding idle behavior in the current release where units will not attack passive enemy buildings in specific situations, but we're fixing that and improving the overall behavior.

 

The Process of Porting to Linux

What's the best way to develop software when people won't start using it for at least 7 years?

This was the question I asked myself back when I started working on Achron. In terms of development tools, Visual Studio 6.0 was still being used (Visual Studio .NET had not come out yet), which had many incompatibilities with GCC (the compiler used on GNU/Linux). The XBox had not been released, so Windows was the only platform DirectX ran on. When I started working on rendering more than just regular 2D images to the screen, I banked on shaders being the future, so I sarted using GLSL when it was only in beta.

When it came time to port to Linux, most of my coding-for-the-future thankfully paid off. About 75% of the code compiled on Linux without even a warning, and most of the platform-specific code was contained in just a few files. That said, there were several issues that came up in the port.

The first major issue was that GCC generated code that crashed on load. After about 4 hours of poking around, it turned out that I had been using explicit template instantiation in a non-standard way that GCC didn't like: I was explicitly instantiating the templates before GCC saw all of the template's code. I'd move the declaration from one header file to another, one would work, the other would crash. Once I saw what was going on, I just had to move 5 lines of code from one spot to another and it worked.

Another issue was of paths being listed with forward slashes versus backslashes, as in "/opt/Achron/terrains" versus "C:\Program Files (x86)\Hazardous Software Achron Demo\terrains". As most other operating systems other than Windows use forward slashes, and Windows generally permits forward slashes, I used them when I could. However, there are a few Windows API calls that either don't like backslashes, or don't like it when you mix forward and back slashes. This can arise when you call a Windows function, say, one that gets the user's home directory, and then look for a file within that. The Windows function will return backslashes for the first part of the string and the engine uses forward slashes. As the initial development effort was on Windows, I was able to resolve issues right away. When I first started compiling on Linux, I used an Ubuntu Linux distribution with a shared Windows. When Ubuntu was using the shared Windows drive, it didn't care about mixed forward slashes and backslashes, but when it was on a local install, it certainly did matter! I found a couple spots in the code where there were lingering backslashes outside of platform-specific code.

A third issue, that really caused a lot of confusion, was the fact that some vendors' video card drivers don't like it when you attempt to use textures that are smaller than 4 pixels by 4 pixels and then try to do anything fancy with them (like mipmapping). We had some very confusing crashes after I started the Linux port, even on Mike's Windows installation! Out came the heavy tools like Microsoft's Application Verifier (on Windows) and Valgrind (on Linux). Application Verifier found nothing. We found that Valgrind did a much better job at detecting issues than Application Verifier. On some video card drivers, trying to mipmap 2x2 texturemaps caused a buffer overflow and corrupted other data! You might be wondering why we're mipmapping a 2x2 texturemap in the first place. We don't do it that often, but when you have an entire shader path and video card state set up and a particular model has a plain glossmap, it's just easier to give it a small texture to save on video card memory. Let's just say that Mike was surprised when I sent him 8 image files and told him it would fix the crash he was seeing.

Using Valgrind also helped us track down another bug. We got everything working in Linux regarding the menu, then we'd load up a level, everything would load fine, and then it'd crash when attempting to render the units. It turned out that there were 5 uninitialized variables when loading a level in the Achron code. In Windows, one of those variables stored a time stamp was always 0, even on debug builds, which is fine. On Linux, given the slightly different memory layout and reuse, the value ended up being a large negative value. This crept into the rendering code and told the engine to render a unit's animation using a negative keyframe, something we'd never checked for; we only checked to make sure the keyframe was less than the maximum. Valgrind pointed us right toward the line with the uninitialized value, and by a quick process of elimination we found it.

 

First Linux Release

Our current build (0.2.2.0) of Achron is our first official release that has experimental Linux support. Currently the release is for 64-bit Linux, with 32-bit Linux support planned for the future. We knew we wanted to only support one architecture for Linux for now (just like we're only supporting 32-bit architecture for Windows for now), because each platform adds many more hours to our build and testing process; because we're such a small team, this time takes its toll. Eventually, we may set up a first round of testers if there's interest, which would ease this process a little.

The decision to initially only support 64-bit instead of 32-bit basically came down to these main points:

1) Our local Linux installations are currently 64-bit (we mainly use Ubuntu); compiling and linking all the libraries with 32-bit code instead of 64-bit code proved to be a bit of extra work (not to mention support for debuggers, etc.). Further, we had some library portability issues getting a version of Achron built on a 64-bit system to run on someone's 32-bit installation.

2) From the people we've talked to who are running Linux, most of those who had computers fast enough to run Achron were running 64-bit.

3) 64-bit is "the future". Despite the increased extra address size, the increased number of registers and other ISA improvements help out a lot.

So, unless there's a rapid migration to 64-bit Linux over the next year, we'll release Achron for 32-bit Linux at some point. Most likely this will be after we have an automatic update system to make our lives simpler.

Also, Achron pretty much needs the Nvidia or ATI proprietary drivers to be playable. The Mesa software OpenGL drivers work and render fine, but it's too slow to be playable. The only exception here is the GL_ARB_draw_buffers extension, which isn't critical now, but may be in the future.

 

Release v0.2.1.0 and Tournaments

A new release, version 0.2.1.0 is available. This release consists primarily of bug fixes and end-game usability improvements. It also contains a few rearrangements of unit capabilities which are part of a master plan to improve balance and unit identity that is still in progress.

In this release, we can now verify wins and losses with our multiplayer matching system. Now we can start Achron tournaments! For now, tournaments will be arranged in the forums, but further functionality will be coming to the multiplayer game matching service in future releases.

If you have already preordered Achron, you can download it here. We've also included an additional sandbox level available for separate download.

Achron changelog:

*changed units in a hierarchy to wait to be slingshot instead of moving when a commander is slingshot
*added automatic releasing all carried soldiers in a tank hierarchy by issuing release soldiers order on commander tank
*made SOPs weaker and increased their deployment time
*added player disconnect and surrender notifications for multiplayer games
*fixed multiplayer pause bug where all players could get stuck in a paused state without an unpause button
*changed endgames of the multiplayer levels:
- changed Iced level endgame to require "Total Defeat":loss of combat+producing units at farthest point in time, an unrecoverable defeat
- changed IcedTactics level endgame to require "total defeat" and death of gates
- QuadTactics level still uses "Anytime Defeat":endgame caused by loss of combat units at any point in time
*added fore-warning of defeat to levels that use the "Total Defeat" endgame
*fixed bug with soldiers trying to hitch ride in MARs
*fixed bug when clearing commander during attack-move could accidentally cause strange behavior
*fixed bug with soldiers trying to hitch a ride in a tank
*fixed multiplayer end game to allow chatting after game is done
*fixed tooltips for Armory upgrades and hotkey binding conflicts in Factory, Carrier, SOP
*updated upgrading process to not allow concurrent upgrades
*added Teleport control to Resource Processors
*updated Macrofab to require specials upgrade to reload cruiser with nukes
*updated MAR to not merge w/o ground unit upgrade
*updated Mech to not build slingshots without gates upgrade
*fixed pause bug in multiplayer - when you're out of timeouts, others couldn't unpause you
*fixed the absence of acknowledgement button when host lost/surrendered in multiplayer game
*fixed bug when typing on console, hitting backspace would return to present
*fixed empty enter on console in pregame chat
*fixed bug where rapid building placement could get the builder unit stuck in build mode
*added Iced sandbox level

Resequence Engine changelog:

*changed mipmapping back to non-GPU method that is more compatible
*added GET_TIME_WAVE_TIME, SET_TIME_WAVE_TIME, GET_TIME_WAVE_TIME_RATE, SET_TIME_WAVE_TIME_RATE, GET_TIME_WINDOW_DURATION, GET_UNPLAYABLE_PAST_DURATION to Rescript scenario script
*moved keybind checking logic when console enabled from Resequence engine to skin language
*added EnginePausedUnbreakable indicator to skin language
*Post-game disconnection logic decoupled in Resequence for further control in skin language
*fixed word wrap jump when cursor is at the end of the line when typing input text
*removed built-in window CONNECTION_ERROR from the skin language and moved the error into variable DisconnectionReason
*merged soundlib.dll into Achron.exe
*improved font rendering - edges have fewer artifacts
*fixed issue where corrupt config variable would be written if configuration.ini was deleted
*split END_GAME in Rescript into END_GAME and EXIT_ENGINE
*changed achronal fields from being an attribute of the scenario monitor to accessed via performs
*multiplayer win/loss results are now reported to the server for future ladders and rankings
*fixed issue where passing in whitespace message to chat followed by a nonwhitespace message would cause the player's handle to be printed repeatedly
*internal changes to make Achron more platform independent
*fixed lag in chat messages when unbreakable timeout was taken

 

Multiplayer Release

Multiplayer is now ready for download! If you have already preordered Achron, you can download it here. We've included a few tactics-based levels.

Once you run the game, you can log in to our game matching service using the same account you use for the forums. Right now it only lists servers, but we plan to add many features to the game matching service in the coming months.

Although we don't yet have the 3D art ready, we have also released a small multiplayer test level that features most of the human race which opens up the humans RTS play. Note that all the 2D units there are just temporary, their animations are very minimal, and we do not yet have campaign levels ready that introduce those new units and their usage. This level is available on the download page.

 

Here are the release notes:

 

Achron changelog:

 

*major update to support multiplayer
*fixed multiple unit behavior bugs (not following commander, speed matching, autopilot, teleporter spin move)
*changed slingshots to only send units that are not moving past its active area
*subordinates respond faster to teleporting commander and teleport after it quicker
*tanks can transport 2 troops
*some unit and weapon name updates
*changed all rescript scripts to use correct terrain height instead of defaulting to 0 (a step required for improving vertical unit movement, which will come in a later release)
*tanks auto move away from obstacles when trying to upgrade to power tank
*changed move-capable buildings' Plant command to Stop (S)
*fixed binding key conflict for cloaking on ATHC
*changed sensitivity of screen edges for panning via mouse
*updated some sound effects
*changed Forest Battle in campaign to be a multi-time attack scenario

 

 

Resequence Engine changelog:

 

*added multiplayer connection service
*added OSDrawnMouse to configuration.ini
*corrected relative time offset markers above timeline (were not always perfectly accurate)
*added relative and absolute time indicators for current mouse position on timeline
*added alpha_to_coverage parameter to ModelCompiler animation script to improve rendering of leaves, etc.
*mipmap generation is now done by a newer faster method (minor reduction of load time)
*fixed bug where dequeueing 4th and 5th commands would sometimes not propagate their parameters
*added support of automatic NAT-punchthrough and negotiation of Internet gateway devices (e.g., routers) supporting UPnP, added ConfigureInternetGateway and InternetGatewayError variables to skin language
*added fog of war toggle, EnableFogOfWar to configuration.ini
*added rechronoport delay so units must wait before chronoporting again. added perform GET_RECHRONOPORT_DELAY and ->TimeSinceLastChronoport to Rescript. added yellowish pulsing effect to indicate that a unit has chronoported recently.
*added set_console and get_console to skin language so the console can be used as an edit box
*expanded maximum level objective description size
*decoupled return and escape keys from console, unbound console to inputs (some skin variables changed)
*fixed bug where a unit could not always attack a target beyond its visibility range even if the weapon had sufficient range

 

EDIT Feb-16-2010 2:36am: We have solved and fixed the pregame lobby issue with the QuadTactics level. While we were at it, we threw in a couple other improvements to the multiplayer experience. If you have already downloaded v0.2.0.0, you only need to download the patch installer on the downloads page.

 

Resequence Engine changelog:

 

*fixed issue with > 2 players being unable to play in the same game
*hosts now notify service when players have left, updating game stats more quickly
*if selected game is no longer invalid, join game does not display
*join is removed if game is in progress

 

Contributing to Achron

Achron is the fruit of many years of hard work by the founders of Hazardous Software and has been entirely self-funded. Not only do we want to share Achron with the world and let people watch its development first-hand, but we want to give people a chance to contribute as well.

As planned with our release on the 17th (on our calendar), we started posting some concept art on the forums to open up community contributions to Achron. We've produced further details on the program on our contributions page. There, we also list the particular roles we're currently looking for.

 

If you have some talent and contribute something that we use, at a minimum, we'll put your name in the credits and give you a couple copies of Achron to give to your friends. If you do enough quality work that we use, then we may (at our discretion) offer you monetary contracts or include you in the same profit sharing program that Hazardous Software's founders use.

 

The rest of the Achron development team and I have been very pleased so far by the response we've gotten from the Achron community, especially in terms of support and feedback. With multiplayer coming out next month, we have some exciting times ahead.

 

Achron Version 0.1.1.0 Released With First Mod Tool

Jan-17-2010 11:27am by the Hazardous Software Team

A new build of Achron is available, which includes the ability to create 3D models that can be imported into Achron. If you've already preordered, you can download it here. We'll also be opening up our community contribution program today on the forums and website.

 

Here are the release notes:

 

Summary:

 

This release is the first to contain the Resequence Model Compiler, used to build models to import into Resequence. This release also contains numerous fixes and improvements. The Frigate unit is also officially introduced, however, like many other units, not all of its abilities are enabled yet.

 

Achron changelog:

 

*added graphics settings low / med / high choices to: main menu -> settings
*added Restart(level) button to: in-game menu
*changed hierarchy to always follow commander, even if doing something else
*added hitting Z twice deletes/clears all future commands for a unit
*changed priority to be purely a "break formation and move as fast as you can" order
*changed attack logic so units don't clump close to targets as easily (reduces own-splash damage)
*added Stop (s)
*changed keys: ESC-Menu, Tab-Map, P-Patrol(defend), H-Change Commander,C-Chronoport, T-Teleport, + (num pad)-camera lock, - (numpad) reset camera
*Removed Auto-moveAway after a chronoport for human player (makes units easier to select)
*increased size of speed buttons above timeline window
*fixed bug where destruction of Comm Center did not disable auto-hierarchy
*increase in visibility range
*fixed bug where ground units would default to their anti-air weapon
*fixed level scripting bug that would not unlock input after screen-locked autoplay
*added hide top bar and resources when screen is locked during level-auto-play
*redid Basic Instructions Level (campaign Level 1)
*changed forest to use experimental tree models

 

Resequence Engine changelog:

 

*right-click cancels command waiting further input
*hierarchy lines are more transparent for non-selected units when all rendering all hierarchy lines is enabled
*added DisplayFullScreen option to configuration.ini to allow for windowed mode
*fixed bug where units would not be displayed properly when the player was paused in time and changed time positions
*prevent unit selection box from appearing if click and drag off a HUD window that accepts mouse input
*improved model compiler camera
*improved shadow rendering quality
*removed deprecated material model from shaders
*changed campaigns to use jpg/png files
*added glossmaps and specularity maps to units and terrain
*added setval to skin language
*minor improvements to non-shadowmapping shadows
*invulnerability flag no longer blocks commander change actions
*unit commands now validated with respect to player on issue in time in addition to acceptance from player (prevents players' commands from controlling units when the timeline has changed and they shouldn't have been able to)
*added DeleteAllFutureCommands and ResetLevel to skin language
*capture mouse within window bounds to make edges of screen usable with multiple monitors

 

Achron Is Available For Preorder

Jan-1-2010 3:45pm by the Hazardous Software Team

Achron is available for preorder! Enjoy, and feel free to discuss on our forums.

 

Calendar, FAQ, and Other Website Updates

We've updated a few pages on our website in preparation for our upcoming preorder and alpha demo release combo. In particular, check out our tentative release calendar and our updated FAQ.

 

Things are moving along smoothly now (had a few technical issues with website stuff earlier in the week), but as long as no other issues arise, there's a 75% chance we'll launch on January 1st, most likely later in the day. We'll keep you posted on this, and again, we'll make the announcement first via Twitter.

 

The Big Announcement: Time Travel Will Go Live

Dec-24-2009 4:45pm by the Hazardous Software Team

Fresh from the future, Achron is currently targeted to be available for pre-order January 1st. Those who pre-order will be a part of a pre-release community, receiving early builds of the game and immediate hands-on experience with time travel.

Our community will be receiving monthly alpha and beta builds to play. Other pre-release programs include mod tools, tournaments, community artwork submissions, community level submissions, the Resequence Engine, and quite possibly third party Resequence time travel games.

All of these programs are scheduled to launch between January 1 and June 1. The features to look forward to between January 1 and March 1 are alpha testing single-player demo, community forums, mutliplayer release, multiplayer tournaments, community 3D model submissions, and level editor. Some programs may begin earlier than expected while others may begin later. Announcements will be made via Twitter, so join our Twitter feed to be up-to-date on the latest news.

We at Hazardous developed a team of experienced and aspiring industry professionals to bring you the polished experience that you deserve. At this time, we have charted a course to deliver that experience as an independent developer. Our target release date for Achron is 1/1/11.

This release model has been working out well for some (e.g., Cortex Command, Overgrowth, Mount and Blade, Natural Selection 2), and others have proclaimed it as a possible future of game development (e.g., Gabe Newell of Valve Software).

We realize that this raises many new questions for fans of Achron. Please hold questions until the new year, as we will be releasing the details of various programs in the coming week.

Preorder if you choose, and the sooner the better, as more pre-orders will help us improve Achron. The pre-order carries a reduced rate of $29.95, and to reward loyalty, the first 500 pre-orders will save an extra 33%. Pre-orders will go live sometime in the next 7-10 days. This will be announced via Twitter, so be vigilant and seize the discount!

We will see you in January for the first demo release! Thanks again for all of the support. We intend to spend 2010 creating fun time-travel experiences for gaming enthusiasts and aspiring developers alike.

Happy Holidays!
-Hazardous Software Team

Latest Development Work

This week was another busy week. Here's an outline of a few of the things that have been going on.

The stuff behind our upcoming big announcement is moving along well. However, there are still two things I'm waiting on before we can announce it, both of which will hopefully be close to being completed after next week.

In terms of development work, this week was quite a big one in terms of art and level design. We were able to get some major performance improvements out of the rendering part of the engine, and now we have a level that has lots of forested areas. This allows us to go back to our other levels and start filling them in with richer content.

The other big news this week was I began work on porting Achron to Linux and Mac. It took me about a day, but I got all of the engine code except for our sound library and about 5 source files to compile cleanly on Linux (Ubuntu). In doing so, I actually found two very minor bugs that I didn't know existed and fixed them. The remaining 5 source files of the engine will be the most work to port, as they contain all the code specific to Windows. Once that's done, then I'll need to run it and see what happens; we'll just have to wait and see.

Given that I've been working on this for so many years, working through the porting work was somewhat like a trip down memory lane. I had to revisit some code that I haven't touched in several years to clear some compiler warnings. I had used the infamous MAX_PATH in about a dozen places (deals with the maximum file name length on Windows), which all needed to be reworked. Luckily I had the forethought to use forward slashes for all of the file handling rather than the traditional backslashes on Windows, so that wasn't a portability problem.

I've also been working on improving load times a little bit too, and have had some success in reducing the load time by a couple seconds on slower machines.

From my last blog post, I found out that some Twitter applications don't like URLs that have hash signs (#) in them because hashes have a specific meaning in Twitter. In any case, we're going to be making some changes to our website in the near future which might take care of that.

Absolute vs. Relative Time

Things are going really well here and we've been extremely busy here at Hazardous Software lately preparing for... well, we'll tell you about in a couple weeks. We just want to make sure all the t's are dotted and eyes are crossed first (but sorry, no ümlauts over the letter n) before we make the announcement. And sadly, yes, my sense of humor gets worse as I get less sleep.

Anyway, Mike and I were talking about a particular level script earlier today, where the player first learns to use the timeline. We started debating whether to tell the player a particular time in the level as relative to present (e.g., 15 seconds ago) or as absolute time (e.g., at 2:18 since the level started). This conversation revealed something about the way we think about time in Achron, something we'd never noticed before. Mike thinks in relative time and I think in absolute time!

When Mike thinks about a battle that happened in the past, he is always moving the battle through time relative to the present; he is stationary and time moves past him. I, on the other hand, remember that the battle was at a fixed point in time, and I think of it as I am the one moving around in time.

These different ways of thinking actually influence where we look at the screen. The relative time offset is shown above the timeline (which Mike usually uses as a reference), and the absolute time offset is shown below the timeline (which I usually use as a reference).

We haven't had a chance to ask our testers yet which way they think, but this is something we'll need to poll after Achron is released and people are playing the game. I wonder if the preference to think in absolute time versus relative time has any psychological bearing or offers any indication of a person's manner of thinking.

Development and Mod Tools

As I've mentioned before, we're planning on releasing various mod tools with Achron. Achron is built on top of our Resequence engine, and very little of Resequence is specific to Achron itself. The engine is flexible enough to create a variety of games, from relatively minor modifications such as making a tower defense game using Achron units, to completely new games such as a block-pushing multiplayer chronoporting competitive puzzle game, to something crazy like a new twist on gridiron football without discrete plays and with time travel ("The pass was intercepted and brought to the future by the cornerback jumping back in time... Wait, what is this? There are now two balls in play, one from the past, and one from the future!"). With a bit of work, you could even build something like a time travel RPG. Resequence wouldn't work very well for making a first-person shooter style game as of now, but we have a good idea as to how we'd need to change the engine if we wanted to go that route in the future.

 

Here's a general outline of our current tools that we're planning to release:

 

1) Scenario Editor: This is our primary editor, which we're planning to rewrite into two components prior to release: a level editor and game mechanism editor. The level editing portion has what you'd expect in a typical RTS level editor, such as editing the terrain, environmental effects, placing things on the map, specifying specialized scripts for the level, etc. The game mechanism editing portion is extremely powerful. When you add a new unit to a game, you specify the 3D model, how it moves, what it can do, and all of the ways it can interact with everything else in the world. Each unit has some basic attributes supported by the engine (e.g., position, health), but the unit's actions and reactions are programmable. This tool is also used to assign controls and scripts to the unit (HUD buttons, mouse controls, keyboard controls).

 

2) Unit and Level Scripting Compiler: Our scripting drives all unit interactions. It is a procedural C-like language (with a sprinkle of SQL-like constructs), that was specifically designed for use with an engine that supports time travel. Time travel imposes many interesting constraints and development challenges that other games don't have to deal with, so the language gives fine-tuned control over some of those nuances. We're interested in investigating other paradigms (functional, object oriented) for this scripting down the road. The script compiler is separate from the engine, so designing another language and writing a compiler wouldn't require changes to the engine. The level scripts can be both chronal and achronal (situated in game time or beyond game time), and have special capabilities in that they have access to virtually all data in the game. Using level scripts, you can make triggers, decide who wins or loses, and even see when each player is on the timeline.

 

3) Skin Scripting Compiler: We have a unique but concise language that we use to create and control the user interface (HUD, menus, etc.). It supports animations, and can be driven by the level scripting. The skin scripting also maintains in-game settings and maps player controls to more global actions (i.e., those that don't involve controlling an in-game unit, like moving the camera). You could even make a game that had no HUD.

 

4) Animation Editor: Our animation editor is what we use to pull in 3D models and prep them for in-game use. This editor is really more of a compiler and in-game preview, as we make a short script to attach flags and attributes to specify how a model will work in the engine. When we split the scenario editor, we may merge the animation editor with the unit editor.

 

5) Campaign Compiler: This tool is how we chain the levels together to make a coherent single-player game.

 

Most of the tools also have command line support and some logging to make automation easy.

 

Hierarchy Demo

We've received a number of questions about how the hierarchy works in Achron, so we decided to make a video showing how it works.

 

We go over various ways that an advanced player can use the hierarchy. Most of the main hierarchy functionality is covered except for auto-healing and auto-response to attacks.

 

We're also working on some big plans for Achron early next year. We'll let you know when the plans are finalized.

 

 

Tactics Videos

We recorded and uploaded some new videos last night to our Youtube Channel (see below) of some actual games as we were testing some of our new balancing and behavior changes.

 

We typically test by playing full RTS games, but, as I've said before, many of our units are not ready to show to the public yet (see the wallpapers and screenshots page to get an idea as to the programmer art still in the game). We're working on a number of aspects on the art side right now, and are looking to start ramping up art production on the units soon. In the mean time, we decided to make a more tactical level for this video using some of our current 3D models. Also note that the set of units used in this level have mostly mid-range attacks.

 

Playing a tactical level is quite different from general RTS because you only start with a fixed number of units (and chronoporters!). It was a good test because it forced us to focus more on unit behaviors, which we've been working on lately. It was also simultaneously slower and faster than a full RTS game as you spend more time deciding strategy and less time building things.

 

The videos are recorded from Mike's computer, with him (dark blue) and I (green) allied playing against an alliance of Greg and Konrad (two of our testers in yellow and light-blue). Mike and I tried to talk a little more than usual to say what we were doing, and Mike used the mouse more than the keyboard shortcuts to allow viewers to see what was happening a little better (not using the keyboard shortcuts, for some reason, made Mike use the hierarchy less than usual in retrospect). We played three games, and each lasted about 20 minutes.

 

When a multi-player game starts, the present starts on the left of the time window and moves toward its eventual position on the timeline, as the player can't go to back before the game started. Both of these videos are near the start of a game, so you'll see the present moving forward in time before it reaches its eventual position.

 

Of the videos we captured, these two were the most interesting to watch. Since these were the first full games played after some significant changes to balancing and unit behavior, we walked away from these games with about a dozen new items on the todo list.

 

 

 

Balance and Rendering Improvements Have Begun

For a long time, we've been laying out plans on how we were going to balance everything: units, races, levels, etc. We had been waiting until we had finished our gameplay feature sets first. We didn't want to start balancing everything, then modify the units' behavior in some critical way, only to realize that the new behavior threw off all of our balancing. Now that the gameplay feature set and base unit behavior are largely complete (pending a some minor tweaks and additions here and there), we have begun our first major balancing pass.

 

We're also beginning to work on improving the rendering algorithms. Already, the current terrain and units models (as previously seen in the videos) are looking a bit better; look for a new video in the next week or two. We're also going to start ramping up the visual arts soon.

 

For anyone not following us on Twitter, I've had two interviews recently, one on OfficialRTS here: http://officialrts.blogspot.com/2009/10/interview-with-chris-hazard.html, and another on the iGameRadio podcast here: http://www.igameradio.com/2009/10/15/podcast-ep-83-hazardous-software-word-ace/ (though their webserver was having issues at the time I posted this).

 

Now on to balancing...

 

In developing an RTS, the real proof of the effectiveness of balancing is always when you test it with people. However, you can do significant initial balancing before testing on a wider scale. By employing basic mechanism design principals, you can design the high-level game structure and somewhat guarantee that no unit types will be dominant or worthless in actual games, based on cost, abilities, and how they compare to all other possible units. Using nontransitive relations (colloquially referred to in game development as rock-paper-scissors technique) is the easiest way to guarantee that players are incentivized to use mixed strategies.

 

Games that are based on simple mixed strategies are often difficult for people because we're not that great at making up random numbers (but we may not be that bad either). Simply label two of each of the six sides of a fair die "rock", "paper", and "scissors", and play against it. Given enough rounds, you can't beat the die on total wins. However, if you're not playing perfectly random, another player could take advantage of the lack of your perfect randomness and win.

 

You can also play off people's abilities too. One strategy can be made overall ineffective unless a player is good at micromanagement, in which case it can beat another method. You can't allow a single dominant strategy though, otherwise the game isn't fun. Essentially, all well-balanced RTS games are, to some degree, extremely large nontransitive games.

 

Simple mixed strategy games can get boring, so setting up interesting combinations of dominant substrategies within a larger strategy space helps considerably. People try to out-think each other, and because people are bad random number generators and also because it's difficult for people to model common knowledge with uncertainty, such relations can and do make for interesting games.

 

In Achron, spending chronoenergy to change the past creates an interesting situation for mixed strategy games. When you see your opponent's strategy, you can go back, expend chronoenergy, and change your strategy to a winning one. Your opponent can do this too, making for some interesting game dynamics in the high-level strategy, keeping the game balanced even with the addition of time travel (other than the addition of chronoporting, which is a balancing topic for another day).

 

In working through our first balancing pass in Achron, we have designed our high-level gameplay strategy structure. The step we're working on now is translating that into actual gameplay. Whereas you can simply change the weapon strength, range, speed, reactions, and other attributes of a unit and hope that you get the balance to what you designed and modeled, we actually have an automated process that drives the engine (units' AI and all), and tells us exactly how close we are to achieving our design, including the statistical error. This obviously takes quite a while to run at full statistical significance, but it makes sure that the empirical data matches our theory. That way, we can don't have to guess; it just works. We're working on using this to balance the humans initially. Once we've perfected the process, then we'll expand this to balance all 3 races, internally and externally at the same time.

 

I'm really looking forward to playing some games after a couple balancing passes. However, I think it really shows what multiplayer time travel does to an RTS; Achron has been fun even before we started balancing!

 

[Edited 10/26, 8:29pm to correct minor error in RPS example.]

 

The Music of Achron

Achron has a four dimensional story which begs for an engaging sort of storytelling -- something with some darkness, gravity, and emotion to it. When I started working with Hazardous Software on music for Achron, there was not yet a visual artistic concept to coordinate with, which meant there was quite a bit of back and forth between myself and Chris about storyline and motivations. We determined that there would be a few key factors to account for in the music. One would be that it should be something one could listen to for an hour at a time without going crazy. While it cannot be confirmed that this will make the final cut, our current intentions are to use tracks which are significant in length, so as not to be an afterthought.

Another major consideration was that there was a story to tell and epic themes were going to factor in. The bottom line is that I did not want to get lost in a generic feeling of military or sci-fi cliche. I wanted to use the music to emphasize story elements.

Because the story begins from the human perspective and much of the story involves being somewhat achronal, we mixed themes of bravado, arrogance, regret, and loss, which accompanies a people who are, for all intents and purposes, lost in space that they had previously conquered. At the same time, these people still have something to lose which is worth fighting for, so that sense of urgency and non-hopelessness has to be inherent.

For the Vecgir, we described their context for being with themes of brokenness, freedom, individualism, and tribal instinct.

The Grekim are a discussion for another day.

In fact, all of the races and factions should come out of the creative process with intertwined themes, and hopefully, a unique sense of ethnicity specific to the culture and predicaments of each race. Some characters with a more of a macro sort of significance will have their own themes as well.

Apart from the action, I wanted the player to feel the underlying sense of aloneness. Not loneliness, per se, but the sense of being completely disconnected from any form of outside civilization, and in a strange place at that. There is room for a sense of wonderment, and that leads to not every moment being uniform and dark. Ambient sound is a wonderful thing. While sweeping epic Hollywood-type orchestral elements are just irresistible to work in, the ambiance wipes away the polish and theatrics of an orchestral arrangement and brings a better sense of reality, closeness, and experience to the soundscape.

Another factor that comes into play when you mix sampled instruments with analog recordings is you get to mix organic, industrial, and synthetic instrumentation to create a sound which is consistent for the characters and settings of the Achron universe.

Overall, we will be sprinkling elements which occasionally remind us that much of the Achron universe is, in some way, distorted by time manipulation.

Perhaps many of these factors are subtle, maybe even unrecognizable, but hopefully they result in an experience that simply feels right. When the game is finally released, I expect to have assisted Hazardous Software in realizing the best presentation of the Achron universe.

I will probably submit a sample of some of the potential themes sometime in the next several weeks. The following clip is currently slated as our title screen and interface track, though it is subject to change. I sincerely hope that it makes you feel lost and alone.

Achron Menu Theme Download (mp3)

 

Art Direction

Creating and conceptualizing the fictional world of Achron is an extremely challenging and rewarding venture. The multifaceted nature of the Achron universe draws upon real world science but also strives to create its own unique identity. The game play innovations in Achron -- the world's first meta-time strategy game -- inspired the art direction to push for a distinctive style. My goal has been to develop a unique identity for Achron, establishing the style, look, and feel of the game that works in parallel with design and story to bring a cohesive package.

 

In the beginning, my approach to designing Achron was drawn from straightforward hard core sci-fi traditional structures and conventional design elements. As the concept rounds evolved a tighter connection with science along with a focus on integrating the story line, I began to push the conceptual designs towards a unique look. Following an evolutionary path, the two alien races in Achron began to take shape. Genetic manipulation, the relationship between all three races across time, and their motivations defined the look and feel of the alien races. Technology was also a factor in the character designs. Each race's technological strengths are critical factors in how the story and gameplay evolve in Achron. Design considerations on how each race interacts in space and on ground as well as how players can distinguish between hierarchical ranks and provide visual feedback on their function within the game were all elements integrated into the design. An evolutionary theme became evident in the designs; quirky and exaggerated proportions were incorporated in creating a distinctive world.

 

 

In this initial character concept art you can see that scale and proportions come into play. This will affect how the player interacts with adversaries during game play.

 

As we continue working on art design and production, the focus will remain to stay with the creators' original vision of Achron.

 

Programming for Performance

It's good to be back working on Achron after being vacation in eastern Africa for a couple of weeks (pictures on my academic site under Travel & Pictures). In this post, I'll talk about more day-to-day development activities, performance in particular.

 

At least once every couple months, I spend some hours profiling Achron while it's playing a big battle. In software development, profiling tells you what parts of your code take how long to run. You find the areas where the engine spends the most time, and you either try to figure out a better algorithm or improve the efficiency of your code. On modern processors, there are many issues to worry about, and sometimes performance can be counter-intuitive.

 

Mike and I have been working on some new features for unit projectile weapons (e.g., missiles, etc.). I added some new functionality to the engine that helps units choose the position to attack, rather than just the unit. As I finished implementing it, I reasoned that this new code might improve performance slightly. The new code orders the possible attack positions first before checking to see if they're attackable by the weapon (e.g., make sure it is in direct line-of-sight for line-of-sight weapons). It doesn't need to waste as much time checking bad positions (e.g., the back side of the target).

 

I went to perform profiling, and sure enough, it did improve performance a little bit. I ran a few large battles to see what the new performance characteristics were like. In one game, I noticed a function using a lot of the CPU time (~8%) that had never been on the radar before. In the other games, it was only few percent of the CPU, but still, I wanted to look into it.

 

The function is one part of checking whether one unit can see another. In the ~30 line function, I noticed a whopping 2-3% of the CPU time being spent on a single line of code!

 

That line of code is a heuristic that decided whether visibility was worth investigating further. Effectively, the line basically says, "if the unit is too far away, don't bother doing detailed checks". To make the heuristic accurate, I used floating point numbers (numbers that can have decimal places). I looked at how fast the processor was executing the code (known as IPC), and it was quite low. In light of the surrounding code, I decided to make the heuristic use integers instead. In this case, integers are less accurate, meaning that it will need to perform the full detailed checks slightly more often, but given the code, should run faster.

 

Sure enough, with the integer code, that line used 0.3% of the CPU! The extra detailed checks did use up some of the CPU time, but the new code was still used about 2% less CPU time than the old floating point code while still providing correct results. (And of course I made note of this in the comments.) Using 2% less CPU may not sound like a lot, but small improvements like this add up through development.

 

Smart-Idle

One useful feature of Achron's gameplay is called smart-idle. Smart-idle means that units will do smart things on their own while idle, which is useful when you are not then or are just too busy to manage every detail. When smart-idle is enabled, units automatically perform many minor tasks such as request repairs when damaged, reload weaponry, and request backup against specific opponent threats.

The goal of smart-idle is to minimize micromanagement for the player so that the player can focus on general strategy across the timeline. A few examples of unit behavior with smart-idle enabled are:

* A repair or healing unit will automatically make its way toward a heavily damaged unit to restore its health.

* Units will automatically move toward a building to reload on ammo or pilot vehicles.

* If one of your units sees an ally that needs recovering (e.g., communications-jammed), a recover-capable unit will automatically fly over and recover the hindered unit.

* Units will automatically move toward a teleporter if they are not close enough to teleport and toward a chronoporter gate to be within range to travel through time when the appropriate command is issued by the player.

Each race can enable smart-idle via their equivalent of the Humans' communication center building, a mobile building that is also used to enable auto-hierarchy. These abilities were made to be toggleable because some expert players may not want to have auto-hierarchy or smart-idle enabled, deciding to micromanage everything themselves. This also gives the player the choice to save the extra time and resources required to spend on building and protecting a comm center. We have found that many players typically want to use at least one of these comm center functions. Since losing your comm center disables both smart-idle and auto-hierarchy, players may build extra comm centers for redundancy in large games.

Since I am a faster clicker/traditional RTS player than Chris, I often don't build a comm center until later on in the game. When I do build a comm center, I usually only use smart-idle to assist my gameplay, but prefer to play without auto-hierarchy as I am extremely particular about how my control hierarchies are set-up. Chris, on the other hand, likes to build a comm center early to enable both smart-idle and auto-hierarchy, and concentrates less on micromanagement.

 

GamingSPARK featuring DARTT and Achron

I had a fun time hanging out at GamingSPARK during SPARKcon where a selection of locally created video games were showcased. Several casual, mobile, student-made and serious/simulation games were featured, including Achron and DARTT. Some players there knew of Achron and were itching to try it, while some had never heard of it but were intrigued by the concept and gameplay. Observing the different people play the game was quite interesting. One of the DARTT levels requires the player to avoid ambushes and survive without sustaining any losses. Beating this level without using time travel requires patience, so it was entertaining to see less patient players quickly learn from their mistakes, realizing that they can go back in time to avoid or to confront ambushes.

 

Play DARTT and Achron at GamingSPARK

As I've mentioned in a previous blog post, we've received quite a lot of interest from people working on serious games. Achron's underlying engine, Resequence, can be used to help teach long-term causality, sensitivity analysis, etc.

 

We've recently put together a mod of Achron called DARTT, which stands for During Action Review Tactical Trainer. It is an early experimental prototype game designed to teach higher-level strategy to commanding officers in the military by allowing the player to instantly revisit any point on the timeline. In some ways, it reinvents After Action Review, as the player has immediate feedback and can explore the strategy space by changing committed decisions.

 

DARTT was also a success in that we did not need to modify any of Achron's engine code. Granted, DARTT is an RTS and shares similarities with Achron. However, we were able to build DARTT's mechanics and create two playable levels in only a couple days using only our mod tools. Additionally, building DARTT gave us ideas for better honing a couple aspects of Achron's gameplay.

 

Next week Friday (Sept. 18th) and Saturday (Sept. 19th), DARTT will be featured at GamingSPARK: http://www.sparkcon.com/2009/09/18/video-games/. If you'll be near Raleigh, NC during that time, both DARTT and four introductory single-player Achron levels will be available for anyone and everyone to play. The Achron levels available at GamingSPARK will consist of 2 tutorial levels (one that walks through basic controls, another that walks through time manipulation) and 2 basic levels (no building or resource gathering involved). See the GamingSPARK website for the location and times. Unfortunately, due to travel conflicts, I won't be able to attend GamingSPARK, but Mike may make an appearance.

 

Teleportation

Teleportation has an interesting history within Achron's development. We knew we wanted some different terrain barriers (e.g., rivers or cliffs) in the game that certain kinds of units couldn't pass over. The ability to move those units past barriers and off islands, such as by using dropship or carrier units, adds to the breadth of strategies possible on a given map.

Very early in development, before carrier units were implemented, we added the ability for units to teleport into Achron's Resequence engine. Teleportation was an easy-to-implement gameplay mechanism intended as a placeholder for carriers. When we started building gameplay with teleportation, it turned out to add so much to gameplay that we didn't want to remove teleportation even when we had carrier units. This was also early enough that the story was just starting to coalesce, and so teleportation entered the Achron universe as a core technology, related to the mechanism by which chronoportation occurs.

In Achron, the maximum teleportation distance is a function of the size of the teleporter. Teleportation is an advanced upgrade for both the Humans and Vecgir. Currently, the Grekim do not have teleportation but are generally more mobile than the other two races, and can be upgraded to individually chronoport (at a cost) without a chronoporter. In addition, Vecgir units can be individually upgraded to self-teleport; self-teleportation requires a large portion of a unit's energy.

Arriving from a teleport also takes a little bit of time. Therefore, if a group of your units teleports right next to an opponent army, the opponent army will likely have time to release at least one volley of attack before your units finish arriving. Further, while the Humans and Vecgir teleporters can automatically teleport units in rapid succession, they can still only teleport one unit at a time. Teleporters are generally more useful to move units around a map rather than to launch units immediately into battle.

Vecgir teleporters can actively repel nearby enemy units back in the direction they came. The active repel mode is helpful in defending against individual close-range units, which need to keep walking forward between each attack. However, the active repel mode is less effective against an overwhelming number of close-range units, and ineffective against long-range units.

Human teleporters have a similar mode, but which works only with a player's own units (and allied units). Everything less than a maximum size within the teleporter's vicinity gets sent to a destination area. Back around 2006, a couple of us became quite fond of using teleportation-centric strategies before we restricted active teleportation to only friendly units. One strategy was to distract an opponent, sneak a teleporter into an enemy base, and then fling various buildings to a different location. Another strategy was to build an armada of turrets and then teleport them into an enemy's base. While these strategies were creative and initially amusing, they were too powerful. To address this, we added further limitations as to what teleporters can move.

Even though we have chronofragging, we decided to disallow telefragging for a couple gameplay reasons. One is that it encourages players to micromanage teleportation targets for strategic overlap. Because teleportation is significantly cheaper than chronoporting, players more easily get into an rapid undo war that favors clicking rather than thinking. A second reason is that it nullifies any advantage one unit type has over another, simply incentivizing players to overuse teleporters and favor units with more hit points. We may eventually end up making telefragging an optional setting, but for now, we've preferred the gameplay without it.

Teleporters often become strategic targets with respect to time travel, just like factories and builder units. Suppose a player uses one teleporter to launch 3 battle groups to different places across the map. If an opponent goes back in time and destroys the teleporter, then those 3 battle groups will not be able to teleport and may take significantly longer time to reach their targets.

 

The Story

We've been working on the story for Achron almost as long as Chris has been working on the engine. Developing the story for any video game these days isn't a task to be sniffed at, and Achron is no exception - our story is quite rich, with plenty of twists and turns along the way.

 

But I can't really talk about that in depth, now can I? That would ruin the surprise.

 

When Chris asked me to start posting here, it initially seemed that the best way to go would be to discuss the writing process for this project. However, after spending some time trying to write out a few posts it became clear to me that that process isn't nearly as interesting as discussions of working out unit balance and strategy. In any case, I'd much rather have a story for you to read than a blog post that was all about the writing process.

 

With that in mind, we're going to be unveiling some short stories over the following months that paint the Achron universe with a little bit more depth. You can find them by following the link to the story page, and looking for links within the story.

 

Large-Scale Tactics

Mike and I have been recording some new videos of Achron for the upcoming August 25th episode of The Escapist Show. One of the videos we recorded for them is a large battle. Mike and I each had about 150 units at our disposal, consisting of laser tanks, mechs, and lancers (most of our unit types don't have art that we're ready to show in videos yet).

 

In the games we typically play, it's quite rare to have such large armies facing off head-to-head all at once, mostly because people don't wait that long before first strike... which, as usual, may be undone after seeing how bad it went and then followed up with a new attack in the past from a different direction. Utilizing large groups of units and working through the tactics with time manipulation was a lot of fun. These larger tactical battles will be in the single player campaigns, as several parts of the story call for them.

 

Being able to travel through time allows both players to react and correct mistakes, so tactics become even more interesting. In one battle, I initially tried sweeping a group of Mike's tanks by the side with about ten lancers. Lancers are fast and nimble air units, but aren't particularly strong. My lancers did some damage, but were then flanked by another one of Mike's tank groups. However, the next time I jumped back to the beginning of the battle, I saw that Mike had intercepted my lancers with a group of his own.

 

Throughout the games, Mike or I would partly surround and defeat a small group of opponent units... and then the other would change history.

 

I distinctly remember the point in 2006 when we first put restrictions on some units' firing directions. It had been on the todo list for a while, something we had planned at the earliest stages of development. Before this was implemented, all units could rotate to fire in any direction almost instantly. These directional restrictions required tanks and many other units to rotate or move to face a target before firing. Flanking instantly became an effective way to gain an advantage on an opposing force, especially when coupled with some tactical teleportation.

 

The hierarchy controls were very useful at this larger scale. I tried a few different management strategies. In the first game, I put all of my units in one big hierarchy, with 4-8 subordinates per commander at the lowest level and about 3-5 subordinates per commander at the higher levels. Because I found myself using various parts of the hierarchy frequently and hardly used the top-level commander, I used about 6 independent command hierarchies instead for the later games, varying their compositions.

 

Initially organizing the units was pretty easy. The communications center building has an auto-hierarchy control that tells units to form hierarchies automatically based on units' types, ranks, and positions. Even with the large number of units in a random layout, it only took a handful of commander assignments to get the form of hierarchy I wanted. The only times I changed the hierarchy structure during battle were when Mike had my units almost surrounded and I was trying to hold off some of his units while others of mine attempted to break away.

 

NCSU Talk and Revised Demo Video

The talk I gave at North Carolina State University (where I'm finishing my Ph.D.) back in June for the Digital Games Research Center is now online here: http://www.youtube.com/watch?v=4dwmgiZ1ajI. The talk is about 70 minutes long.

Abstract: While many games have utilized the enormous computing power available on consoles and PCs for graphics, physics, and artificial intelligence, few games have realized this untapped resource for innovative gameplay. In this talk, I will discuss in-depth about the use of time travel and time manipulation in gameplay, sharing our experience developing the world's first meta-time strategy game Achron, a real-time strategy game where all players and units can jump to and play at different times independently and simultaneously. I will present a brief history and overview of time travel and time manipulation as it is used in literature, movies, and current games. The types of time travel described in science fiction are much richer than have been previously implemented in video games, and I will discuss ways of implementing them from a gameplay perspective, while touching on some technical aspects. I will share various nuances about time travel and time manipulation mechanisms and how they affect game design, showing benefits and pitfalls, and how they relate to traditional puzzles and strategies in gaming.

We've also posted a revised video of the first Achron demo video:

 

Everyday Development

For a slight change of pace for the blog, this post will be more detail than usual about what sort of day-to-day things I've been working on for Achron.

As the gameplay and time manipulation portions of the engine have matured over the years, my focus on Resequence (Achron's engine) development has shifted. When I started developing Achron, I began with the core engine interactions and time manipulation and then moved slowly toward developing features that were less critical to gameplay. Right now, I'm primarily working on little details that allow for more advanced in-game scripting and on the user interface, and will slowly begin transitioning to work on improving the rendering and visual effects in the near future.

Like almost every sizeable software project, game development has its share of less glamorous tasks. I often need to code new features, fix bugs, provide a new API call to make something possible on the user interface, or work on the business side of Hazardous Software. For example, here are the seven most recent changes I've made to the Resequence engine (I just finished one of them an hour ago):

* added shadow chronoenergy cost to show how much chronoenergy is needed to issue a command
* fixed bug where selecting a unit's chronoport control and then immediately selecting a movement control without issuing the chronoport command would result in ETA (estimated time of arrival) not being displayed on the timeline
* tuned chronoenergy model and chronoporting constraints to disincentivize chronoclone griefs
* added UI skin language control of rendering of selected regions on the timeline
* added InsufficientMaxChronoEnergy and ShowTimelineWhereInsufficientChronoEnergy to UI skin language
* added support for multiple simultaneous fonts in UI skin language
* added built-in actions to scripting language to allow scripts to be independent of game speed without using constants

Throughout all of this development, I continue to work on mathematical models of Achron's gameplay for balancing and to make the game fun. I often use various techniques from the disciplines of game theory and operations research. Even something as seemingly simple as a racing game with no powerups during the race, such as NASCAR, can have complex strategies (see http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/viewArticle/727/636 for an interesting basic analysis). My goals in designing Achron's gameplay with Mike are to (1) keep the game open to a wide variety of strategies while (2) keeping gameplay easily understandable and manageable so (3) players can be creative without needing to devise overly complex strategies, all while (4) removing incentives that create gameplay griefs.

Part of what makes these mathematical models interesting is the open and repeated nature of interaction in games, and Achron's time travel makes the analysis even more interesting. However, game theory must be carefully applied because a good strategy can become a bad one when time is taken into account. (If you are knowledgeable about game theory and are interested in this area, I highly recommend reading the book Repeated Games and Reputations by Mailath and Samuelson.)

Sometimes I'll design a handful of prototype models for some gameplay aspect in a spreadsheet. Then I'll send some graphs back and forth with Mike and others. After discussing them, we'll implement the model we believe will work best for gameplay and then start testing to see how well it works. Most recently, we've been doing this process for tuning the costs of chronoenergy.

Time Manipulation Strategies in Achron

We've been making some good progress on a number of fronts: chronoenergy model, timeline UI, concept art, etc. In particular, the chronoenergy bar now indicates how much more chronoenergy is needed if it is insufficient, and the timeline shows where chronoenergy is currently insufficient to issue commands.

We've recently added an additional alternative mechanism to prevent chronoclone griefs. Chronoclone griefs occur when a player affects units that have traveled to the past, but their chronoport arrival is no longer on the timeline and so the changes are not propagated. Before, we only employed economical incentives to prevent such griefs, where a player could cause a chronoclone grief at the cost of significant chronoenergy. The new mechanism involves an extended portion of the timeline beyond the player's ability to affect the past with chronoenergy. As long as this time distance is greater than the maximum time distance a unit can chronoport, then chronoclone griefs become impossible. The added benefit of this new mechanism is that we can reduce the costs of chronoporting to encourage more of it in games without risking chronoclone griefs becoming a dominant strategy. We'd been discussing adding this mechanism since long before Achron was publicly announced, but we finally reasoned that it may lead to better gameplay. We're going to start having our testers try it out the new mechanism in the next couple weeks (along with some new models of chronoenergy regeneration when in the past), and I'll post how it works out.

I was reading some of the posts on the Chronofrag forums recently (an unaffiliated forum for discussing Achron), and came across their discussion on enumerating strategies that are unique to Achron's time manipulation here: http://chronofrag.com/viewtopic.php?f=2&t=36. It's quite an impressive list so far, worthy of some discussion. As of my time of writing this blog post, all of the strategies listed are possible in Achron. (However, a few, particularly those regarding permanent chronoclones, are only available for certain game configurations.)

For starters, I'd like to discuss what they call the red herring attack. With the red herring attack, you attack your opponent, wait for your opponent to respond, and then undo the attack. The objective of this strategy is to either distract your opponent from something or to force your opponent to spend time and chronoenergy responding to an attack that will be undone. I've used this strategy myself and have seen others use it in our playtesting.

Building on the red herring attack is the dead men tell you lies strategy. This is where a player uses units that have been destroyed in the past to attack you some time in the nearer past or future, before the timewaves catch up and remove the attacking units from existence. We've used this strategy in play testing. One memorable game with a similar strategy was between Mike and I back in February. It was a memorable game for me, because it was one of the few times when I almost beat Mike. Mike is a better RTS player than I (and he did most of the unit design), but I tend to use time manipulation more creatively; if it weren't for my strength there, I wouldn't stand a chance. Anyway, I carefully won against him back the far past and completely undermined his success. He'd been somewhat neglecting the past, focusing on building a massive army in the present. He usually doesn't neglect the past so much, but he may have been overconfident in assuming that he was going to win this game. Once he saw how much I had disrupted the past in my favor, he rushed me in the present before the timewaves caught up. Because we were playing the game mode where win at any time at or before present wins the game, Mike ended up winning it. But I was close!

The last two strategies I'm going to comment on in this post from the chronofrag forums are what they call paradoxical attacking and wavefunction collapse. Both of these strategies involve the player setting up some form of temporal paradox (e.g., the grandfather paradox), and then building a different strategy on each side of the paradox. The opponent must then react differently when each time wave comes by. I'd never thought of doing this before, and to the best of my knowledge, no one on the team has either! It'd probably be somewhat tricky to pull off, but it just goes to show the richness of strategies that players can create with free-form time travel.

To add to Chronofrag's list of strategies, here's a few more off the top of my head that I remember seeing (or using myself) in games:

Economic undermining: Play in the past and strategically target an opponent's resource processors (RPs). The opponent will have less resources throughout the timeline; some buildings, units, and upgrades the player had built won't be able to be created in the new history because the player won't have had enough resources (which may include some very critical units, factories, or upgrades). Normally, good RTS players try to expend their resources as fast as possible, keeping their resources close to zero in order to utilize the resources as soon as possible. However, players who keep their resources too close to zero put themselves in a weak position with respect to economic undermining.

Perfect startgame: When starting a game, stop, slow, and fast forward as appropriate to give precise commands so your builders create resource processors as early as possible on the timeline. For good measure, throw in a red herring rush to an opponent in the mean time if they're close enough on the map.

Optimal mix: First, scout or attack an opponent to see what types of units your opponent is building. Then, go back in time to manufacture units that work best against your opponent's mix of units, and proceed to attack with this new optimal mix. I've won at least a couple games mainly due to this strategy.

Me too: Go back to the past, build more units (or just chronoport units to the past), and set them as subordinates in armies before they go out to war. The subordinates follow along with everything that army does without needing to change your strategy or expend more chronoenergy. This strategy can complement optimal mix, and is particularly helpful in one of our current single player levels.

 

Website Update

We uploaded some updates to the website today with a little bit of new information. The new navigation buttons up top are in the style of Achron's menus.

 

Work On In-Game Scripting

All is moving along well on development. We've been working on improving the in-game scripting API to add all sorts of features to levels, especially those where we teach the player to use various aspects of time travel. It's particularly interesting developing this, as there are really multiple times going on, while the player is only watching one at the same time. If an event occurs 2 minutes ago in a tutorial, you have to consider whether the player should be notified in the present.

We're also still working on fine tuning chronoenergy consumption and generation models for gameplay purposes.

Achron was also discussed on last week's Dogear Nation podcast.

For those of you following us from the USA, have a safe and fun 4th of July weekend!

 

Advanced Hierarchy

In creating our hierarchy controls for Achron, we built a 'priority' dispatch to give the player exact control over which orders units execute. Units can be controlled either by their commander's orders or directly by the player. The 'priority' control is a simplified way for the player to tell busy subordinates to immediately do whatever their commander is doing without having to micromanage the subordinates. The default priority button is the space bar.

A 'priority' dispatch is used to force subordinates to follow their commander if those units are busy executing a previous objective from their commander. Since player-input has the highest priority, a player-issued command to any subordinate will override previous orders (as expected). However, in the case where a subordinate is busy following player-issued commands, a 'priority override' dispatch (simply pressing priority twice in a row) is used to force subordinates to re-follow the commander. In all situations, you can think of the space bar as telling your units "NOW!" to the current order.

A hierarchy can be setup manually by the player, or the player can enable Auto-Hierarchy, a mode where units will automatically create hierarchy groups. Players who like to use hierarchies but prefer not to spend time setting them up will find this mode useful. When a commander unit is destroyed, its direct subordinates simply revert to being independent units but will attempt to complete their last objective. Without Auto-hierarchy enabled, the new commander-less units remain without commanders. With Auto-hierarchy enabled, they will automatically try to find a substitute commander.

I'd also like to point out that a fan has set up unofficial Achron forums at http://chronofrag.com. We're unaffiliated, but we'll be watching that forum among others.

Chris has posted the slides from the talk he gave at both the Triangle Game Conference and North Carolina State University. The PDF may be found at his academic website here: http://www4.ncsu.edu/~cjhazard/publications/cjhazard_time_travel_gameplay.pdf

New User Interface and Paused Time

We've posted a new video showing our revamped user interface. In the video, we also show how a player can pause time to issue precise commands.

 

Progress on Business, HUD, AI

Things have gotten busy lately - lots of travel, but busy in a good way. We've been looking at many potential business opportunities to get Achron out to the market, and we still have more interesting avenues yet to explore.

We're still making good progress on the new user interface. I just have a few parts I need to finish implementing to make the skin language more flexible, mostly dealing with string manipulation and integration between the in-game scripting and the skin. We're planning to post another video in the next week or so to show the new user interface (among other things).

Another project we're working on is an improved AI with respect to automated healing, repairing, and recovering. Repair units currently respond to nearby units that need repair when smart idle is enabled. What we're working on adding is the ability for a player to assign repair units to a specific hierarchy group. This way, the repair unit will give priority to other units within the same hierarchy.

Serious Gaming Applications

Not too long after I first started working on Achron, Mike and I began discussions about practical applications of this technology beyond time travel in video games. Since we've unveiled Achron, we've received significant interest in using some of our technology for serious games such as military and corporate applications. Here are the three main uses we're looking into:

1) Training. Achron's temporal mechanics can be used to teach long-term thinking using a simulation. When a player is able to go back and change decisions, they begin to automatically think about the long-term effects and causality of every decision they make.

2) Sensitivity analysis of simulations. Suppose you have someone who isn't particularly quantitative, but wants to learn how a system behaves in a simulation in various situations. Achron's engine provides a way for the user to blur the line between hypothetical and actual when driving a simulation.

3) Collaborative planning. Several people can be editing the strategy of a timeline all at the same time. Once an event has aged such that it is no longer on the timeline, then it is considered committed.

Chronofragging

Many games utilize the concept of tele-fragging or spawn-fragging someone, where you destroy your opponent by spawning or teleporting to the same location as them. In Achron, a Chronofrag is when a unit travels through time but winds up occupying the same space as another unit. The weaker of the two units will be destroyed, while the stronger will immediately incur the appropriate amount of damage as they cannot both occupy the same space at the same time. An analogy for fans of the Terminator series would be the timetravel sphere of destruction that burns everything in its space, except in Achron the time traveler is not protected.

If a unit is stationary for a long time and time travels into the recent past, it may chronofrag itself. In this case, the time traveler will just barely survive as the damage it will incur will be almost all of its own health (the time traveler has a slight advantage). If a large unit travels through time into a space overlapped by several units, the damage will be spread out accordingly.

One possible strategy is to sacrifice some units from the future by sending them to the past to chronofrag an opponent that was attacking your base, delivering massive and immediate damage to those enemy units. This mechanism also lends itself to interesting strategies and uses of the chronobomb. Not only can a chronobomb bottleneck opponents' forces, but it can also be applied to use the opponent's forces against themselves. One such strategy is to use a chronobomb against an enemy in the past at a location where the opponent has different units there in the future, chronofragging all those enemy units.

To see an example of a chronofrag, check out our previously posted video here: Chronoporting

Triangle Game Conference Talk

The first day of the Triangle Game Conference was a lot of fun. My talk went well, and the Escapist Magazine has some coverage of it:
http://www.escapistmagazine.com/articles/view/conferences/tgc_2009/6016-TGC-2009-Day-One-Wrap-Up.3

Also, the talk was videotaped, so I should be able to post portions of it sometime in the next few weeks once they get the DVDs ready.

Attractors

When playing Achron, you don't need to worry much about temporal mechanics as the game engine will figure them all out for you. You can see changes on the timeline and the gameplay is simplified because you can react to them. However, it can be fun to think through some interesting cases.

For example, time waves add dynamicism to the timeline. Suppose you start out with some damaged units and just barely survive a big battle using the damaged units. You send a heavily damaged mobile field base (MFB) back in time to before the battle to aid in repairing those damaged units. The next time wave will bring these repairs forward in time, and because the ground units are now repaired, they are able to protect the MFB. This time, when the MFB travels back in time, it is no longer heavily damaged. When it arrives in the past, it is able to repair the ground units more quickly. Eventually, after a couple time waves have passed, the system stabilizes.

Also, the Triangle Conference is almost here. Mike and I will be attending the IGDA kickoff party tomorrow night, so feel free to say "hi" if you see us.

I'll be talking a little more about this in my talk on Wednesday, but if you want to read up in the mean time, look up dynamical systems theory and attractors.

TGC and Alliances

It's been a really busy week here. Work on the new UI is progressing, we've made a few more gameplay tweaks, and I've pretty much finished the slides for my upcoming Triangle Game Conference talk. The good news is that I've talked with the conference organizers and they said that I have permission to post portions of my talk online. Barring any last minute misfortunes with AV equipment, I plan to post the videos a couple days after my presentation on the 29th for anyone who is interested. See the post below for what I'll be discussing.

A subtle point about time travel is that alliances between players don't necessarily need to be permanent. We currently have a mode in Achron where players can create and break alliances during the game. Say John and Greg are playing against several other players. Five minutes into the game John and Greg form an alliance so that their units do not attack one another (unless explicitly told to). At nine minutes, Greg has been doing much better than John, but only because John protected Greg's units from an opponent's massive attack. Another attack comes in and Greg moves his units out of the way such that John's forces are weakened even further. Immediately afterward, Greg breaks the alliance. John feels that his alliance with Greg was a bad deal, goes back to the five minute mark, and undoes his original alliance with Greg. Now the entire timeline will change accordingly, with John and Greg having been opponents for the whole game, both scrambling to change the timeline in their favor.

We'll need to wait until we have a large pool of playtesters before we decide whether dynamic alliances will be a default multiplayer option. But the option is definitely there.

Multiplayer and Time Waves

One of the more common questions we have encountered is regarding how multiplayer works and exactly what your opponents see on their screens, so we updated the FAQ to better explain time waves and what players see in multiplayer matches.

bit-tech Interview Published

Bit-tech just published a 4-page interview with me about Achron. Check it out:
http://www.bit-tech.net/gaming/pc/2009/04/14/achron-interview-your-head-will-explode/

Using The Future

We've posted two new videos!

Here a demonstration of using the future to see upcoming battles:

 

The second demo video is of the grandfather paradox, and can be found on our new paradox page.

Command Hierarchy

Due to the mechanics of time travel gameplay we wanted to add something to the game that would assist the player with managing their units. One of the aspects we added for this purpose was the command hierarchy. A hierarchy is created when the player directs units to report to another unit, turning that chosen unit into a commander. The player can then direct commanders to report to other units, creating a command hierarchy tree.

Each command issued to every unit consumes chronoenergy, limiting how much a player can change and play in the past. Without command hierarchies, controlling large armies in the far past would be expensive in terms of chronoenergy. This was not the desired effect since we wanted to encourage players to use time travel and play at different points on the timeline. We added the command hierarchy specifically to deal with this issue, giving the player control of any number of units that were setup in a hierarchy by issuing just one command to the top level commander. The command would then propagate down the command chain, making all the subordinates and their subordinates (and so on) follow this one unit.

As we started to play using hierarchies, we realized that it had potential to be useful and helpful to the player on other ways as well. In addition to enabling the player to change history without using up more chronenergy, the command hierarchy assists with some micromanagement. Any unit under attack in a hierarchy group will summon the wrath of the rest of the group, even when it's beyond the group's visibility range. This lets the player deal with other strategies instead of micromanaging units that may be spread out or ambushed out on the perimeter. Another positive aspect of using a hierarchy is that it also adds flexibility to the player in terms of how groups of units move and attack. The player can choose to control the units in a hierarchy to move in unison as a whole group, or to move independently at their own top speeds. If a multi-level hierarchy is setup, the player can then selectively control intermediate levels of the hierarchy as individual subgroups for specific tasks.

Triangle Conference Details

The Triangle Game Conference in Raleigh, NC is coming up, and they've posted the schedule. I'll be talking on Wednesday, April 29th from 2:45-3:45pm.

I've started putting together the details of my talk. I'll be revealing some of the subtle gameplay mechanisms that we've put in place throughout the development of Achron. In particular, I'll be discussing some of the ways we addressed various gameplay exploits (unintended dominant strategies, also known as "griefs") that come along with time travel as well as trade offs in helping the player navigate the timeline. I'll also touch on some resolutions to the technical challenges of implementing time travel and how building a game with advanced time manipulation outwardly affects the general development process.

Adding time travel sometimes takes one recognizable gameplay mechanism and transforms it into another that is also recognizable but disguised. Imagine a simple game where the player traverses an area with randomly encountered battles. Adding time travel to this game turns it into a simple maze. The player goes back in time to back out of the "dead ends" (battles). Some gameplay mechanisms that are less fun without time travel become fun with time travel and vice versa. I'll discuss how time travel affects the complexity of puzzles, briefly touching on complexity classes from computer science from a conceptual level (without any of the hard math).

Grandfather Paradox

By popular demand on Twitter, our next video will depict the classic grandfather paradox, showing how Achron cycles between the different possible states, eventually settling into one state. Even though this particular scenario is not commonplace and is not generally a desirable strategy in actual gameplay, we think it will help some people see the flexibility of the engine and see the possibilities of what can be done in the game. We hope to have this video posted sometime within the next week or two.

While the engine has successfully handled every mind-bending multilayered paradoxical scenario we've thrown at it, these paradoxes do not typically occur in a game unless the player sets them up explicitly (such as in a match between expert players).

FAQ Updates

We've seen an enormous amount of discussion and speculation about Achron on various blogs. We've added some more questions and answers to the FAQ.

The Unveiling

 

Our unveiling at the Experimental Gameplay Session went well! Check it out some demo videos on our youtube channel: http://www.youtube.com/hazardoussoftware

 

Here is the Achron Alpha first demo video, the general demonstration of time travel:

 

This is the second demo video, highlighting a two-player game:

 

The third demo, highlighting chronoporting (sending units through time):

 

GDC

GDC has been a lot of fun so far. I've shown Achron to some people I've met. Most of them have been pleasantly surprised at how easy and intuitive it is to manage time travel, and how we allow the player to focus on the time travel gameplay rather than unit micromanagement by giving the units intelligence.

For anyone following this blog who is at GDC, the Experimental Gameplay Session is going to be Thursday from 3-5pm at room 135 in the North Hall. It's listed on bottom of page 82 of the GDC program guide book.

 

The Future

Achron allows the player to see and manipulate the speculative future. The future is extrapolated from the present based on all of the units' current actions and objectives. Suppose one player moves his armies to go attack an opponent. The opponent will see large red marks on the timeline in the future and can jump to the future to see specifics of the attack.

Being able to play in the future gives players the flexibility to play all over the timeline. For example, a player may build up armies in the future to send to the past, using resources they do not yet have.

 

Backstory

Here is a partial summary of Achron's backstory: Achron Backstory

We will also be posting some videos of Achron after our presentation at GDC next week.

 

The Strategies

Chris used a neat strategy against me in a memorable free-for-all game between him, Konrad, and myself. I launched a massive surprise attack on Chris's mining base, so he traveled back in time, prepared a large fleet to counter my attack and succeeded. However, in the present I acquired nukes and sent a nuke back to the end of the battle that destroyed his remaining fleet. Before it was over, he jumped back further in time, moved his mining base and undid his counter attack. Since his fleet had left the area and my army had conquered it, my nuclear blast from the future decimated my own forces! Right at that time, Konrad came at me with his forces, so I didn't have time to undo my nuclear blast.

 

Triangle Game Conference Presentation

After GDC, I'll be giving the following presentation at the Triangle Game Conference in Raleigh, NC on Wednesday, April 29th:

Title: Innovative Gameplay Using Time Travel and Time Manipulation: New Genres of Meta-Time Games

Abstract: While many games have utilized the enormous computing power available for graphics, physics, and AI, few have utilized this resource for innovative gameplay. I will discuss the use of time travel and time manipulation in gameplay, sharing our experience developing Achron, the world's first meta-time strategy game, a real-time strategy game where players and units can jump to and play at different times simultaneously and independently. The types of time travel described in science fiction are much richer than have been previously implemented in video games, and I will discuss ways of implementing them with regard to gameplay, how time travel relates to traditional puzzles and strategies, and other technical aspects.

 

Time Map

Like many other games, Achron allows the player to view an overhead map of the surrounding area. However, Achron shows a map of the timeline as well.

For example, if the player is attacked at a certain point in time, the timeline will show the amount of damage received at that point by a large amount of red on that portion of the timeline. The timeline also shows information including damage dealt and chronoports.

Figuring out what information to show on the timeline took some consideration and tuning over the years. Some information, such as damage received, is useful to show the player when a particular event occurred. Other information, such as the amount of available resources, helps the player to figure out strategic points on the timeline.

 

Is there a home time?

One question I frequently receive is whether or not something in the game can go back to its home time after time traveling.

Let's say that a soldier, at age 25, uses a chronoporter, a gate that sends things through time, and travels back to the year 2000. He spends a year in the past, and in 2001 he decides return to the future. Should he return to the present in 2009 so that he returns right after he left? Should he return to 2010 where he is the proper age of 26? Or should he not time travel again and be 34 years old in 2009?

Achron allows players to make these kinds of choices for themselves in real-time.

Typically, players will use time travel distances ranging between 10 seconds to 15 minutes. If another player is attempting to adversely change the past, players will sometimes keep racing back to out-undo each other. Anything that must travel back in time in order to maintain the current state of causality is denoted to the player, which helps manage paradoxes.

 

A Quote From Jonathan Blow

A quote from Jonathan Blow via e-mail on February 12, 2009 regarding Achron, posted with permission:
>> It's interesting because you can view this game design as the implementation
>> of the sort of classic sci-fi time travel warfare that's been written about
>> for a long time (with specific game design decisions to help make things workable
>> and interesting). And it's like, hey, why *hasn't* someone done that yet?

 

It's Real

Developing Achron has been very exciting due to the novelty of having to deal with time. It is real multiplayer time travel, not scripted but freeform and with no gimmicks. Implementing time travel has presented us with several significant challenges that have not been dealt with previously by anyone, but we've been able to leap over them. To meet the challenges we developed a new engine from scratch, created an interface that's both easy to use and powerful, and came up with methods and abilities for awesome gameplay.

We don't fake the time travel, it is not "we have three 'levels' you jump between and pretend they are different time periods". It is real, not pre-set and not predetermined. You can jump to anywhere on the timeline. Your actions, whenever you do them, will affect history and may even create paradoxes. Solving these challenges has been real fun, and of course playing the game even more so.

 

The Announcement

Achron. (ay-kron) N. One who can self-communicate across time, in such a way to transcend time. ('a-chron'ological)

After a decade of design and development, household computers are now fast enough to run Achron. We will be unveiling Achron at the Experimental Gameplay Session at GDC.

Home • News • Gameplay • Buy & Download • Technology • F.A.Q. • Forums • Blog • Hazardous Software • Contribute to Achron

Privacy Policy • Terms of Service • End-User License Agreement (EULA)

Achron’s website is designed by Heatbrain,
a website design and development firm that supports and believes in games as art,
and, of course, shares a deep love for chronofragging (and fragging in general).