Re: The New Board

[capmikee@home.martnet.com]

On Wed, Jan 23, 2002 at 07:06:33PM -0500, Ronen Tzur wrote:
> 
> It now compiles, but is pretty unplayable, at least for me:  the directional 
> keys are not moving in the expected direction, and there's no fire key.

Right. The good news is, I think I just added that bug. I'll let you
know when I've had a look at it.

> It looks very nice, although I haven't looked at it enough to understand 
> exactly how everything works, it does seem it should make the implementation 
> of Adept much easier than the old board.

I hope so.

Here's a quick summary of the way board.c works now:

the main function is board_frame().

It looks for input. If there is input, it checks against the rules
what the result of the input should be. (by calling board_step or
board_selection). Then it stores the result.

board_step() initiates cursor movement if the step is legal.
board_selection() "commits" the selection if it is legal -
committing saves the selection in the board's data, but doesn't
update the state of the game yet. Committing includes initiating a
"slow sprite paint" but it does not include starting a field battle.

If the result has a message associated with it, the message is
displayed.

Next time the board is updated, the result is read and animations and
board updates are performed.

Animations will suspend the processing of input and results by returning
NOT_READY_FOR_UPDATE. Animations include cursor movement, "slow sprite
paint" and field battles. Each type of animation gets a priority, and
suspends other actions triggered by the same result.

Here's an example of board.c in action:

Dark teleports a basilisk onto a unicorn. An ssp is initiated, and the
result (BOARD_NEED_FIELD) is saved.
When the ssp returns control, board_update_state() is called.
board_update_state() reads the result (BOARD_NEED_FIELD) and initiates a
field battle.
When the field battle is complete, board_field() stores the result of
the battle and returns control.
The next time board_update_state() is called, it sees that the result
is the end of a field battle. It sends the complete move, along with
the field result, to the board_rules module, which updates the turn.

some other known bugs:
ssp (slow sprite paint) doesn't work
not all messages are displayed: at the beginning of the turn, the
"light/dark plays" message is missing, and when messages should appear
in sequence, only one can be shown.
revive and summon elemental spells probably don't work.

The biggest problem in my mind is the way messages are displayed. The
message area is blanked at the beginning of every turn because it's
not the result of anything. If messages need to be displayed in
sequence (like "the wizard conjures a spell", "select a spell:") they
can't because there's no queue for messages.

Perhaps it wouldn't be too hard to implement a queue of messages, but
I keep wondering if it would be better to have a queue for all types
of output events (move cursor, display message, do ssp, do field
battle). If that's something you want to implement in your general
game framework, maybe it could be integrated with the board.

- Mike

-- 
It is no longer a choice between violence and nonviolence in this
world, it's nonviolence or nonexistence.
                                         - Martin Luther King, Jr.