Mycal
Staff member
Rather than make any real progress with the bridge crap, I for some reason started working on the server and client connections. I honestly have no idea why I started working on that but I did. One thing working with Odyssey, Mirage, and our very own sourcecode has taught me, socket connections suck if you don't set it up properly from the start. First point, I absolutely hated having index based sockets in every iteration of code I've ever seen, so I threw that concept out. Second point, I also hate having text based packets so I threw that out. Finally, I hate winsock, though that has no real meaning, just wanted to state that fact. I'm sure System.Net.Sockets uses Winsock, but it sure makes it a lot easier to work with at the very least.
Rather than use any kind of index based socket connections, our server will instead be a collection of sockets. Each socket will handle it's own packet communications separately. So how do we differentiate between the different sockets? Simple. We assign a unique id to each socket (using GUID not an incremental index just to be clear
). These ids will always be random and never be assigned to the same person twice (in theory). Next, any and all communication is encrypted with a unique key per user. Basically, we use a combination of a public key and session keys for encryption. I'll leave it at that so as not to give away how to decrypt packets. As far as I can tell, the encryption happens fairly fast so there is no worries about it slowing down too much in a real world application.
Finally, I started work on some of the backend storage for maps. For client-side caching (and possibly server side as well) we'll be going with a SQLite database. I honestly am beginning to hate SQL because of how dynamic everything is. Rather than maps just occupying rows in one table, I have been forced to move maps into many rows across 6 different tables. Because we have no idea how many actual tiles there will be on a map and we can't make an assumption based on the size since it is dynamic as well (and changeable at any time) tiles had to be moved to a separate table. Tile based animations also have to be moved to a separate table, as well as layers on a tile, and so on and so on. Man, maps are gonna be a gigantic pain to send to clients.
So where are we right now? Let's take a look.
BSGame.Core.* finished? Check
BSGame.Drawing.* finished? As much as we need right now
BSGame.Database.* finished? No MySQL yet, but SQLite is working fine
BSGame.Network.* finished? Check
Looks like the BSGame library is getting pretty feature complete. As for the actual game stuff.
Client is looking pretty good. It has all drawing routines already setup but still needs network connections. It also has scripting support and is running pretty much flawless (though still need to figure out why passing parameters sometimes doesn't work on new scripts). After network connections are finished, I'll port this over as Odyssey's new client shell.
Server is looking really good. It does basically nothing but parrot packets, but it handles all connections properly. It is multi-threaded so it should work fairly well when we add some real functionality to it. This is already ready to port off as Odyssey's server.
World Editor is a whole other story. This is the project I dread working on the most. No matter how much I work on it, it never seems to be easy to expand on at later dates. That and all the extra functionality that I want to add to it seems so daunting because of the large amount of work it still needs. I think I need to create a thread in the Odyssey subforums about this, but I'm thinking to speed up work on the conversion, I may fork this off and make it Odyssey's temporary editor for everything as well. The only thing wrong with this is how to connect it to a server. For a single game, it is easy since I can have it directly connect to the database and edit in that way (with offline support so you can create maps without internet), but for Odyssey, it can connect to any server. Maybe it should directly connect to the server and act like a client..Yeah I think that'll work.
Ok, off to Odyssey forums to create a thread about some changes that I'll propose.
Rather than use any kind of index based socket connections, our server will instead be a collection of sockets. Each socket will handle it's own packet communications separately. So how do we differentiate between the different sockets? Simple. We assign a unique id to each socket (using GUID not an incremental index just to be clear
). These ids will always be random and never be assigned to the same person twice (in theory). Next, any and all communication is encrypted with a unique key per user. Basically, we use a combination of a public key and session keys for encryption. I'll leave it at that so as not to give away how to decrypt packets. As far as I can tell, the encryption happens fairly fast so there is no worries about it slowing down too much in a real world application.Finally, I started work on some of the backend storage for maps. For client-side caching (and possibly server side as well) we'll be going with a SQLite database. I honestly am beginning to hate SQL because of how dynamic everything is. Rather than maps just occupying rows in one table, I have been forced to move maps into many rows across 6 different tables. Because we have no idea how many actual tiles there will be on a map and we can't make an assumption based on the size since it is dynamic as well (and changeable at any time) tiles had to be moved to a separate table. Tile based animations also have to be moved to a separate table, as well as layers on a tile, and so on and so on. Man, maps are gonna be a gigantic pain to send to clients.
So where are we right now? Let's take a look.
BSGame.Core.* finished? Check
BSGame.Drawing.* finished? As much as we need right now
BSGame.Database.* finished? No MySQL yet, but SQLite is working fine
BSGame.Network.* finished? Check
Looks like the BSGame library is getting pretty feature complete. As for the actual game stuff.
Client is looking pretty good. It has all drawing routines already setup but still needs network connections. It also has scripting support and is running pretty much flawless (though still need to figure out why passing parameters sometimes doesn't work on new scripts). After network connections are finished, I'll port this over as Odyssey's new client shell.
Server is looking really good. It does basically nothing but parrot packets, but it handles all connections properly. It is multi-threaded so it should work fairly well when we add some real functionality to it. This is already ready to port off as Odyssey's server.
World Editor is a whole other story. This is the project I dread working on the most. No matter how much I work on it, it never seems to be easy to expand on at later dates. That and all the extra functionality that I want to add to it seems so daunting because of the large amount of work it still needs. I think I need to create a thread in the Odyssey subforums about this, but I'm thinking to speed up work on the conversion, I may fork this off and make it Odyssey's temporary editor for everything as well. The only thing wrong with this is how to connect it to a server. For a single game, it is easy since I can have it directly connect to the database and edit in that way (with offline support so you can create maps without internet), but for Odyssey, it can connect to any server. Maybe it should directly connect to the server and act like a client..Yeah I think that'll work.
Ok, off to Odyssey forums to create a thread about some changes that I'll propose.