Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Updating positions from MySQL database  (Read 1099 times)
0 Members and 1 Guest are viewing this topic.
Offline Reck

Senior Newbie





« Posted 2012-12-02 10:54:34 »

Hello!

I am currently running this block of code inside my Render method:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
        if (this.frame == 60) {
            try {
                otherPlayers = database.getPlayers();
            }
            catch (Exception e) {
                e.printStackTrace();
            }            
            this.frame = 0;
        }
        this.frame++;
       
        for (int i = 0; i < otherPlayers.size(); i++) {
            Player newPlayer = otherPlayers.get(i);
           
            g.drawImage(newPlayer.getFigure(), newPlayer.getX() - 30, newPlayer.getY() - 53);
            g.setColor(Color.white);
            g.drawString(newPlayer.getName(), newPlayer.getX() - 30, newPlayer.getY() + 17);
        }


It updates the players in the games position every 60 frames. However, the first bit of code where it actually requests the new info from the MySQL makes the game FPS drop almost 50%!
The target FPS is 60, but when it's requesting new positions every 60 frames, the framerate is between 30 and 50. How do i fix this? :-)
Offline saifix

Senior Newbie


Medals: 1



« Reply #1 - Posted 2012-12-02 11:16:02 »

Ughh, well, polling the database can be relatively costly and you're doing this once every second. You're bound to encounter some lag, especially since it looks like you're not only deserializing the players updated position but the entire structure stored for them. Are you sure you have no alternative way you can go about this? It looks like you all you're doing is synchronizing server state with your clients. How about creating a central server which keeps track of player state and updates the client at a set interval?

edit: I think it's worth adding that you quoted that block of code from your Render method. You should separate game logic from rendering, as far as game logic is concerned rendering should be a read only operation.
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #2 - Posted 2012-12-02 11:16:34 »

Dont fetch stuff from the database Smiley.
You should use an client / server construction if you want to have multiplayer.
The server would have all active entitys in memory, so it would not take so long.
New entitys gets loaded from the database and then gets managed in the server, storing them at some interval.
Also the data fetching should be in an diffrent thread, so you wont need to wait for new info.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Reck

Senior Newbie





« Reply #3 - Posted 2012-12-02 13:50:30 »

Ughh, well, polling the database can be relatively costly and you're doing this once every second. You're bound to encounter some lag, especially since it looks like you're not only deserializing the players updated position but the entire structure stored for them. Are you sure you have no alternative way you can go about this? It looks like you all you're doing is synchronizing server state with your clients. How about creating a central server which keeps track of player state and updates the client at a set interval?

edit: I think it's worth adding that you quoted that block of code from your Render method. You should separate game logic from rendering, as far as game logic is concerned rendering should be a read only operation.

Doesn't the Update method only run when there's a player input? :-)
Offline Reck

Senior Newbie





« Reply #4 - Posted 2012-12-02 13:51:28 »

Dont fetch stuff from the database Smiley.
You should use an client / server construction if you want to have multiplayer.
The server would have all active entitys in memory, so it would not take so long.
New entitys gets loaded from the database and then gets managed in the server, storing them at some interval.
Also the data fetching should be in an diffrent thread, so you wont need to wait for new info.

How would i approach this? I have no idea how i´d start that. Any tutorials? :-)
Offline appel

JGO Wizard


Medals: 51
Projects: 4


I always win!


« Reply #5 - Posted 2012-12-02 13:56:18 »

Fetching stuff from database is modern day equivalent of reading data from a tape drive.

I do wonder why you're using a database. Besides, using framerate to control the polling frequency into your database is awfully wrong. What happens if I run the game at 20000 fps or 5 fps?

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline Reck

Senior Newbie





« Reply #6 - Posted 2012-12-02 13:59:04 »

Fetching stuff from database is modern day equivalent of reading data from a tape drive.

I do wonder why you're using a database. Besides, using framerate to control the polling frequency into your database is awfully wrong. What happens if I run the game at 20000 fps or 5 fps?

I'm using MySQL because i've made webapplications for some years, so i'm familiar with that :-) The framerate control of updates is going to use Deltatime, this is just for testing purposes
Offline saifix

Senior Newbie


Medals: 1



« Reply #7 - Posted 2012-12-02 13:59:31 »

Ughh, well, polling the database can be relatively costly and you're doing this once every second. You're bound to encounter some lag, especially since it looks like you're not only deserializing the players updated position but the entire structure stored for them. Are you sure you have no alternative way you can go about this? It looks like you all you're doing is synchronizing server state with your clients. How about creating a central server which keeps track of player state and updates the client at a set interval?

edit: I think it's worth adding that you quoted that block of code from your Render method. You should separate game logic from rendering, as far as game logic is concerned rendering should be a read only operation.

Doesn't the Update method only run when there's a player input? :-)

Maybe I should have put that a little differently, when I said update what I meant was synchronize state with the clients. My bad :-)

OP: for such a simple game I'd have a server run which handles input and sends off state updates (anything such as a new position) every set period. For example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
long lastUpdate = 0;
while(running) {
    handleInput(); // pop events off of a queue which is populated by the networking thread
    long delta = System.currentTimeMillis() - lastUpdate;
    if(delta >= synchronizationInterval) {
        for(int i = 0; i < connectedPlayers.length; i++) {
            Player player = connectedPlayers[i];
            // send updates to this player
        }
        lastUpdate = System.currentTimeMillis();
    }
}
Offline Reck

Senior Newbie





« Reply #8 - Posted 2012-12-02 14:12:08 »

