[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mike's patch to Rob's patch
Mike Ciul wrote:
} Hi, everyone.
}
} I've done some work on the code, and I think I'm about ready to share it
} around. Most of what I've done is in the field AI. I made some pretty major
} changes, but most of them were on Rob's todo list.
Sounds cool! Always nice when your todo list gets done by someone else :)
} Anyway, let me know how I should make the code available.
Hmm - how large is the patch? If it's less than 5 or 10 k gzipped, you
could potentially email it to the list (although maybe we should have a
separate list if this becomes a common thing). If it's larger, maybe put
it up for FTP... Is there an FTP area on SEUL we have set up (or can one
be made) for transferring/publishing large patches?
} TODO
}
} * Sometimes the game crashes with the message:
} "iface_frame(): reply is too short."
} It seems to be during the computer player's board turn.
} Needs looking into.
This happens when the board AI fails to correctly translate its intended
move into a sequence of keystrokes, and it reaches the end of the keystroke
list without having finished its turn. My local copy of XArchon has an
additional printf after that error message, saying what the computer was
trying to do... did you get that as well, or did that mod not make it into
the patch?
} * Animate all archon-theme sprites. I think only the elementals are
} animated now. Some actors, like knight and goblin, need their
} firing states fixed so they don't show two weapons at once.
Yes, we need to take out the tests for elementals in the sprite animation
stuff, and generalise the way that's done. At the moment, it assumes that
elemental sprites are animated, but have no facing (they don't have
different sprites for moving up, down, etc), while other sprites have
facing. The other sprites can be animated, by simply adding, say,
move.down.1.xpm, move.down.2.xpm etc. I feel that all sprites should be
treated the same; to have an elemental whose sprite has the same appearance
no matter its facing, simply have symbolic links from all the different
facing sprites to the one set. XArchon checks for this and doesn't
allocate space for sprites that are symbolic links, it just sets a pointer.
Ideally, I like the hard-coded names in the theme directory to be done away
with altogether, apart from a few top-level text files (like NAMES) which
actually give the complete paths to all the sprites.
} * Adept game. I don't know very much about Adept, so this is a low
} priority for me.
Fair enough - I guess it falls to me, as the one who started it :) OTOH,
should I post my summary of Adept (a la the one I did for Archon)?
} * field rock collisions are annoying. You can get stuck on rocks, and it's
} hard to walk by them since they stop you even on a diagonal.
} here are some ideas:
} rocks push you away from their center instead of stopping you.
} If you hit a rock, your direction changes by 45 degrees.
I like the 'push you away from their centre' idea; it means that you'd
bounce off the rock like in the original if you walked straight in to it,
but you'd be shunted around it if you only glanced past it (as opposed to
in the original, where you were moving back some short distance in the
opposite direction to your current movement. You could get stuck
'bouncing' off a rock indefinitely, even though you were walking past it
diagonally and had just caught the corner pixel).
} * The original game had 2 kinds of obstacles. I assumed the second kind
} were trees or hedges. I think their cycle was twice as fast as the
} rocks. Should we add them?
Did it? I don't remember them, but you could be right.
Have fun,
Rob R.
\((/
~oo~
/))\