Data abstraction

Newbie & Debugging Questions
#1

Hi people of java-gaming.org!

I am attending a 5 year high scool java course soon. I have been programming Java for 1 year and am heading in for some bigger stuff, namely a re-make of the NES bubble bubble version in java with network support. I have been designing this project for a while now and I am sure about how to build all the core workings of it (how to program the logic). There are, however, some implementation questions in my design I have yet to answer, namely:

How should I tackle implementing the user interface and still get a nice seperation between ui and core? Creating a rendering module that collects data and renders or simply use Java2D methods inside each class that should paint itself on the graphics object I supply?

Moreover, how should I avoid duplicating alot of code from server-client view? I mean: stuff like movement logic and how “the invader rifleshots” move can be hard to get synchronized by alot of requests? Is a nice way to keep the ui components smooth and non choppy (choppy and non smooth would be becouse of network lag) by letting the objects have a position and a velocity sent to the client so the client can keep objects moving and only send new point and velocity when there are changes?

Say, should I make the server take “left button pressed” and then assure it is pressed until “left button is released” is sent? Couldnt this cause alot of trouble on UDP (planning to use it)? Maybe find a mix by letting it assume it is pressed for an amount of time? Example:
“left pressed” was recieved
assuming left is pressed until “left released” is recieved or for 20 ms (?)
“left pressed” was recieved 15ms later
the “assuming timer” is reset to keep expecting for 20 ms
“left released” was recieved 15ms later, stops moving

Last one:

How can I in a smooth way transfer positions of players, enemies, weapons and items (score, and so on)? Sending objects? (possible?) or sending some kind of raw data and interpet it?

If anybody know the answers for this or have a some good urls that would be great. I’d love to take anything about this project into discussion! (Not just here for concrete facts)

#2

I’ll try to help about networking. Note: I implemented networking only once and it was TCP. But I think I did a good job, it’s fast paced game and syncing is better then I expected :slight_smile:

I think it’s a bad idea to send events on UDP, as it packets can get lost or the one sent later could arrive first. If you send “left pressed” and then after short time “left released” several things could happen. Server could only receive “left pressed” and thus would be heavily unsynchronized. It could only receive “left released” and again player on server would never turn left. It could receive “left released” (nothing happens) and then “left pressed” (equal to first problem).
One solution would be send event status every packet… so every packet would contain “going_left=true” when player is turning left.

I suggest using TCP first if this is your first networking attempt. It’s not noticeably (if all) slower then UDP and you can relax as your messages will surely arrive and in order. In short, it’s easier to implement. You can then try to use sending single events.

About delay, I sorted it with dead-reckoning. You ping server and calculate latency time, use some useful average with eliminated extremes. Example of latency in ms: 24, 20, 26, 19, 150, 29. 23 … you first need to eliminate extremes (as 150, it’s lag spike which doesn’t reflect actual latency time) and then calculate averages of the rest. You’ll come up with something.
I always liked writing this kind of algorithms. Let’s say average delay is 50ms. You can then assume for all your received messages as they had come 50ms late, and calculate where server player should roughly be by moving it for another “50ms” in that direction.
Also, by saying “moving it” it doesn’t necessary mean that you should teleport player there, you could set that his moving has tendency to that point and over next few updates you could move him slowly towards that point. This would prevent choppy movement.
It’s always way better if it looks good, doesn’t matter if it’s out of sync by few pixels :wink:

I think I cover most of your networking questions, if I missed something ask and I will try to explain if I know how to do it.

#3

Thanks, that was really helpful! This is enough to solve most of my networking questions. You told me all I needed to know about sending events, now I just need to be sure on how to send the game data. I mean, even if each game only contains less than 15 enemies, 3-4 shots at the same time and only player coordinates it is still alot of work to do.

The more I think about how much work the server/gui connection will bring I am beeng more and more interested in leaving out network support. Implementing the game with a single client with the logic built in would be so much easier! I mean, having to seperate server/gui would leave me duplicating efforts! Just writing the server would be interesting, but I really want a working client too. Maybe it could be modelled like this:

Client 1 - works as server
Client 2 - works as client

Client 1 and Client 2 both have the some code running
Client 1 listens to Client 2’s movement of the Player (Bob)
Client 2 listens to Client 1’s movement of the Player (Bub) + environment changes

This could work but it seem like a bad idea to me.

Maybe I should just scrap the network support.

#4

Edit: since nobody else is replying, this has passed to all network discussion, better to be moved to networking, mods?

Sorry for huge posts :wink: I’m trying to pass everything I have learned.

Writing networking took me same amount of time as to write the game itself, but this is all because I started from scratch, didn’t know anything about networking and wrote whole thing myself (server, client, and all technical stuff behind it).
It’s not that much work when you know what you are doing. Once you figure out how to sync movement of one game object (a player for example) all others can be done is same way probably, because game objects tend to work very similar. If you do movement sync for a player you can easily do it for all other movable objects, since they probably move in same way but with other variables (different maximum speeds and accelerations, but same formulas).

And now about the data itself… basicly for each game object you have to send it’s position (2 shorts), direction (a float), speed (a byte) and it’s unique status (it’s name, weapon, number of kills and such…). This is all highly dependable on your game and I can’t tell you how to do it. As you wrote the game engine that process all this data, you’ll know best what to send and when. Sometimes you don’t need to send data until something changes… sometimes you need to send data every time. I don’t know anything about your game (or game type even) so I can’t help you with this.
All I can say that I’ve found it very easier to assign unique ID number for each object and then process received messages by that ID number, instead of putting data in the message some fixed way.
Example: first I’ve put Team1 players (player1 first, then player2 …), then Team2 and so on…, so when reading message on the other side I first processed team1 starting at player1 and so on. When I’ve assigned each player unique ID and processed data on other side on player with same ID it was much easier. I didn’t have to care anymore about putting it all nicely in message in some exact order, and reading in the same order. You just get the object with some ID and put data into it. This saved me lot of debugging as if you screwed up with reading or writing 1 byte in the message everything got screwed and it was almost impossible to debug in some short time… and network debugging is hell.

About your concern of duplicating gui code… huh? Server is just a client that tells other clients it’s data should be used. When you run game engine, it calculates all bonuses, collisions and such. Server does this and clients connected to it don’t have to (more precisly they should be corrected by server on regular basis). When you play single player … it’s like a server with no clients connected :slight_smile:

Your model isn’t a bad idea. That is how server-client works. Client receives everything from server, it only calculates movement for it’s player. Status of other players and enemies (where they are heading, what they are doing) are all from server messages. Client doesn’t calculates damage and such things at all… server does and sends results to all clients which display them. In short, clients just do calculation so they can draw data from server best they can, but don’t do actual game calculations as damage and collisions. Again this is all highly dependent on your game.

you’ll need to learn it someday…

#5

Thanks for all your replies!

I will create a game library that can either be wrapped in any way I decide to implement. I will create an experimental java2d gui for debugging the game core first. Later, I will implement a nice server and client.

#6

For UDP and a fast game, send posititon, direction and speed. You can always calculate the extimated current position of an object when you know when it was where and how fast it goes in which direction. Everytime you get new info for the same object, you update your estimation with the real information. In most cases your estimation will be so close that nobody will notice corrections. Updates should arrive every few 100 ms or faster, so your worst error is maybe 200 or 300 ms.

It doesnt matter if a packet drops or if the order changes. In generel you can always calculate the position by last known position + movement speed and direction * time passed. In most cases you’ll get enough updates to keep the error low.

-JAW