Continuing in the spirit of open development, it's been another week, so we are unleashing a brand new alpha! Here is what is new in Overgrowth this week... Starting with a much needed FAQ.

As usual, we have fixed a number of bugs, tweaked some stuff, and implemented some new features. Aubrey has created even more art.

I am happy to say that we are now starting to work towards our animation system which is the first step towards combat.

Going through our svn code logs the past week, here are a few highlights:

- A few optimizations
- fixed a lot of bugs
- added texture_scale to config (setting that to 1 instead of 0 should make it go much faster for a lot of people)
- preparing editor framework for new types of editors
- added 'chaining' for commands in undo/redo list
- mirror functionality added to scale tool
- new paintbrush tool (auto-places objects for easy plant placing)

An SPF Trac has been set up and the bug reports / feature suggestions are rolling in. So far it has been really useful! I'm glad that is finally set up.

John made a FAQ which has been really helpful.

Thanks as always for all the support!

Hey guys, we've been talking a lot about our fighting system recently and I wanted to provide you with a first draft of what we're planning to do in Overgrowth. These are the ideas that materialized from discussions I had with David and Phillip a few days ago. Remember that what I mention here is not set in stone.

What is an attack?

An attack is an animation paired with an intended damage value to be dealt to another character if the attack is successful. An attack will be initiated by the release of the left click button. As was done in Lugaru, an attack will be directed towards the most dangerous enemy (the enemy who is going to strike the player first). David explained that auto-targeting should behave like Clint Eastwood in a western movie: Clint is able to clear a room of bad guys with his six-shooter by shooting the guys who can draw their guns fastest first. Stallone also used this method when he killed the river pirates at the beginning of Rambo IV. The type of attack and amount of damage done by the attack will be determined by context.

What is context?

Context is nothing more than the state of several variables. Here is what our initial definition of context will look like in this first draft:

