This is like relearning Java all over...

[AJim]

I'm not new to Java, i've been doing it since 1999. But its all mostly applications and whatnot. Nothing like a game. I've done basic, non graphic heavy games, like breakout, pong etc..using only basic java shapes and my own classes. But these were all applets, and I used to think applets were the way to go.
But BAM i come to these forums and i see that i'm quite outdated and the applets i've seen are useless <almost>.
Learning to do fullscreen itself is quite a task and I'm still having trouble :\ But its nice refresh, and I really want to learn how to do all this. But game programming is a totally new direction...even school courses I have to throw out the window.
Sometimes it feels like quicksand and i can't get out.
Anyone have a hard experience first time programming java for games? I'd like to hear how you got through it.

[jbanes]

Anyone have a hard experience first time programming java for games? I'd like to hear how you got through it.

I don't know if you'll find this useful or not, but I actually had a rather easy time. The reason was that I already understood many of the underlying concepts from Pre-Java days. One of the best things you can do is to pick up a good book on game programming (a used copy of the original "Trick of the Game Programming Gurus" if you can get it) and study it thoroughly. Once you understand the basic concepts behind double/triple-buffering, page flipping, sprite management, game animation, etc. moving into the Java stuff is as simple as asking yourself "what API do I use to accomplish that"?

[AJim]

I've had this 'Black Art of Java Game Programming'. I understand the concepts in there, but most of the API is deprecated and quite old. But the concepts many of you use here are quite, shall i say advanced? Such as BufferStrategy, and page flipping etc... I think the only thing this book ever covered about less flicker was DoubleBuffering and I know how to do that. But the problem with the book is, its all applets. Just applets.

Games published by our own members! Check 'em out!

[jbanes]

"Black Art" is not a general game programming book. It's a book on how to create applet games. Most of the good ones were for C/C++, but the REALLY good ones didn't even matter what language was used (even if the examples were in C). Be very wary of books that are technology specific. Many of them are absolutely useless (like a book on DirectX, blech).

[AJim]

great..another thing i should throw out..
so much..

X_X
hopefully i can get this soon..maybe a month i can start to develop my own ideas and simple games..

[nickdotjava]

I know what you feel like.  What you really want to do is move away from java's graphics.  IMHO, they really baby you, and they're not that powerful.  LWJGL or JGO are the future (I hope).  And down with DX.  

Try picking up a book on OpenGL.  I'm using the OpenGL SuperBible by Richard S. Wright, Jr.  and Michael Sweet.  It covers the simpler concepts.  After writing some simple games with an OpenGL binding, then start with the more advanced topics.

[jbanes]

Try picking up a book on OpenGL.

Why don't you just shoot the poor guy in the head? Jumping straight to 3D with a poor understanding of 2D is a sure fire recipe for failure. And the Java2D APIs do *not* "baby you". They are actually about as powerful of 2D APIs you're going to find.

*grumble* *grumble*...blind leading the blind... *grumble*

[nickdotjava]

You can do 2d with OpenGL.  Just ignore the z axis.  

So what you're recommending is getting "Tricks" and then learning a graphics api?  Is there a significant difference between the first and second edition?  And if so, why the first edition?

[jbanes]

You can do 2d with OpenGL.  Just ignore the z axis.  

*groan*

So what you're recommending is getting "Tricks" and then learning a graphics api?  Is there a significant difference between the first and second edition?  And if so, why the first edition?

There's no "Second Edition" to my knowledge. Just a bunch of books after that one that tried to capitalize on the name. e.g. "More Tricks of the Game Programming Gurus" These books were ok, but they didn't carry the same weight of general knowledge of the original.

BTW, sorry if I seemed snappy. I think it's time for me to go hit StarBucks.


Tricks of the Game Programming Gurus

[nickdotjava]

mmmm....  Starbucks...

Games published by our own members! Check 'em out!

[AJim]

a nice hot cup of Java...har har

i like hot coco..

[Jeff]

Don't forget we have a whole topic for beginners

"Newless Clewbies"  

Thats meant in a joking, friendly way.  We were all there once.

I think if you look there you will find many of your questions already addressed and folks happy to help you with the oens that are left.

He'res a basic organizing thing to understand about games programming though.  Forget about event driven code.  Most games fundementally are a big loop where each time around the loop does all the processing and drawing for one "turn."  Even so called "real time" games are really made up of consecutive turns where each turn is one video frame.

[blahblahblahh]

