Loading...
  OR  Zero-K Name:    Password:   

Forum index  > News   >

Cold Take #6 - Physics vs. Formulas

5 posts, 958 views
Post comment
Filter:    Player:  
sort


5 months ago
Shots in Zero-K are physically simulated, they hit everything that gets in their way, but how are the results so deep that the whole game can be designed without damage bonuses?

Read it here: https://store.steampowered.com/news/app/334920/view/3958168875487633267
+10 / -0
5 months ago
Suggestion (if easy to change). The first figure should add to the title the fact that this is a fight between "6 glaives and 2 reavers. " (and maybe have the title on top). Like this at first I thought the 6 rows with "Ally Glaive" were one glaive - and it did not make much sense, then I realize there were 6 different glaives. Alternatively put some "id" like "Ally Glaive A", "Ally Glaive B", etc,
+1 / -0

4 months ago
quote:
This is not new, every RTS has physics, and without it they would essentially be spreadsheets. Physics is fundamentally what gives players any reason to care where anything is. Every game with time, space, and simple rules linking them together has some sort of physics.


Spreadsheets run pretty fast. What would happen if an RTS game was designed from the ground up to essentially be a spreadsheet. Pretty much can probably run most of it from a database engine such as hsqldb because they they do everything spreadsheets does.
+0 / -0

4 months ago
The whole point of a database engine is to store files on disk, which will undoubtedly be slower than running something on ram even if you use a modern ssd. Additionally, there's many features of a Database Engine that work counter to the kind of efficient access for 30 simulation frames a second. A natively compiled C++ engine like springrecoil should have a faster possible runtime than a JVM based app like hsqldb.

It's possible that an engine written to preform like springrecoil could be built differently. I know that there have been many changes to CPU cache size, parallelized operations, and vector operations in the past 20 years, and it's possible that close scrutinization of algorithms could lead to a more efficient engine. For example, what if all entity positions were stored in a matrix, and gravity specific to every entity was stored in a second matrix, could this make gravity calculations faster? This would require a memory architecture where unit's positions and speeds may be stored separately from other data such as colision volumes, and does this separation lead to slower performance for other operations? This is all putting the cart ahead of the horse, because I do not know how the engine currently stores this data.

Also, as far as I am concerned, compiler optimization is black magic, and x86 asm is black magic. Additionally, a "re-write" of the engine would mean having to re-engineer all the things that are necessary, like widget integration and pathfinding. I always know gf mentions pathfinding as a good reason to use springrecoil.
+0 / -0
quote:
Spreadsheets run pretty fast. What would happen if an RTS game was designed from the ground up to essentially be a spreadsheet.

Ultimate Battle Simulator perhaps? Games that boast a massive unit count must have pretty simple behaviour for each unit.
+0 / -0