Today Iâ€™d like to talk a little about resource and asset management in our little project: Star Force Battleship. Remember this is an ongoing series so if you missed the first episode, you can find it here.
We basically have a few different types of assets to take care of, and ideally, we want everything to be loaded once at the same time so we donâ€™t have any hiccups during gameplay. Hereâ€™s a simple breakdown of our assets:
- Models exported from Max.
- Dynamically created geometry.
- Compiled FLSL shaders.
- Music and sound effects.
Of all this stuff the most important ones are the models, textures and shaders, mostly because thereâ€™s quite a lot of processing before theyâ€™re sent to the GPU and, again, we donâ€™t want that happening during gameplay. To make things even more interesting, we canâ€™t just create an entire couple of geometry / material for every single bullet / enemy we have because theâ€™d be just too many and our resources on mobile are already pretty scarce.
The loading process
The loading itself isnâ€™t very special: We just use [Embed] on most of our assets except the sounds and then we start creating the resources we need. The first thing we create are the materials that are the ones that take longer to be sent to the GPU.
Thanks to FLSL we can create very cool effects in a very optimized way, with the best examples being the scrolling background, the â€œcylinderâ€ texture and the animated explosions. Just in case you donâ€™t remember how the game looks, hereâ€™s a commented screenshot:
Letâ€™s take the scrolling background material for example. We load it like this:
We tell Flare3D to load the texture and then we create a new FLSLMaterial that contains a 2D sampler called â€œtextureâ€ that will hold the texture we just started loading. Finally, we upload() the material by hand. This is very important: Flare3D, by default, will only upload material buffers when theyâ€™re actually used. While this is a reasonable approach most of the time, specially on desktop computers, here on mobile that would probably freeze our game as soon as we enter the level. By calling it by hand we make sure that by the time we finish our loading state, everything is ready to run.
Something similar is done for our dinamically-generated meshes like the bullets: We create a single Plane instance that will be cloned later. Something like this:
Simple stuff right? Once this mesh is created and uploaded, cloning it to create our bullet pools isnâ€™t as costly as creating and uploading a whole new instance. But pools, my friends, is material for another chapter of this adventure. Let’s call it a day for now
Stay tuned for more!