I’ve been categorizing and refactoring unit deaths in the game. Made this comment block in the code. Might be interesting for you to see it too:
// Killing of a unit is done in 4 big steps
// 1. KillUnit - unit is doomed to die (could be next tick, if unit is doing exchange).
// - Fire event
// - Register statistic
// 2. KillInternally - we can kill it now (exchange interactions are done)
// - Abandon old tasks
// - Create and execute Die task (exits house, shows animation, takes ~20 ticks)
// 3. KillFinalize - erase all unit data and hide it from further access
// 4. Delete - when unit has no pointers left
// KillUnit usages
// A L - gic_TempKillUnit (kills any selected unit)
// S G - UnitOwnerChange (from script, or capturing a wagon. Kills old and creates new)
// A/S L - ScriptingActions.UnitKill (kills any unit)
// S L - CheckAnimalIsStuck (kills any stuck unit)
// A L - Unit.HitPointsDecrease (killed by enemy)
// A L - fCondition <= 0 (any unit could die of hunger any time. training units get their condition topped manually, yet script can reset any condition back to 0)
// S - - TrainingCancel (kill wip unit)
// S U - UnitTrainingEnd (kill Blank unit)
// S L - FindPlaceForUnit fail (extra units get killed when house is destroyed)
// S L - DeleteUnit (by MapEd)
// S - - TKMUnitTaskDie (final result of Die task)
// S C - TKMUnitTaskWagonGoHouse (wagon entering house)
// A - animated death
// S - silent kill
// L - Lost
// U - Upgraded
// G - GivenAway
// C - Consumed
I had some doubts about how to handle “Skirmish” setup in MapEditor. Cos there are plenty of ways for Skirmish maps to be made made “unfair” (placement of resources, dynamic script, etc..). So I thought that maybe the MapEd should not be so strict about the “Skirmish” setting …
Ideally I’d want to pop up a dialogue with settings – which aspects of the mission should be (or should be not) equalized. So the setting is more helpful than restricting. But that would take some time to implement ..
.. two hours later ..
So what “Story/Skirmish” does now is just sets the flag to “Story” or pops up a “Skirmish setup” menu. Actual Skirmish “equalization” happens in “Skirmish setup”, where you can choose what to “equalize”.
New settings could appear there later in development (e.g. indicators of existing unfairnesses or more detailed descriptions, or something else related).
There’s one more feature I want to include into Alpha 8 – terrain triggers.
Terrain triggers are special zones placed in MapEd, that trigger dynamic script events when a unit enters into the zone. This is very helpfull for story missions scripting. With that feature, events could be triggered once and then removed/disabled if not needed.
After watching second part of Knights Province play (https://www.youtube.com/watch?v=33tjOSoJfNQ) I’ve decided to look into house notifications. As of Alpha 7.1, they indicate when a house if missing a worker, or a connecting road (these are 2 very popular situations for new players). In Alpha 7.1 those notifications are rather vague and easy to miss in the background. So I’m drawing new icons for them. Here is the style:
Icons are good at attracting attention, as they should, but I’m not entirely happy about the style – it looks a bit “artificial”.
Key thought on the matter:
games do have artificial elements all over them (take “magic” GUI for example).
a town with dozens of these icons could look “crowded”.
this is an RTS, genre where you need to manage a lot of different things and every help from the game is appreciated.
“float-above” notifications are more affordable than arriving messages, which need to opened, read, clicked “go to”, finding an outlined/highlighted house and only then seeing a problematic house.
perhaps notifications can become houses “thoughts”. I need to think more in that direction ..
Until then, this is what I’ve been working on today (and refactoring controls render overall) 🙂