hi again,

i was just thinking in my head how i might do something like this. so, your suggesting i put all commands into a queue, and then once a certain time has passed we execute the current, non redundant commands in the queue? then, as the game starts to lag, the server sends the clients the new delay for sending commands?

now, how about this instead? instead of queueing up commands, i simply just put a timer on how often a command can be executed. in fact, this is already in place. for example, i will restrict it so a player cannot click to move except once every 100 MS. basically, instead of hard-coding this 100 MS, i simply have the server send this limit.

i guess i could see this getting kind of sloppy though. (or not?)

In my suggestion, you would USUALLY locally execute the commands immediately, because the queue limit for those commands wouldn't be exhausted, and thus the commands would be sent out on the next network pulse. Only when clicking a whole lot very quickly would the command queue timer kick in and limit how often commands are executed. You could easily run network pulses 20, or even 50, times a second, where "network pulse" simply means checking if there are any queued commands, and if so, whether there's bandwidth (or command time) available to execute them. I bet no player would notice a network pulse rate of 50 (20 ms extra delay, worst case), and most probably wouldn't notice a rate of 20 (50 ms extra delay) in a 2D click-to-move-there RPG.

Actually, there are two things that go into determining whether you can execute a command: the overall network packet rate (can't send a packet if you sent one in the last X milliseconds), and the command-specific timer (gun repeat rate, etc). This would be a nice little re-usable class to write, really: it's like a priority queue with multiple inputs where inputs can have the "last wins" or "queuing" properties, and a callback to execute-and-send queued commands.


If you already have a timer limit for different commands, then using that is fine. Sending a scaler from the server for very loaded situations (i e, time scaler == 1x for loads up to 10 players, and time scaler == players/10 for more than 10 players) could make you more elastic to load, at the cost of seeming more laggy to users. The question is still how you combine commands, though, because if you walk and fire during the same 100 millisecond interval (say), you really do want to be sending those commands in the same packet. But you can't see into the future whether to delay a specific packet or not :-)

But a server with real up-link capability would be better :-)

one thing is.. RakNet automatically does bandwith throttling and packet splitting and such.. so, if the server is clogged, then everything will still run, but everything will just appear to react slower.. no? the only thing i can think of is that since the client doesnt wait for an "ack", the client's actions will appear to have no lag but everyone else might be "hopping around".

hi again,

i've run into a snag again and would like your opinion. the full system is almost implemented and im really happy how it turned out - im not doing 2 lookups, instead im storing Players with PlayerID's for their key still, even in the Map class. so, my Map class has 2 members:

std::map<PlayerID,Player*> players_on_map;
std::map<ID,Entity*> entities_on_map;

anyway, heres the problem. i wanted to use this system in my collision detection as well. as it is now, when doing coldet/reaction with a character, i loop through all characters in the game, check if they are on the same map, then do the detection / reaction. however, now, since i have already partionined the characters by map, i could just do a lookup, grab the list of Entities in the Map, and do collision / detection reaction with them.

theres a problem though. now this means i must add collision detection info to my Entity class? it already has x/y/w/h, so it really already contains all the data needed for collision detection. however, there is one major problem.

when i do collision reaction, i have a member called Is_Moving() and Stop_Moving(). i need this for doing character to character collision reaction. when 2 players (or npcs, or both) collide, i have them "meet in the middle" of their collision (if they are both moving; if one is moving, the moving guy moves to the edge of the guy who collided).

ok, so there is a few problems.

so i give Entity the Get_Rect() and Is_Moving() and Stop_Moving() members. however, here, only the Character child of Entity will use the latter 2 functions.

second, my Entity class is starting to get bloated. shouldnt i be keeping Entity nice and simple and neat? how complicated is your "Entity" class? actually, i guess its not really bloated (yet).

now, the most serious problem. what about items? items are Entity's, but they dont do collision detection / reaction. i know i could just give the Entity a bit flag saying "dont do collision detection with me".

i dont know though, these solutions just seem a little different then how i've done things before. im not exactly an expert C++ programmer, so i dont exactly trust my instincts just yet. in 6 months i might be either kicking myself or praising myself, and i'd rather not wait 6 months to find out when i could just ask someone whos smarter then me [smile].

lastly, there is one alternative to all this, that would actually fix all of these problems. instead of moving collision detection information into my Entity class, i simply give my Map class 2 more members:

std::map<ID,Projectile*> projectiles_on_map;
std::map<ID,Character *> characters_on_map;

now, when i wnat to do collision detection, i dont grab the entities_on_map lookup table, instead, i grab either the projectiles or characters on the map. then collision detection stuff can stay in these classes. i personally think this is much cleaner and nicer (and easier!), however, im worried that all those inserts and removals might screw me. what do you think?

ps, sorry if my post is hard to read, my thoughts are scattered right now

[Edited by - graveyard filla on January 2, 2005 3:31:47 PM]

"Entity" often gets quite bloated. You could consider making a "MovingEntity" separate from "entity" and keep a list of only moving entities for collision detection. Or you could keep a separate hash grid, or quad tree, of only the moving entities -- no matter whether they are subclassed or not; this would accelerate collision queries quite probably.

The only way to make Entity not be bloated, is to support QueryInterface() on Entity, so that you can ask it for other sets of properties dynamically. I e, perhaps entity only has x/y/w/h, and you QueryInterface for IMovingEntity, which returns NULL if it's not a moving entity.