Spring RTS Engine

Boxes for teams:

Instead of just having boxes for each ally team it could be useful to have boxes for each team instead. Ideally that would be a switch somewhere choosing which of the two the boxes are for. This would be useful for certain maps that are odd shapes/arrangements.

Ceasefire modes:

There are a few ways that this could be implemented. Presumable in all cases there would be a start duration at least. So you could have a slider from 0 to 10 minutes. If set to 10 weapons wouldn't be able to fire until 10 minutes after game start. This is what some games I've seen do. However the use of start boxes gives more possibilities for this that are pretty cool, I wouldn't have suggested cease fires otherwise. Basically with a start box you could also prevent the units from being able to move out of the start box until the ceasefire time is over.


Huge map support:

I would love to be able to play one mapsthat are 1024x1024. I know this is an insane size but I think it could be achievable in the long run. Ideally there would be a slightly different map format for it, disabling height map alterations (hardness would only affect unit speed) and ground scarring. It would have a tiled height map so that it wouldn't use huge amounts of ram. The maps wouldn't be of the highest quality, it's a trade off, but would provide an element of fun. Of course everything else would be tiled similarly. I would potentially be interested in making a mapconv style program for this if devs decided to go ahead and do the game part. Pathing might be an issue. Perhaps paths could be precalculated for popular mods and included in the file, or as it uses height map tiles perhaps it could get a speed up by reusing calculations for each tile. To be honest I have no idea what exactly pathing is or does so I am guessing here. Another point to look out for is how object coordinates are handled. Tuiling can easily save memory but depending on how object locations are stored, retrieved, etc there might be a need for some considerable alterations there.

Unit limit increase:

I don't know if it still applies but a while back I pointed out that the max units, no matter what is 5000. Not per player but overall. If this is still the case I think it would be better to have an absolute maximum of 50000. Although no system should be able to handle that it will make the game future proof. Also I've played single player games of DOW and TA with around 15k units total on the map and while it is slow it is just about playable so 5k in my experience is too low. Not an immediate concern, but something to consider in the future.

Cluster rounds:

I used to mess around with the settings in Tiberium sun allot and this was great fun because of the cluster weapons. It would be nice to see something like that for spring. In coding terms it would be kind of like making a weapon inside a weapon. For example a warhead could, when at say 30% distance from target or 5 seconds after being fired disappear and a number of smaller war heads would be created instead. If spring has this already, wow I havn't seen it :/

Chemical clouds and similar:

Again something from CCTS. Some weapons would leave a cloud that would float around randomly/slowly damaging anything that touches it and would eventually fade. I love the idea of this. Imagine a kind of no man's zone between two sides with deadly gas clouds floating around. This might seem hard to implement, but then it might not be. Partly it could use some of the features used for a flame thrower. Perhaps a new weapons movement class would need to be written though for one that moves around randomly. On a similar not it would also be interesting if there were weapons that could acidify water. Might be achievable via LUA?

Pre base setup:

Similar to the ceasefire in a box suggestion. It would be cool if there was a mode that you could turn on for starting so that as well as placing your start point you would also be able to place the starting resources worth or either buildings or units inside the box. Kind of a quick start mode. The exact details could be variable. Units only? Only nuildings that the commander can build? Would work especially well with the start boxes for teams rather than allies.

1. No comment, I thought it was possible but never paid attention

2. Unnecessary. People who want to play with build times (newbs) will obey the time on a gentlemen's agreement anyway, and people who would renege (be it out of spite or any other reason) won't join the games. Perhaps that'd be a useful deterrent for that kind of person, but you only have to play a game with that person once to know that you don't want to play with them again. In any case, see also the last request.

