Question

I’m making a turn based rpg game with some multiplayer functions using GAE. I have a pvp lobby where players can view other players that are online. Players can also challenge each other in the lobby and start a fight. The actual fighting is not taking up that much resources. Whats taking up resources is the lobby. From my dashboard I can see that “datastore read operations” is what’s taking up most resources.

I’m fairly certain that the way I’m doing this is pretty stupid, I mean there just has to be a better way. Every player that is in the lobby pings the server every other second. Then the following happens:

1. The server checks through a list of registered players to see if the name of the pinging player matches the name of the players in the list. That object is then used in (2) and (3).

2. The server updates the time that the player pinged so that it (later) can return a list containing only players that have pinged the server in the last 10 seconds.

3. The server checks if someone has challenged that player.

Here’s the code that tries to find the pinging player(that is, (1) above):

javax.jdo.Query query = pm.newQuery("SELECT FROM " + Player.class.getName());

        List<Player> players = new ArrayList<Player>();
        players = (List<Player>) query.execute();

        for(int i = 0; i < players.size(); i ++)
        {
            if(players.get(i).getName().equals(playerName))
            {
                //Found correct player!
                break;
            }
        }

When there are hundreds of registered players, finding a particular player once every other second for each player in the lobby seems like a real waste.

Question: Is there some better way of doing this? I’m thinking perhaps I’m fetching the calling player inefficiently?

Answer 1

You’re iterating over every single registered player every time you try and find one. Since you’re doing a simple equality test, you should apply a filter to your query to return just the desired record. JDO queries, and how to add filters, are documented here.