When working in a 3D environment it can get expensive to create both a 3D and 2D version of your loot for your game. I have a theory that some games solve this problem by simply throwing the 3D object into your games UI. Games like Borderlands seem to work this way, but 3D objects in themselves are more expensive to create than 2d objects. And if your in a position like we were, were we are buying a lot of our assets, that means there are a lot less 3D objects to choose from than there are 2d options.
Some games solve this by having a standard 3D object that will hold anything. Kingdom hearts does this. They have a money orb, a health orb, and an item orb. The fact the item orb can be anything, is really a way to escape making a 3D version of the loot.
Still other games like YS 8 as an example get around this by using an old trick called billboarding and just displaying their 2d graphics in the game this manner. Billboarding is basically the effect of making the sprite always face the player. That’s how you get games like Paper Mario where you can still move around a 3D environment without the 2d being much of a hassle.
And finally you have the cheapest of all of these options…just don’t show it in world space at all. Atelier Ryza: Ever Darkness & The Secret Hideout went with this option. Which while effective, felt kind of like a disappointment for a game centering around collecting items.
Looking through all these options, we ended up going with the YS approach & billboarding it. But of course, the age old technique had to be updated a little bit for our particular situation. Always looking at the camera is great and all when there is only one camera, but in a local co-op game there are two cameras. To solve this we created a billboard class that would scrape the sprite renderer component & create two children empty game objects each with two components on them: a cloned sprite renderer and a face camera class. Each object was then properly named so we could track it for debugging and given a different player’s camera to track.
The next problem with this approach is the fact that if you have two sprite renderers going on at the same time and the players stand perpendicular to an object, they can see both at the same time on the same camera.
We had to solve something similar with the floating health bar. And that was solved by making two layers. P1_UI & P2_UI and if we do that with this….well it works, but then causes the problem of showing through anything that’s in between. Our UI layer is painted on top of everything else. So of course, the solution ended up being making two layers specific to the cause. P1_Billboard & P2_Billboard. I can only imagine the issues that would arise from having 4 players. There is probably a more efficient way to filter these things without just layers from the camera, but I have not run into any and have not dedicated the time to researching exactly how the camera filters outs what it does and doesn’t display well enough to theorize a solution.
Of course these are the kinds of things that make big budget games not able to just simply ‘add co-op’ in the middle of development. A game that’s going to have local co-op has to be built with that in mind from the get go. That way every feature that gets added in is co-op battle tested rather than the other way, where you’d add co-op and then have to re-write all your features.
If your interested in how we get a loot magnet working on this. You can read about that here.