Distance (from targeted enemy): d = either "close" or "ranged"
Preparation Time: t = amount of time that left click has been held (it's like the wind-up to an attack, raising the sword over your head)
Position: p = either standing still, accelerating to left of target, accelerating to right of target or crouching

So now we can say that your attack is a function of these variables.
Attack = F(d, t, p)

However, I've already mentioned that an attack is an animation component paired with an intended damage component. So we should really say that:
Attack = F(d, t, p) = (A(d, t, p), D(d, t, p))

How does the animation function turn context into an animation?

First let's clarify the effects of preparation time, t. Every attack animation will have a set of "key frames". Each set will include a "preparation frame" (for a punch this would be pulling back your fist) and an "attack frame" (sending your fist forward). The player's character will animate towards the "preparation frame" as soon as left-click is held. Then when left-click is released, the player's character will quickly animate towards the "attack frame". This gives players analogue control over the timing of their attacks. It should now be clear that preparation time only controls the play speed of an attack animation not which attack animation gets selected.

This leaves distance and position as the two contextual determinants of what attack animation will be selected. Distance shall have two valid attack states: close and ranged. Close attacks will be moves like knees, elbows, chokes, sweep kicks, gut punches and head butts. Ranged attacks will be moves like roundhouse kicks, haymaker punches, front kicks, the famous double punch from Lugaru.

If there are 4 major positions: standing, crouching, moving left across the enemy and moving right across the enemy then four positions times two distances equals eight animations to fill in. I have arbitrarily filled in the list so these moves are highly subject to change:

[close][moving left] -> gut punch from right to left with the right fist
[close][moving right] -> gut punch from left to right with the left fist
[close][standing] -> knee to the gut
[close][crouching] -> sweep kick
[ranged][moving left] -> roundhouse kick that knocks the enemy to the left
[ranged][moving right] -> roundhouse kick that knocks enemy to the right
[ranged][standing]-> double punch
[ranged][crouching] -> might not exist, maybe a cool break dance leaping attack

How does the damage function turn context into damage?

Each attack move will be paired with a maximum damage value. This maximum damage value will be moderated by a function dependent on preparation time. Here's the logic. A rushed strike is fast but weak. Conversely, if you are holding a sledge hammer behind your head, you not only stop gaining additional damage, you forfeit extra damage that could have been caused from one fluid wind-up and swing. Eventually your arms will get tired holding the hammer in the raised position. Thus it seems that there is a quick zone, an optimal zone, and a late zone for any strike. As a function of damage versus preparation time, the curve would probably look something like this:

Overgrowth, like Lugaru, will again use two kinds of damage: permanent damage and temporary damage. Both kinds of damage will be scaled proportionally to the preparation time function illustrated above. If at any time the permanent damage plus temporary damage done to a character, exceeds his health, he will either die or be unconscious.

Permanent damage stays forever. Temporary damage is based on the idea that 5 punches to the head in 5 seconds is more likely to knock someone out than 5 punches to the head spread evenly across 5 hours. Temporary damage represents the pain and trauma that a fighter can recover from over time.

Other Candidates for Context Variables

Weapons - As was the case in Lugaru, equiping a weapon will change some of a player's attack moves.
Species Type: Each species will have various special moves. I believe David has mentioned that rabbits will have specialized ranged combat with strong kicks whereas wolves will have specialized close quarters combat moves like biting with their razor sharp teeth!
Brutality: Overgrowth may include a binary brutality variable. This variable would have 2 states: lethal and non-lethal and would affect the brutality of the player's entire move set.
Other Positions: Ok so we covered 4 positions standing, crouching, moving right and moving left. However, what about the case where one or both characters are climbing and an attack is initiated? What if one or both characters are in the air? These will need their own treatments as well. The rabbit kick from Lugaru is a special case scenario.
No Enemies In Range: What happens when you push left click and there's no one to attack. Perhaps this will result in a taunt.
Detection: If the player has not been seen by an enemy they will probably have a modified attack move set at their disposal. Remember the stealth kills from Lugaru.
Right click: You will probably use right click to climb as well as to grab and block attacks. Additionally right click might serve to cancel initiated range attacks. There may be an over-arching theme of left-click being used to escalate fights and make them more violent while right click is more passive and involves more respect for the enemy's well being (think of Mr. Miyagi from karate kid).

What are your thoughts on this initial draft of Overgrowth fighting? Please share with us any games that you think have awesome fighting systems.

This question comes up every once in a while on various indie forums: How should I host my video game? What are some good mirror services?

The cool thing about this question is that now there is pretty much one canonical answer: Amazon CloudFront.

There are a few things to take into account for a file host:

- Latency
- Throughput
- Reliability
- Cost

A local server is faster than a distant one. This is because the farther the packet needs to go, the more likely it is to get congested. It is not uncommon for packets to get delayed or get dropped completely, and due to the way TCP works, only a certain amount of packets will be sent out at a time.

Here's an images that illustrates centralized hosting. Instead of arrows, it might be more useful to illustrate the number of routers a TCP request might have to go through.

So, a possible solution would be to have many servers situated as close to the downloaders as possible. That way, if someone from San Francisco downloads your file, it is just as fast as if it was someone from Japan. Sometimes you will notice companies will list ridiculous amounts of mirrors for their large software downloads based on the location.

This is exactly what Amazon CloudFront does -- but a lot slicker. Amazon has built a number of data centers around the world which connect to various internet backbones. All you have to do is upload your file to Amazon S3 and enable Amazon CloudFront on your S3 bucket (tutorial here).

When you upload your file to Amazon's file server, Amazon will cache it at various edge locations closer to users. That means that Amazon has a number of servers around the world and will transparently mirror your file to the most efficient locations in response to demand. The way it does this is very simple. Amazon tells your DNS server (the server that translates a domain name into a raw IP address) to respond with a different address depending on where that DNS server is located. If that edge location has your file, it will serve it up locally. If not, it will get it from the central location, and next time, that local server will be ready.

The end result is that when a user goes to download your file, they are seamlessly downloading it from a local server instead of being routed to a single server however inefficient that might be.

Here's an images that illustrates a content delivery network. Each request is routed much more efficiently than if there is a single, centralized server.

But what about the cost? Traditionally, a fancy content delivery networks was prohibitively expensive. These days, "software as a service" is the new fad, and with Amazon Web Services, you pay for exactly what you use and nothing more. Given the rise in popularity of streaming video sites like Vimeo (but don't use them) bandwidth is dirt cheap now. One HD video view is about the size of 10 downloads of Lugaru, for instance.

I believe our bandwidth bill comes out to about one penny per download of Lugaru. Its so cheap, it might as well be free. So feel free to download Lugaru or one of Davids other games and test the download speed for yourself. ;)

What do you use for file hosting? If there is any interest, next week I will talk about Google App Engine, and how to give your website the same treatment that CloudFront gives to static files for free.

Undo is one of the most important functions in any editor. It's one of those quintessential things that makes working with a computer qualitatively different from working with traditional tools. Sometimes when I'm sketching with pen and paper, I'll impulsively think "hmm, that last line is a bit off, time for ctrl-z!" And then I get a jolt, look down, and remember there is no undo for real life. (I actually do this with ctrl-f too. I'll open up a book to find a quote and my first thought is "where's the search bar."). Undo is essential, but in the past I've found it easy to put off. There's always some cooler feature that will actually do something. Eventually, of course, it becomes apparent that none of those cool features will in fact be usable without undo, but by that time adding undo is a huge headache.

