There are some great minds lurking here (and some real humorous donkies to balance those off ) so I thought I'd run my server engine design by the boards and see if someone can point out some of the pitfalls Im missing or about to fall into. The goal of this engine is to support a limited number of players in a client/server environment in a potential MMOLG environment. The idea is to get the alpha world up and running for testing purposes. Server app runs on our server platform and listens on port xxx. Client starts the app on their computer somewhere on the Internet. Client App encrypts the UID/PWD and authenticates it to the server by opening a connection on port xxx at the servers IP and passing the info to the server. The server takes the authentication data and routes it to it's server farm LAN, specifically to the authentication server(s). Server authenticates the UID/PWD and passes a token back to the client and starts a file version/integrity check client side and updates/patches files as necessary from the patch/download server. Once patched the client applet is pushed to the server selection screen. Then the character selection/creation screen and the login server loads the player characters info for that server into memory. The player sifts through his character slots, selecting the character of his choice. The client is then pushed to the actual game console screen and their character is entered into the landblock server at the coordinates from their last logout which are checked first to ensure they are legal coordinates. If the login point is for somereason in an illegal area of the world map for that landblock the server drops the user to a "safe zone" coordinate. Immeadiately after determine the actual login point data from surrounding world objects begin streaming to the client. On keypress for movement the client sends that movement command to the server handling the landblock the player is in and the player location database is adjusted to show the player is in motion at heading xxx at a rate of xx base don the players runspeed read from the players character stats currently held in memory on the landblock server the player is currently a part of.. Am I on the right track here? Can all this truely be done with mySQL. I mean sure the answer is yes but am I missing any major gaping logic holes I need to plan for? This is the culumnation of several months of work here so I jsut want to make sure Im ready to jump in both feet before I start begging for database developers. Thanks guys. Have a good night Mark Fly by night Studios C++ Coders needed edit: ACK forgot is mySQL a cross platform deal? IE if I port the C++/OpenGL code to consoles will my SQL databases be an issue? Thanks again [edited by - Slyxsith on March 27, 2003 12:02:35 AM]

I don''t see anything you''re doing that mySQL can''t do. You''re not doing any "fancy" DB stuff. What''re you''re doing could be handled by a simple flat-file since all you seem to be storing is username/password and some basic player data, so mySQL should handle it fine.

Porting your OpenGL code should have no effect on the server, so I don''t see how that would affect mySQL.

I guess what I was really looking for is some feedback on my flow chart, as skeletal as it is.

Of course mySQL can do database functions I was looking for a little more specific feedback. If you can run combat engines damage formulas and inventory control for a MMOLG with a flatfile database in a game of more than 1 player you have better database skills than I do. I was looking for some feedback regarding the logic of the whole thing.

SQL is an industry standard due to its powerful parsing tools and relational tabling. What I'm looking for is a little discussion on MMOLG database development. What are the pitfalls that a MMOLG running SQL databases for landblocks, inventories and player development. I was hoping for some feedback from peopel that have been this road before me =) Everyone and their dog in this forum has sworn to develop a MMOLG of some kind I was hoping to get some feedback about it.

Thanks

Mark


Fly by night Studios
C++ Coders needed

[edited by - Slyxsith on March 28, 2003 3:26:04 AM]

xcuse my ignorance, but what the heck is MMOLG ? I tried to search in the cyberspace but all I could find was zip.

2DNow - Yesteryears technology at your fingertips! - REDESIGNED!

You should restrict the use of SQL to player information such as skills, inventoriable items, damage and last known stable position, and commit those periodically to disk. You should also make sure this information is well protected as this is what players pay for at the end of the day.

If you do have player information that is temporary in nature (speed, heading, emotional levels, ...), I suggest you put them in a linear file that is size modulo 4K so that this file can be memory-mapped; if a catastrophe occurs, then the file can be used to reconstruct the player's current status and update the player SQL database appropriately.

I don't fully understand your 'player location database'; you want to put the landblocks on an SQL server? I can understand you do not want the entire gaming world known to the player up front (the MMORG gameplay involves a discovery process); but player movement will surely dominate your network capacity and you don't want to bloat it with incremental geometry transactions. Maybe the client side could have keycoded landblocks on a local hard disk/CD and opening up a previously unknown landblock to the player involves sending the decoding key only ? Then yes, you would need another SQL database indexed by player ID just for that.

quote:

---

Original post by Slyxsith
ACK forgot is mySQL a cross platform deal? IE if I port the C++/OpenGL code to consoles will my SQL databases be an issue?

---

You can implement the SQL database on a machine and everything else on another. SQL queries can be made across a (secure) network without any problem. Besides, it is a good idea to separate the stable, don't-touch-it, SQL machine from the in-development, Jell-O-like, pre-alpha, MMORG server...|8-}

-cb



[edited by - cbenoi1 on March 28, 2003 12:21:59 PM]

Thanks CB. I''m really going to need to research the player location database. As you said it''s going to be the most aggressive service on the server and optimizing the way movememnt and player locaitons are handled and updates is going to be the key.

Thanks for the critique. If you''ve got any websites on MMOG database development I''d love to browse them.

Thanks

Mark

I think you misunderstood my comment about MySQL. MySQL is actually NOT a very good DB for a lot of stuff. It is lacking many features, some of which can be consdered very basic features. Many of the more basic features are being added, but they are not there yet.

When I mentioned a flat file, I wasn''t joking. I''m guessing that your needs aren''t really a RDMS, but just an easy way to store persistant data. I''m not saying don''t use MySQL for that, but I think you might want to look more closly at what features are missing from it before you make your decision. For another free and more complete DB try PostgreSQL.

It isn''t as simple as MySQL, and it might not be as fast, but it is more feature complete. Whether you need those features or not, I can''t say.



Another point I''d like to mention about you flow, which cbenoi1 brought up is your storing of player locations in the DB. Of course you have to do this, but you mention doing it with each movment of the player. Simply put this is overkill, and your DB will probably choke on this if you have any number of players. A more sane method is to update on a periodic basis, like every 5 to 15 minutes. Or when they logout, or change zones.

Thanks Xiol,

Yeah that location update thing was a disaster waiting to happen apparantly. =)

What I''m looking into at the moment is some kind of caching feature that would store the most used information in an area in RAM locs. Then as you suggest write the data to the master file every so often. Good call and thanks for the heads up.

Mark


Fly by night Studios
C++ Coders needed