diff options
author | rodri <rgl@antares-labs.eu> | 2021-07-29 14:56:10 +0000 |
---|---|---|
committer | rodri <rgl@antares-labs.eu> | 2021-07-29 14:56:10 +0000 |
commit | 3241d4b8c80f9424a3f725b5905def22916fc854 (patch) | |
tree | 2240ce49ee442db534161f8cf4de1640e3dd0408 /notes | |
parent | 9942eb201a657640cf244b261008b850352a29f3 (diff) | |
download | musw-3241d4b8c80f9424a3f725b5905def22916fc854.tar.gz musw-3241d4b8c80f9424a3f725b5905def22916fc854.tar.bz2 musw-3241d4b8c80f9424a3f725b5905def22916fc854.zip |
made the client window size immutable.
added some dev notes to a file.
renamed Lobby.healthcheck to Lobby.purge, which makes more sense.
Diffstat (limited to 'notes')
-rw-r--r-- | notes | 17 |
1 files changed, 17 insertions, 0 deletions
@@ -0,0 +1,17 @@ +• there's, at most, two players waiting in the lobby at a given time. +it makes no sense to allocate more than two seats since the threadsim +will consume them whenever they are ready to join the party. i'm +thinking of using channels to synchronize the two threads, so +threadsim doesn't loop doing nothing (but sleeping) until at least a +couple of players join. + +• the integrator has to operate with vectors and the different objects +in the universe, some of which may require their own governing laws. + +• think of a way to pack the bullets efficiently. will they be part +of the global state broadcast? what does the client need to know to +render and manage them? + +• it could be beneficial to do dynamics in the client as well, which +means sending more data, and probably require a tighter sync, but a +smoother user experience. |