Combatant locator.

Alright, so the way I'm identifying which character to which a packet corresponds is as follow.

I have a set that contains a pair consisting of a character locater pointer & an enet peer pointer. Now enet creates and maintains the peers which is why I only need a pointer too them. The character locator on the other hand is managed in my code. It is created when a client connects and deleted/deallocated/disposed/freed/(insert favored cleanup term) when the client disconnects. Each peer object has a void pointer which I use to store the pointer to my combatant locator.

The combatant locator contains the map and character index which allows quick access to the exact character without needed to know the exact memory location. Part of the reason for this is that combatants & maps will be in stl containers which may stuffle things around when they grow or shrink. So using an index is the safest way.

Now when a packet is recieved I create a new instance of Message which is a union I created to store packet data. It is a char[] & int[]. The reason for this is I can read the uint8 from the packet into the message and then use a set of const or enum values to pull the needed int values from the correct offset in the message. All of that of course depending on the message type which is the first int in the array. The second being the message length. The rest depends on the message type.

After the message object has been created it is added to a new sdl event object and pushed into the sdl event queue.

The question you may be asking is when does the character get created. Well the anwser is after login & character selection. The pointer to the combatant locator is still unique because only one instance of it is ever created so the pointer is unique. This allows it to act as an identifier even before the user actually selects a character to play with.

I haven't implemented it but my plan for the login sequence is as follows.

user requests login with username & password. Server validates credentials and if valid responds with a list of characters they can select. On failure they get a disconnect.

If they pass the client sends an identifier for the selected character back to the server. The server then populates the character locator which allows all future operations to be applied correctly.

So the conclusion is just that the combatant locator seems to be the best way to tie a peer to a character. Additionally I should mention that a combatant locator can also point to a monster but that isn't implemented yet. The monster class is just a stub that inherits from Combatant.


Popular posts from this blog

VK9 - Milestone8 Completed

VK9 - Milestone13 Completed

VK9 - Milestone16 Completed