[java] Check my understanding...

Started by
17 comments, last by CaptainJester 18 years, 9 months ago
I made a post a while back regarding how to learn Java. Looking back it actually looks kind of silly, I didn't realize it was as simple as just booting the command line and using the SDK directly (I apologize for that, it really did turn out to be a stupid post.) I have been following some Java tutorials and while I am not yet ready, I have started "spying ahead" to what I will be wanting to work with as far as developing games in Java. To be clear, my goal with these is not to make performance intensive stuff. While I hope to learn all I can in the future, the reality of the now is I simply want very basic rendering to the screen, with input and sound, and file access. I am going to go ahead and say that from what I have seen, LWJGL seems to be the closest to what I think my needs are. However, one thing is bothering me about the LWJGL things that I have seen. It appears that the LWJGL game programmers almost strictly do not use Java's objects during their main loops. In fact, all of the tutorial material I saw seemed to have a particularly annoying limitation. What I need to know is do I have my head on straight about this. Based on my own experiences writing 2D games in a few more simple environments (Blitz etc, nothing impressive yet), you usually want to be able to control objects in the game world (anything from RTS units to the typical 8/16 bit "bullet", to goombas) completely dynamically in terms of numbers. I had assumed (perhaps naively) that in a language like Java I would have a sort of Entity.bullets.fireball and Entity.monsters.orc.orc_with_hammer kind of thing going on. I remember reading that there was a sort of list you could create by using a built-in Java class so that I could cycle through dozens of unnamed orcs and fireballs or whatever I needed and simply process them every cycle, changing their state and spawning and deleting them pretty much freely. They would contain their own code, keep track of their own health, etc. An object called Screen would keep track of the resolution the user was running in, and it would interact with the game objects. It would probably query the game objects who would then return a value that would equal something like which sprite strip, which frame, and their coordinate in the playfield. All would be perfect as I could spawn and despawn objects freely. It made perfect sense to me... Then BAM, all the Java game specific tutorials are using arrays and stuff! Yikes! No offense, but that seems to really call into question if I should bother using Java for my needs... I seriously would like to avoid the "Just use an array and an old fashioned procedural loop" because that won't teach me anything. I actually want to do this pretty much OOP, but apparently creating and destroying JAVA objects during the main loop of a game is not feasible? Let me ask this, would you normally create and destroy objects in the main loop in, say, C++? Is my understanding of how to use objects in games completely wrong?
Advertisement
from my what i have seen in programming (2 CPP classes, 1 java class) if you have more than one of the same type of object (multiple orcs or bullets) the easiest way to program them is to have one set class for that type and then have an array of them. This makes the code a lot nicers than having orc1, orc2, orc3. Yes you would have something like Entity.bullets.fireball in Java just remember that inorder to have it you yourself must program it
When the world can't make you smile, program one that can
Quote:
am going to go ahead and say that from what I have seen, LWJGL seems to be the closest to what I think my needs are. However, one thing is bothering me about the LWJGL things that I have seen. It appears that the LWJGL game programmers almost strictly do not use Java's objects during their main loops. In fact, all of the tutorial material I saw seemed to have a particularly annoying limitation. What I need to know is do I have my head on straight about this.


Well have you looked at full code for any real LWJGL games ? Small demos and examples don't count, of course they will put everything into a single source file just for ease of learning. Personally my LWJGL engine, which is currently interfacing with the TrueAxis physics engine is mostly object-oriented. I have an EntityManager, with respective StaticEntity, DynamicEntity classes. From a file I will load positions/orientations of all the objects in my scene and create a DynamicEntity for each, as well as creating a StaticEntity for the "world" geometry. Then I add these all to my EntityManager singleton, which is really just a wrapper around (not an array *gasp*!) a LinkedList. With a LL you get cheap adds, cheap iteration+ (semi-)cheap deletes, and NO resizing.

Is this the kind of object-oriented system you think LWJGL is forbidden from? it certainly works quite well for me.

