by date
MMORPG Contest - Week 5
MMORPG Contest - Week 5
| Name: | Tony Richards | ![]() |
|---|---|---|
| Date Posted: | Dec 06, 2006 | |
| Rating: | 4.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: | or Subscribe with . | |
| Profile Page: | View profile page for Tony Richards |
Blog post
Programming, programming, programming.
I've handed off to two other team members the Login GUI and the Advanced Camera and I don't have a status update from them yet, so hopefully they're done or close to being done.
At any rate, tons of programming completed on my part this weekend.
Database Integration
I completely re-did the MySQL database integration so that it works by two queues: A request queue and the response queue. For the response queue, I used the existing game queue so all responses get processed by the main game thread. The request queue is sort of like the game queue, except it has a condition variable associated with it so the database thread can wait until the queue isn't empty. That makes it so it doesn't have to continually poll.
So, the main implementation outside of the two queues is simple. A database thread is started at dedicated game server startup. When the game engine (or anything else) requires data from the database, a specialized event requrest (for instance, a LoginRequest) is created and put onto the database Request Queue. The database thread wakes up, looks at the request event, executes the appropriate database query, then creates the response event (i.e. LoginReponse) and puts it on the main game event queue.
When the game engine gets around to it, the response event is handled appropriately.
This implementation makes it so that database requests do not slow down the main game thread. It forces us to use an event model for everything else, but that's not really a bad thing. The AI manager will be re-written in the next few days to use this new event model.
Login Server
The login server was re-written so that it's not longer in script and it uses the new database interface. It also now uses the new event driven model.
The Login Server has also been expanded with support for dual redundancy, allowing one server to be down and using the other as a backup. If I have time I'll eventually create a load-balancing mechanism (implemented on the client side) to help balance loads.
"Why would a login server require load balancing?" you might ask. Well, the Login Server has been re-tasked to encompass several new tasks.
It's now also the primary database server. Instead of having database requests routed through the zone servers, all database requests are now sent to the login server from the client, processed, then returned to the client.
I eventually plan on making a cache system on the client's machine to reduce the load of the database server.
What's the advantage of doing it this way?
As you know, Artwork / other content can be updated by downloading patches.
Quests, items, player levels, NPC' conversations, etc will be updated on the fly in the dev environment, and this method of having a database server will allow the clients to immediately get these updates without having to create / download / apply a new patch. This will save a tremendous amount of development time.
All of the data-driven content can be updated either in-game or via our web interface (depending on the type of data) and immediately applied to the game, even with multiple designers. In-game editing isn't finished yet, but the web interface is complete. When it's all said and done, our myriad of game designers will be able to hop in the game simultaneously, chat about features, drop in NPC's, edit NPC dialogs, add quests, then form up a team and play-test it right then and there.
Future Stuff
Chat Server - Same basic implementation as the Login Server, except without primary / secondary servers.
NPC Dialogs, Quests, etc - The database design is finished. We just have to add the HUD for displaying and editing the information in-game. Editing will be lower priority because we can already edit the data using our web interface.
The rest of the coding - We've got some minor things to finish up. Most of everything else we need is already completed in the MMO Kit and it's just a matter of integrating it and making minor tweaks. I fully expect to be 90% feature complete by the end of Week 7, giving us a full 5 weeks for the designers / story tellers to finish and play-tests a bunch of quests.
Once that's in progress, I'll be concentrating on just artwork and bug fixes. I would've rather had 6 weeks for this, so in my estimation we're about a week behind schedule, but all that means is that we'll have to do without a few NPC's and possibly purchase a few extra props / buildings.... or worse comes to worse, although I didn't want to do it, I'll probably end up throwing in some artwork from content pack(s) to make up the difference.
The first week of January we should have enough in-game to release our first beta. Most of the art should be finished and many of the quests will be finished. If you're interested in beta testing, please e-mail me with the word "Fractured Universe Beta" in the title. Give me a little information about your rig (Operating System, CPU Speed, GPU, RAM, etc) so I can make sure your system can handle it. Also tell me what other games you've played. For now I'd prefer most beta testers to have previous MMO RPG experience.
Please, we need Linux, Windows and Mac testers alike, so if you can help out we'd definately appreciate it.
Thanks!
I've handed off to two other team members the Login GUI and the Advanced Camera and I don't have a status update from them yet, so hopefully they're done or close to being done.
At any rate, tons of programming completed on my part this weekend.
Database Integration
I completely re-did the MySQL database integration so that it works by two queues: A request queue and the response queue. For the response queue, I used the existing game queue so all responses get processed by the main game thread. The request queue is sort of like the game queue, except it has a condition variable associated with it so the database thread can wait until the queue isn't empty. That makes it so it doesn't have to continually poll.
So, the main implementation outside of the two queues is simple. A database thread is started at dedicated game server startup. When the game engine (or anything else) requires data from the database, a specialized event requrest (for instance, a LoginRequest) is created and put onto the database Request Queue. The database thread wakes up, looks at the request event, executes the appropriate database query, then creates the response event (i.e. LoginReponse) and puts it on the main game event queue.
When the game engine gets around to it, the response event is handled appropriately.
This implementation makes it so that database requests do not slow down the main game thread. It forces us to use an event model for everything else, but that's not really a bad thing. The AI manager will be re-written in the next few days to use this new event model.
Login Server
The login server was re-written so that it's not longer in script and it uses the new database interface. It also now uses the new event driven model.
The Login Server has also been expanded with support for dual redundancy, allowing one server to be down and using the other as a backup. If I have time I'll eventually create a load-balancing mechanism (implemented on the client side) to help balance loads.
"Why would a login server require load balancing?" you might ask. Well, the Login Server has been re-tasked to encompass several new tasks.
It's now also the primary database server. Instead of having database requests routed through the zone servers, all database requests are now sent to the login server from the client, processed, then returned to the client.
I eventually plan on making a cache system on the client's machine to reduce the load of the database server.
What's the advantage of doing it this way?
As you know, Artwork / other content can be updated by downloading patches.
Quests, items, player levels, NPC' conversations, etc will be updated on the fly in the dev environment, and this method of having a database server will allow the clients to immediately get these updates without having to create / download / apply a new patch. This will save a tremendous amount of development time.
All of the data-driven content can be updated either in-game or via our web interface (depending on the type of data) and immediately applied to the game, even with multiple designers. In-game editing isn't finished yet, but the web interface is complete. When it's all said and done, our myriad of game designers will be able to hop in the game simultaneously, chat about features, drop in NPC's, edit NPC dialogs, add quests, then form up a team and play-test it right then and there.
Future Stuff
Chat Server - Same basic implementation as the Login Server, except without primary / secondary servers.
NPC Dialogs, Quests, etc - The database design is finished. We just have to add the HUD for displaying and editing the information in-game. Editing will be lower priority because we can already edit the data using our web interface.
The rest of the coding - We've got some minor things to finish up. Most of everything else we need is already completed in the MMO Kit and it's just a matter of integrating it and making minor tweaks. I fully expect to be 90% feature complete by the end of Week 7, giving us a full 5 weeks for the designers / story tellers to finish and play-tests a bunch of quests.
Once that's in progress, I'll be concentrating on just artwork and bug fixes. I would've rather had 6 weeks for this, so in my estimation we're about a week behind schedule, but all that means is that we'll have to do without a few NPC's and possibly purchase a few extra props / buildings.... or worse comes to worse, although I didn't want to do it, I'll probably end up throwing in some artwork from content pack(s) to make up the difference.
The first week of January we should have enough in-game to release our first beta. Most of the art should be finished and many of the quests will be finished. If you're interested in beta testing, please e-mail me with the word "Fractured Universe Beta" in the title. Give me a little information about your rig (Operating System, CPU Speed, GPU, RAM, etc) so I can make sure your system can handle it. Also tell me what other games you've played. For now I'd prefer most beta testers to have previous MMO RPG experience.
Please, we need Linux, Windows and Mac testers alike, so if you can help out we'd definately appreciate it.
Thanks!
Recent Blog Posts
| List: | 11/13/08 - Take Two... 11/13/08 - Zen and the Art of Indie Game Development 04/10/08 - Indie 2.0 - Content Packs 03/14/08 - Indie 2.0 - Part 1 01/04/08 - IndieZen Dev Blog, Dec 2007 12/13/07 - Happy Birthday IndieZen! 11/25/07 - IndieZen Dev Blog, Nov 2007 11/17/07 - IMGDC tech talk |
|---|
Submit your own resources!| Dave Young (Dec 06, 2006 at 18:55 GMT) |
| Dreamer (Dec 06, 2006 at 19:27 GMT) Resource Rating: 5 |
Quote:
NPC Dialogs, Quests, etc
Dave has just finished up work on a shiny new editor for that stuff, it'll go into an update shortly or should be on SVN right now, might give ya a headstart on your own.
Anyways excellent work, glad to see your progress on this.
Regards,
Dreamer
Edited on Dec 06, 2006 19:29 GMT
| Mads Laumann (Dec 06, 2006 at 20:29 GMT) |
Keep 'em coming :)
| J Sears (Dec 06, 2006 at 22:01 GMT) |
| Tony Richards (Dec 07, 2006 at 15:43 GMT) |
I had a few people request more information about my database code, so I posted it as a resource.
| Tony Richards (Dec 07, 2006 at 16:10 GMT) |
You must be a member and be logged in to either append comments or rate this resource.



4.0 out of 5


