Spring RTS Engine

so i spent all night last night reading the wiki and looking at almost all of the parts in balanced annihilation. (because i have it, and my home internet is very, very poor right now). basically, my question is, what other hard coded limitations are there, and please correct or verify some of my assumptions listed.


so far, i have noted very few limitations:
1). 32 unit classes (mostly for targetting AI)
2) 4 unit types (kbot, vehicle, hover and ship) .. ..which made me scratch my head, because air?
3) max map incline of 89.99 degrees. (no over hangs or bridges)
4) a unit max, i think. (5000, or perhaps the engine could do as many as a cpu could handle)
5) only two resources, (metal and energy)
6) fuel systems have been deprecated
7) there was the yard tags, about only 7 of them, iirc. (more can be coded, i assume, not really a problem)
there is only three types of collision boxes, but you can make custom collision boxes around unit pieces.
9) this one is a question, which i will find out later, but it seems maps need pathfinding meshes. i assume this is for optimization, and the engine does have a bulk cpu pathfinding routine as well, if a defined mesh is not available.
10) weapon types. although there are various ways of making them, and certainly some awesome tricks i have envisioned to get what i want, there was one weapon type that was removed, it seemed to be an arc-swing type weapon? in my vision, there will be many many arc/wave type weapons, a little different from pyros fire, but i envision using the flamethrower script in short bursts if necessary)
11) detection types: radar, seismic, los, sonar
12) 32 bit
13) no way to define the effects of a weapon depending on the unit type it hits, (ie, a bullet will make the same noise and explosion effect if it hits a person or a tank)
14) 2 weapon effects: damage and stun

so,i learned and had literally hundreds of questions answered last night. its just I have lots of slow time at work, and no access to spring from work. so you will have to forgive me, as i will be posting here A TON from now on. I am incredibly excited. knowing ba as well as i do, and knowing 3d modeling, low poly modeling, and animation as well as i do, severything makes sense.

A quick response off the top of my head:

1,3,4,11 are correct, these are limitations.
9,12 are cases where you are incorrect and the limitation you describe does not exist.
5,8,10,13,14 are not limitations - in some cases they may be the default behaviour, they can be easily changed/overcome (to an experienced dev) by writing suitable lua gadget/widgets.
2,6,7 are cases where I think you (or I) are simply confused by terminology, so I can't give you a response.

awesome. thanks, the answers helped a ton.

for 7: the yardmap is documented as having multiple values, one being (g), which means buildable on geo vents only. my guess is other tags can be made, for other, as of yet undefined, terrain feature.

I am very surprised there can be more than metal and energy. i was already resigned to that, but now... oh boy.

2... the four unit types, seems to be fairly deeply embedded in the engine, as there are map area definitions which determine how the different types move over the terrain. my guess would be, for example if you had a mudpit, kbots could be defined to move at half speed, and tanks at 1/4 speed. i would guess more types could be created, but then map definition would need it too, if there were areas that used that feature.

not really anything i am concerned about, atm.

7: this is a case where you can replace the engine behaviour with lua.
2: this is a limitation. There are not many cases left where the four OTA unit types have hardcoded significance in the engine. They have been gradually removed over the years. https://springrts.com/wiki/Mapdev:terraintype says not to use/rely on the hardcoded terraintype speed mutipliers anymore, but I think some new callins would need to be created before a lua replacement would be viable.

NeOmega wrote: 1). 32 unit classes (mostly for targetting AI)

You are referring to unit targeting categories, and yes the limit is 32.

2) 4 unit types (kbot, vehicle, hover and ship) .. ..which made me scratch my head, because air?

That is a somewhat outdated view. A more modern view might be 'building, static ground unit, mobile ground unit, hover, ship, air, gunship'.

3) max map incline of 89.99 degrees. (no over hangs or bridges)

Correct.

4) a unit max, i think. (5000, or perhaps the engine could do as many as a cpu could handle)

32000 https://github.com/spring/spring/blob/d ... ants.h#L92 , a useful file for checking hard limits btw.

5) only two resources, (metal and energy)

Engine support for only 2, but you can make as many as you wish via lua.

6) fuel systems have been deprecated

Again, in favour of greater flexibility via lua.

7) there was the yard tags, about only 7 of them, iirc. (more can be coded, i assume, not really a problem)