The thing is, LWJGL is made to be as small, fast, and portable as possible. For this reason it doesn't have a huge codebase with a bunch of OOP mumbojumbo. Basically, it is up to you to come up with a clever scheme of scene management.

I think maybe a large part of the phobia of objects is the garbage-collecting system. Most people think that they should avoid at all costs ever calling "new" during your game loop. The problem is that people that get locked into these coding styles for "performance" are actually getting more and more outsmarted by each new JVM.
Yes, I understand that, but the problem with Arrays is that they are fixed. Unless I am totally missing something, you can't change the number of objects involved very easily. For example, suppose you are using a Roguelike type of game. You want to have random level generation (you know, one of those things where it runs one of those dungeon tunnelers to hollow out a bunch of rooms, and then populates them with Slimes and Torches and crap.) In that environment, just as an example, it is very difficult to put a cap on the number of things you'll want to have. How many Orcs is enough? 50, 100, 250? Also, wouldn't the memory be occupied regardless? I am not trying to be an http://www.gamedev.net/community/forums/topic.asp?topic_id=326558, but I am ready to move on to games just a bit more complex than Space Invaders.

I'll lay it out on the table. I have successfully made a playable (althought I must confess I never polished it) Tetris, space invaders, asteroids kind of stuff. I really can't learn too much else that way. My next step is more complex 2D single player fare. Not talking Civilizations or anything like that, nothing with an advanced AI yet. I am thinking of trying to write a platformer, and then after that I would like to attempt to make a 2D graphical Roguelike. So while I am being slightly ambitious, this is nothing completely insane here. And for the record, I will probably re-write Tetris and such in Java before moving on to anything more complex. I realize people with huge, noobish visions are a dime a dozen, I just wanted to make sure I was clear that I have a HUGE sense of reality going on here, I am only one person, and a n00b at that.

Here, let me just show you some vaguepseudocode for what I mean by dynamic.

Main loop start
{
do that timing thingie to see how much time has passed
run as many game logic loops as necessary(based on timer millisecs)
run one screen flip
{
process various game logic, see if input keys were hit etc
blah blah blah
....
check to see if game condition calls for spawning anything. If it does then spawn
....
for each Entity.enemy check their status, collisions etc
during the check of each entity allow for dynamic deletion of enemy
}
}

What I am referring to are the various methods people use to achieve this effect. I.E. having an unsorted, not specifically named list you can sort through, add to, and remove things from TOTALLY dynamically, without resorting to, for example, having "ghosts" of enemies that you turn on and off, but that still occupy memory.

EDIT:Optus: err, I wrote this reply before I read your reply, so it might not apply :)
This isn't a Java specific thing- you're getting "game programming" confused with "engine programming"

Game programming is nice and intuitive. You spend your time writing things like you describe:

if(!endOfLevel)   Engine.spawn(new HammerOrc());else   Engine.spawn(new Boss());...if(playerHit){   if(playerWearingArmor)      player.damage(damage / armorAmmount);   else      player.damage(damage);}


Engine programming is difficult and mindnumbing.