With the Overgrowth editors, I wrote the undo/redo framework at the beginning, and this has helped a lot. I'm not, by any means, an expert on this subject, but I still wanted to share our method for doing this, since I've found it pretty straightforward and easy to work with.

Two Types of Undo

First, let's look at how other programs implement undo. Little Big Planet (LBP) is a great example of a brute force method to implementing undo (and isn't it nice how all our examples can be about LBP :) ... okay, I'll admit it, we were playing LBP again last night :( ). LBP's undo feature simply rewinds every movement on the screen. It looks just like a video played in reverse. This gives the user complete analog control over the exact moment in time he or she wants to go back to. Unfortunately, as a user, this isn't usually what I want. I have an idea of what actions I want undone, not how many seconds I want to erase. The LBP system is good for gameplay video capture and for games like Braid that rely on time reversal. But effective editors need a more filtered history.

The big alternative to the 'rewind' method is what I'll call the 'semantic record' method: only important events are recorded and these events are packaged into discrete semantic actions. This method is everywhere. In Photoshop, for example, you don't rewind a painted line, you undo the entire 'paint line' action. This is what the Overgrowth editors use.

Command Patterns

The basic requirement for any action history is that each recorded action must be able to run both forward and backward. Sometimes this concept is formalized into the notion of a Command Pattern, which, in the present context, is a command structure that bundles a forward running Execute() version of some routine with a reverse running UnExecute() version of the routine. In the Overgrowth map editor, we have just six of these underlying command patterns: ADD/REMOVE, SELECT/DESELECT, GROUP/UNGROUP, TRANSLATE, SCALE, and ROTATE. Out of these, we build all the user-level controls, such as copy, paste, load, group rotate, and clone. Paste, for example, is just recorded as an ADD command that happens to act on objects in the copy buffer.

The full action history is simply represented as a list of commands with a pointer to the user's present location in the history. Undo() calls UnExecute() on the pointed to command and then moves the pointer back one step; Redo() moves the pointer forward one step and then calls Execute() on the newly pointed to item. As is usual, the redo side of the list is cleared whenever any new actions are recorded.

The undo/redo list. Blue boxes represent actions that can be undone. Yellow boxes represent actions that can be redone.

