Mycal
Staff member
Boy I hope no one ever looks at this code. It's a mess 
. I spent the last few weeks refactoring a lot of code, but I think I may have made it even messier. I'm doing things very weird in some places, but they make perfect sense for their purpose.
This post may be a little more technical than most of my other ones.
The VB6 project of Ody, is not object oriented. There are a lot of user defined types and global variables. In doing this port, I've found myself rewriting nearly every aspect of this game. I've also made use of a lot of BSGame libraries from the ORPG that I was developing before this. Additionally, a lot of code is shared between server and client, so rather than duplicate code, I've created a Core class library for Ody called Odyssey.Core. This is basically where the world lives. It also handles loading/saving from the new database. The database makes use of the Entity Framework port for Mono. We use Lidgren for networking, MonoGame for graphics, custom UI library for, well the game UI, and there are many other BSGameLib helper libraries that all are required for some function. This is a lot of dependencies.
This week, I've been mainly working on refactoring and cleaning up some of the Entity Framework related code (which has been a blast, by the way; this is some really neat stuff) and I now have a very weird loader dependency. I have a loader that lives in Odyssey.Core that essentially, you pass it the connection string or database context and it will load whatever you want. It also serializes the data into a more sane class object (this could probably actually be rewritten more simply, but I really like how verbose it is right now). I then have a World object which holds all of the Guilds, Halls, Maps, Monsters, Npcs, Bans, Players, Scripts, etc. This world object does nothing on its own. However on the server, there is yet another world object that inherits this one. It creates a context and loads all data (minus players) on initialization. It also handles saving any changes to those objects. But it doesn't stop there. I also have a server loader which loads the config file, which loads the world, creates the server socket, and loads "extra" stuff (that I'll get into in a later post).
I have lots of loaders...Coincidentally, saving is rather simple. Loading an object is much harder than saving it. Player.save(context).
It's kind of weird seeing everything come together piece by piece. I'm far past my internal deadline, but I've made a lot of progress for a one man show coding only in my free time. I should really start posting screenshots with these posts.
As a side note, I rewrote the lighting engine that was in BSGameLib to be compatible with Odyssey (that currently uses no camera), but it won't be in the first version. This will require changes to the Map data structure that I don't really feel like messing with at the moment. I am storing lights separate from the map, but the map light level is currently non-existent. It currently only has an Always Dark flag. There needs to be a separate darkness level setting per map as well.
. I spent the last few weeks refactoring a lot of code, but I think I may have made it even messier. I'm doing things very weird in some places, but they make perfect sense for their purpose.This post may be a little more technical than most of my other ones.
The VB6 project of Ody, is not object oriented. There are a lot of user defined types and global variables. In doing this port, I've found myself rewriting nearly every aspect of this game. I've also made use of a lot of BSGame libraries from the ORPG that I was developing before this. Additionally, a lot of code is shared between server and client, so rather than duplicate code, I've created a Core class library for Ody called Odyssey.Core. This is basically where the world lives. It also handles loading/saving from the new database. The database makes use of the Entity Framework port for Mono. We use Lidgren for networking, MonoGame for graphics, custom UI library for, well the game UI, and there are many other BSGameLib helper libraries that all are required for some function. This is a lot of dependencies.
This week, I've been mainly working on refactoring and cleaning up some of the Entity Framework related code (which has been a blast, by the way; this is some really neat stuff) and I now have a very weird loader dependency. I have a loader that lives in Odyssey.Core that essentially, you pass it the connection string or database context and it will load whatever you want. It also serializes the data into a more sane class object (this could probably actually be rewritten more simply, but I really like how verbose it is right now). I then have a World object which holds all of the Guilds, Halls, Maps, Monsters, Npcs, Bans, Players, Scripts, etc. This world object does nothing on its own. However on the server, there is yet another world object that inherits this one. It creates a context and loads all data (minus players) on initialization. It also handles saving any changes to those objects. But it doesn't stop there. I also have a server loader which loads the config file, which loads the world, creates the server socket, and loads "extra" stuff (that I'll get into in a later post).
I have lots of loaders...Coincidentally, saving is rather simple. Loading an object is much harder than saving it. Player.save(context).
It's kind of weird seeing everything come together piece by piece. I'm far past my internal deadline, but I've made a lot of progress for a one man show coding only in my free time. I should really start posting screenshots with these posts.
As a side note, I rewrote the lighting engine that was in BSGameLib to be compatible with Odyssey (that currently uses no camera), but it won't be in the first version. This will require changes to the Map data structure that I don't really feel like messing with at the moment. I am storing lights separate from the map, but the map light level is currently non-existent. It currently only has an Always Dark flag. There needs to be a separate darkness level setting per map as well.