Things for this update:
- Multiple items carried by units
- Auto harvest and all drop off
- Visual cue for harvested nodes
- Harvest Animal action
Multiple items carried by units
A unit can now carry any number of different stuff as long as they have the carrying capacity to hold it. Watch as this man carries a ball of water with his bare hands, a pile of berries and a wooden log.
Yep. The wooden log completely dominates the graphic. It is like all encompassing poop. Poop looks bad. I will have to make this look nicer later.
Auto harvest and all drop off
A unit will automatically go back to harvest nodes of the same item type (without care about material type, I'm not sure if this is good or not but playtesting later will reveal this UI choice). They will also drop off everything they are holding. They only check around a node up to a distance of 2. Because I intend the game to be about regions, I will eventually change this to have them look for a non-empty resource node of the same item type in a region. I may, after that, think about how to optimise that check.
Additionally, I still need to make a "right-click return". That is, I need to detect that a user has selected units and that the user clicked on a building. Then I should queue a drop-off action. I want to reuse the harvestNode action, so I've added a setState on the action in preparation of this. Essentially, I'll queue an action, set the state to drop off and then when the units are done drop off, they'll see that they are done harvesting and thus finish off the action.
I'd put in a pic but it wouldn't mean much :) Essentially, I queue up a harvestNode action for a unit, put it at drop-off state and give it a dummy resource node. When the unit completes drop-off and checks to see what else there is harvest it will see that they have a dummy resource node and then immediately stop. Any units with nothing simply move toward the building.
Visual cue for harvested nodes
After a tree, bush or grass is harvested, the user should see some visual confirmation that yes this stuff has been harvested. Additionally, I am planning to have stuff regrow on the same spot unless you destroy it, plant something else over top etc. What do I mean by this? Say you chop all the wood from a tree, it becomes a tree stump. Next spring when trees regrow, some of those stumps become full trees again. Automagically.
Right now, all these objects are created via batched geometry because they are many and they do not move. Unfortunately there isn't an easy way to update this with the basic staticGeometry offered in Ogre3d. You basically have to call reset and then add back all the entities. In addition, the visibility rules for individual entities will NOT be respected because it makes whole groupings visible or invisible. Rebuilding small staticGeometry may not be overly expensive but it is certainly suboptimal but I've not yet found a better solution so I'll leave it as is (ie. poop). Whenever you exhaust a resource node it turns into the exhausted entity, which really means I remake all the entities for a forest and then rebuild the staticGeometry object. If later I find that causes FPS to drop below 60 then I'll do something better.
Harvest Animal action
The harvest animal action requires several components:
- Combat Stats
- Combat Resolver
- Death
Combat Stats
Many things will share similar stats for combat resolution. This means hp, damage output, damage types, resistances and of course, everything that affects those stats such as equipped weapons, armour, skills, magical blessings and so on. In another project we put this all into a single object. I'm going to mimic that here as well. We'll start off with just hp and damage. Simple enough for what I need right now.
Later on, this class will also keep track of all equipped items (weapons and armour) as well as magic (say a unit has stone skin cast on her). The combat resolver (discussed next) will then grab a unit's combatStats object and from there go combatStats->getDamage() or something along those lines. This means a unit could be carrying various weapons but only equip some of them. On top of this, a unit may choose to switch through weapons during combat (wasting some amount of time). In essence a unit would do something like combatStats->unequip(int slot) and then combatStats->equip(int slot). This will be useful later to mimic basically any pre-industrial soldier. If you learned your history you might know that soldiers back in the day carried "whatever-the-eff-I-have" package of equipment, most of which was owned by themselves. We, today, might picture an a middle age "archer". But really, back then, even English longbowmen carried significant melee weapons and armour because no battle was ever decided by arrows alone (and most were not decided by arrows at all).
Combat Resolver
The combat resolver will be a class floating somewhere in the nether. Like pathfinder, it sits out there to perform resolution of actions. In this case, it will be harvest animal and later for attack action. When a unit reaches another it will attack it. It simply calls combatResolver->resolve(unit* attacker, unit* defender). This then does a one-way damage calculation. Whether that unit hits back is entirely up to that unit to queue up an attack action that has this unit as a target. The main reason I do not have this as a two-way damage resolution is because the other unit might be doing all sorts of stuff. Imagine playing Starcraft and watching your marines fire on enemies. It's a one-way package.
I intend there to be more than one type of damage that can be dealt in the future, so there may be a loop to get an array of damage types and then figure out the other unit's armour and resistances and then apply the damage and reduce hp. In any case for now, just one damage stat.
Death
I have a baseUnit class so I intend to have something like: "virtual void death() = 0;". Then units and structures will code their own death. When they die in the combatResolver, this is called. So basically they get taken out of a faction's unit or structure list, they are replaced by some corpse and their carried and equipped items will then be added to it. Then you can loot the body. Maybe some of the equipment gets broken and is unrecoverable (or becomes salvageable/repairable items).
ME PUNCH GAZELLE FOR MEAT!
Things for later
Leaking Memory
Right now I have some issues with reference counting before I can delete objects so those things are just plain leaking. I will have to use ref counting and likely I'll just use Ogre's pointers (so that I don't have to touch Boost itself). Leaking memory is like leaking poop. Very bad.
Combat visual cues
For combat visual cues I'm thinking something along the lines of Exile (if you know that indie game from Spiderweb Software). Basically a number inside of a bloody splat atop of a unit which indicates damage done. The colour of the splat changes depending on damage type. It should disappear after half a second.
Reactions
We'll want units to react to being attacked. Animals should flee (have a target attacker and just greedily path away). Units should fight back.
PathFinder
Just a bit of code clean up, right now the only pathfinding I coded was greedy. I am going to call it "greedy" and then also have an A* in there as well. That'll be useful for when reusable paths are created (such as trade routes).
I'd like units to naturally spread out instead of standing on top of each other. This mimics Starcraft like behaviour.
There should be a sort of exit condition for getting as close as possible to a target location. This helps if the actual spot you want to move to is blocked somehow, or the path is impossible then they should move closer but then stop. This is similar to any game where you tell a unit to move to somewhere impossible. The greedy algorithm is an acceptable problem (where the unit moves at all toward an impossible location) and is sometimes desired (you want a unit to move closer to a spot even if they can't get to it).
Item Weight
Right now all items take up the same space. I think I need to add item weight. Everything raw will be the same. It's more about finished products such as military equipment. Otherwise you could have a single soldier huffing about with fifty swords and well that just doesn't seem right. Maybe more like five swords.
std::shared_ptr to the rescue?
ReplyDeleteThat or it's an indication of a major design flaw and it's more of the latter. :P
Delete