I have background in 2D Game Programming in Java.

But I have a question about how 3D Game programming works in terms of how to put the character in the game. Because in 2D Game Programming, it was just having multiple game objects in an array list and having a game loop go through the array list and drawing everything into a graphics context from the array list.

I made 3 basic 2D Games(Pong, simple arcade shooter and a guess a word type program that parses text and draw graphics based on what the text was read in by a Java class)

I also have several questions here:

1) Is there a built-in method or function that adds the 3D model of the character into the game and also move the joints of the character?

2) Where to begin for 3D Game Programming having a 2D game programming background or should I write more simple 2D games and then make the jump to 3D Game Programming?

The "Where to begin" sounds vague so I will just elaborate on this a bit more. I want to do create water or fire simulations in the future. I'm really into the programming and problem-solving aspect of things even though initially I do not know how to approach. Basically, being a programmer or a software engineer as good as the guys at Blizzard or Santa Monica Studios. Not necessarily working at the studio but being able to be at that level of knowledge has been on my mind ever since I started Computer Science 2 years ago.

Not sure how far off I will be to do the fire and water simulations. I need advice from you guys just to see what is out there for me to understand.

1) Is there a built-in method or function that adds the 3D model of the character into the game and also move the joints of the character?

Not directly. Some engines and libraries will provide that functionality to various degrees, just like 2D drawing packages provide that functionality to varying degrees.

In your 2D experience you needed to loop through the list and draw everything. Choices are to render it a pixel at a time, or to pass blocks of images to a library, or to have a an engine where you simply create a sprite, assign an image, and be done. Most libraries are closer to the latter, it is rare that people write 2d rasterization systems any more.

In the general sense the same is true in 3D; all the points must be multiplied by their various transformation matrix values and shaders and other processing, every frame. There are many more steps involved than the 2D process. Although you can go through everything yourself by hand, very few people actually go through the full process. Most relying on engines and libraries to make the work easier.

2) Where to begin for 3D Game Programming having a 2D game programming background or should I write more simple 2D games and then make the jump to 3D Game Programming?

Different people have their own preferences and do better with different things. Some people like to rely heavily on existing engines, so if that is you look for game engines that rely on Java. Some people like to do everything themselves by hand, so if that is you look to JOGL.

For me personally, I would generally rather work at a high level and leverage existing engines and libraries. I much prefer a system where I can call actor.PlayAnimation("Foo") and be done with it. Other people have a very different view, and they want to manipulate the individual buffers, writing the code that transfers point clouds and interleaved arrays to the video card.

As for a good way to learn it, a well-rounded programmer has a pretty good understanding of the entire system even if they don't write code for every part. With that in mind, I'd recommend getting a recent edition of the OpenGL Programming Guide, also called the Red Book. It will start you out with a high level overview of the rendering pipeline, and the very basic tasks of specifying colors, points, lines, and polygons. It begins by walking you through the details involved, even though those basic operations are almost never used any more because they have such a terrible command-to-result ratio. It will walk you through from those basics all the way to storing data on the graphics cards and intermediate-skill techniques for batch rendering, along with various beginner-level techniques for writing shaders and such.

Different people have their own preferences and do better with different things. Some people like to rely heavily on existing engines, so if that is you look for game engines that rely on Java. Some people like to do everything themselves by hand, so if that is you look to JOGL.



For me personally, I would generally rather work at a high level and leverage existing engines and libraries. I much prefer a system where I can call actor.PlayAnimation("Foo") and be done with it. Other people have a very different view, and they want to manipulate the individual buffers, writing the code that transfers point clouds and interleaved arrays to the video card.





As for a good way to learn it, a well-rounded programmer has a pretty good understanding of the entire system even if they don't write code for every part. With that in mind, I'd recommend getting a recent edition of the OpenGL Programming Guide, also called the Red Book. It will start you out with a high level overview of the rendering pipeline, and the very basic tasks of specifying colors, points, lines, and polygons. It begins by walking you through the details involved, even though those basic operations are almost never used any more because they have such a terrible command-to-result ratio. It will walk you through from those basics all the way to storing data on the graphics cards and intermediate-skill techniques for batch rendering, along with various beginner-level techniques for writing shaders and such.

After reading your feedback, I feel I am the type of person who would rather use game engine that is compatible with Java. I am going to take a look at JOGL.

By the way, thanks for the book recommendation! Based on a Google search, this would be the 8th edition.

What do you mean by going through everything by hand?

By "doing everything by hand" frob means to use JOGL directly to do the low level rendering yourself.

Basically correct.

There are some people who deeply enjoy writing model loaders, converting binary formats into structures used in game, writing API calls to manage what data lives on the video card, moving the data manually over to the video card at the right time or moving it off as resources become scarce, constructing a hierarchy of matrix transforms and shaders, and then processing them. For these people, they can get satisfaction knowing that they are approaching the theoretical transfer rates of the hardware, or making sure that their rendering pipeline works well on all ages of hardware. It can be a lot of work, and you can invest a tremendous amount of effort into building extremely high performance systems.

These people like to make game engines, device drivers, and assorted low-level software. It is a good thing because all those parts are important. I'm glad that other people enjoy doing it and then choose to make their engines available. My passion is in making games, not engines, but I am grateful for the people who enable me to do what I love.

These people are doing everything "by hand". They write model loaders, texture loaders, resource caches, and more. They don't rely on others to build the engine for them, they want to do it all by themselves.

I am happy to support people with a passion for engine-building rather than gameplay development, so I wanted to make sure you knew about that. It looks like you may also prefer gameplay development over engine-building, and that's okay too. We need all kinds of people to make great games.

If you choose to use an existing engine you still need to understand the mathematics behind it. You still need to understand the basics of how 3D worlds operate, how models get converted into the pretty pictures on the screen, and how you can manipulate them. The Red Book (the new cover looks somewhat orange, but it says it is still the Red Book 8th edition...) is fairly easy to read and will give you a fairly comprehensive look at the mechanics behind the magic. Even if you do use an engine, it is still a very good thing to pick up that knowledge to know what is going on. There are also various online tutorials that cover much of the same content, but they are hit-and-miss. The book is well regarded generally and used copies are inexpensive.

If you choose to use an existing engine you still need to understand the mathematics behind it. You still need to understand the basics of how 3D worlds operate, how models get converted into the pretty pictures on the screen, and how you can manipulate them. The Red Book (the new cover looks somewhat orange, but it says it is still the Red Book 8th edition...) is fairly easy to read and will give you a fairly comprehensive look at the mechanics behind the magic. Even if you do use an engine, it is still a very good thing to pick up that knowledge to know what is going on. There are also various online tutorials that cover much of the same content, but they are hit-and-miss. The book is well regarded generally and used copies are inexpensive.

Thanks for the heads up.