User Tools

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).

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.

*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.

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.

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.

You can simplify Knolan's formula, and cut out the need for finding floor(), by using the float value of n instead. In the above example where you have 5 cells x and 2 cells y, you would come out with:
n = (5/2) = 2.5
so that for every time your x movement is >= 2.5 you move 1 y and store the remainder (.5) in your counter variable. I would write this up like:

I've used Gimp, Paint.net and Photoshop for some of my 2D projects in the past and I would personally suggest Gimp. While it is, at first, a little more complicated than PS, I would say it takes no more than a week or two to become fairly competent with the UI. Also, it is extremely well-documented (the user docs are here), has a huge user-base and an active forum at gimpforums.com and has an enormous plug-in library so it will be hard to find anything that it isn't capable of accomplishing.

You really should be using a layer-based image editor for game art as it will speed up the process of generating your sprites once you've got the hang of it.

Programming a game for a browser is similar in many ways to programming any game except that you need to also understand the mechanics of client/server communication for even the most basic interactions. As others have already mentioned, learn PHP, MySQL and JavaScript. You will also need a means of displaying your game's content. With Flash-based games this was as simple as drawing on the stage, but with Flash gasping its last few breaths (hopefully), I would suggest an alternative, either the HTML5 canvas element or SVG. In terms of the best way to learn all of the fundamentals you will need to get started, take a look at W3Schools, they have fairly comprehensive guides and language references that walk you through the basics of web design/development and cover all of the languages you will need.

As far as what you've listed as project goals, there is nothing that can't be accomplished on that list, but there is a lot of work involved to get it all done.

If it were my project, I would start with the basic interactions (moving around the world map/dungeons, picking up/using/dropping items, etc.), then design the battle system and hammer out all the remaining details on the single player side before ever starting on the multiplayer content. This will allow you to have all interactions in place so that you can easily define the data models needed for the networked aspect of the project.