You are referring to yardmap, but the buildingMask tag and associated lua callouts allow replication of 'g' like behaviour on a per mapsquare basis.

there is only three types of collision boxes, but you can make custom collision boxes around unit pieces.

Yes, also as of 104, selection volumes.

9) this one is a question, which i will find out later, but it seems maps need pathfinding meshes. i assume this is for optimization, and the engine does have a bulk cpu pathfinding routine as well, if a defined mesh is not available.

No pathfinding meshes, only pathfinding algorithms though there are 2 available https://springrts.com/wiki/Modrules.lua#system

10) weapon types. although there are various ways of making them, and certainly some awesome tricks i have envisioned to get what i want, there was one weapon type that was removed, it seemed to be an arc-swing type weapon? in my vision, there will be many many arc/wave type weapons, a little different from pyros fire, but i envision using the flamethrower script in short bursts if necessary)

Don't recall any being removed. If you mean a sword like swing this can be (somewhat clumsily) be replicated.

11) detection types: radar, seismic, los, sonar

Yes, although you could make your own with lua, albeit performance would potentially become an issue.

12) 32 bit

There is a 64 bit windows build but I have no idea if it syncs for multiplayer.

13) no way to define the effects of a weapon depending on the unit type it hits, (ie, a bullet will make the same noise and explosion effect if it hits a person or a tank)

All possible via lua.

14) 2 weapon effects: damage and stun

You forgot engine support for adding impulse (pushing), but lua can do anything you might reasonably wish it to.

so you will have to forgive me, as i will be posting here A TON from now on. I am incredibly excited. knowing ba as well as i do, and knowing 3d modeling, low poly modeling, and animation as well as i do, severything makes sense.

Excellent.

You may want to poke around the Zero-K codebase as well: https://github.com/ZeroK-RTS/Zero-K. I have pushed the engine further than BA so you should find some more mechanics and examples.

1). 32 unit classes (mostly for targetting AI)

Unsure and unclear. I believe that unit categories are only relevant to NoChaseCategory, BadTargetCategory and OnlyTargetCategory so if there is a limitation it is contained to a few cases. However, my target priority gadget allows for target priorities and targetability to to be set arbitrarily on a per weapon and unit basis as well as allowing for these settings to change during the game. Therefore much of the purpose of BadTargetCategory and OnlyTargetCategory is replaced by lua, it may well be all replaced. I am unsure exactly how NoChaseCategory works in the engine and interacts with target categories so maybe it can be replaced as well.

2) 4 unit types (kbot, vehicle, hover and ship) .. ..which made me scratch my head, because air?

Not really a thing as this concept is mostly deprecated. As far as I am aware the unit types are even less used than unit classes. These four words only appear together in reference to speed modifiers that are added on top of the maps terrain. There is no real limit to the type of interaction your units can have with the terrain of a map. You can independently set their slope tolerance, slope speed malus, whether they hover, max water depth, min water depth etc.. I think that units can even have their movement type changed during runtime.

If there is a limitation it is that there are only a few types of speed modifiers (think roads) that exist on maps.

3) max map incline of 89.99 degrees. (no over hangs or bridges)

Yes.

4) a unit max, i think. (5000, or perhaps the engine could do as many as a cpu could handle)

Others would know better than me for strict technical limits. However, I would be surprised if someone made a game with a playable framerate with unit counts exceeding 5000.

5) only two resources, (metal and energy)

Not a limitation. The engine contains handling for these two resources, however, the scripting is easily powerful enough to replicate any resource system you may want. Zero-K uses metal and energy but the engine implementation has so many issues that I have almost entirely replaced resource handling with lua, so I know it can be done.

6) fuel systems have been deprecated

Not a limitation, same reason as 5). Any behaviour you may want to link to a "fuel' attribute of units can be scripted. Zero-K has a system similar to fuel in which bombers return to airpads to reload and this system is entirely lua.

7) there was the yard tags, about only 7 of them, iirc. (more can be coded, i assume, not really a problem)

There is no limitation related to restricting structure placement, I don't know what else yardmaps might do. Zero-K has metal spots which are enforced to only be able to have metal extractors placed on them. You could make a system of arbitrary spots with limited structure selection.

there is only three types of collision boxes, but you can make custom collision boxes around unit pieces.

