I've been working on a very important feature of the code this last week or so. I figured I'd share some of the details here.
One of the biggest advantages of Unity is its editor. It is not without its issues, but it does at least allow quite extensive customization. This is important for me as an indie because I'd rather write the game than have to write tools to make the game. So anything that gets me the tools done faster is better.
I realized something when I was working on a "EnergyProvider/EnergyConsumer" feature for the game. It struck me that I was dealing with simple resource flows and that rather than use type specific resource producer/storage/consumer why didn't I abstract the interface so that ANYTHING could be produced/stored/consumed. This realization then led me to another epiphany. If I think of a resource as a unit of something, then surely I can think of the specification of those resources as an "Inventory" of sorts?
Once you start thinking about it in those terms, it becomes clear that most resource flows, either via trade, craft, production or whatever, are simply inventory transactions. So in order to "produce" something, all I needed was an inventory with the goods to replicate in the resourceproducer object (whatever that ended up being) and an inventory to receive them.
So I've been looking at a number of inventory systems, both available for Unity and out there in the wider game development sphere. It turns out that nobody seems to have really detailed the features and functionality of a good inventory system. At least none that I can find.
I've made an inventory system previously but I was never quite satisfied with it. At its core it should be relatively simple to make one. But there are a lot of little issues to do with things like stacking, how to apply "effects" when things are stored in the inventory etc. But leaving that aside, I started developing the basic inventory system support code first.
Items are the "templates" of things. The "ItemBase" class I created is an abstract notion of what a specific object entails. In the simplest case, it is a data description of how to put together an object used to represent the abstraction. I used the ItemBase class as the starting point for all items, be they tools, clothing, food, props, etc. I knew that I would be spending a huge amount of time defining items, because ultimately the game is greatly involved in the production/trade/consumption of items.
So I created this Item Database Editor:
The Item Database is a game-wide storage of all item base instances. Basically it stores all item definitions, of which there will be many tens of thousands potentially.
Of course these definitions are not useful by themselves. So the next part of the system is the "InventoryItem". This class deals with specifying a count of a specific Item within an inventory. So in essence, an Inventory is simply a container with InventoryItems in, that each specify an ItemBase and a Count value. Of course its never quite that simple, because of the effects that need to be handled as Items are added/removed from an inventory (for instance, you might get a special feature added to your player if you add a specific item to the player inventory).
The fun comes when you start thinking of other uses for Inventories. They are merely containers for counts of items after all. So lets think... What is a recipe? Well, it takes N number of input ingredients (i.e. an input inventory) and produces an output (i.e. an output inventory). What about trade? Well, trade is basically transferring one sub-inventory from its parent and adding it to the inventory of another. Resource production? How about adding an Inventory to another Inventory at a specific rate? Resource consumption? simply subtracting a count of items from an inventory.
Hopefully by now, you realize how much of an important part of the game this is. Having useable inventory handling really opens up quite a lot of gameplay.
So right now, I'm working on UI to actually display the contents of an inventory in a rational way (which isn't easy given Unity's poor UI tool choices). Once I've got a way to show an inventory in a panel on screen in a reasonable way, I can add on top some of the more usability related issues I've seen with other Inventories. As you might be able to make out in the Item Database Editor shot, I've already got stuff like name filtering sorted. It turns out that C# and specifically LinQ makes this kind of thing really quite trivial.
The other big thing we've been working on this week, is to nail down the final shader solution for the shack buildings. Tim has been trying to find a solution he likes in Maya, which I will then turn into a realtime shader in Unity. Its probably fair to say we aren't quite there yet. Here's what the current version looks like (with placeholder mask textures for the rust/diffuse transition).
Anyway, quite a lot of work this week, even though its been like working in an oven here in the UK (we aren't used to heat at all and have no air-con).
Til next time!