So I’m pretty close to getting objects/npcs/creatures working in this thing, at least on a preliminary level. Trees are back running under this entity system, and I have some hardcoded items that make use of specific assignments to create the effect of picking up an item and having your stats modified.
The meat of the system is the Entity() class, which controls worldmap-related entities–trees, monsters, and so on. In terms of a top-down tile based game like this to create an entity there’s a few things you need:
An image to represent it on the screen
any important statistics
what happens during a collision
some sort of update package
This is all in terms of worldmap-based entities; inventory items, once they’re in the inventory is simply an array of data and nothing more.
But essentially the above items are created and tracked through the Entity class; initialisation sets a self.type parameter to indicate what type of entity we’re talking about–currently a tree, item, and closed door are the 3 available item types. A tree doesn’t do anything–it acts like a fixed sprite on the gamemap that matches the worldtile it should be on with each update pass.
However the closed door entity, for example, is a little more useful–it has a certain set worldcoord pair, it has no update package, and when the player bumps into the closed door, it deletes itself and reveals the underlying tile–that of an open door picture–thus giving the effect of what looks like a door opening. So what really happens in the game is that when you open a door, you aren’t actually setting a door’s status to Open–you’re deleting the door instead. Closing the door can be handled by creating a closed_door type Entity above the open door tile when the player presses say, C to make it look like the reverse just happened.
Similarly, when you run across an “item” type, “item” has a property of self.stats, which is a simple string of say, “136”. When the player bumps into that, you call player.inventory.additem(“136”), and the 136 is essentially an address to a config file defining what item type to add: 1 is the item’s equip location, 3 is the armor material, and 6 is the armor quality. Then a separate process handles playing with Player.inventory to add the right stats and names. Once that gets loaded into player.inventory, we delete the “item” entity from the gamemap, and print a message saying you picked up something. To give the effect of dropping an item, we simple reverse the process–create an address for the item, create an Entity.item, give it the id of “136”, and set it’s position to a nearby tile and pop out the data from the player’s inventory stats.
Though I havent yet implemented it, this will give rise to a really flexible entity system after I generalise all of this out. Instead of having a .type of “door” and .type of “item”, we can give an Entity the properties of “disappears when collided” for a door, and “disappears when collided” and “call additem(addr) when disappearing” for an item on the ground. Later on, I imagine I’ll be able to add an Entity with properties of “disappeared when collided”, “call additem(random) when disappearing”, and “move towards player during update” (or perhaps a more general “figure out what to do during update” function) to simulate creature behaviour and getting stuff off its body afterwards.