I am beginning to consider a move back to a pure Java implementation, as the discussion seems to be moving more towards a solution that would be better serviced by an object-oriented design. Although C++ would also fulfill this, I hate working with C++ and have vowed never to touch it (however, I am in love with C).
Anyways, it seems that we may have some in-game communications issues that we need to satisfy. One of these comes into play with the CLI communicating with the core, in order to get a list of what the player can see so that sense can be made of what the user typed.
Internally on the core engine side, everything within the game will be an object. Objects will all have certain flags that can be set, and every object will have a (hopefully) unique ID. This ID will be a message digest of some random string, generated using the MD5 algorithm. This algorithm provides a digest ID that is 16 bytes long.
This ID will be preceeded by a 1-byte (char) type ID, which will provide a quick way to determine what type of object any particular ID belongs to. These type IDs will include "p" for player, "c" for character (any player can register multiple characters), "n" for NPC, "m" for monster, and "o" for object (an object is anything that is not one of the other types).
In theory, every type o object will have points, the same as every character. These points will represent various attributes, such as how much damage it can inflict when used as a weapon, how much damage it can absorb when used as a shield, and the HP for the object.
The way I'm thinking, is that when the CLI queries the engine for a list of what a particular user can see, the engine will return a list of IDs. Perhaps another engine will run an ID query engine, allowing the CLI (or the core engine) to get information on any particular ID.
As for how the IDs are returned from the core engine, I think an array of arrays will do. Each ID will be 33 characters long. Something would have to be inlcluded so that the CLI would know where the ID list ends.
Another option would be a linked list. The advantage of this is that the linked list naturally has information about where it ends, and it can be spread across memory. Also, each element of the list could be free'd after it is analyzed. With an array, the memory can't be free'd until the entire list has been processed, and then the entire array is free'd. Also, with the linked list, each element is also malloc'd individually, whereas with the array, the entire space is malloc'd at one.
Hmm... lots of questions. Dan, perhaps you know some performance issues on this? We are pretty much facing either
char **getVisisibleIDList(char *playerID);
or
#define ID_32 char *
struct IDList {
IDList *prev;
IDList *next;
ID_32 ID;
};
IDList getVisisibleIDList(ID_32 playerID);
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am beginning to consider a move back to a pure Java implementation, as the discussion seems to be moving more towards a solution that would be better serviced by an object-oriented design. Although C++ would also fulfill this, I hate working with C++ and have vowed never to touch it (however, I am in love with C).
Anyways, it seems that we may have some in-game communications issues that we need to satisfy. One of these comes into play with the CLI communicating with the core, in order to get a list of what the player can see so that sense can be made of what the user typed.
Internally on the core engine side, everything within the game will be an object. Objects will all have certain flags that can be set, and every object will have a (hopefully) unique ID. This ID will be a message digest of some random string, generated using the MD5 algorithm. This algorithm provides a digest ID that is 16 bytes long.
This ID will be preceeded by a 1-byte (char) type ID, which will provide a quick way to determine what type of object any particular ID belongs to. These type IDs will include "p" for player, "c" for character (any player can register multiple characters), "n" for NPC, "m" for monster, and "o" for object (an object is anything that is not one of the other types).
In theory, every type o object will have points, the same as every character. These points will represent various attributes, such as how much damage it can inflict when used as a weapon, how much damage it can absorb when used as a shield, and the HP for the object.
The way I'm thinking, is that when the CLI queries the engine for a list of what a particular user can see, the engine will return a list of IDs. Perhaps another engine will run an ID query engine, allowing the CLI (or the core engine) to get information on any particular ID.
As for how the IDs are returned from the core engine, I think an array of arrays will do. Each ID will be 33 characters long. Something would have to be inlcluded so that the CLI would know where the ID list ends.
Another option would be a linked list. The advantage of this is that the linked list naturally has information about where it ends, and it can be spread across memory. Also, each element of the list could be free'd after it is analyzed. With an array, the memory can't be free'd until the entire list has been processed, and then the entire array is free'd. Also, with the linked list, each element is also malloc'd individually, whereas with the array, the entire space is malloc'd at one.
Hmm... lots of questions. Dan, perhaps you know some performance issues on this? We are pretty much facing either
char **getVisisibleIDList(char *playerID);
or
#define ID_32 char *
struct IDList {
IDList *prev;
IDList *next;
ID_32 ID;
};
IDList getVisisibleIDList(ID_32 playerID);