Jump to content
  • Advertisement
Sign in to follow this  

Game Logic

This topic is 2377 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm starting to develop multiplayer games, for now I'm working on simple things, like a extension dll.
My DLL Game Logic:
I am developing in Pascal, using ADO to connect to SQL, and Client / ServerSocket for TCP Connections in mode ctNonBlocking / stNonBlocking.
The above structure is used in a DLL which acts as an extension of a game, and works as follows:
1 - (Client<->Server->SocketThread->LoginThread) The dll is loaded by executable and connects to the server, then the player performs login to the server (2 Querys).
2 - (Client<->Server->SocketThread->GlobalInfoThread) After logging in, the client requests some information and the server returns data (7 Querys).
3 - (Client<->Server->SocketThread->RetraceInfoThread) When you open a window in question, the DLL sends a message to the server requesting data to update the client (7 Querys), that used, because items can be upgraded by purchasing through a browser.
4 - (Client<->Server->SocketThread->OpenPrizeThread) Players open a chest and the server return the prize (9 Querys).

1 - Upon arrival at about ~ 300K queries, the connection to the database seems to be destroyed, not sure.
2 - I'd like some tips to improve my structure, because i think it's a bad design.
3 - The SQLServer (2000) ends up consuming somewhere around 1.5GB ram to get around the ~ 300k queries, and the server is slow...


  • There are 4 threads calling SocketThread (Login, GlobalInfo, RetraceInfo, OpenBag), each with its connection to the database through a thread.
  • I am using Query objects in the CursorLocation: adoUseServer to UPDATE / INSERT and the SELECT to adoUseClient.
  • The average of people connected to the server through this dll is 150.
  • Not sure if the logic posted, is problematic, since it was previously using a single database connection for all threads, and I think I have not done a full test with this logic.
  • I will do a full test posted to this logic, with upgrade on SQLServer (2005 SP3) and upgrade in server hardwares, anyway, i would like to help me.

Share this post

Link to post
Share on other sites
I have a hard time understanding what the DLL is. Are you saying that there is one DLL, loaded on the client, which implements all of the client, server, socketthread and loginthread code?
Does the client talk directly to the database?
If that is the case, stop right there -- databases should never be readable/writable directly by clients. That's not only poor performance, but also a giant security/cheating hole.
Instead, the typical solution is to use a game/application server. The client talks to the game server, the game server enforces rules, and does data access to the database if needed.

Also, what do you use the database for? If you try to read/write properties each time something changes ("I moved from place X to place Y") then that's not something that you'll want to use a database for -- that should be in RAM, typically in the game server, and the database should only be used for transactional data ("I traded X for Y") or periodic checkpoints ("saves") of player data.

Finally, I think you have way too many threads. It's OK to do things asynchronously, and it's OK to have worker thread pools that run asynchronous tasks, but a thread dedicated to a socket, for example, is not a good way of structuring a program. You will end up with too much locking needed, and all of those threads will eat lots of stack.

Finally, to your "growing RAM store" problem -- have you instrumented the server to see what the memory is used for? How many connections are there? How much is in query cache? Have you tuned the server to the amount of memory you're willing to give it?

Share this post

Link to post
Share on other sites
The dll have a own connection with the server that I developed and described above.
Clients doesn't connect/talk to database, adUseClient is cursor location for get data for database fastest and adUseServer to write/update, the connection occurs in server.
The database is used to obtain information on loads of items.
Any Socket received by Server is repassed to a new socket thread, its wrong?

procedure TServerThread.ReceiveData(Sender: TObject;
Socket: TCustomWinSocket);

Share this post

Link to post
Share on other sites
Server, Login, Info, Prize, DBConnnection Threads is a global thread.
Only the socket thread is created on receive socket.

Share this post

Link to post
Share on other sites
If you are going for performance, here's some advice:
Each server should create some pool of connections to the database. Exactly how big, and how this is done, varies by database brand. Start by some small number, like 4.
In the server process, run everything as asynchronous tasks. Use a pool of worker threads to work on tasks.
I/O, which includes file system, database queries, and network data, should enqueue or unblock tasks in the worker thread pool. This probably means that you have to use more of a continuation-passing style of programming, and less of a "serial thread" style. But Fibers can help if you really don't want to do this.
In Windows, you implement most of this using the thread pool and I/O completion ports.
In Linux, you implement most of this with epoll and pthreads.
boost::asio is a library that can help with portability, and/or a higher-level API than those basic building blocks.

If your goal is something else, then you'll have to express those goals before anyone can give any better advice :-)

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!