Day 11

Yesterday’s post was a bit of a cop out. Truthfully, I just haven’t been in the humour of working on the game these past few days. There’s not a lot you can do when that happens except try to work through it – it’s just a shame about the timing.

Today didn’t go particularly well either, though it did go slightly better. I’ve been thinking about the game’s plotline and I’ve now got a very good idea how the first two hours are going to play. I think that’s a more realistic target than trying to do the whole thing (particularly when I’m working at this rate).

I also did a little coding today. For a start, I fixed that annoying targeting bug – it was quite straightforward to fix after coming back to from a day off.

This blog has been very “I did this, then I did that” for the past few days, so just for giggles, I’m going to go into this problem in detail! To give an example of what was happening, say an enemy chose to use the “standard attack” action, which (at the moment) looks like this:

#animation xoff, yoff, type, startframe, length, speed, refrain, z-order;

action Attack{
    frame 13;
    animation 0, 0, 0, 0, 2, 2, 2, 1;
    damage 120;
    wait 10;

In this case, the first action command is “enemy”, which tells the engine to define a targetset like this:

}else if(battlecommand=="enemy"){ 
  for(int i=partysize; i<totalbattlesize; i++){ 

(i.e. it fills the targetset array with the npc numbers of the enemies.)

This is all well and good for when a hero is performing the action, but when an enemy does it, it’ll mean that he’s attacking his own party – not what we want. So there’s a quick routine to fix this before the commands are processed. Namely, we switch around the command to select the appropriate targetset.

      if(battlecommand=="ally"){ battlecommand="enemy";
      }else if(battlecommand=="allies"){ battlecommand="enemies";
      }else if(battlecommand=="allysplit"){ battlecommand="enemy";
      }else if(battlecommand=="enemy"){ battlecommand="ally";
      }else if(battlecommand=="enemies"){ battlecommand="allies";
      }else if(battlecommand=="enemysplit"){ battlecommand="ally";

Seems straightforward enough, right? I spent about half an hour on it on friday evening trying to figure out why it wasn’t working, before I eventually gave up and just went to bed. It was a particularly confusing bug – sometimes the engine would get the targetsets the right way around – and other times it wouldn’t.

Turns out the problem was really stupid, stupid enough that I found it very quickly when I started coding today. All the information is there, so I’m leaving it as an exercise for the reader, if you’re so inclined. 🙂

With this fix, and the other additions I made to the targeting system (that “quick graphical thing” actually turned out to be a pretty big deal), I’ve now whittled down the engine additions to one final item.

from, like, ages ago:
Here’s what’s left to add to the “general” side of the engine:

– Battle animations
– Reading battlescripts and itemscripts from a file
– Full implementation of all the target sets

– Status effects

Today marks the end of my first week working full time on this, and I’m honestly not all that happy with how it’s gone. The way I see it, though, it’s no big deal to slack off a little in the first week. To do so in the second week, however, is unforgivable.

* 1 Comment

1 Comment so far

  1. Terry on February 19th, 2007

    Really, no one? It’s an interesting problem and the solution’s there if you think about it.

    Oh, ok. Read on for the answer.

    It’s really quite simple. The engine was reversing the action direction for enemies correctly – the only problem was that it was storing the changes that it had made. So the next time that action was run, it would see the wrong targetset, reverse it, and as a result would appear to be doing nothing. (Whereas really, it was reversing the targetset twice.)

Leave a reply