Sevii - A Pokemon Server Development

[kinvao]

Yes, you need the player position to do lot of things ( like this ) but with the initial idea you need to send two packets per step...which is a heavy load...

 

[Bradley]

I could try that, but that would also mean that every grass tile would need to have an encounter rate (not that hard though, just another map layer to parse). I'm already sending a packet per step, because otherwise other players won't be able to see you move.

Intentionally you can also create an attribute or some sort of thing to put down on spaces so then you can select what exactly approaches out from the encounters within the grass and if you wanted to do it quickly just hold down the mouse and hover over each tile to auto add that attribute it would make a lot more thing's easier.

 

[The General]

Quick question. Would wild pokemon encounters be processed by the server (as in a percentage of encouter rate per patch of grass), or by values in the Tiled maps? I'm considering the server, but sending a packet each time the player enters a patch of grass seems a bit excessive, because I already do that per move. Unless I combine those, but that wouldn't be very modular, would it?

Only send an packet when an encounter happens? You are talking about bytes here, its not excessive.

Looks like your project is coming along nicely. Wish I could join but not really that much time lately.

Edit: I think you have a couple design flaws. Currently at work but will update this later.

 

[The General]

Okay so here are a couple of things I'd like to address:

Cheating
So in pretty much any game people will try to exploit the game. Sometimes this means they will try to automate / bot parts of the game or they will try to obtain or achieve certain objectives. What often is the case is that games handle the logic in the client. Which makes sense as you want to keep the stress on the server to a minimum so you can scale as much as possible. It's great in a lot of ways. Just have the client calculate a certain value or perform a certain action and have it dispatched to all other clients that are connected to that server. The downside is that this is really prone to cheating. You said you wanted have the client calculate what pokemon could appear and have that send to the server. Sending this to the server goes via a packet. This can easily be spoofed. Say you would just send the pokemon with stats the server, I could easily intercept that packet and replace it. Possibly making illegal pokemons or obtaining pokemons that can not be obtained in that certain area.

A great example of this design flaw is Minecraft. Player walking is calculated on the client. What happened to Minecraft was that a lot of people figured this out and made fly cheats so they could just fly around despite flying not even enabled on the server. Because it makes sense as calculating to see if a player is making a valid move costs a lot of time and it would be a huge bottleneck to calculate these movements every gametick.

As you are writing your application in C++ there is a lot of performance you can achieve here. Don't be afraid to make calculations on the serverside. For example you can just store the map in memory and just request that specific route / area or even tile to see if pokemon can be encountered there and what probability each tile has. Like for Feebas in Emerald, only one tile each day gives the possibility to encounter feebas. A simple lookup table will solve this issue and it's not an expensive operation. Memory is cheap.

Scalability
Actually tying in to the above, you said you want to have all the map data on the client side. I would say don't for a couple reasons; The map data here is just a bunch of tiles with an integer indicating what tile to draw. That's pretty much all it is. Send it in chunks of like 32x32 tiles. Even if that's just 3 bytes per tile (16 bits for the image, 1 byte for anything else), you're only talking about 3KB. Thats pretty much nothing. You'll be sending much more in player update packets like walking and maybe some other statusses. Yes you can cache this map data on the client side but I would suggest you should not keep that around for too long.

Also by making it dynamic like this you are able to easily update / change maps runtime without even having to restart the server. Imagine if players could just be in game while you build the map? Like if you have a certain role for players that are map makers you can build another tool interface where they can just click the tile, change its state and image and what not and it will be applied live to anyone? Pretty cool right?

Other stuff;
Try to load as many resources as possible when starting the game (That is before the login screen). The tilesets are just a bunch of images and don't take up too much memory. Pokemon sprites, fonts and player sprites can also be loaded. Thats pretty much most of your game already. Avoid loading resources runtime. While it usually should not cause any issue related to performance, it is just more user friendly as you don't know what other processes are doing on the computer. Also note that doing it like this you are less likely going to run into issues with memory later where you might want to load resources but there is not enough memory available. Unlikely scenario but it could happen.

Modularity should ALWAYS be kept in your mind. Re-using parts of your code makes future development so much easier. Maybe you want to add a new world later on and not having it in a modular format will prevent you from easily adding it. Using interfaces is a good practice for this.

Players stand still A LOT. They don't move that much as you might think. Packets are cheap so don't worry about it. As long as your network is properly implemented, the amount of packets you send should not matter. Having a gamecycle could help reduce the packets. If you send all walk packets per tick (Where a tick is a certain number of frames) you can just calculate these packets once, write them to a buffer and send that same buffer to all players.

Only send data that is relevant. If player B is out of screen by a couple dozen tiles, don't send packets to player A and vice versa. If you use the chunks method you can just send the packet to all players in a certain chunk and its surround chunks (Imagine standing on the chunk border and one tile ahead the player won't move).

If you want to further reduce the amount of messages you send then concatenate your packets. Not exactly sure how you are sending the packets but lets say you send it like: identifier / length / body Then you can just keep adding packets together to send them as whole: identifier / lenght / body / identifier / length / etc... Then on the client side you just read the header (say 2 bytes (32k different packets seems enough imho) then the length of the body say 4 bytes (bodies rarely get that big but its just 4 bytes not that much) and then the actual body. After that the client keeps reading the buffer and if there is another packet added to it, it will read that too.

My project was only a test with SFML actually. Just the client. I havent made much progress as much as I would like to as I didnt feel it was a serious project other than some fiddling around. I see this has potential and would like to join your project and work together with you. I will most likely developer on Arch Linux and I assume you are on Windows so that would give great coverage. I've got a decent knowledge about C++ and my main focus will be on writing great performing code. Profiling is important so for that you could use valgrind along with gdb for debugging.

I have a lot of ideas that I would love to see in an pokemon MMO that I have never seen before and I think together we would be able to create a really great game.

Send me your Skype so we could chat and have me tell you some of my ideas. Luxray

 

[The General]

Btw any updates Luxray ?

 

[Luxray]

I was away for a few days, I'll add and read the post later