Archived Blog Posts

We have three exciting pieces of news today!

First is we have finalized a release date of August 29th for Achron.

Second is that I will be speaking at PAX on Saturday, August 27th at 9:00pm in the Raven Theatre. I'll be talking on strategic thinking in gaming, from game theory, to foundations of trust and reputation, to strategic revelation of information, to how others' beliefs affect your best strategy.

Finally, we have a new anachronism story up. Check it out!

Are you going to PAX? Thoughts on the new anachronism? Discuss on our forums: http://www.achrongame.com/forums/viewtopic.php?f=73&t=3691.

The Achron Beta Tournament was a success and a lot of fun. The champion was Kytin, but there were many fascinating strategies employed. Commentated video casts of the final games on July 17th are now all available to watch online here: http://www.youtube.com/playlist?list=FF40C181F3D00A60, courtesy of Shadowfury333.

Also, our winner of the "guess 3/4ths of the average guess in the range of 0 to 100" bonus competition was Neveras, who guessed 32. There were two others who guessed 32 as well, but Neveras was the first. Information about your opponent is a major component to the game Achron, and this challenge was for people to try to figure out what is going on in the heads of other strategic thinkiers.

More Achron tournaments are on their way through the upcoming launch! Check them out on the Achron forums.

We've really appreciated all the feedback we've gotten on balancing since the 0.8.3.0 release. Performance improvements in the engine allowed us to increase the visibility and attack range, which by itself didn't introduce any new balancing issues, it did emphasize existing issues.

The good news is that this focus on balance has unearthed a number of bugs in our balancing process. One of the many benefits of treating balancing as a scientific process is that once you fix an issue once, it's usually fixed forever (unless you do something to change that part of balancing). Also, it helps us find the root cause of balancing issues. When we hear about the issues, we can then focus on exactly what is wrong rather than try some things and see what happens. This saves us a ton of time balancing the game. Sometimes it is a bug in the balancing algorithms, sometime it is a design flaw that we made when laying out units' strengths, weaknesses, etc.

The Grekim octo was the unit with the biggest balancing issue. When we ran the octo in our balancing tests, we did it in such a way that the octo's extremely short range was downplayed in the validation. The octo appeared far stronger in simulation runs than it really was in practice, which threw off its balance. Whenever there's a mismatch between the model and the actual game, that's an issue that must be addressed. However, because it was a flaw with the evaluation that we tuned the unit to, we didn't notice it until recently. This goes to show how validation is always important. The octo's HP has been bumped up. The Vecgir foundation healing rate was also improved to help early-game balance in the interrelated tangle.

The next biggest issue was the Human lancer. It was a bit too strong for its own good, which was more a design-level issue than a bug in the balancing, but the nuance was between upgraded and nonupgraded lancers. This issue is now fixed as well.

We also found some bugs in the way resources were related economically. There was a mismatch between the model and the actual game as to how quickly a resource processor or importer begins production. The balancing framework had the implicit assumption that a resource was produced instantly upon creation, which was only true for the importer. Now the balancing algorithm is correct and we changed the game so that the importer does not produce an RS immediately. This bug caused some units' prices to be off by about four percent. A four percent error in unit price of many human units may not seem like much, but when you combine it with other balancing bugs, it adds up.

While we are fixing the balance issues, we've also been doing another pass on emphasizing unit roles. For example, the tornade is now weaker versus air units to better fill the role of antiground air unit, and turrets in general are stronger against air units.

Because balance is such an important part of the game, we're planning on releasing a new build, v0.8.4.0, in the next couple days with these balance fixes. Before recently, we'd been spending most of our balancing efforts concentrating on mid and late game economies, because they're tractable for analytical techniques, versus early game where combinatorics is more prominent. Now we're putting more effort into the early game.

We've also noticed that there aren't many big maps out there yet. That affects balance as well, especially when teleprotation becomes important.

We're well aware of the balancing issues mentioned here and those previously mentioned on the forums. Have you seen any other potential balancing issues that haven't been mentioned yet? Discuss on our forums: http://www.achrongame.com/forums/viewtopic.php?f=73&t=2827

