12.05.06 the cold is a little bit better but it still hurts. we just had egg big icerain here for 5 minutes i never saw such a thing bevore. well back to the game. apart from some code cleaning i thought all day long how to achieve a good entity handling then it came to my mind.
my game should not be able to allow players to join later. i totally forgot that in awe about a6 multiplayerprogramming

so what i plan now is the following. the external serverbrowser assigns each player a playernumber already. it then passes it via the -d command to the engine. the host will generate a unique number for the game he starts and assign it too with -d.

at gamestart each client sends his unique game number to the host and checks if its right. this way only players wich where in the same lobby can be in the same game.

now for the entity handling:

first thing i do is create an entity for each player with ent_create that allows the player to disconnect. this entity is placed 1000 quants under the level and is just there to handle the disconnect AND it stores the playernumber assigned by the external starter.

the next thing iam gonna do is, that i browse through all entites and check for the player numbers at the server. so at the server i create pointers for the server with the names: thisisclient1, thisisclient2... so that iam able to use send_var_to directly to them saving bandwith.
again, i browse through the entitys wich where created with ent_create and assign pointers to them because they exist both on the server and client and are just there to handle disconnects and store the playernumber. those entities have .nosend flag set.

then i only work with local entites from now on.

i create 10 local entities for each client with the pointers host, client1, client2...client9
the same for the host, he also gets this host, client1, client2...client9.


each of those entities has a different function. i hope you could follow

now image the following. the client with clientnumber 1 clicks his local entity2. because this is obviously not his own entity he sends a variable request_health_player2 with his player number set. the host then sends the health of player2 to player 1 who requested it by clicking on his local entity for player2.
the same for movement. imagine the client with number 1 clicks his local client1 entity. because of his playernumber 1 he knows this is his entity. now when he clicked the entity he can click somewhere else and this sends the vector client1_wants_to_move_there[3] to the server.
the server then moves his own local entity client1 with c_move, sending back the position client1_is_at[3] 4 times a second. (later ill add sending only to those who can see client1.


i think this is the best system for my kind of game. everything is done by sending variables triggered by local entites back and forth. game logic is kept completely at the host while clients can only make requests and the host then checks if this is possible or not sending results back to clients.


this is contrary to locoweeds system wich was more dynamic but i dont need the ability for players to join and leave as they want because the game is like a soccer game it goes for ~60 minutes average and you level up during that time. so late joined players wont have a chance anyway. only those who join with the right gameid assigned by the serverbrowser will be able to join and pick a race to play with.

because iam not feeling very fresh in my mind right now i postpone the coding to tomorrow probably doing some other designwork for the game right now.

from cleaning up my code i learned, that its better to comment right away when writing. and deleting unused variables as soon as you realize you dont need it. doing this afterwards is just plain boring work.

well i hope there are no flaws in my system and its possible to manage everything from inventory to fighting and so on in my game. if you dont understand a thing just dare to ask or if you find a logical problem please let me know. thanks!