3. lol, 1024x1024? You realize a 32x32 map (the 'reasonable' limit in Spring which works on all systems, or at least, on ATI cards with shadows enabled) is 1024 screens in area, and 1024x1024 would be over a million, right? Disregarding the need for an entirely new map format to handle that (which probably still wouldn't cut it), you'd also need some kind of supercomputer to handle enough units and all their pathing and crap to have a population density of one per square mile.

4. More reasonable, and I agree that Spring should be able to match what the SYs made TA do (that is, 5k per player). It at least needs to made more clear that the 5k limit is pooled, and not per-player. There was recent discussion about raising the limit, I think, but I don't know if it went anywhere.

5. Been requested a hojillion times before

6. Should be possible in svn at the moment with a new CEG tag

7. Has been done for a very, very long time. Try the CA deployment mutator. It's even limited to a certain area and stuff, tying in to #2 above.

Orakio wrote:Boxes for teams:

Instead of just having boxes for each ally team it could be useful to have boxes for each team instead. Ideally that would be a switch somewhere choosing which of the two the boxes are for. This would be useful for certain maps that are odd shapes/arrangements.

It would be far cleaner to just support multiple boxes for each ally team. Then you can make whatever weird shape you want for the start position.

The deployment mutator will do the last one

SM3 maps support 1024x1024 maps but they take up far too much ram to be sueful.

The problem is as your max zoom distance rises, the smaller the map seems. In an rts huge maps are huge because they take ages to scroll across which zooming foobars.

Actually I intended to make a patch for cluster weapons, or rather CEGs that emit weapon explosions. Well, intended... kinda lost interest.

Huge maps are also possible by scaling your mod down, speaking of weapon ranges, models, speed etc.

2 and 6 can be done with Lua, 7 was already done with Lua (what do you think the deployment gadget does?). Then again, 6 was done with Lua already too, how else do you think did I get those poison clouds and napalm weapons in Kernel Panic Division Zero?

Orakio wrote:
Huge map support:

I would love to be able to play one mapsthat are 1024x1024. I know this is an insane size but I think it could be achievable in the long run. Ideally there would be a slightly different map format for it, disabling height map alterations (hardness would only affect unit speed) and ground scarring. It would have a tiled height map so that it wouldn't use huge amounts of ram. The maps wouldn't be of the highest quality, it's a trade off, but would provide an element of fun. Of course everything else would be tiled similarly. I would potentially be interested in making a mapconv style program for this if devs decided to go ahead and do the game part. Pathing might be an issue. Perhaps paths could be precalculated for popular mods and included in the file, or as it uses height map tiles perhaps it could get a speed up by reusing calculations for each tile. To be honest I have no idea what exactly pathing is or does so I am guessing here. Another point to look out for is how object coordinates are handled. Tuiling can easily save memory but depending on how object locations are stored, retrieved, etc there might be a need for some considerable alterations there.

That´s what i always sayed size is what matters, forget about fun, look & Gameplaysmechanics. Size for the AA-Blobs.. i mean.. if you could choose between a beautifull Map like Tangerine/IronGauntlet or the endless new Map format of supcomander - who would choose SC ?

Insane Size is Insane.

+1 sc


jokes, id love maybe 40x40 maps..

SM3 would make larger maps FEASIBLE but not rediculously large like 1024X1024. We could actually go a huge size if SM3 were finished and in theory much faster because SM3 requires less memory for texture tiles. Just my $1 but you guys want larger maps start pulling for sm3.

easiet way to do it would be to make a version of BA with everything's size speed and range halved. Epic-BA or sth. then you can play on DSD as if its an absolutely gigantic 40x20 map!

1X1 units have superior pathing that will change things.

Ah well yes huge maps could be somewhat achieved by scaling down units. Also it should be possible to do it with little cpu usage increase or memory increase if you wrote it from scatch. I don't know how the engine currently deals with maps so it could well be unfeasable. The main idea is for things like WD. A dolphn in a bathtub isn't exactly going to reach it's full potential. A huge map would allow for planes to have more realistic speed ratios to land units. Would also make having forward bases extremely useful as well as peepers. Most of the time now, it's hard to build something like a BB or advanced radar without part of it's range exceeding the map bounds. Still perhaps 256x256 would be more reasonable. Not something I would consider the coders to get up and implement immediately, but could be something to keep in mind when working on the terrain handler. I'm not to sure how it works at the moment but if you had a terrain object that has gettilesize, getheight at, etc functions, it would facilitate for easier implementation of different map types.

As for the potential for those interesting weapons types, sounds like they are almost doable so perhaps something to suggest for the modding forum or CA.

True about ceasefire you can just have a casual agreement and rely on players to restrain themselves. Still even if players abide it's a pain to have to keep a timer of some sorts external to spring so although not essential it would be handy.

A map size at which airplanes have realistic speeds would be effing huge. A plane at mach 1 moves ~333m/s, for a 1 minute travel that'd be 20 kilometers. Tanks drive at 60-80 km/h at most, that'd be 15-20 minutes to traverse that distance. Noone wants to see such long approaches, five minutes to move across a map is already insane.

Lol, 1024 x 1024 = MMO Spring.

Unit limit. I have a different idea, unit limit by class to prevent spamage.

That's a mod-side thing, you can limit units with fbi tags or Lua.