Neither Mike nor I are big fans of April Fool's Day on the Internet. It makes the Internet unusable. So, instead of going all out and changing everything or making some big announcement, we've added three subtle but amusing April Fool's Day pranks to our website that were not there before today. See if you can find them all.

Discuss on our forums: http://www.achrongame.com/forums/viewtopic.php?f=73&t=2589

If you're reading this blog post, chances are you're moving through time. You're probably going through time in the same general direction that I am, and unless you're traveling at a notable fraction of the speed of light relative to me, you're also probably going through time at about the same rate that I am.

On April 8th and 9th, I'll be part of a small conference on the philosophy of time travel at North Carolina State University: http://www4.ncsu.edu/~carroll/Webpage.htm. In particular, I'll be on a panel with Sara Bernstein, John Roberts, and Stephen Reynolds, discussing time travel right after the kickoff lecture by J. Richard Gott. It's a pretty cheap conference ($25, $10 if you're a student), and should be quite a bit of fun if you're in the area.

I've been doing some thinking in preparation for the conference, and a thread on our forums regarding favorite time travel stories spurred an interesting thought: what real-life experiences have people had that are like time travel in some way?

I'm interested in hearing peoples' stories, so if you haven't posted on our forums before, check it out via the link below. I'll kick off the discussion with two stories of my own.

The first took place when I was in high school. I was driving a friend back home after we'd just finished football practice. We were driving down the road past Joe's Super Service, a very memorable landmark on that stretch of road. While still driving down that straight road, we passed it again. We both looked at each other with extremely bizarre facial expressions, and I asked, "didn't we just pass Joe's before like 5 minutes ago?" My friend, with his eyes looking like they'd pop out of his head at any moment, affirmed. I don't have a good explanation other than the fact that it was probably the most oddly coincidental déjà vu experience I've ever had. Déjà vu is still not well-understood, whether it is just a neurological aberration of memory (we'd driven down that road many times) or whether it has a pharmacological basis (we were both exhausted, probably low on electrolytes).

I enjoy travel and have been to a number of developing countries, but my homestay experience on Isla Amantaní, an island in Lake Titicaca in Peru, felt particularly like going back to an earlier point in time. I was a towering giant among the people there who had been acclimated to living at an altitude of 15,000 feet, hiking up and down terraces all day. Our host spoke Quechua and only a little Spanish, and probably had never used a phone in her life. That made it a fun challenge to explain what I did for a living at the time: a software architect who designed simulation and performance tools for cell phone infrastructure. They had a party every night on the island; I was initially worried that the party was going to geared toward tourists and overdone. However, the party really seemed like it was for themselves, which made it a very interesting experience as to what life was like before modern technology.

What real-life time travel experiences have you had? Share them on our forums: http://www.achrongame.com/forums/viewtopic.php?f=73&t=2463

When people hear about laws that could change how you buy games, they initially think about censorship. This is not one of those laws.

Earlier this year, Senate Majority Whip Dick Durbin put in an amendment to the Dodd-Frank Wall Street reform act, which was passed into law. This amendment has two effects that will impact purchasing games that work together. The first is that it removes the restriction on merchants (people and websites that sell games) from price-discrimination among payment methods. The second is that it puts control of debit card overhead charges (that all of us merchants pay for each transaction) in control of the Federal Reserve.

Today, the Federal Reserve announced the price caps of debit cards, and some banks have already claimed that the low charge allowance could make banks lose money on debit card transactions (stocks have dropped today, lawsuits are already being filed, some claiming the end of debit cards, etc.). This also has a ripple effect. When these laws go into effect next year, debit cards will be very cheap for merchants.

Every time you make a purchase with a credit card, debit card, or other payment network (e.g., Paypal), the company you're buying something from has to pay a flat fee and a percentage of the transaction to the merchant services provider, either the company that issues the payment device or a middleman. Have you ever wondered why you had to buy credits for online games in bundles instead of microtransactions? This is because the base rate is usually some fraction of a dollar, and the amount depends greatly on the arrangement. If the merchant has to pay 30 cents on a 20 cent purchase, the merchant is not going to sell. Further, some payment methods are much more expensive than others. Because of fees, Paypal, American Express, and some other reward cards cost so much that some merchants won't accept them.