Ughh, well, polling the database can be relatively costly and you're doing this once every second. You're bound to encounter some lag, especially since it looks like you're not only deserializing the players updated position but the entire structure stored for them. Are you sure you have no alternative way you can go about this? It looks like you all you're doing is synchronizing server state with your clients. How about creating a central server which keeps track of player state and updates the client at a set interval?

edit: I think it's worth adding that you quoted that block of code from your Render method. You should separate game logic from rendering, as far as game logic is concerned rendering should be a read only operation.

Doesn't the Update method only run when there's a player input? :-)

Maybe I should have put that a little differently, when I said update what I meant was synchronize state with the clients. My bad :-)

OP: for such a simple game I'd have a server run which handles input and sends off state updates (anything such as a new position) every set period. For example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
long lastUpdate = 0;
while(running) {
    handleInput(); // pop events off of a queue which is populated by the networking thread
    long delta = System.currentTimeMillis() - lastUpdate;
    if(delta >= synchronizationInterval) {
        for(int i = 0; i < connectedPlayers.length; i++) {
            Player player = connectedPlayers[i];
            // send updates to this player
        }
        lastUpdate = System.currentTimeMillis();
    }
}


I can see the sense of having a server to handle the game state and now and then write the current state to the database. I, however, have absolutely no idea how to write such a server. How would you suggest me learning it? :-)
Offline saifix

Senior Newbie


Medals: 1



« Reply #9 - Posted 2012-12-02 14:19:42 »

Ughh, well, polling the database can be relatively costly and you're doing this once every second. You're bound to encounter some lag, especially since it looks like you're not only deserializing the players updated position but the entire structure stored for them. Are you sure you have no alternative way you can go about this? It looks like you all you're doing is synchronizing server state with your clients. How about creating a central server which keeps track of player state and updates the client at a set interval?

edit: I think it's worth adding that you quoted that block of code from your Render method. You should separate game logic from rendering, as far as game logic is concerned rendering should be a read only operation.

Doesn't the Update method only run when there's a player input? :-)

Maybe I should have put that a little differently, when I said update what I meant was synchronize state with the clients. My bad :-)

OP: for such a simple game I'd have a server run which handles input and sends off state updates (anything such as a new position) every set period. For example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
long lastUpdate = 0;
while(running) {
    handleInput(); // pop events off of a queue which is populated by the networking thread
    long delta = System.currentTimeMillis() - lastUpdate;
    if(delta >= synchronizationInterval) {
        for(int i = 0; i < connectedPlayers.length; i++) {
            Player player = connectedPlayers[i];
            // send updates to this player
        }
        lastUpdate = System.currentTimeMillis();
    }
}


I can see the sense of having a server to handle the game state and now and then write the current state to the database. I, however, have absolutely no idea how to write such a server. How would you suggest me learning it? :-)

Well -- there's really countless ways to go about implementing a client-server model for a game. However for now I'd suggest you keep it simple and look into the thread per client model.

Quote
It's probably the most popular threading model, because it's reasonably simple to implement, and is the fastest model when the maximum number of ``simultaneous'' (at the time scale of the service completion) requests is in the order of a few tens. The server sits in a loop accepting forthcoming connections, and as soon as they arrive it spawns a thread that is responsible for handling the client for all the duration of the connection. Using a separate thread for each client has the advantage of reducing complexity, because each code path needs to perform only a single operation: the main thread accepts connection, and the child threads service them.

The downside is that this model doesn't scale well with the number of clients, for two reasons: because of the demands of each service thread on system resources, and because the of time the system spends context-switching (or, even worse, process-switching) among threads. With current technologies, this last term significantly impacts the server's performance when there are more then a few tens of threads running. With increasing number of connections, both terms reduce the rate at which each client can be serviced up to a point when accepting new connections becomes impractical.
.
If you don't want to get into the nitty gritty details of networking code right nwo and just want to progress on with your game you could also use a pre-existing third party library which abstracts a lot of the stuff like Netty or Apache MINA.

https://netty.io/
http://mina.apache.org/

edit: http://docs.oracle.com/javase/tutorial/networking/overview/networking.html
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Phibedy

Senior Duke


Medals: 9



« Reply #10 - Posted 2012-12-02 15:03:58 »

As a lib I would choose kryonet: http://code.google.com/p/kryonet/
I wrote my first Multiplayer in UDP, it's funny to deal with dataloss (write own "tcp-methods") etc. But I don't know how much time you wanna spent on the project.
If you don't have that much time and want an effective solution, you should use a lib.
best regards
Offline Reck

Senior Newbie





« Reply #11 - Posted 2012-12-02 15:07:19 »

Thank you for the really great answers!

I think i'll try to use a framework to get going. I guess later on i can read more up on the networking stuff, i'll probably have classes about it in school as well (just started 3 months ago studying computer science).

The game is going to run on the browser. Which framework would be easiest and best to use?
Offline sproingie

JGO Kernel


Medals: 202



« Reply #12 - Posted 2012-12-03 17:32:42 »

My recommendation is ditch the database completely.  Keep it in memory.  You're trying to write a game like a web app, and the more you hang on to that model, the worse it's going to make the code and your experience writing it.
Offline Reck

Senior Newbie





« Reply #13 - Posted 2012-12-03 17:37:49 »

My recommendation is ditch the database completely.  Keep it in memory.  You're trying to write a game like a web app, and the more you hang on to that model, the worse it's going to make the code and your experience writing it.


It should turn out as an applet. However, i did choose to write a gameserver, which just loads up the MySQL database at startup :-)
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (49 views)
2014-10-17 03:59:02

Norakomi (38 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (34 views)
2014-10-15 16:18:58

TehJavaDev (65 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!