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.
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.
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.
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.
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:
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!
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.
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.
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.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.
Here are the release notes:
*major update to support multiplayer
Resequence Engine changelog:
*added multiplayer connection service
EDIT Feb-16-2010 2:36am: We have solved and fixed the pregame lobby issue with the QuadTactics level. While we were at it, we threw in a couple other improvements to the multiplayer experience. If you have already downloaded v0.2.0.0, you only need to download the patch installer on the downloads page.
Resequence Engine changelog:
*fixed issue with > 2 players being unable to play in the same game
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.
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
Resequence Engine changelog:
*right-click cancels command waiting further input
preorder! Enjoy, and feel free to discuss on our forums.
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.
join our Twitter feed to be up-to-date on the latest news. We at Hazardous developed a team of experienced and aspiring industry professionals to bring you the polished experience that you deserve. At this time, we have charted a course to deliver that experience as an independent developer. Our target release date for Achron is 1/1/11. This release model has been working out well for some (e.g., Cortex Command, Overgrowth, Mount and Blade, Natural Selection 2), and others have proclaimed it as a possible future of game development (e.g., Gabe Newell of Valve Software). We realize that this raises many new questions for fans of Achron. Please hold questions until the new year, as we will be releasing the details of various programs in the coming week. Preorder if you choose, and the sooner the better, as more pre-orders will help us improve Achron. The pre-order carries a reduced rate of $29.95, and to reward loyalty, the first 500 pre-orders will save an extra 33%. Pre-orders will go live sometime in the next 7-10 days. This will be announced via Twitter, so be vigilant and seize the discount! We will see you in January for the first demo release! Thanks again for all of the support. We intend to spend 2010 creating fun time-travel experiences for gaming enthusiasts and aspiring developers alike. Happy Holidays!
Here's a general outline of our current tools that we're planning to release:
1) Scenario Editor: This is our primary editor, which we're planning to rewrite into two components prior to release: a level editor and game mechanism editor. The level editing portion has what you'd expect in a typical RTS level editor, such as editing the terrain, environmental effects, placing things on the map, specifying specialized scripts for the level, etc. The game mechanism editing portion is extremely powerful. When you add a new unit to a game, you specify the 3D model, how it moves, what it can do, and all of the ways it can interact with everything else in the world. Each unit has some basic attributes supported by the engine (e.g., position, health), but the unit's actions and reactions are programmable. This tool is also used to assign controls and scripts to the unit (HUD buttons, mouse controls, keyboard controls).
2) Unit and Level Scripting Compiler: Our scripting drives all unit interactions. It is a procedural C-like language (with a sprinkle of SQL-like constructs), that was specifically designed for use with an engine that supports time travel. Time travel imposes many interesting constraints and development challenges that other games don't have to deal with, so the language gives fine-tuned control over some of those nuances. We're interested in investigating other paradigms (functional, object oriented) for this scripting down the road. The script compiler is separate from the engine, so designing another language and writing a compiler wouldn't require changes to the engine. The level scripts can be both chronal and achronal (situated in game time or beyond game time), and have special capabilities in that they have access to virtually all data in the game. Using level scripts, you can make triggers, decide who wins or loses, and even see when each player is on the timeline.
3) Skin Scripting Compiler: We have a unique but concise language that we use to create and control the user interface (HUD, menus, etc.). It supports animations, and can be driven by the level scripting. The skin scripting also maintains in-game settings and maps player controls to more global actions (i.e., those that don't involve controlling an in-game unit, like moving the camera). You could even make a game that had no HUD.
4) Animation Editor: Our animation editor is what we use to pull in 3D models and prep them for in-game use. This editor is really more of a compiler and in-game preview, as we make a short script to attach flags and attributes to specify how a model will work in the engine. When we split the scenario editor, we may merge the animation editor with the unit editor.
5) Campaign Compiler: This tool is how we chain the levels together to make a coherent single-player game.
Most of the tools also have command line support and some logging to make automation easy.
We go over various ways that an advanced player can use the hierarchy. Most of the main hierarchy functionality is covered except for auto-healing and auto-response to attacks.
We're also working on some big plans for Achron early next year. We'll let you know when the plans are finalized.
We typically test by playing full RTS games, but, as I've said before, many of our units are not ready to show to the public yet (see the wallpapers and screenshots page to get an idea as to the programmer art still in the game). We're working on a number of aspects on the art side right now, and are looking to start ramping up art production on the units soon. In the mean time, we decided to make a more tactical level for this video using some of our current 3D models. Also note that the set of units used in this level have mostly mid-range attacks.
Playing a tactical level is quite different from general RTS because you only start with a fixed number of units (and chronoporters!). It was a good test because it forced us to focus more on unit behaviors, which we've been working on lately. It was also simultaneously slower and faster than a full RTS game as you spend more time deciding strategy and less time building things.
The videos are recorded from Mike's computer, with him (dark blue) and I (green) allied playing against an alliance of Greg and Konrad (two of our testers in yellow and light-blue). Mike and I tried to talk a little more than usual to say what we were doing, and Mike used the mouse more than the keyboard shortcuts to allow viewers to see what was happening a little better (not using the keyboard shortcuts, for some reason, made Mike use the hierarchy less than usual in retrospect). We played three games, and each lasted about 20 minutes.
When a multi-player game starts, the present starts on the left of the time window and moves toward its eventual position on the timeline, as the player can't go to back before the game started. Both of these videos are near the start of a game, so you'll see the present moving forward in time before it reaches its eventual position.
Of the videos we captured, these two were the most interesting to watch. Since these were the first full games played after some significant changes to balancing and unit behavior, we walked away from these games with about a dozen new items on the todo list.
We're also beginning to work on improving the rendering algorithms. Already, the current terrain and units models (as previously seen in the videos) are looking a bit better; look for a new video in the next week or two. We're also going to start ramping up the visual arts soon.
For anyone not following us on Twitter, I've had two interviews recently, one on OfficialRTS here: http://officialrts.blogspot.com/2009/10/interview-with-chris-hazard.html, and another on the iGameRadio podcast here: http://www.igameradio.com/2009/10/15/podcast-ep-83-hazardous-software-word-ace/ (though their webserver was having issues at the time I posted this).
Now on to balancing...
In developing an RTS, the real proof of the effectiveness of balancing is always when you test it with people. However, you can do significant initial balancing before testing on a wider scale. By employing basic mechanism design principals, you can design the high-level game structure and somewhat guarantee that no unit types will be dominant or worthless in actual games, based on cost, abilities, and how they compare to all other possible units. Using nontransitive relations (colloquially referred to in game development as rock-paper-scissors technique) is the easiest way to guarantee that players are incentivized to use mixed strategies.
Games that are based on simple mixed strategies are often difficult for people because we're not that great at making up random numbers (but we may not be that bad either). Simply label two of each of the six sides of a fair die "rock", "paper", and "scissors", and play against it. Given enough rounds, you can't beat the die on total wins. However, if you're not playing perfectly random, another player could take advantage of the lack of your perfect randomness and win.
You can also play off people's abilities too. One strategy can be made overall ineffective unless a player is good at micromanagement, in which case it can beat another method. You can't allow a single dominant strategy though, otherwise the game isn't fun. Essentially, all well-balanced RTS games are, to some degree, extremely large nontransitive games.
Simple mixed strategy games can get boring, so setting up interesting combinations of dominant substrategies within a larger strategy space helps considerably. People try to out-think each other, and because people are bad random number generators and also because it's difficult for people to model common knowledge with uncertainty, such relations can and do make for interesting games.
In Achron, spending chronoenergy to change the past creates an interesting situation for mixed strategy games. When you see your opponent's strategy, you can go back, expend chronoenergy, and change your strategy to a winning one. Your opponent can do this too, making for some interesting game dynamics in the high-level strategy, keeping the game balanced even with the addition of time travel (other than the addition of chronoporting, which is a balancing topic for another day).
In working through our first balancing pass in Achron, we have designed our high-level gameplay strategy structure. The step we're working on now is translating that into actual gameplay. Whereas you can simply change the weapon strength, range, speed, reactions, and other attributes of a unit and hope that you get the balance to what you designed and modeled, we actually have an automated process that drives the engine (units' AI and all), and tells us exactly how close we are to achieving our design, including the statistical error. This obviously takes quite a while to run at full statistical significance, but it makes sure that the empirical data matches our theory. That way, we can don't have to guess; it just works. We're working on using this to balance the humans initially. Once we've perfected the process, then we'll expand this to balance all 3 races, internally and externally at the same time.
I'm really looking forward to playing some games after a couple balancing passes. However, I think it really shows what multiplayer time travel does to an RTS; Achron has been fun even before we started balancing!
[Edited 10/26, 8:29pm to correct minor error in RPS example.]
In the beginning, my approach to designing Achron was drawn from straightforward hard core sci-fi traditional structures and conventional design elements. As the concept rounds evolved a tighter connection with science along with a focus on integrating the story line, I began to push the conceptual designs towards a unique look. Following an evolutionary path, the two alien races in Achron began to take shape. Genetic manipulation, the relationship between all three races across time, and their motivations defined the look and feel of the alien races. Technology was also a factor in the character designs. Each race's technological strengths are critical factors in how the story and gameplay evolve in Achron. Design considerations on how each race interacts in space and on ground as well as how players can distinguish between hierarchical ranks and provide visual feedback on their function within the game were all elements integrated into the design. An evolutionary theme became evident in the designs; quirky and exaggerated proportions were incorporated in creating a distinctive world.
In this initial character concept art you can see that scale and proportions come into play. This will affect how the player interacts with adversaries during game play.
As we continue working on art design and production, the focus will remain to stay with the creators' original vision of Achron.
At least once every couple months, I spend some hours profiling Achron while it's playing a big battle. In software development, profiling tells you what parts of your code take how long to run. You find the areas where the engine spends the most time, and you either try to figure out a better algorithm or improve the efficiency of your code. On modern processors, there are many issues to worry about, and sometimes performance can be counter-intuitive.
Mike and I have been working on some new features for unit projectile weapons (e.g., missiles, etc.). I added some new functionality to the engine that helps units choose the position to attack, rather than just the unit. As I finished implementing it, I reasoned that this new code might improve performance slightly. The new code orders the possible attack positions first before checking to see if they're attackable by the weapon (e.g., make sure it is in direct line-of-sight for line-of-sight weapons). It doesn't need to waste as much time checking bad positions (e.g., the back side of the target).
I went to perform profiling, and sure enough, it did improve performance a little bit. I ran a few large battles to see what the new performance characteristics were like. In one game, I noticed a function using a lot of the CPU time (~8%) that had never been on the radar before. In the other games, it was only few percent of the CPU, but still, I wanted to look into it.
The function is one part of checking whether one unit can see another. In the ~30 line function, I noticed a whopping 2-3% of the CPU time being spent on a single line of code!
That line of code is a heuristic that decided whether visibility was worth investigating further. Effectively, the line basically says, "if the unit is too far away, don't bother doing detailed checks". To make the heuristic accurate, I used floating point numbers (numbers that can have decimal places). I looked at how fast the processor was executing the code (known as IPC), and it was quite low. In light of the surrounding code, I decided to make the heuristic use integers instead. In this case, integers are less accurate, meaning that it will need to perform the full detailed checks slightly more often, but given the code, should run faster.
Sure enough, with the integer code, that line used 0.3% of the CPU! The extra detailed checks did use up some of the CPU time, but the new code was still used about 2% less CPU time than the old floating point code while still providing correct results. (And of course I made note of this in the comments.) Using 2% less CPU may not sound like a lot, but small improvements like this add up through development.
We've recently put together a mod of Achron called DARTT, which stands for During Action Review Tactical Trainer. It is an early experimental prototype game designed to teach higher-level strategy to commanding officers in the military by allowing the player to instantly revisit any point on the timeline. In some ways, it reinvents After Action Review, as the player has immediate feedback and can explore the strategy space by changing committed decisions.
DARTT was also a success in that we did not need to modify any of Achron's engine code. Granted, DARTT is an RTS and shares similarities with Achron. However, we were able to build DARTT's mechanics and create two playable levels in only a couple days using only our mod tools. Additionally, building DARTT gave us ideas for better honing a couple aspects of Achron's gameplay.
Next week Friday (Sept. 18th) and Saturday (Sept. 19th), DARTT will be featured at GamingSPARK: http://www.sparkcon.com/2009/09/18/video-games/. If you'll be near Raleigh, NC during that time, both DARTT and four introductory single-player Achron levels will be available for anyone and everyone to play. The Achron levels available at GamingSPARK will consist of 2 tutorial levels (one that walks through basic controls, another that walks through time manipulation) and 2 basic levels (no building or resource gathering involved). See the GamingSPARK website for the location and times. Unfortunately, due to travel conflicts, I won't be able to attend GamingSPARK, but Mike may make an appearance.
But I can't really talk about that in depth, now can I? That would ruin the surprise.
When Chris asked me to start posting here, it initially seemed that the best way to go would be to discuss the writing process for this project. However, after spending some time trying to write out a few posts it became clear to me that that process isn't nearly as interesting as discussions of working out unit balance and strategy. In any case, I'd much rather have a story for you to read than a blog post that was all about the writing process.
With that in mind, we're going to be unveiling some short stories over the following months that paint the Achron universe with a little bit more depth. You can find them by following the link to the story page, and looking for links within the story.
In the games we typically play, it's quite rare to have such large armies facing off head-to-head all at once, mostly because people don't wait that long before first strike... which, as usual, may be undone after seeing how bad it went and then followed up with a new attack in the past from a different direction. Utilizing large groups of units and working through the tactics with time manipulation was a lot of fun. These larger tactical battles will be in the single player campaigns, as several parts of the story call for them.
Being able to travel through time allows both players to react and correct mistakes, so tactics become even more interesting. In one battle, I initially tried sweeping a group of Mike's tanks by the side with about ten lancers. Lancers are fast and nimble air units, but aren't particularly strong. My lancers did some damage, but were then flanked by another one of Mike's tank groups. However, the next time I jumped back to the beginning of the battle, I saw that Mike had intercepted my lancers with a group of his own.
Throughout the games, Mike or I would partly surround and defeat a small group of opponent units... and then the other would change history.
I distinctly remember the point in 2006 when we first put restrictions on some units' firing directions. It had been on the todo list for a while, something we had planned at the earliest stages of development. Before this was implemented, all units could rotate to fire in any direction almost instantly. These directional restrictions required tanks and many other units to rotate or move to face a target before firing. Flanking instantly became an effective way to gain an advantage on an opposing force, especially when coupled with some tactical teleportation.
The hierarchy controls were very useful at this larger scale. I tried a few different management strategies. In the first game, I put all of my units in one big hierarchy, with 4-8 subordinates per commander at the lowest level and about 3-5 subordinates per commander at the higher levels. Because I found myself using various parts of the hierarchy frequently and hardly used the top-level commander, I used about 6 independent command hierarchies instead for the later games, varying their compositions.
Initially organizing the units was pretty easy. The communications center building has an auto-hierarchy control that tells units to form hierarchies automatically based on units' types, ranks, and positions. Even with the large number of units in a random layout, it only took a handful of commander assignments to get the form of hierarchy I wanted. The only times I changed the hierarchy structure during battle were when Mike had my units almost surrounded and I was trying to hold off some of his units while others of mine attempted to break away.
All is moving along well on development. We've been working on improving the in-game scripting API to add all sorts of features to levels, especially those where we teach the player to use various aspects of time travel. It's particularly interesting developing this, as there are really multiple times going on, while the player is only watching one at the same time. If an event occurs 2 minutes ago in a tutorial, you have to consider whether the player should be notified in the present.
We're also still working on fine tuning chronoenergy consumption and generation models for gameplay purposes.
Achron was also discussed on last week's Dogear Nation podcast.
For those of you following us from the USA, have a safe and fun 4th of July weekend!
The second demo video is of the grandfather paradox, and can be found on our new paradox page.
Our unveiling at the Experimental Gameplay Session went well! Check it out some demo videos on our youtube channel: http://www.youtube.com/hazardoussoftware
Here is the Achron Alpha first demo video, the general demonstration of time travel:
This is the second demo video, highlighting a two-player game:
The third demo, highlighting chronoporting (sending units through time):
This release features some game balance improvements, usability improvements, small rendering improvements, and a number of bug fixes.
Summary: This point release fixes two important bugs in the previous release, as well as several additional bugs.