Currently, all of these companies have agreements set up that prevent merchants from passing discounts or surcharges on to the customer. This new law allows people who sell games to charge differently based on how you plan to pay. Are you using card X? Sure, we accept it, but it'll be an extra dollar. Do you want to using online payment method Z? We'll accept that as well, but for two extra dollars. With the costs of debit cards artificially low, people will probably be more likely to use their debit cards to save money, and thus the credit card companies will need to drop their prices to stay competitive.

If these laws are here to stay, it could mean some interesting things for buying games. Perhaps microtransactions will start to take off in the USA. People making very small casual games might be able to charge even less for them; it could open a niche market for ultra-casual games or also an online pay-to-play version of the arcades of yore. Perhaps every game vendor will have a laundry list of prices based on how you pay. Perhaps this will further the walled-garden trends we've been seeing with portability barriers, such as iPhone and Android, using different payment methods. Or, perhaps nothing will change from the consumer perspective, but merchants will keep the prices the same and will get the profit where the banks/payment services companies are no longer making them.

At first glance, this law may seem good, in that it gives more information to consumers and, in theory, takes money from banks and put it in the hands of the customers. However, by putting overly stringent price controls on debit card networks, it could do some serious damage as well. Further, it'll be interesting to see how businesses and contracts evolve around these new laws. What constitutes a "payment card network"? Obviously Visa is, but what about Paypal? What about Apple's App Store, for which you can buy prepaid cards? Apple's App Store is tremendously expensive for merchants when compared to credit cards, and is more for marketing and entering the market. What about Valve's Steam? The lines are fuzzy.

What are your thoughts on this law? Discuss on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=2147

Today we are very excited to open up to our community a mod repository system that will facilitate the development (co-operative even) of mods and maps for Achron. If you are eager to get started, you can access this system here.

You can use this resource to collaborate and share your creativity with the rest of the community. You may create as many packages as you wish, but we're starting everyone off with a 40 MB storage limit.

To get started, click on the link above to see a listing of currently available community-created packages. From there you can narrow your search or begin creating your own packages by clicking on My Packages. On that page you will be presented with a form for creating a new package, followed by a list of all the packages that you either own or for which you are a contributor. Adding contributors to your package allows your friends to add and update files of their own.

Each page has links at the top to easily get you back and forth between packages, files, and the main list. We have a lot of exciting ideas for future features within this system and hope that you will find it useful. Happy modding!

Give us your initial thoughts and feedback on this first iteration of our mod hosting on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=2119

As if we weren't busy enough here at Hazardous Software, the past month and a half have been even busier than usual. I've been traveling quite a bit for various business meetings (Achron-related stuff). We've have all been working hard on building single-player levels and making good progress on Achron game assets.

The voice acting is almost complete and level layout and scripting are moving along. We've also fixed a few bugs and have made some pathfinding improvements.

It's quite amazing how much of an improvement the new single-player levels are to the demo levels we've had in the releases since last January. The narrative and diversity of objectives really make the game that much more immersive.

If you could know one thing about Achron's story before it's released, what would it be? Discuss on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=2093

Most modern RTS games have a number of groups, of which the player can control one at a time. Usually, these groups are called "factions" or "races", but both of those terms are problematic. In Achron, we call these primary groups "species".

First, why is "faction" problematic? A faction is generally defined as a group within some larger organization or group. That's perfectly fine for in-fighting. In Achron's story, the most obvious conflict is between Humans and "aliens" (intentionally left ambiguous as to not give away spoilers). Any RTS veteran pretty much knows that there will be cases of Humans fighting Humans, Grekim fighting Grekim, etc. As has happened many times in history, alliances can break down such that two factions of the same group find themselves on opposite sides. The term "faction" works in this sense, but Humans and Grekim, for example, are not parts of a larger, well-defined group.

Race is another term frequently used to describe sides in RTS games. This term is problematic as well. Biologically speaking, races are groups within a larger population that have distinctive features but retain the ability to reproduce with one another. This is clearly not the case in Achron. Sometimes the term race is colloquially used to mean some sentient species, such as the "Human Race", but this doesn't reflect the biological definition.

Species generally means a point on a taxonomy in which organisms are able to interbreed. Although biologists debate whether a statistical approach, lineage approach, or traditional classification approach to defining species is best, many things are clearly recognizable as distinct species.

