Total Continuity
Moderator: Moderators
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Total Continuity
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))
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))
Last edited by DmitryProfessional on 11 Nov 2019, 21:23, edited 5 times in total.
Re: Total Continuity
Looks like your url tags weren't filled in correctly
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Re: Total Continuity
thought it was ok, op
fixed
fixed
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Total Continuity
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.
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Re: Total Continuity
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
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
Re: Total Continuity
Yes it does, units have how many Polys? Texture resolution? How many units per fps? How does animationscripting work?
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Re: Total Continuity
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.
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.
Re: Total Continuity
COB won't be appreciably faster than lua
Re: Total Continuity
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).
Also LUS allows much greater flexibility for integration with luarules gadgets (i.e. game logic).
Re: Total Continuity
Solid Majority is still using cob though..
Also if you are good at cobol, you get well paid legacy jobs at banks.
Also if you are good at cobol, you get well paid legacy jobs at banks.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Total Continuity
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.
The fact that you can reload your script with luarules reload is pretty much unbeatable for convenience. Supposedly reloadcob works too though.
Re: Total Continuity
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
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Total Continuity
That's actually really interesting. What sort of ballpark amount would = "Large Numbers"? Are we talking 100s or 1000s or somewhere inbetween?
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Re: Total Continuity
I agree, difference might be not big, cob or lua. I shall run tests on it.
And there is statement on Wiki,
About Spring interpreter:
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)
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.
Presumably, because it is compiled and designed to work on much slower PCs.
And there is statement on Wiki,
Implies, COB is (maybe only slightly) faster.Unless you already have lots of complex unit scripts by porting TA content, Lua is always better
About Spring interpreter:
Means it can be improved.This interpreter runs in a very straightforward way, without any fancy optimizations, so don't expect great performance from it
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)
Well, 1000 units would not be bad, more - even better. As comparable to SupCom, it has to be around that.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?
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.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Total Continuity
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.
My question was directed at kloot though.
Re: Total Continuity
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.DmitryProfessional wrote: ↑29 Jul 2019, 08:36Implies, COB is (maybe only slightly) faster.Unless you already have lots of complex unit scripts by porting TA content, Lua is always better
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.
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06