Your range is Java, so I figure maybe c# wouldn't be to far away for you either.

If it wasn't because XNA is slowly dying after Microsoft stated that they'll give it up (I believe from somewhere next year) I would suggest that, but another alternative is Monogame.

Currently I develop in XNA, and the game I am currently making was/is my "virgin voyage". I've learned more than I could possibly imagine over the last 10 months or so. The reason I suggest Monogame is that it is very similar to XNA, and the structure of it should be close to the same. I am personally considering converting my game to monogame, and continue my development there.

As for art and sprites, I can only advice you to at least try making them yourself. When I started 10 month ago, I had no experience in any kind of graphics, but decided to try it out and read a few spriting tutorials and such. I might not be the best spriter, but sometimes I do manage to draw something that I am really satisfied with.

Where to start is hard to say. Although I've learned a lot from just leaping into the fray, I am not sure that was the best decision I've ever made Since I don't know exactly how experienced you are, it's hard to say if something like a moving camera will be a challenge for you or not.

The very first challenge for me was something as simple as drawing my array of tiles to the screen, and having the player collide with the world. Later more advanced problem showed up, like creating random terrain, spawning mobs, mob AI, rotating objects etc. Some of those things are still challenges for me, but not as much as before. If you're interested check the link in my signature, and look at my very first video of my game, and then take one of the later ones, to see how simple it started, and how it has evolved.

To get your hands dirty, here's a random idea - How about making a simple top down game, where you go into a castle/dungeon/something to kill stuff and find the treasure. Here you will get to deal with basic collision detection, tile based worlds (if you choose), simple animations and weapon collision with monsters and such.

Maybe add a small boss encounter to play around with a little AI.

Again it's hard to say, since I don't know your experience level. Tetris is also a good way to learn how to handle arrays. Before I started making my game I actually failed twice when trying to make a tetris game. A few month ago I figured it was time to try again, with all my new experience, and within a day I managed to make the game, including drawing the graphics and creating a decent menu for it as well.

Anyways this is turning in to a wall of text, I hope some of that wall is of use to you- I wish you the best of luck, and I hope your journey is fruitful

Join an existing project that has the same or similar goals. It's really hard to build a game, and it's even harder to build one if you've never done anything more complex than pong. Joining an existing project that needs help is a great way to learn from other, more experienced programmers and to see how someone else has done it. Not that their method is the best or most correct, but it gives you a general direction of where to go with it.

I personally really like opengameart.org -- LOTS of free resources (graphics, music, sound, 2d/3d art, etc.) so it should be very easy to get some good resources to start with.

Try a text-based game to start out. Graphics tend to be a thing all their own... yes you'll need to learn how to do graphics programming eventually, but starting out with a text based game can teach you a whole lot about understanding game-flow and logic without having to muck about with pixels or polygons.

Posted Today, 08:31 PM

Try a text-based game to start out. Graphics tend to be a thing all their own... yes you'll need to learn how to do graphics programming eventually, but starting out with a text based game can teach you a whole lot about understanding game-flow and logic without having to muck about with pixels or polygons.

Meh, really?

Text games are great, but it teaches you nothing about game loops and painting to the screen, which is what this puppy is sniffing for. You could emulate those things, but you don't see it in context. Using a modern language like Java, graphics are no-sweat. It seems like you already know how to program, you just need to learn more about games specifically. Work on a whole lot of mini-projects before you make anything in 3D. Get really confident about each step of the programming process before moving on.

Even though pong may same simple, that teaches you enough to move on to some "real deal" 2D graphics.

Try to learn about lighting and shading and complex graphics stuff in a 2D context before trying to muddle through that while worrying about 3 axes.

You could work on a 2D tiled game, I recommend horizontal/vertical instead of isometric. When you switch to 3D Isometric its just the angle of the camera, and setting up 2D isometric diagonals can be a pain for processing at many points.

Since your considering 3D, I wouldn't plan on using Tiles to lock your players position. in 3D you'll typically be more free to move around. I.e. you will have a tile/texture background, and store an exact location on the map, and a heading. (for MMO, you need a heading, so a character will still maintain a basic trajectory on network lag)

A heading is typically something like a momentum vector(x,y) And every update you keep adding the momentum to the location. Server Updates would include a new location, and another heading, even it the heading is (0,0).

You'll need a rendering engine, and want to keep it a bit structured. In pong, you can get a way with a single X/Y variable for the ball and two Y variables for the paddles, and all other actions simply work with those values directly. For a larger scale game, you'll need to manage things in classes/structs, Typically most engines refer to these as GameObjects. Then you'll store the game objects in a list/array, usually per type. (Background, Unit, Effect, foreground and such)