Are you used to calling alien species in an RTS "races"? Have you heard any terms to describe groups in an RTS? Discuss on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1965

Our hero kicks open a door, brandishing a fully automatic bazooka loaded with phased-plasma laser rounds, and screams, "Get down!" Enemies pop out from behind the terrified, innocent civilians and the entire room erupts into gunfire, groans, and cursing. The letterboxing on the screen thins until the player finds himself back at the game's UI, and control is returned to him. It's time to shoot things. He dashes across the room, knocks over a set of shelves, and perforates half a dozen enemies. More enemies charge into the room behind him, and then things start getting really difficult.

Video games are a unique storytelling medium specifically because any game that claims to have a story actually has (at least) two: the narrative told through the cut scenes and dialog, and the narrative constructed by the player moment to moment as they play the game -- or, the Cinematic Narrative and the Gameplay Narrative. The Gameplay Narrative is a strange beast, because it's where the rubber meets the road: it encompasses the Cinematic Narrative, and extends it via the vocabulary of the gameplay. If the gameplay feels at home inside the context of the game's story, then the player gets the benefit of increased immersion. A bad story will clash with the gameplay, and that results in broken suspension of disbelief.

A good example of these two narratives working toward a common goal is the Silent Hill series. (Be warned: this will get spoilery.) The choices the story makes are enhanced by the way the game is designed. None of the protagonists are experts in combat. There is no HUD. The only feedback the player gets during combat is the dull pulse of the controller's vibration feedback that gets more and more frantic the more damage the player takes. Enemy attack patterns are slow and plodding, interspersed with rapid, vicious attacks. This builds a moment-to-moment tension that is enhanced by the texture and atmosphere of the town.

[Spoilers]

But Silent Hill is more than just a scary town, it's a reflection of the people unfortunate enough to stumble into its city limits, and this is core to the series' design philosophy. In the second game, the main character has returned to Silent Hill to search for his deceased wife. He acts disoriented and confused throughout the game, mirroring the player's own disorientation and confusion at the events that take place. The veil is only lifted in the final scenes of the game. We learn that the main character's wife didn't die from a wasting disease, as the game had implied -- he killed his wife to put an end to both their suffering, and was so overcome by guilt and self-hatred that he couldn't face what he had done. He forgot all of it, and was slowly led to Silent Hill in order to satisfy an unconscious desire to be punished for his actions.

That's a stunning way to end the game, but knowing the truth beforehand changes the tone of the story. Almost all of the enemies in Silent Hill 2 are horrifying distortions of the female form. For the entire length of the game, the main character is forced to fight, and then kill these abominations, repeating the act of murdering his wife with each combat encounter until he remembers the truth of what he has done. It's a powerful combination of gameplay, design, and storytelling.

[/Spoilers]

One of the techniques that I used in Achron to help bring the two narratives together was to take the gameplay logic and use it to drive the Cinematic Narrative. With few exceptions, the technology that governs the actions of the units also restricts the actions of the characters -- no one's going to be doing anything in the Cinematic Narrative that isn't a reasonable application of the rules of the Gameplay Narrative. We've created a universe for you to play in, but we made ourselves work inside that universe to ensure consistency, and to satisfy our own inner geeks.

LAYERS

This technique is more of a storytelling technique, but it's one of which I'm fond. In a video game, there's really only one story that you can be sure that each player will at least see -- the cinematics, and the action that takes place during each level. But what are you to do with the rest of the universe you created, all this wonderful detail that's left over without giving the player reason to start hunting for the Skip Cutscene button? Layering can help with that.

Does the story have lots of interesting background information? Some of this can go into found journal entries, or audio logs. Does the story provide a way to show what the supporting characters are like when they're not around the main character? Get that in there as well, but be careful. Layering's a great tool, but if you deliver all the information the same way, then it starts to get old. Spice it up a little by changing how the information is presented. Maybe it's a transcript of a conversation, or a series of emails. Maybe it's a story fragment written in second person. Finding what works best can be tough, but if done properly layering will reward players that want a deeper look into your universe without punishing players who aren't interested. If done very well, then you'll draw in a few people who were on the fence about giving that extra little bit of their imagination.