Reversing Commands

Figuring out how to play commands in reverse can be a bit tricky. What has worked for me is to record each command with some packaged data, which fully describes both the starting state and the ending state of the associated action. Then, Execute() applies the ending state and UnExecute() applies the starting state. For example, each TRANSLATE command comes packaged with a starting_pos and ending_pos. To undo a TRANSLATE, we simply reset the object's position to starting_pos.

As an alternative to recording starting and ending state, we could instead record a forward and reverse transition function. Execute() would call the forward transition function and UnExecute() would call the reverse transition function. This method would be more memory efficient when multiple obects are translated at once. Rather than having to remember a starting_pos for each object, we would just have to remember a single transition vector. Unfortunately, in gaining memory we lose speed -- applying transition functions is usually slower than just resetting to a recorded state. Sometimes the memory is more important, other times the speed. Luckily for us, for the action history, usually both are negligible, so we implement each command pattern according to which method is easiest and most intuitive. With transformations, recording and reapplying state has proven cleaner.

Pseudocode for the TRANSLATE command record.

Packaging Commands

Complicated commands require some further data structures. When a user moves multiple objects at once, semantically it makes sense to record this as just one action. In such a case, we bind all the individual TRANSLATE commands into a single event in the undo/redo list. When this event is undone, UnExecute() is called on each individual TRANSLATE, setting each affected object back to its starting_pos.

Actions that affect multiple objects at once are bundled in the history list.

Sometimes history management improves from even more bundling. For example, holding alt and transforming an object clones the object as it is being transformed. This is recorded as an ADD followed by a TRANSLATE, SCALE, or ROTATE. Here, undo should pop back both the transformation command and the ADD command. To facilitate this, command patterns can be chained with neighboring commands in the undo/redo list. When chained, these commands with be undone or redone as a unit.

When multiple commands make up a single semantic action, these commands are chained together in the history list.

Memory Management

One last tricky bit with undo is memory management. When an object is deleted, there's always the possibility that it will be brought back with an undo. One simple way to avoid costly and confusing recreation of objects (and the accompanying invalid pointer mess) is to never actually free the memory of an object as long as it remains in the undo/redo list. Instead, the object should just be unlinked from the active structures. The necessary information for relinking should be stored in the deletion record. (Edit: I previously suggested simply flagging these objects as deleted, but after reflecting on the comments, I think a flagging method is too hackish. Also, to be accurate, the Overgrowth editors primarily rely on unlinking and relinking.) If the object leaves the undo/redo list (e.g. when the redo part gets scrapped), only then should its memory actually be freed. Technically, these delayed frees might waste some memory, but for the purposes of the Overgrowth editors, I've found it sufficient.

What do you guys think of these methods for handling undo/redo? Do you know any other tricks of the trade, alternative paradigms, or convenient formalisms?

Hey guys I've noticed on our live chat that a lot of people end up asking similar questions about Overgrowth. I am happy to answer them individually but I bet a lot of other people have these questions as well.

- When will Overgrowth be released?
- What are Overgrowth's system requirements?
- How will Overgrowth be different from Lugaru?
- What kinds of characters will there be in Overgrowth?
- Will Overgrowth be an open world game?
- What is the Overgrowth story-line?
- How will Overgrowth multiplayer work?
- How much does it cost to preorder Overgrowth?
- Why should I preorder Overgrowth?
- Can preorders be transferred to Steam?
- I preordered Overgrowth but I've lost my key, what's the easiest way to get it back?
- Does David Rosen really exist?
- Will the Whale Man be in Overgrowth?
- I have a question that's not on this list. How can I contact Wolfire?

When will Overgrowth be released?

We do not really know when Overgrowth will be completed at this point and without a publisher or any external investors, we have the luxury of being able to release it when we want to. We will take as much time as is needed to get the game done right. If we tried to pick a specific date right now, we would probably get it wrong and disappoint a lot of people.

