Question

I'm currently developing my first game in Java language.

The game is an endless runner with obstacles to avoid and enemies to kill. Unfortunatelly im still not experience enough and many times im just improvising. I have no idea if my method of loading of obstacles is good or bad in terms of performance (how fast a game runs, how much fps).

Currently my code is designed in a way that I have a level class, and in level constructor I create all obstacles that will be used in that level. The obstacles are shown in the game window randomly. When an obstacle is needed, the state of obstacle is reset and the obstacle is rendered. When obstacle go offscreen rendering and update funtions are stopped. The obstacle object is still on the heap memory ready for reuse. So there is no creating objects on the fly and then removing the references.

I have no idea if its good for how fast the game is running or not good or irrelevant? How about garbage collector is it good practise or not? I code it that way beacuse it was simplest for me because the obstacle objects are actually pretty complicated and it would be more difficult for me to code it the way of creating them on the fly randomly. And there is probably 40 or 50 objects allways ready for use? The objects are referenced through ArrayList of ArrayLists.

So is this acceptable design or complete garbage? What is your thoughts?

Was it helpful?

Solution

You should implement both options, and profile your game

(More information about profiling: JVMMonitor)

The basic idea is:

-Create objects at runtime: Better use of memory (Might not be less memory used), but slower code (Less FPS).

-Preload Objects: Faster code (More FPS), but worse use of memory (Might not be more memory used, but you use that memory for more time).

IMHO, usually the best idea is to preload the objects and images. Still, you should test your case and decide what is best for your project.

OTHER TIPS

Object reuse is the core feature of an object pool.

If seeded while loading the level they can allow for expensive object initialsation without intoducing any performance spikes during gameplay.

Where the pool size is tuned to suit gameplay and platform requirements they usually improve realtime performance.

But remember to profile, it is important to test any asumptions.

Licensed under: CC-BY-SA with attribution
scroll top