public void spawn(Entity e){   Tree worldTree = Engine.getWorldTree();   Vector3df origin = e.getOrigin();   for(Enumeration e = worldTree.getNodes(); e.hasMoreElements){      Node n = (Node)e.nextElement();         if(n.isFound(origin))      n.Insert(e);   else if(n.hasChildren()){         Node parent = n;         while(parent.hasChildren()){            Node[] children = parent.getChildren();            for(int i = 0; i < children.length; i++){               if(children.isFound())                  children.Insert(e);            }         }    }    else       Throw new EngineException("Entity location not found in world tree.  Invalid coordinates!");}


Ok, so, that was completely fictional. However, it still makes sense. Spawning and manipulating Entities in a game world is potentially very very complex stuff! This is the case in any language you use.

No language has a built in game Engine. There are 3rd party engines available for Java (JMonkeyEngine, JOgre, AgentFX, etc) and C++ (Ogre, Irrlicht, Genesis3D, etc)- but these exist only because somebody took the time to do all the dirty stuff.

As far as creating/destroying objects during the loop- there are issues with this sort of thing in any language if you don't know what you're doing. Typically though, these are the worries of someone writing an engine- trying to prevent memory leaks and hiccups. If all you're doing is creating/destroying Orcs and such, this won't be a problem. If you're optimizing your particle engine to prevent it from garbage collecting 5000 particles every second, then this might be a concern :D

Java 1.5 is very good at these sort of things though- Don't worry about creating/destroying objects in the main loop.
(From c++ point of view) To add to memory leaks you also tend to worry about memory fragmentation.
The more applications I write, more I find out how less I know
So which of these extensions are Engines, and which are the things that you use to build engines? Is LWJGL an engine? While I may become interested in engine development at some point, my inclination right now is that I would like to learn more about actual game design. Which java setup would be the best for diving right in(with a solid understanding of Java itself of course) and making stuff happen?

Just to be clear, I am not looking for a glorified RPGMaker2000 type of thing. I don't want any assumptions to be made as far as the games BEHAVIORS, I want to to ALL of that myself. I don't want built in systems for HP/MP. I really just want a way so that I can focus maybe 30% on Java and 70% on the game logic itself.

Of those 3RD party engines you listed(and I am not saying this to be lazy, I Know I can easily Google them all, I am asking you because you seem more experienced than I) which(if any) would be perfect for focusing purely on 2D game design, preferably for running on a windows/Linux desktop in fullscreen? (Note that when I say 2D, I mean 2D from my perspective. I don't have any problem with ones that do 2D sprites as 3D flats as opposed to per-pixel) I am not saying this to avoid googling, just wondered if any of them were "dead on" for my needs.

EDIT: Fresh off Google> http://goldenstudios.or.id/products/GTGE/ I wonder if this is what I am looking for?
The big ones (JOgre, JMonkeyEngine) might be too big for what you want.

I'd suggest GTGE (http://www.goldenstudios.or.id/).
- The creator frequents these boards so you can get some nice help from him.

I havn't used it myself, but from looking at it, it'll probably be best thing to bring you to the "30/70% ratio" you want. However, without knowing what type of game you're shooting for I fear that "30/70" might be wishful thinking. 1:1 might be more realistic for a simple game.

A step from that is Java2D itself- which is just using the Java graphics library in conjunction with an applet or frame. This is probably too loose though. However- Java2D is a great progession from GTGE once you've gotten some game logic under your belt. Especially because GTGE is written in Java2D.

Also, to help you organize your thoughts about engines/game logic. Here is a nice tutorial by kevGlass http://www.cokeandcode.com/info/tut2d.html I've sent a few of my friends there who were wishing to learn about Java game programming.

Good luck!
Well my 30/70 thing was just talking out of my butt :) I appreciate the help on this thread, now I better get back to getting the rest of plain ol' Java under my belt so I can start into this.

If you want to make a game, not the basic stuff, then yes, GTGE is what you looking for!
This is very true especially when you say you want to make 2D game, cos GTGE is focusing on 2D game development.
Then you can indeed focus 30% on Java and 70% on the game logic/game design.

And GTGE can also use OpenGL mode (both LWJGL and JOGL supported), but the basic GTGE will only using Java2D, that way GTGE can make pure 2D game without the need of any other library instead of Java SDK of course.
The beauty thing is to port from GTGE Java2D to GTGE OpenGL via LWJGL/JOGL, the game only need to change 2 lines of code roughly, and the game is already in OpenGL world.
Basically GTGE use OpenGL mode only for performance wise, but not closed for mixing 3D objects in 2D ;)

Now here is the list of GTGE features :
http://goldenstudios.or.id/products/GTGE/

And the most important thing is, GTGE is actively developed with the best support I can say.

Any question? :)
-------------Golden T Game Engine - Java Game EngineGolden T Website | Golden T Forum

This topic is closed to new replies.

Advertisement