New this week

This week I created a very basic UI. The UI relies heavily on the events which is something I have little experience implementing and using.

UI

The biggest problem with creating UI was getting the UI to update only when it needs to. To solve this I used unity events. The easiest way to describe this is with an example. The ammo counter on a gun doesn’t need to be updated every frame. It only needs to be updated when the value changes. The only times an ammo counter value changes are when the gun is shot, the gun’s special used (as some may require ammo), a reload occurs or a weapon is changed. By having an event trigger when any of these things happen then having the UI manager and HUD script subscribed to them, we can update the ammo only when it matters.

An unexpected difficulty was getting the various timing systems and converting them into a percentage. If I had used a deltaTime timer for all timings it would have been a trivial problem. However because the gameobjects are disabled when changing weapon I elected to use a timer uses Time.time instead. As these functions regularly even when the game object is disabled.

Converting these to percentages was pesky as additional variables had to be implemented. I needed an additional start time which records the time at the beginning to determine how far through the duration it is. Below is the prototype UI, one as neutral, one with all bars active.

As you can see, it is disgusting. However, that is not the point. The point is to see how well my system integrates and how I can make it integrate better, with Unity’s UI. So far it seems successful. Theres some more things I need to test but for a basic UI that displays all useful information its good enough. Some features involve, Disabling bars once they are full (to not clutter UI) and that’s about it.

Miscellaneous

As my foray into animation ended and UI began I took the time to clean and bugfix many things. The major of which is I updated my object pooling system. This was updated so that the objects being pooled didn’t have to be assigned manually. Whenever an object is called from the pool, a check is made, and it is added to the pool if its not their already. I was planning on doing this for a while since I knew it wouldn’t be realistic for feasible to pool everything including items that may not appear in a run. The way it is done now I may need to improve in the future. Currently all pooled items are spawned the moment 1 is called. It seems to work fine now but may cause lag spikes on different systems so if the need arises I’ll change it so objects are progressively instantiated. A lot to do with this cleaning had to do with unifying persistent objects and opening the path for scenes without a player in it. For example, a main menu. This is still in progress and is next on the agenda.

What’s next?

Next on the agenda is making a basic main menu. This will serve solely as an entry to player absent scenes. Much like the UI it’ll be disgusting and ugly, but it’ll exist solely to test functionality. Aside from this I may work on a on screen message system. Something like a killfeed but for any message. This’ll help debug items with specific effects and give early testers feedback on whether an item is working or not without complex UI.