With that said, every week we give our preorderers a new build, so even though the game is not officially released, it is possible to get a hold of it. We will have a better idea of how long this project will take as we continue to make progress.

What are Overgrowth's system requirements?

Overgrowth is too early in its development for us to know for sure. We are supporting Mac OS X, Windows, and Linux. Overgrowth will support a number of graphics settings to help it run on older computers.

How will Overgrowth be different from Lugaru?

While Overgrowth will be inheriting the spirit of Lugaru's tried and true combat system, it will also benefit from every cutting edge feature that our new Phoenix Engine has to offer. Fans can expect better graphics, better physics, more characters, more moves, great mod support, and co-operative multiplay.

What kinds of characters will there be in Overgrowth?

We are planning to include 5 character types in Overgrowth: rabbits, wolves, cats, rats and dogs. The main character is Turner, the rabbit from Lugaru.

Will Overgrowth be an open world game?

Many people have asked this, and everyone seems to have a slightly different definition of what an "open world" is. You can expect the Overgrowth single-player campaign to be fairly linear like Lugaru with hopefully a few major decisions along the way to spice things up.

What is the Overgrowth story-line?

Overgrowth will pick up a few years after Lugaru left off in the same universe. Turner will again be the main character but I'm not supposed to leak any major plot points just yet.

How will Overgrowth multiplayer work?

Our primary focus will be adding some co-operative, multiplayer elements. We're not sure yet how many players can be supported at the same time but initial multiplayer tests have been successful.

How much does it cost to preorder Overgrowth?

USD $29.95. You can preorder Overgrowth here.

Why should I preorder Overgrowth?

1. You get admitted to an exclusive club called the Secret Preorder Forum or SPF. I am bound by the 1st rule of SPF (and 2nd and 3rd...) not to talk about what happens in SPF but it is full of Overgrowth discussions, alpha testing stuff, and people showing off modding screenshots and such. For an example of the kinds of things that get created in SPF, click here.

2. You get to download our weekly alpha builds. Fans have enjoyed watching us build Overgrowth from the ground up. Now many are enjoying building their own houses and jumping around with rabbot. Every week, new stuff is added, until we are done (and then hopefully fans will take over with our modding tools!)

3. You get that warm fuzzy feeling of knowing that you are helping the small indie company that is Wolfire survive in the crowded and noisy space of the gaming industry. Thanks to fan support we were able get better computers and more coffee. Both have helped us code faster.

We have no publisher or external investors, so we are in a pretty unique situation where we are getting funded by fans. When you preorder, you also get the Mac, Windows, and Linux versions of Overgrowth, and we get 100% of the money. If you order through, for example, Steam later on, you will only get the Steam version and we will not get your full support.

Will preorders be able to be transferred to Steam?

Yes! See this blog post here. Not to be one upped by Steam, Stardock's Impulse has agreed to offer the same deal, so you can get the Mac, Windows, Linux, Steam, and Impulse versions of Overgrowth upon release by preordering.

I preordered Overgrowth but I've lost my key, what's the easiest way to get it back?

We've made a page just for you right here. Still having trouble? Send us a message using the info on our contact page.

Does David Rosen really exist?

Some people on the forums (I'm talking about you Nutcracker) have questioned the existence of our fearless leader David Rosen. David is very real. You've heard him speak in the Design Tours and our ModDB interview and you've seen his picture. Shun the nonbelievers, shun!

Will the Whale Man be in Overgrowth?

At first the Whale Man was intended to be a joke but because of his warm reception we're not so sure any more. We'll have to wait and see. Be warned, he is often very disagreeable.

I have a question that's not on this list. How can I contact someone on the Wolfire Team?

Come talk to us! We are pretty unique in the fact that we are reachable on instant messengers in addition to email, forums, etc. Also please feel free to reply with questions that I missed underneath this post and I'll add the important ones up top.