He'res a basic organizing thing to understand about games programming though.  Forget about event driven code.  Most games fundementally are a big loop where each time around the loop does all the processing and drawing for one "turn."  Even so called "real time" games are really made up of consecutive turns where each turn is one video frame.

Chuckle; if you have a big loop etc then you have almost the perfect situation for event-driven code - you just have to make a few minor changes. Hmm. I can see what you're saying, but you shouldn't dismiss events so easily.

The issue for most people with event-driven logic is that you MUST (absolutely MUST!) implement synchronous execution (if you add this to your description above, then event-driven logic will work perfectly). It's actually easy to program games with events if you set things up properly - if you're happy to lock your framerate to a single value, and provide a sub-layer that causes variables to only be updated on a clock-edge, it's all simple.

In more detail, you need to set things up so that:

- on each method call, any variable you want to change does NOT get changed, but instead a temporary variable gets updated to what you want the variable to contain on the next clock-tick.

- on each clock tick, all variables first get updated with the contents of their temporary, THEN all methods get executed.

This is fairly easy to implement by having all classes extend a superclass which manages the updating of variables, and always only assigning to the temporaries in your main source code.

...and if you've done any microchip design, you should have no problems. I probably wouldn't recommend it to anyone else though, unless they intend to do lots of complex stuff where they want parts of the game/level/etc to react to each other - reaction chains are much easier to implement and maintain in event-driven logic.

[Jeff]

Chuckle; if you have a big loop etc then you have almost the perfect situation for event-driven code - you just have to make a few minor changes. Hmm. I can see what you're saying, but you shouldn't dismiss events so easily.

The issue for most people with event-driven logic is that you MUST (absolutely MUST!) implement synchronous execution .

Okay, if you accept Microsoft's abomination of a message queue a big loop as 'even driven' then I aquisce.

But to me event driven by difinition means multi-threaded or the events aren't 'driving" and what you are real doing is just event-processing, which i agree can fit a game-loop model.

I think its just a question of how we use the terms where we differ, not the concepts themselves  

JK

[AJim]

X_X.
Event driven mean like switch/if statements about a certain event? Or maybe i'm misunderstanding the phrase.

Are threads a big part of programming a game? I read some of you hate threads and mainly use a loop. But how do you control the timing of the loop? With a thread? a Timer? maybe a counter?

(Sorry if this is like a newbie question, but it feels relevant enough to the answers posted)

[blahblahblahh]

Quick note to original poster: IIRC, there are plans to produce articles on this topic. It was one of the things we were discussing pre-GTG and when people started to get really geared up, we were asked to wait for the GTG announcement.

If/when GTG people get the more important things out of the way, and then get on to creating an area for articles on java.net, then there's no shortage of interested authors from this site who have volunteered, IIRC.

I think its just a question of how we use the terms where we differ, not the concepts themselves  

Heh, yeah . "Once a hardware designer, always a hardware designer"? Hmm, maybe . Well, to me, an "event" is synonomous with an "edge" in hardware design. Both of them are (can be?) defined as being "the moment something changes".

My blinkered perspective is partly coloured by my work with MMOG engines, where event is frequently (and IMHO most usefully, in that area) defined as "any change in any game state any where". In that area, an "event based system" is one where listeners will receive notification of every change, no matter which physical server it occurred on, delivered to their VM. Multi-threading may or may not come into it (except that you are usually talking about a distributed system).

The phrase "-driven" usually IME refers to how you architect the code that is invoked as a result of an event or state-change. If you create self-contained class hierarchies that implement an interface and receive a call to a "notify( event )" method every now and then, AND they do all their processing inside the context of the thread that called the method, then they are being driven by the event.

If, OTOH, the method(s) that are invoked as a result of an event merely store the data of that event, and a separate thread (or same thread, but from a different context) jumps in [ * ] and does something with the data, then it is not being "driven" by the event, it is being "fed" by it. My understanding is that this latter case is how most single-game-loop developers are working? It makes your execution time very deterministic etc (you do very little processing during event-handling, since you have no control over how often or when events will be handled).

[ *  - ...and this thread is not being deterministically invoked by the fact that the notify() method was recently called. I.e., usually the events come in at random intervals (e.g. mouseevents, or keyevents), whereas the processing thread comes in 60 times per second, and if there is data pending, does something, if not, it just drops out and goes and does it's other work elsewhere.

EDIT: Correcting YABB's parser problems. You can omit [ list ][ /list ] but it still interprets the [ * ]. Oops.

EDIT2: turning off smileys does NOT stop YABB from parsing [ * ].