Layering also extends from the dialog and background story to the other aspects of the game: the music, voice acting, visual design, and level design. All of those things can be used to impart the texture and atmosphere of the game's world to the player. It's very much a team effort.

What do you consider to be good examples of video game stories? Do you favor games that take a more traditional approach, or do you prefer the in-the-moment narrative? Give us your thoughts on storytelling in video games on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1839

One of the most difficult parts of running a small business is that when an important business meeting occurs requiring the president of the company, it also requires the producer and engine programmer to go to the same meeting.

As of Monday afternoon, Mike and I were feeling really good about the release that was planned for today with the Grekim and Vecgir. We had about one day left of work to finish the release and then were going to test it. As of Monday evening, we suddenly had an urgent business meeting opportunity come up which was so potentially important to Achron (in a good way) that it required we drop everything else in preparation.

We're re-planning the next release for next week, probably Friday or Saturday after I return from the meeting. This delay will not affect art production, so there's a good chance that we'll be able to include more good stuff in the next release than we anticipated. Voice acting for the single-player campaigns is also moving along nicely.

I am not sure what to say about this particular track, except maybe that it is the energetic opposite of Frozen Over. Perhaps these two are the North and South Poles of our concept for the musical content in Achron. I have learned in the last few days that it is possible to become carried away, and that sometimes it is worthwhile, though not always expedient to go down that road. I hope it rocks your socks off.

Several nights of sleep died to bring you this music. From here I go on blog strike until Chris Hazard agrees to two conditions.

1. Take a nap.

2. Write a blog.

Though these demands be not realistic in the short term, he has much to share with you when we get to the other side of a few imminent matters and 20 hour workdays. He is a machine.

IGF approaches, and it is one reason among several for added production intensity around here. We think of you often, friends, even when we are silent for a while.

EDIT (by Chris Hazard): I got 12.5 hours of sleep last night, so I should be good for a while again. I think that counts as my nap.

End Of All Things (download mp3)

Discuss your thoughts on this song on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1769

In music production, it is fairly common to end up with a case of "good music, poor engineering". While you may not be able to put your finger on so-so engineering, the engineer is sort of the secret member of the band, whose part fully determines whether or not a track is worthy of professional use. There is so very much to know in the sound engineering department that people go to school for it, like my friend Josh Grondski, whose advice I typically inquire of for final mixes. Some important elements of audio engineering include:

Microphone quality and position

You can miss the desired effect by having your microphone too close or too far away from your instrument. The East West Play libraries which comprise most of my toolkit have been recorded with multiple microphone positions, which I can mix the sound from for different tones, and by using mostly sample libraries, I get to sidestep most of the pitfalls related to microphones. The actual, non-sampled accordion sounds help me keep it real, though it is a sacrifice I make for art to play that 30 pound accordion in studio. It's like wearing a piece of furniture!

Reverb

I like to use big reverb and make it sound like we're in a symphony hall or a cave or something, though this is not always the best practice. That spaciousness adds a lot of depth for this sort of music, if you can keep it from muddying up the sound. That said, it is easy to go too far with the reverb, and sometimes its good to have the percussion sound closer or farther away than the rest of the music.

EQ

The equalizer is the key to almost everything when it comes to shaping sound. Each part of the EQ band represents frequencies you can play with. You can make sound brighter, make that kick drum pop, carve out a unique space for each sound so that they don't sound muddy, mess with frequencies so low that they are felt and not heard, or create any number of other effects.

Needless to say, engineering is an underappreciated art form, but if you have been to a local bar a few times for a rock and roll show, you can tell when the sound guy knows what he's doing, and when he just knows how to plug everything in. It can solely determine the quality of your evening.

With that said, here are the final mixes for the Frozen Over and The Vecgir Theme. Feel free to listen to them alongside the previous cuts, and the quality difference should be indefinably obvious.

Frozen Over (download mp3)

We Are Vecgir (download mp3)

Discuss your thoughts on sound engineering on our forums: http://achrongame.com/forums/viewtopic.php?f=73&t=1531

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

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

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

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

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

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, 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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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

: 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.

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

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.

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:

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.

*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

*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

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

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

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

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 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

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 upcomingis 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.

Things are going really well here and we've beenbusy 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.

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 (). 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): This is our primary editor, which we're planning to rewrite into two components pri