I need a good method for saving the player information yet not using a lot processing power! Would using SQL work? ALL YOUR BASE ARE BELONG TO US!!!!

Nah, why not write your own load/save routines? Read up on the FILE* object and associated functions, or on the fstream object and associated methods. Much simpler IMO than including SQL code, and likely a lot faster (process-wise).

"They set us up the bomb"


MatrixCubed
http://MatrixCubed.org

I''m not sure about whether or not SQL would be quicker or slower... but I do know that if you don''t have the SQL libraries setup on your computer already, they can be a pain-and-half to setup... these have been my experiences atleast, unless someone knows of a great site for setting up MVC++ to use embedded sql.

I''ve been fooling around with MySQL for the account/password verification system so that shouldn''t be a problem.

I would suggest SQL server. You can take the time to write your own database software, which will probably be a little faster than SQL if you know what you''re doing, but it adds so much time to the project... I can''t see it being worth it for most of us.

I think you''re way over doing it with SQL. Just make sure you log the amount of time it takes your server to do things. That way you can easily find bottlenecks.

Ben
http://therabbithole.redback.inficad.com
http://www.vendettaonline.net

I agree with Kalvin. In many cases it''s actually easier to use your own format (for plain game data at least), especially if you don''t have experience with SQL (or whatever db you''d be using). These databases can be useful though for component interaction, e.g. publishing game stats live on your website.

Oh, and: "How are you Gentleman!!"

cu,
Prefect

---
Sanity is the trademark of a weak mind.

Kalvin i can''t really test it out because it won''t show any difference untill we start reaching the maximum amount of users the CPU can handle.

I think i''ll use MySQL then since it''s easy to administrate, to call in the c++ program, and i don''t know how to create my own database program.

ALL YOUR BASE ARE BELONG TO US!!!!

It takes 570msec right now for one client to sign on. That means the server stops processing messages for 570msec. Multiply that by the potential number of people signing on at once. Anyway you look at it, my log on routine needs some tweaking. Everything else takes zero msecs. Meaning I don''t have an apparent limit at this time for how many the server can handle.

The max per CPU depends on the speed of your code. That''s determined by placing timers around it to log how long it takes to do certain things. Multiply those numbers by the number of clients you want to allow.

If it takes 1msec to process a move for one client you can only have 1000 clients requesting moves per second. Actually only a 100 before people start noticing and getting annoyed. The last person to request will have to wait 100msec for it to be processed which equals borderline acceptable lag.

Ben
http://therabbithole.redback.inficad.com

If this is truly intended to be a scalable MMORPG, my recommendation is also to use MySQL -- offload the persistence code and secondary cache to another machine that can handle the load.

quote: KalvinB wrote: It takes 570msec right now for one client to sign on. That means the server stops processing messages for 570msec. Multiply that by the potential number of people signing on at once.

That's only if you do everything blocking, synchronous, and single-threaded. Obviously a game server should use nonblocking, asynchronous, and/or multi-threaded networking.

To those people who are serious about writing a truly *massive* MMORPG: I suggest you find and understand the code for a production server that handles hundreds or thousands of outstanding clients -- ircd or Apache webserver both spring to mind. Even knowledgable network programmers would be hard pressed to design a server that can cope with demands on this scale, and not many people on this list are of that caliber.

Edited by - fprefect on February 20, 2001 2:57:42 PM