Spring RTS Engine

I'm kind of floating around the idea of a little concept game that uses scripts to create tech levels that have no upward limit. The idea being that units in each higher tech level becoming exponentially more expensive, as they get more DPS, HP, range etc. While resource gathering units would also get exponentially more resources.

Setting up a simple place holder game with only a few units that visually don't appear to change with each tech level while the unit stats do will not be as hard as trying to figure out balance of input vs output or cost/ reward.

I'm thinking maybe at x3 per level cost (assuming leveling up is controlled by price of the factory EG TA style) you would get anywhere from a 1.25 to 2.5 return on particular characteristics (ie manuverability increase less than weapon range increases, which less than DPS, which is less than HP). For resources maybe x2.5 mex or energy production increase, which allows for an increased difficulty in tech stepping as it is slower than the cost of the next level.

I'm wondering if anyone else has input on strategies or cost reward ratios for a ridiculous tech ladder system?


Obviously with a script controlled tech level you wont have alot of variety or unique units for niche roles, but this is more of a plan to see how such a game would play out.

On another note I'm thinking such a game would have no stationary defensive units, and require mobile units to fufill that role, so that tech turtling does become a black hole. maybe that is not necessary if other mechanics could discourage it?

You'd need the number of available unit types to be finite, but it could be made large enough that in practice no one would ever reach the top of your tech tree.

It wouldn't be hard to generate unit defs iteratively with unitdefs_post, although I'm not sure how you'd procedurally generate different models (if you wanted them as well).

Could be fun to add a bit of randomness into how the tech levels develop - reminds me of a half baked mutator I once wrote that hacks into defs.lua, reads in the unit/weapon defs of a game, fits a simple statistical model to them, and then resamples them randomly on each run...

Ah yes. The unitdef limit would indeed require an upper end. okay maybe instead of open it would have an upper limit, and since the cost increase exponentially than a practical tech level maximum could be calculated. Players wont be running up a tech tree for more than a couple hours. How long do some of the really long games last?

Anyways, this mutator you mentioned randomized weapons and unit characteristics per each game?? That's sounds similar to what godde was asking for some time ago, about a game where unit characteristics are not consistent from game to game so simple counters and tactics would not be universal and would have to be learned with each new game.

You don't *have* to rely on unitdefs, as you can still change unit properties via LuaRules and adjust the UI to accommodate.
The spaceship in Area17 that we made had just one unitdef, but you could still upgrade its properties (hp, shields, anti missile lasers, weapons, drones, etc.). Easily enough you can make higher tier units contain the appropriate properties.

right. But if you are modifying the unitdef via lua rules to simulate upper tier units, would that affect all units with that unit def or only specific ones?

for example player 1 and 3 both have the same race so if player 1 builder an upper tier version of on units that require modification would that also affect player 3's? or if player 1 has a ton of older lower tier units lying around would building a new tier force the older lower tier 1 to become upgraded when the lua rules adjusts the unitdefs for the new upper tier (which may not be part of the game design)?

