1 |
[quote]In gadget code all you'd have to do really is copy every unit/projectile/etc's position, velocity, etc in a table then load it from there.[/quote]That is just saving and loading, that is not the problem. But is not enought.
|
1 |
[quote]In gadget code all you'd have to do really is copy every unit/projectile/etc's position, velocity, etc in a table then load it from there.[/quote]That is just saving and loading, that is not the problem. But is not enought.
|
2 |
In "your time" a unit might be [i]that[/i] position.
|
2 |
In "your time" a unit might be [i]that[/i] position.
|
3 |
In "my time" a unit might be [i]this[/i] position. Or maybe the unit does not exist yet/anymore.
|
3 |
In "my time" a unit might be [i]this[/i] position. Or maybe the unit does not exist yet/anymore.
|
4 |
That is not possible with spring. The same goes for projectiles and everything else.
|
4 |
That is not possible with spring. The same goes for projectiles and everything else.
|
5 |
Imo there are three options and all suck:
|
5 |
Imo there are three options and all suck:
|
6 |
1) The "Lets' use spring but actually not use it" option.
|
6 |
1) The "Lets' use spring but actually not use it" option.
|
7 |
Only use spring for rendering, do not use any of its physics, do not use the command system, use it only for rendering things.
|
7 |
Only use spring for rendering, do not use any of its physics, do not use the command system, use it only for rendering things.
|
8 |
Aka the technically correct answer to every problem ever. Sadly it is so theoretical that it is useless.
|
8 |
Aka the technically correct answer to every problem ever. Sadly it is so theoretical that it is useless.
|
9 |
2) Use multiple instances of spring that talk to each other. This allows different time-zones to be alive at same time.
|
9 |
2) Use multiple instances of spring that talk to each other. This allows different time-zones to be alive at same time.
|
10 |
This
is
maybe
doable
but
cumbersome.
|
10 |
This
is
maybe
doable
if
spring
gets
some
function
to
spawn
new
instances
(
like
~happend
when
spring.
restart
was
bugged)
but
cumbersome.
|
11 |
3) Divide the map into several identical areas. Each area is a different time-zone and stuff gets copied around and blabla and each player only sees his area.
|
11 |
3) Divide the map into several identical areas. Each area is a different time-zone and stuff gets copied around and blabla and each player only sees his area.
|
12 |
\n
|
12 |
\n
|
13 |
None of that seems like a good idea.
|
13 |
None of that seems like a good idea.
|
14 |
\n
|
14 |
\n
|
15 |
@Shadowfury333 : Do you have a source/link for that?
|
15 |
@Shadowfury333 : Do you have a source/link for that?
|
16 |
It reads as if they had to optimize everything to make it work with realistic hardware requirements. That seems bit strange.
|
16 |
It reads as if they had to optimize everything to make it work with realistic hardware requirements. That seems bit strange.
|
17 |
Achron uses 1 GB ram or so, that includes everything: models, textures, sounds, map etc.
|
17 |
Achron uses 1 GB ram or so, that includes everything: models, textures, sounds, map etc.
|
18 |
It seems strange that they would optimize to a level of only using 8 bits to store units health and could not fit other properties.
|
18 |
It seems strange that they would optimize to a level of only using 8 bits to store units health and could not fit other properties.
|
19 |
If health and coordinates of a units can be stored then what prevents storing other properties?
|
19 |
If health and coordinates of a units can be stored then what prevents storing other properties?
|
20 |
A few more variables per unit is only a few more bytes, even multiplied by 100 units and even storing it for every single frame (say in a 45min game) would only mean a handful more MB.
|
20 |
A few more variables per unit is only a few more bytes, even multiplied by 100 units and even storing it for every single frame (say in a 45min game) would only mean a handful more MB.
|