What’s been happening with Evolution RTS and how it’s gameplay has grown

Evolution RTS Units capturing a Control Point

Hi everyone, it’s been quite a while since I posted any news about EvoRTS and specifically changes to the gameplay, so this post is intended to bring everyone up to speed.

Website Redesign

As you might be able to tell, the website has seen a bit of a makeover. On the front end it might not seem like that much has changed, but behind the scenes, it is much easier to manage. It is built using my super powerful wordpress framework (Shameless Plug), and it allows me to do much, much, more than was previously possible (barring a ton of work). I’m still working out all the kinks, but for the most part it’s pretty solid so far.

What’s been going on with EvoRTS?

Forgive me, but some of this will be copy pasta from a post I made in the forums recently with some added details.

Personally, the current released version is kind of embarrassing to be honest. I tried very hard and failed pretty badly. I have been working on the next version since February and have been testing extremely extensively with KoyoteKamper, who happens to have a ridiculously crappy laptop. I’ve managed to get him up to an average of about 30 fps in most situations (give or take a bit here and there).

So, that’s pretty significant. I’ve also been working on making the gameplay much more simple and now it even has an internal luaAI that actually plays the game reasonably competently (probably won’t be much challenge to experienced players, but for noobs it should work really nicely).

I don’t really want to go huge into depth about gameplay changes because that’s being saved for some pretty detailed blog posts, but suffice it to say that I am focused on players having fun. Yes, it should be challenging, but at the same time, if the challenge feels like a grind then no one will want to play that, so the trick is to make the challenge fun each time. I think I/We (koyote has been helping me a lot) have achieved or are extremely close to achieving that.

Suffice it to say, while the reviews are disheartening to read, and while some are just silly, there is a ton of reviews that have perfectly valid points in them. Sadly, one of the current problems is the fact that it’s so difficult for a player to actually make it into the game (I.E. they don’t make it past the lobby). That sucks. New version should solve that though.

So basically, that’s it in a nutshell. The somewhat longer explanation would be the fact that the current release is hit or miss. Partly due to using an older, less compatible version of the engine, and partly because of some dodgy Lua. The Spring Engine has had a long and complicated history with ATI/AMD video cards. ATI writes drivers that are very strict, and will fail in many cases if the commands it receives are not 100% “correct”. Now, that could be a point of contention with the Spring Devs as JK has told me previously that clean commands are sent, yet the drivers continue to fail. Suffice it to say that until somewhat recently, ATI/AMD does not play nicely with OpenGL rendering. Nvidia on the other hand will take pretty much any curve ball you throw at it and present you with a home run.

Knowing this, you can probably see why the release of EvoRTS was a bit of a mixed bag. Even to this day, there are a lot of people who download it but never make it ingame. It’s frustrating, but there hasn’t been a whole lot that I could do about it.

This all changed somewhat recently (January/February), when Hokomoko (a Spring Engine Developer) offered to help me get EvoRTS into the newest version of the engine. This was previously impossible to do because there had been significant changes to how Lua worked in the engine between Spring versions 96 (current EvoRTS engine) and version 97. Basically, I was a bit stranded. To make a long story short, with Hokomoko’s help and a mountain of work, EvoRTS is now working beautifully on the latest Release Candidate of the engine. That said, this latest RC has some reasonably debilitating bugs, but they will get sorted out, and the game is very playable, and shouldn’t have any strange or highly specific issues with ATI/AMD anymore (YMMV).

Which leads me to changes to the gameplay and the game itself…

Big Evolution RTS Gameplay Changes

Well, the first big change is a change to how resourcing works. There are a lot of moving parts here but I will try to address them as coherently as possible.


Previously, to gather metal you would have to send workers out to build Metal Extractors on predefined metal spots. This serves the function of making you need to expand and cover territory. Depending on where the spots are, a patch of land may be more or less valuable. It has a lot of weaknesses though. For example, games tend to snowball once a tipping point is reached. A lot of games are ok with this, but EvoRTS has always had a really strong comeback element, and it is one of the gameplay elements that I like the most. In EvoRTS, it is almost always possible to come back from behind.

So, how is it different now?

Metal spots no longer exist. Metal extractors no longer exist. There is no need to go out and harvest metal anymore. Instead, metal is given in increments of 3m/s compounding every 2.5 minutes. What this means is that you start with an income of 3m/s, then at 2:50, that increases to 6m/s, and so on. It caps out at a maximum of 15m/s. This has a lot of advantages on the game design side of things. First off, it eliminates snowballing. This is important as the snowball effect makes it so that no matter how hard you try, you ultimately lose because the snowball eventually rolls over you. With equal income, you and your opponent are on equal footing (theoretically) for the entire game. This brings me to the caveats…

