Bug fixes
October 30th 2011 -
I put in a good few hours of bug fixing on the weekend. The Firefox 3.x version bug was particularly frustrating because Firebug is flaky when you try to run 3.x and 7.01 on the same machine. alert() got me enough of the way to realise the problem.
The barrels now don’t disappear when you stand on them, and items that are hidden due to low light levels (rather than point of view being blocked) are rendered as black rather than not at all, which was the original intention. Should make everything visually less confusing.
As for the zombie bug – ah, that was one of my favorites, an iteration through an array that was changing. I was previously looking at the square the avatar was on to see if any zombies could see it, and then moving the zombies. However, the fact that the zombies moved changed the “this is what can see this square” list. So it was a real bug. I decided to fix the movement algorithm anyway, because it violated my design principle that all the levels should be deterministic and that the determinism should be apparent to the player.
So, here’s an example of the problem. You’ve got two zombies that want to move into the same square. Which one gets to move into it?
a) a random zombie (bad!)
b) the zombies are in a fixed order, and that order is apparent to the user (eugh)
c) the northern-most one goes first, then the eastern one, the southern one, then the western one. Or some variant. This is deterministic but a pain in the neck for the user to remember.
d) neither zombie. They are very polite (ok, but perhaps something a little less peaceful?)
e) both zombies. They occupy the same space (yuck)
f) both zombies. They kill each other. (cool!)
Actually, I went for a combination of d) and f), with the side benefit that the polite monsters will give way to the aggro monsters. I want an algorithm that doesn’t just work for zombies, of course. Some of the monsters will give way. Some of the monsters will happily fight other monsters. So I wanted some generic parameters I could attach to each monster type that determines its behaviour.
I also wanted the monsters to be able to choose when there was more than one target. If all its enemies were in roughly the same direction, it should head towards them.
It was quite a bit of work, even with the most basic of “as the crow flies” path finding. I could no longer go through a list and move each monster. I had to compile a list of where everything wanted to go and resolve any conflicts. Anyway, it all seems to work now, but I’m really going to have to write some regression tests soon. Testing is a pain.
DaveMc Says:
October 31st, 2011 at 12:03 pm
Could you use the direction the zombie is facing as an extra cue to make the determinism apparent? If the zombies face the direction they would move if the player stood still next turn (instead of facing the direction they just moved, which I assume is what they do now), it might make some variant on c) more palatable.
Just a thought.
admin Says:
November 8th, 2011 at 2:43 pm
That’s a good point – I’ve put in code so that the zombies face according to the direction they *want* to move, which is a nice indication of what’s going on, and a good deal creepier to boot. In some cases, though, there are still conflicts that have to be resolved (unless I’ve misunderstood your point). I quite like the “aggressive” and “passive” monster behaviours, which the player can take advantage of.
One thing I’d like to do is show the moving (well, sliding like chess pieces, for the moment) from square to square, which will hopefully motivate the passive behaviour better (ie. show both monsters “bouncing” off the square).