Spring RTS Engine

Hello everyone!
I am making a game, the project is currently called Total Continuity.
We can discuss it here if you are interested : )

Progress video:
Demo (July)
Demo (Short, Early November)
Demo (Short, November (2))

Looks like your url tags weren't filled in correctly

Thanks!

thought it was ok, op
fixed

I like it, it looks very slick and polished. I only question using the ZK emp sound to indicate that a construction has started as I don't think that sound fits.

Thanks!
Yea, should be different sound, however the mismatch is amplified by the fact that vfx and sfx are not synchronized
(Needs tweak to make nano instant)
Biggest part of sound environment shall be ambient sounds. Continuing nano spray will have sound, same are robot movement and trucks upon acceleration.
Yea, this is significant portion of work in future And interesting

looks really good.

Yes it does, units have how many Polys? Texture resolution? How many units per fps? How does animationscripting work?

Models being used are about 1500-1700 faces. They are made by Mr Bob, Beherith, FireStorm, Cremuss and Kaiser, all included in BA:R distribution.
I will make new models when I finish basic stuff, at least some of them myself to establish style (there shall be 2 playable races), polycount will be about the same, except for big ("Experimental") robots. Yea, making those will take time. But gonna be fun.
Current texture is 1024 iirc.
Unit count - a lot, but it will depend on how extensively I use LUA. I intend to keep number on hundreds. Well, the general scale should be comparable to SupCom, with huge maps thus lots of units. Units are generally much faster, so big maps feel like medium sized.
All animations I do with COB, afaik it works faster than LUA. (I don't have COB-LUA interaction often)
Most problems I have occured are related to pathing. Units sometimes move jumpy, and pathfinding is especially not good on some maps, can't rely on it. That's on engine side, but not critical though.

As strange as it might seem, but most of dev time is being spent not on coding, or, I predict even modelling, but on designing those units, figuring out which unit functions there should be, and what playable races. Despite how challenging might be all visual stuff, this one looks the hardest.
It's like there is always a way to make things easy and there is a complicated way to make things more interesting.

COB won't be appreciably faster than lua

In follow up to that; Where did you receive the implication that it was?

Also LUS allows much greater flexibility for integration with luarules gadgets (i.e. game logic).

Solid Majority is still using cob though..

Also if you are good at cobol, you get well paid legacy jobs at banks.

I would say that BOS/COB has more examples to work from, as any given project probably has hundreds of scripts to look through. However, lus is objectively better and easier to use in a lot of ways.

The fact that you can reload your script with luarules reload is pretty much unbeatable for convenience. Supposedly reloadcob works too though.

In the interest of completeness, note that compared to the Lua VM Spring's COB interpreter does not perform (as much or at all):

• memory allocation
• garbage collection
• hashtable indexing
• stack management (COB copies a few ints per function call)
• pointer chasing

While not an endorsement to use COB, for unit-script code the overhead of these operations is sadly *quite* appreciable in large numbers and should always be kept in mind.

That's actually really interesting. What sort of ballpark amount would = "Large Numbers"? Are we talking 100s or 1000s or somewhere inbetween?

I agree, difference might be not big, cob or lua. I shall run tests on it.

FLOZi wrote: ↑27 Jul 2019, 18:54 In follow up to that; Where did you receive the implication that it was?

Presumably, because it is compiled and designed to work on much slower PCs.
And there is statement on Wiki,

Unless you already have lots of complex unit scripts by porting TA content, Lua is always better

Implies, COB is (maybe only slightly) faster.
About Spring interpreter:

This interpreter runs in a very straightforward way, without any fancy optimizations, so don't expect great performance from it

Means it can be improved.
I overall like COB, I think such kind of stuff should be compiled and optimized. Whether it is optimized or not, it >can< be done on engine side.
(Was written before I read Kloot's post)

Forboding Angel wrote: ↑29 Jul 2019, 01:21 That's actually really interesting. What sort of ballpark amount would = "Large Numbers"? Are we talking 100s or 1000s or somewhere inbetween?

Well, 1000 units would not be bad, more - even better. As comparable to SupCom, it has to be around that.
It kinda works for BA where is little LUA overhead. Most lag is due to T1 spam, mainly because they constantly send Fleas/AK to scout and counter units with high reload time, and also lots of nanos/windgens. So, this is game design-related.
Take SupCom, there is smoother transition into T2 thus no need to spam T1 economy, and T3-T1 difference is huge (which I don't really like, but this is a solution nonetheless).

Yea, hardest is to keep unit count moderate (not much above 1000) while all units are viable.

Not really. Evo uses army supply to make a Max mobile unit ceiling while not restricting buildings. Food count is a great way to stop snowballing. It's one of the things the starcraft does well (although sc snowballing happens anyway because blizzard is shit at balance, i.e. "if we make every unit overpowered then it will be balanced!!!”) a.k.a. r/therewasanattempt.

My question was directed at kloot though.

DmitryProfessional wrote: ↑29 Jul 2019, 08:36

Unless you already have lots of complex unit scripts by porting TA content, Lua is always better

Implies, COB is (maybe only slightly) faster.

I find that it implies (not even, as it directly states) the opposite. Anyway I stand by the suggestion that lua is preferable unless you are porting old content until I see hard numbers otherwise.

FWIW, coming from one of the few projects where (nearly?) all cob scripts were rewritten in lua I didn't see any appreciable difference even in large games.

Cue ThinkSome telling me I was never in any large S44 games.


@kloot; Is there any significant advantage in multiple unitdefs running the same script? In either cob or lua.

FLOZi wrote: ↑30 Jul 2019, 18:13 @kloot; Is there any significant advantage in multiple unitdefs running the same script? In either cob or lua.

In both COB and lua, performance-wise probably not a lot (might save a few cache-misses if you're lucky).
Development-wise probably yes.

Hello!
Short video of current progress here:
Click
: )