Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Feb 2011
Offline Last Active Jan 19 2014 03:39 PM

Posts I've Made

In Topic: Player Movement - Input + Network Messages

21 August 2013 - 08:59 AM

Maybe I'm over-thinking it but I think I'd rather just say "Move + " rather than pass in an actual value. This way I think it helps prevent cheating maybe?


This is a good idea. You should still pass data to the server only when there's a delta, but you're right, this should make it harder to cheat.


If I do a check server side and confirm that the player did not change direction/speed, do I even need to send the updated position to the clients? If the clients all know a player is moving, I can use some client-side prediction to show their position.. I guess that could get out of sync pretty quickly. I wonder how often I would need to update the clients with the position?


You'll want to do the server side check on a very limited basis. The example that I gave was probably a little too limited, but when there are multiple players at once, each client will send any input changes to the server while the server is busy doing all of the physics calculations and pushing updated positional "snapshots" of the scene at set intervals of a few milliseconds. The snapshots should contain all information related to position for each non-static object so that the clients are synced to the server's version of the game. The server side check is to ensure that the server's version is accurate and doesn't need to be done nearly as often, once every one to two seconds should keep any interpolation error correction from being very noticeable.

In Topic: YAML vs JSON vs XML?

20 August 2013 - 05:03 PM

I can't really speak to the pros/cons of YML, I wrote a quick and dirty parser for it a while ago for a webapp, but that's my entire experience. As far as JSON is concerned, if you're not using Javascript, there isn't much point. The reason that JSON is so nice in web development is that it is instantly recognized by the browser's JS interpreter as an object so there's no additional parsing necessary. This is only true in Javascript, though. Any other language requires a custom library to interpret JSON.


Personally, I would say work with XML. For one thing, you already know it. For another, a lot of people already know it, so if you end up bringing another person in on your project, they won't be stuck trying to familiarize themselves with a new data format (and if the person you're bringing in isn't at least somewhat comfortable with XML, you might need to ask if they're a good fit).

In Topic: Player Movement - Input + Network Messages

20 August 2013 - 04:33 PM

On the networking issue, I agree with NightCreature that UDP is a better protocol, but that has no real bearing on finding a "best solution" solution to your problem. It might throw up some roadblocks along the way, but that's all.


As far as how the client-server model should work, the most efficient way that I've seen to handle and dispatch client events to a server is to track each player object's states, depending on what type of game you're making this might only be a movement vector, and transmit those to the server only when they change. So, to break this down a little further:


(Assume only one player is actually playing and everyone else is watching, just for ease of typing this out)


*Player presses the left arrow key, movement vector is now (-5, 0).

*Vector (-5,0) is pushed to the server, stored player vector is updated.

*Player position is updated and transmitted to all connected clients.

*Player continues press the left arrow key, movement vector remains (-5,0)

*No data is transmitted to server

*Server uses stored player vector to update position and transmits to all connected clients.

*Player releases left arrow key, movement vector is now (0,0)

... and so on.


Every now and then, you'll also need to do a full state check for each connected client, ensuring that the server's calculated position for that player is correct, since any dropped packets could result in a miscalculation.


And as for your first question, neonic's solution is absolutely the way to go. My input manager classes always have a private boolean array with 256 indexes. It uses minimal memory and means that you don't need any custom handlers for each key.

In Topic: Game management

09 February 2013 - 05:08 PM

I agree with L Spiro and EWClay on this one. Game programming isn't where you start, but it's a nice place to end up.


When I started programming, all I wanted to do was make games, so as soon as I could render a jpg I was off and running (and crashing and burning). There's a lot of behind the scenes stuff that goes into making a game, at a very abstract level, and understanding all of the fundamentals about procedural and object-oriented programming is an absolute must.


As far as learning how to sketch out your ideas on paper, I would look into buying a book on UML, it's a fairly standard design language for object-oriented programming and you might get a sense for how larger projects are structured from the examples in the book. This is the book that I have, if you want to go that route.

In Topic: HELP!

27 October 2012 - 03:21 PM

If your end goal in learning Java is to make video games, I'd suggest taking a look at Swing, Zetcode has a good tutorial that will walk you through the basics and teach you about the different class types in Java.

If you're looking for more specific advice, let us know what it is you're looking to learn and I'm sure someone will be able to help you.