I'm saying that you should have only one set of constant unitdefs, and simply change the actual unit (instance) properties via Spring.SetUnit* functions. You can do almost anything with it.
Changing the unitdefs directly while the game is running is not supported (it *might* work but I've no idea if or how it would sync).

Make a base unitDef for each type of unit and then scale its stats based on its level. All units of the same type would have the same underlying unitDefID but be scaled ingame individually in UnitCreated.

I know for certain that you can change:

• Health
• Speed
• Reload Time
• Build Speed
• Metal extraction rate (at least, you could a few years ago, I have not used extraction in a while)
• Sensor range (los, aLOS, sonar, jamming)
• Unit costs

ZK has a gadget which can change a lot of the above in a fairly generic way. It handles a bunch of weird behaviour and edge cases to do with reload time and speed. These edge cases are mostly to do with 0 speed or reload speed though so you probably don't need them.

Since 101.0 you can change:

• Weapon Damages
• Mass

You can modify basically anything on the fly if you reimplement it in lua. I recommend against using Spring.SetUnitResourcing to change the resource drain/production of a unit because I recall getting weird behaviour out of it. I think the lua function sets resourcing in addition to the unitDef derived resourcing. Perhaps you would be able to get it to work but I just ended up reimplementing resource production in lua.

Just so you're not confused, I was saying the same thing that GoogleFrog explained in much finer detail.
To add on that, you can represent different unit tiers via unit rule params, so luaui can see it too.
I'm not sure if you can use different models, but unit shaders might allow you to do custom appearance as well. There are probably limits to this though and might require drastic changes to the shader framework if you were to use it (which I think should be done anyway, regardless of this project).


Lastly, some useful ways of modifying unit attributes can be found in a ZK's gadget: https://github.com/ZeroK-RTS/Zero-K/blo ... ibutes.lua

you can control metal, energy cost, and build time also on the fly?

Concerns:

• People who split their upgrades could be fucked over
• If you upgrade the wrong type of unit
• if you can hide back upgrade unharrassed and then roll out with massively OP units that few things can touch
• once people figure out the unit that upgrades to be the best with minimal skill to use your game will be over. no variety same thing over and over.
• slippery slope.

these are concerns off the top of my head.

bobthedinosaur wrote:you can control metal, energy cost, and build time also on the fly?

I have my own economy. your economy can be whatever you want with unit costs being controlled by lua

Stuff done in the def files or def's _post.lua file = the changes are applied to all units of that unittype
Functions like Spring.SetUnitMaxHealth() = change is only applied to that one unit

bobthedinosaur wrote:you can control metal, energy cost, and build time also on the fly?

Spring.SetUnitCosts of https://springrts.com/wiki/Lua_SyncedCtrl#Unit_Control looks promising.

Beside the properties of units that can be changed by calling a function (like Spring.SetUnitMaxHealth() etc) one should not forget the properties of whatever new stuff a script added.
If there is cluster-weapon-script then you could upgrade the amount of submunition-projectiles that comes out of the main-bomb.
If there is a units-on-fire-script then you could have an upgrade that makes units immune to burning.
If there is a units-can-jump script you could make an upgrade that gives longer jump-range or allows to double-jump. (jump again mid-jump in air)
If there is terraform then that could require unlocking.
(...)

Setting up a simple place holder game with only a few units that visually don't appear to change with each tech level while the unit stats do will not be as hard as trying to figure out balance of input vs output or cost/ reward.

I feel when upgrades and changing stats play such an important role, then having them reflected visually would be important to understand what is going on.

a game where unit characteristics are not consistent from game to game so simple counters and tactics would not be universal and would have to be learned with each new game

Many games are 'figured out' but are still fun to play.
RTS games contain lots of numbers and numbers are boring. Luckily after a while one does not need to look at the resource numbers anymore or check how much hitpoints a unit has - You get a feel for it.
Discovering a new game is fun but only if it is really something new to discover. Randomly changed numbers do not seem fun, more cumbersome and it might not even change the playstyle that much. If a game is decided because "Oh, I did not notice today those tanks can shot so far" is not interesting.

What might be fun is maybe a bit the opposite: Randomly removing units from the game. zero-K had a "raider weekend" with turrets disabled.
There are the popular "no-metal" maps that basically remove the metal-extractor and play totally different. That could be taken some step further, TA-mods have hundreds of units. Even with random selection of 50% units disabled the game would stil be playable. The units are still the same (so there is no boring comparing of numbers) but it would still give the challenge that each match you have to totally re-think how to play.

Silentwings wrote:
It wouldn't be hard to generate unit defs iteratively with unitdefs_post, although I'm not sure how you'd procedurally generate different models (if you wanted them as well).

PieceLego? SetPieceHierarchy?

Alright guys now aside from the technical aspect which I see is very open, so lets get back to design philosophy.

Smoth expressed concern with an unbalanced OP in leveling. could there be a way to balance leveling? Smoth, are you implying that a sinle tech level game has the best balance system? Leveling doesn't have to be a krogoth at level 3. maybe krogoths are level 8 and there is much between the pewee/AK and the krogoth?


Also the randomly generated stats thing would be absurdly difficult to pull off. but a system that allowed for players to recognize quickly and not be completely randomized, (maybe more of a set number of predefined planned out balanced state that could rotate?) may be better. for example recognize maybe a dozen differnt unit groups that could be randomly remoze from a list but still allow game play to occur with out major missing unit counters balances.

bed time