Today I’d like to explain what I’ve been working on for the past several weeks. This wouldn’t be even remotely possible if not for the work done by CommonPlayer (Stowtemid). Without him, this idea would have been dead on arrival.
The Issue: Mappers currently take a shotgun approach to resource layouts. They try to put resourcing locations in strategic places, and try to define resourcing amounts that will work for most, if not all games using the spring engine. Unfortunately, that approach will generally work well for one game, and be fairly mediocre for others.
The problem, with feeling!
The issue above only covers part of the problem. And even larger one is that some mappers will define too many metal spots or not enough. For games that have very tightly controlled economies like Evolution RTS, that presents a significant problem.
Case in point? Koom Valley. I LOVE this map. It’s pretty, it has a great layout and makes for awesome battles, but there are somewhere around 150 metal spots on it, each giving around 2.0 income. This quickly devolves into insanity. The vast majority of contestable resource locations are no longer important because it
Feel free to count…
The common response would be that this map isn’t intended for small games. That is a perfectly valid statement, but what if we could make it so that that isn’t the case? Why should we have to throw out playing on a particular map, simply because it wasn’t specifically designed for the number of players we want to use on it?
How do I plan to fix it?
In a few words? Randomized mex layouts. Evolution RTS uses LuaMex, and what luamex allows for is resource locations defined by lua. You can define where they are, and how much they give. But lets crank this into high gear. If we can do all that, what is to stop us from having an algorithm that places them for us based upon parameters we feed into it?
Then, building on that, if we have parameters we can feed into an algorithm, what is to stop us from having multiple layouts that can either be specifically chosen or randomized each game?
At that point, things start to get really exciting. It can be made so that each time you load a map, even if it’s the same exact map, you can end up with a very different game, only because the layout changed! The possibilities start to show themselves. But, there are some fairly significant problems…
The Problems, and how I went about solving them
The problems with this approach start presenting themselves early; at least to anyone who is familiar with spring. I’ll try to list all of the ones that I considered major:
- Most maps have the metal spot textures baked into the map, which could cause a lot of confusion.
- Currently, luamex identifies a resource location by having an animated white ring. Combined with the baked in metal spot textures, this is doubly confusing.
- Pressing f4 will show the original baked in metal map.
- What if metal spots get placed on the side of a hill/cliff?
- How can we make it so that the spots are placed such that your start isn’t completely screwed over?
I gotta admit… That last one was by far the most important to me. Most of us are spring loaded (lolpun) to consider a 3 mex start as standard.
Evolution RTS’ resourcing follows a fairly set guideline and progression. For those of you who aren’t aware, evolving things in Evolution RTS is key to advancing. Yes sure, you have your tech facility, but in edition to evolving to different tech levels, various other units and buildings are independently capable of evolution. You start at Tech 0, and progress all the way to Tech 3. Building the Tech facility grants you Tech 1. In this case, as metal extractors are the focus, you start out with a basic t0 mex. That t0 mex will produce whatever amount is written south of the mex spot. As soon as you get t1, it’s extremely important to get to t1 mexes, as the output essentially doubles.
Before getting too deep into that, it’s important to understand why this is the case. If you have a look in the modoptions for Evolution RTS, you’ll see that you can literally change just about anything. In most cases, you can tailor the game to play however you like, ESPECIALLY when it comes to resourcing.
The important slider here is the “Metal Extractors Income Multiplier”. That slider directly controls the output of each metal extractor. It also affects the number shown on the map south of the mex, the density of the color of the ring, and various other things. The important bit to focus on here, is the income itself.
For the sake of making is super simple (as it’s fairly more complicated), imagine that the progression of resource income takes this route currently.
Mex Spot Value * Income Modifier
2 * 0.5
2 * 1
2 * 2
2 * 3
As you can see, the jump from t0 to t1 is incredibly important. This served an important gameplay function to make the early game scrappy and hard fought, and to reward players who managed their energy income and metal effectively. Unfortunately, without a guaranteed close 3 mex start, that becomes problematic, as you are starved of resources almost constantly.
This was fixed by softening the curve of mex progression. So in simple terms, we make t0 mexes give the same as t1 mexes did previously, still cap t3 mexes as the same amount, and split the difference between t1 and t2. The result? Massive gameplay improvement. You don’t get the same urgency to upgrade to t1 as you can hold on to t0 for a little bit longer, but in my testing, it was preferable and beneficial to gameplay.
This one is easy. The random metal spot algorithms allow for me to control the output curve for mexes, starting from inside to outside. So I did it kind of in this pattern.
It’s hard to visualize, but image we have just 4 rings of mex spot locations, each number represents the output of that ring, starting from inner (center of the map) to outer (edges of the map).
1, 0.66, 0.33, 0.5
So what this allows for is that your starting mex spots will give a good amount. Not the best, so you can’t just turtle along on your starting mex spots, but enough to get you going. The more you fight towards the middle of the map, the better your income will be.
Fix #3: What if mex spots get placed on the edge of a cliff?
Honestly, this one was simple. Evolution RTS builders already have a terraform speed of something like 100000, The idea being that I don’t see any gameplay benefit from terraforming obstructing something that can be built at a specific location. Sometimes there is still a 1 or 2 second delay, but it’s not really noticeable.
But what about the groundplate? Doesn’t it melt over the sides of the terraform?
Yes, it did, but it no longer does. I solved this by increasing the footprint by 2, and then adjusting the yardmap on those extra footprints so that the yardmap is open all the time, which in turn doesn’t obstruct movement or buildings. Functionally, it is exactly the same as before.
Fix #4: Metal spot confusion
This was a big one. I’m not exactly a GL guru, so drawing crap is rather hard. The documentation on the spring wiki for it is rather sparse if you aren’t already familiar with it. If you were familiar with it I’m sure it would make complete sense. But then I started looking at the work Floris did on luamex in order to make animated rings. Turns out, he made it easy to change the amount of lines and dots. So after some fiddling and modifying some of the GL drawing, I came up with this:
Even cooler, these animate. The are large, and completely remove any ambiguity. In playing the first game with these markers, the baked in metal spot textures were not even really on my radar from the get go. If someone like me, who has been playing TA style rts games since ’97 can easily discern resource locations from these, then it will be easy as hell for anyone else.
I tested this theory by getting a gaming friend (Swagamemnon) to try Evolution RTS for the first time a few days ago. The only other RTS game he has ever played is Starcraft 2 (of which I also play a lot). From the very beginning he had no questions about where the resource locations were (he also loved the way that the mex income curve worked as described above). And that is in part due to the next fix…
Fix #5: Pressing f4 will show the original baked in metal map
Frankly, this sucks. When I’m playing, I shouldn’t have to press a button to see where resource locations are, how much they yield, and I shouldn’t lose LOS display when I do it.
So I decided to solve all those issues by:
- Always draw resource location markers.
- Always draw the yield below the location marker.
- Always draw resource locations on the minimap (this one is still a little buggy, I think because of an engine issue with DrawInMinimap())
The end result is this:
In one very simple move, I have completely obsoleted f4 mode. If you notice, Geothermal locations are also drawn all the time. Unfortunately, in this screenshot, the metal locations aren’t drawn on the minimap yet due to the aforementioned weirdness with DrawInMinimap() (they show up on the minimap after a few minutes usually). But pressing tab or zooming out will show you the same information, so this counts as a minor bug that I’ll be trying to figure out (maybe minimap drawing has a buffer that needs to be flushed or something?).
It’s also worth noting that this mex spot layout is set by Commonplayer’s (Stowtemid) latest placement algorithm. Pretty neat amirite? I haven’t even gone into the awesomeness that is his algorithms for this, but you can check them out by clicking here.
And lastly, do you even really notice the baked in spots? For the vast majority of us, not really… Not unless you specifically look for them.
In the next version of Evolution RTS I’ll most likely be unbinding F4. The trick is to rebind it before exit. Evolution RTS players will a lot of the time play other spring games using the Evolution RTS lobby, so I don’t want them to end up with random strange issues in those games.
I didn’t initially set out to write a dissertation on the evils of baked in metal maps, but I guess that’s what this turned into. Hope you liked my walkthrough of how I solved one of the largest issues (in my opinion) that spring games have to deal with. This is available right now on the Evolution RTS alpha test host. Give it a go!
The post Resource layouts, Extraction schemes, Visual Representation, and how I fixed it. appeared first on Evolution RTS.