While metal income is fixed, you can still supplement your metal income by reclaiming energy cores. Additionally, if you are leaking metal (your storage is full and you’re just sending metal off into the ether), it directly effects your ability to fight your opponent. In testing, it is always interesting to look at the graphs and see who used all of the resources they took in. Many times you will see that the person who lost the game was the one who did not spend their resources completely. This brings me to the last point about this, which is that it puts a very strong emphasis on what you spend your metal on. If you spend your metal income all on buildings, and your enemy spends all of his income on army, then your opponent will likely win, because he invested his income more efficiently. So, instead of making land grabbing with mexes more important, we make it more important to spend your resources wisely.


Remember that metal is just one resource that you need to worry about. You have to have energy in order to fire weapons, power shields, cloaking, etc. Because your income is fixed, it means that you must wisely split your income between enough army to crush your opponent, but also on energy and storage infrastructure to allow your units to be effective in battle. If you have a giant army but you run dry of energy five seconds after the battle starts, your army turns into a bunch of very expensive paperweights.

The upshot of all of this is to simply make it so that instead of it being really difficult to gather resources, we make it so that using resources wisely is rewarded and having a strategy going into the game is a wise move.

But you might be thinking “But in this case, people would just build up a 200/200 army and roll out only then!”…

Control Victory Points

Not a terribly sexy name at the moment, but it is descriptive. Control Points are spread throughout the map. The points can be captured by simply moving units into the circle. It’s very similar to how Dawn of War or Battlefield control points works. Probably more similar to Battlefield. You and your opponent(s) start with a maximum score (by default right now it is 3500). For each Control Point that your opponent controls, you will lose that many points from your score every second. There are 7 points on each map that can be captured. This causes you to need to move out as quickly as possible, and you will find that you constantly are fighting over control points. When a player reaches a score of 0, that player’s units will explode. This makes for some very intense and exciting games, and in testing we have had a ton of fun with them.

Additionally, there are 3 Control Victory modes:

  • Countdown
  • Tug of War
  • Domination

Countdown is the game mode that I just described. Both player’s score counts down until someone hits 0.

Tug of war causes the points to be transferred from one player to another but with a small catch… Point values are doubled, meaning that if you own 7 points, you will receive 14 score points from your opponent every second.

Domination requires that you own all of the Control Points for 30 seconds. If you accomplish this then you score 1000 points, at which point all of the Control Points capture status is reset (in other words all points go neutral after a score). First player to 3500 points wins!

All of the parameters are highly configurable from the lobby, and you can change nearly everything about the gameplay with these configuration options.

New Maps

I have been working on a set of new maps specifically created just for EvoRTS. Previously I had used maps that were created by the Spring community for various Spring games. This resulted in some fairly questionable gameplay quality at times, and so I decided that it would be best if I created a map pool specifically for EvoRTS. Currently 5 maps are done. There are a variety of types that cater to various techs. The latest is a basin with a lava pool in the center that covers 3 Control Points and is designed for up to 8 person FFA. But, that’s just one of them. I’ll be making posts showing them off some time in the future.

Shard AI is now a LuaAI!

Now, understandably, you might not realize why this is a big deal. Shard existed before, so who cares that it’s now written in Lua? Well, the reson this is a big deal is that LuaAIs are packaged with the game, instead of with the engine. This allows for the AI to be a much tighter part of the game that if it is an AI that must be compiled externally from the game and the engine. Additionally, with C++ Shard, it could only be used properly by people who were using steam to play EvoRTS because the configs were not part of the game. To make things even better, Shard knows how to play using control points as well. This is a huge deal and a ton of thanks go out to Eronoobos for making it possible!

Welp, that’s about it! All of the above is still in testing and will likely remain that way for some time. The plan is to push out a game that is polished but functional and hopefully you guys will appreciate the work that has gone into it.

That said, I might mention that if you have any interest in helping develop Evolution RTS, feel free to let me know! The source for the game is at www.source.evolutionrts.info. I am in reasonably desperate need of a Lua developer (because my Lua skills are laughable). Please remember that EvoRTS is free and open source, so this is not a project that is handled behind closed doors.

If you’ve read this far I would like to say thank you, and that I’m sorry for the rough time that EvoRTS might have given you. The upcoming release addresses most of the valid points that have been left in the steam reviews and aims to be much easier for newbies and vets alike to get into. Chou!