How is your application structured?

Hello. I’m familiar with OpenGL but I’m new to JOGL. I’m using JOGL 2. How are your applications typically structured? I know that no two will be alike but is there a consensus on best practices?

For instance, does your main class implement GLEventListener, or is this offloaded to another class, and why?

Where or what method do you start the main Animator loop from?

What code do you typically put in main() vs init()?

I ask because I hate the feeling of putting my heart into some application and then realize later that I’ve been doing it wrong the whole time. Any other advice for someone who is familiar with OpenGL but not with JOGL?

Thanks!
Mossen

I don’t know if this is the best way, but for me this works very well. I structure my entire games through a few key classes, all built around an Actor which can act and paint. Everything is represented using an Actor; bullets, player, credits, title buttons, enemies, etc. It has some other properties too namely a location, size, it’s Intersection (the object representing it during a collision) and a link to the World it is in. The World class is a type of Actor that can hold Actors. When it acts it tells it’s child actors to act, and when it paints it tells it’s child actors to paint. The World also has means for allowing Actors to find other Actors within the World, check for collisions and handles painting the Actors in their correct order (layers).

At the core of the game is a MainLoop (essentially an Animator) which holds a World and repeatedly calls for it to act and then paint in order. When it paints it actually sets a flag to say it’s painting, calls the canvas to display (which only paints if the flag is set) and then waits until the flag is unset. Inside the canvas is a GLEventListener which will paint the world and then set the painting flag to false. Then some other per frame things happen, like updating the controls and loading any new textures whilst I have the GL context.

When painting a GraphicsGL object is made that wraps the GL object, offering some more common and high-level operations like drawing rectangles and textures. This is continually passed down from the paint event in the canvas all the way through the entire game, Actor by Actor.

When making a new game, it’s usually built as an applet that combines all the mainloop and display code together. I then pass it a PreGame to start, which is a type of World that runs a little animation (like fading in my logo) whilst running load events in the background on each frame (these load textures, sound and create the main game world in advance). When the animation has finished and has loaded all it’s tasks, it grabs the mainloop and sets it’s world to the main game world (passing control from the PreGame to the Game itself).

The Game itself is usually structured as a World that contains three other Worlds: Background, Title and GameBoard (this is where the game really takes place). The Background holds any Actors for drawing the background to the game, the Title holds Actors for representing the title letters/buttons and is where the title code goes, and the GameBoard holds the objects for the game itself.

Any further structuring is specific to the game.

Separate the concerns and use some design patterns (MVC, …). Don’t mix everything.