Cold Take #6 - Physics vs. Formulas

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,

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.