Since in battle-chess you really only move one piece every turn/frame, the answer could simply be to store the change somewhere and send it to the DrawFrame() function. I must admit though that it feels like an ad-hoc solution and would likely not work as well for more active games. For example, it would not work if you wanted to allow players to skip the animation by pressing some key at any time (unless you check for input while animating, but this could make your code a bit messy).

Well, it would seem that you would need to decrease the time-step between renders, i.e. a move would not occur in a single time step but would be drawn out over several frames.

The answer though lies in the type of game you want to make. In a TBS game you could make moves animate them at the end of the loop. Animation would then proceed as outlined above (send the change). For more real-time games, you would need to have position variable for all entities in the game and update them each frame (keeping the update small so you don't get the same problem as with chess).

I think that for what you are looking for, you need to make gameplay independent of your display. Each frame needs to call your DrawFrame function. Somewhere in your program you will need to maintain a list of animations that are being displayed. Each animation should itself know where it is being displayed on the screen, and which image to display. So your game loop will go something like this:



The important thing here is that your animations will also need to know how long it should take to complete their animation, not in frames but in real time. The animation code should be able to interpolate the movement and frame-flipping of the image on the screen. This will create a frame-rate independent display.

Quote:Original post by Boris Karloff

while (!quit){	// Handle Input	read starting and destination position		// Update	Chessboard.movePiece(startPos, destPos)		// draw	DrawFrame()}

Let's start here. You have too much cohesion between your main loop and your program logic. You want a higher level of abstraction that passes user input to the chessboard system, which then resolves piece movements, delegating actual animation of the pieces to the pieces themselves.

The Piece is responsible for animating its transition from its initial position u to its final position v over an interval t. Piece::moveTo() sets this transition in motion, but Piece::update() is responsible for the step-by-step movement. Board::update() calls Piece::update() for each of the Pieces it stores. Board::state() returns a representation of the state of the Board (the positions and animation indices of all Pieces) that is ready to be rendered. Board::ready() indicates whether user input can be processed by the Board (obviously, it returns false while any of the current user's Pieces is moving).

Here's how I'd do it:

Suppose you have an array of all of your pieces. Each element in the array is a structure that holds information about each piece (rank, position, animation_state, etc).

So what you do is you trigger the animation state when you want a pice to move. You would also probably have some other variables in the structure, like destination_square or animation specific settings so that your animation function will know how to animate the piece.

Then each time through your main game loop, you check every piece on the board and see which ones need to be moved. The ones that need moved, get moved.

In chess, only one piece moves at a time, so I would probably just halt all other processes in the game until the piece has finished animating. Basically set game_state = ANIMATING_PIECES; Then once the animation has finished, set game_state = WHATEVER_THE_USUAL_STATE_IS; That way the usual stuff will not execute until the Animation has finished.

since this is battle chess, I'd probably have a game_state called ANIMATING_BATTLE. Then the battle animation can execute while everything else is halted.

basically like this:


switch(game_state)
{
case WHATEVER_THE_USUAL_STATE_IS:
{
/*The usual junk
would go here*/
break;
}

case ANIMATING_PIECES:
{
/*Code to animate a move*/
if (no_more_anims)
game_state = WHATEVER_THE_USUAL_STATE_IS;
break;
}

case ANIMATING_BATTLE:
{
/*Code to animate a battle*/
if (no_more_anims)
game_state = WHATEVER_THE_USUAL_STATE_IS;
break;
}
}


This is most likely how I would do it, since chess is a turn based game. Everything happens in order. In a real time game, you would be constantly doing the animations so this wouldn't work.