You'll want to start gathering some basic physics, like a leash. a leash matching the idea of a real life leash, where one object can move around freely, but once it reaches the leash length, (by radius) it starts pulling the object on the other side around. This can be used for Camera movement to help keep it smooth. Leashes often include a springy ness, where the distance it moves gets faster, the farther from the leash source it is. Leashes/springs/etc... are good physics effects to know how to use. Look Up Cartesian/Screen Coordinates, which is probably what you used for pong, and learn how to translate those to and from Polar Coordinates. You should also make sure your using and are comfortable with Vectors (2D,3D,4D) and how the can be used for position, or difference/movement. These are things that are highly important in 3D and you can apply in 2D.

You'll need path AI's, like A*, which is a pretty easy one to start with, so you can navigate a map with obstacles. Otherwise your character will need to be directly controlled, and NPC's will have very limited movement ability. I.e. Ever played a game where something was chasing you, but if you ran to the other side of a short wall, the other character just runs into the wall, and keeps running at it, as if the shortest path to you was the only path? A* (and other path finders) are what gets used to allow npc's to walk around an obstacle, even if it means going slightly out of the way.

You'll need to learn to program timed events. In pong, every step, you were constandly checking the position of the ball compared to the paddles and what direction. Fighting engines also need to account for time between strikes. It would be like pong, deciding to hold the ball and then send it across a moment later. At every update, an NPC can attack, I.e. 30 times per second. Adding modifiable variables to characters, like Friction, Speed, Strength, Reaction (typically a measurement of time between strikes, and/or the ability to defend against an attack from a certain speed unit) Understanding about each object potentially having its own values that are modifiable, i.e. a unit gets a spell, how do they update speed.

With pong, you would typically just set a single speed variable, and probably just do a basic direction check for boundaries. RPG's, with potentially thousands of managed objects in play require a different approach.

Another key thing, to go along with Vectors, is the use of Floats instead of Ints. with pong, you probably jsut used integers to set position of objects on the screen, and integers to move them (i.e. no decimal precision) Floats on the other hand for location/movement/abilities can present much smoother motion, espeically when applying more significant physics than a bounce.

Posted Today, 08:31 PM

Try a text-based game to start out. Graphics tend to be a thing all their own... yes you'll need to learn how to do graphics programming eventually, but starting out with a text based game can teach you a whole lot about understanding game-flow and logic without having to muck about with pixels or polygons.

Meh, really?

Text games are great, but it teaches you nothing about game loops and painting to the screen, which is what this puppy is sniffing for. You could emulate those things, but you don't see it in context. Using a modern language like Java, graphics are no-sweat. It seems like you already know how to program, you just need to learn more about games specifically. Work on a whole lot of mini-projects before you make anything in 3D. Get really confident about each step of the programming process before moving on.

Even though pong may same simple, that teaches you enough to move on to some "real deal" 2D graphics.

Try to learn about lighting and shading and complex graphics stuff in a 2D context before trying to muddle through that while worrying about 3 axes.

100% disagree.

When someone says, "Make a text game" it doesn't mean a text adventure game in the normal sense. I'm thinking more like MUD type games, where you have a huge world, but it is represented via text instead of graphics. And, if they are programmed properly, these games can easily be converted to graphics.

Take a Zelda-like game, but done in text. A screen may look like this in text:

############

# #

@ x #

#

# x #

############

And, from the main loop, these screen are simply drawn as part of the loop:

whlie(IsRunning) {
  Envionment->Update();
  Enemies->Update();
  Player->Update();
 
  World->Draw();
 
  UpdateScreen();
}

For text, World->Draw() would draw the world in a text console, and you don't have to worry about graphics.

But, if you decide you want to do graphics, you can substitute the text for graphical tiles, and overload the Draw() and UpdateScreen() to draw with graphics instead of text.

This method basically allows you to not worty about having graphics and animation, and you work on the core engine and gameplay. Once you are comfortable with it, you can add graphics if you choose.

Good luck!

When someone says, "Make a text game" it doesn't mean a text adventure game in the normal sense. I'm thinking more like MUD type games, where you have a huge world, but it is represented via text instead of graphics. And, if they are programmed properly, these games can easily be converted to graphics.

I really have to agree with this. I was teaching a class on level 1 game design, which was essentially a Windows UI form/button based RPG, with rooms, items and enemies moving around. I had also showed them how to tile an image. For the last day of the 5 day class, the the students took things into their own hands, and organized (with only a little help from me) and added an X/Y coordinate to each room, and filled in the missing ones (I.e. some times you enter a tunnel, and you pop out 5 squares away.)

It was incredible watching them work together, each taking on a piece based on interest, comfort-ability and skill level. The turned it into a 2D tile game in a day, with a monster walking around, and items, all visually represented. My best class ever, and certainly proving your point.

- The text game did have loops, and timers running, which would do things like move a monster and manage intervals on fights.