I admit I got distracted more than I wanted to this week, however, when I was able to focus, I was able to get some solid progress done on the inventory UI.
Equipment Slot Blocking
This is pretty simple (in concept anyway). When you’re dragging and dropping a sword, you shouldn’t be able to drop it on the chest equipment slot. I took 2 approaches to this:
- I implemented a visual cue so that it was clear as day that the slot wouldn’t be able to be used. You can see that in the above GIF, where when I select a particular item, all slots that it cannot go into are grayed out.
- If you hover the selected item over a slot it cannot go into and release the mouse, the item will just go back to its starting slot.
So with these 2 implementations, there is now no way, from a UI perspective, that an item can get put into the wrong equipment slot. I stress the UI perspective because as of now, from a straight coding perspective, there is nothing blocking it. That will be something that is addressed when I tie both the back-end and the front-end together.
Double Clicking Equipping
Again, another pretty simple concept. If you double click on an item that is sitting in your inventory, if the corresponding equipment slot is empty, the item will automatically be set there. You can see that in the 2nd half of this post’s GIF.
At the moment, if the equipment slot is occupied, nothing happens. I’m not entirely sure what the functionality should be, so I’m just going to leave it at the moment.
Look at that, another simple concept 🙂 Yeah, I searched around for some SFX for moving items around the inventory, and came across this package pretty quickly: http://opengameart.org/content/inventory-sound-effects.
It’s sort of hacked together at the moment, and with the existing SFX I already put in a few months ago, it’s clear I’m going to be need a real, global solution pretty soon.
Some people might be asking why I have spent time this month working on an inventory system. In fact, I’ve had a co-worker who’s also working on his game question a lot of the development decisions I’ve made thus far. He thinks I should take advantage of the Unity Asset Store more, since many of the systems I’ve created already exist in some form.
One reason is because I never want to be tied to a system that I don’t have control over. By that, I mean… Look, life happens… People put out assets and then you never hear back from them. Unity puts out a new release, their asset doesn’t work anymore, and they’re never going to come back to update it. Now, I know that many of these systems come with the source code, but the truth of the matter is, I don’t want to be responsible for sifting through someone else’s code in order to update it if it comes to that.
The other reason is one I’m not ready to talk about at the moment. But I’m going to need as many of the systems written in a way so as to support some formats I’m going to using in the future. And that’s all I’ll say about that 🙂