This is not a limitation, with a caveat. It is correct that units can only have spherical, cylindrical or rectangular collision volumes. However, there is a piece collision volume system that I have not looked into and, in the worse case, a game that really requires more extravagant collision volumes can simply paste multiple units together to seamlessly create one big unit.

9) this one is a question, which i will find out later, but it seems maps need pathfinding meshes. i assume this is for optimization, and the engine does have a bulk cpu pathfinding routine as well, if a defined mesh is not available.

Incorrect or unclear. The engine generates pathfinding meshes for the map when it is loaded. This mesh is cached for future games and updates when the terrain changes during the game. Map makers and game developers do not need to worry about generating path maps.

10) weapon types. although there are various ways of making them, and certainly some awesome tricks i have envisioned to get what i want, there was one weapon type that was removed, it seemed to be an arc-swing type weapon? in my vision, there will be many many arc/wave type weapons, a little different from pyros fire, but i envision using the flamethrower script in short bursts if necessary)

Not a limitation. For arc type swing weapons I recall an experimental unit from years ago which effectively wielded a lightsabre. This was probably done with a noexplode constantly emitted beamlaser. In any case, lua can set damage and effects once the weapon collision is detected.

11) detection types: radar, seismic, los, sonar

Sort of a limitation. The terrain-raytraced LOS and radar systems would be slow to replicate in lua so if you want this sort of detection you are limited to the options within these systems. That said, you can add more systems on top. For example there was a Spring game with mass-radar which would should blobs of enemy units as a region of high mass instead of inidividual radar dots. Lua also allows for units to be arbitrarily hidden or revealed.

12) 32 bit

Yes, in my experience. The 64 bit windows build does not work for me and has not been tested on many users so it is unlikely to work.

13) no way to define the effects of a weapon depending on the unit type it hits, (ie, a bullet will make the same noise and explosion effect if it hits a person or a tank)

Not a limitation. Weapon impacts cause events which can then be handled by lua to spawn effects or do any other game mechanical thing you may want.

14) 2 weapon effects: damage and stun

Not a limitation. You can create just about any status effect you may want and weapons can also apply impulse to knock units around. Zero-K has a general slow effect as well as a weapon disarm. See https://github.com/ZeroK-RTS/Zero-K/blo ... ibutes.lua

The thing is, all the limits you listed but one (12) 32) can be circumvented by a little scripting.

Spring has been 64-bit default for Linux for ages, and the windows 64-bit syncs with everything else.

3) Is the hardest to overcome IMO.

Map incline is indeed limited to 90' but if you just want bridges/overhangs for visuals they can be faked.

yeah, i already thought about workarounds for things like archs or bridges. i dont really intend to use them, but i figured you could put in features or even gaia units to fake archways etc. you could possibly even use invisible transports to rail units across "bridges". but these are all things i am not terribly concerned about atm.


ive actualyy read most of the spring wiki now, and read the lua manual, watched some tutorials. i understand now this engine is basically limitless. I kind of wish they used lua instead of java in my college programming courses, (i failed the second one, only time i ever failed a course in my life). Compiling really blows holes in my momentum.

The limitations of the engine get people like me hard

FLOZi wrote:

5) only two resources, (metal and energy)

Engine support for only 2, but you can make as many as you wish via lua.

6) fuel systems have been deprecated

Again, in favour of greater flexibility via lua.

Then why is "two resources" not deprecated then?
Am I missing something here?

There is only engine support for the 2 legacy resources which many games utilise... Pretty much all the 'major' (i.e. not ludum dare or kdrs little mini games) projects afaik.

On the other hand, Gundam did its own totally independent resource system with lua years ago.

Personally I'd like to see greater engine support for multiple resources ( https://springrts.com/wiki/User:Flozi/E ... dResources ) but I doubt it will happen - it really isn't necessary.

FLOZi wrote:Personally I'd like to see greater engine support for multiple resources ( https://springrts.com/wiki/User:Flozi/E ... dResources ) but I doubt it will happen - it really isn't necessary.

We might as well completely remove resources as a concept in the engine. I'd like to see support for more complex data structure sharing between synced and unsynced, such as having tables (or table-like userdata) in rulesparams.

My view is that resources are a standard RTS trope, so the engine should lend a hand in building a world dependent on them.

We don't always have to reinvent the wheel as well as design our own cars.