I thought I’d take the time to share my implementation of the Snowspeeder movement in Hoth Strike.
If you’ve played the prototypes of this game you’ll notice that the speeder is restricted to vertical movement. It sits static in the centre of the playfield and everything else moves around it. All sprites in the game have a speed attribute, including the speeder, but it simply ignores it. The player’s control of the speeder directly affects the ground speed (nGroundSpeed). Consequently all sprites react accordingly to the speed of the ground.
The AT-ATs walk at ground speed. Anything other than this would just look awful since the sprites would appear to “slide”. I hate that. The Probes use their speed attribute but it’s generally set to about 2 or 3 pixels. The explosions move North (0) only but like the Probe and AT-AT are directly affected by the ground speed. In short, when the player moves East (2) or West (6) across the terrain the ground speed increases and this is incremented to the other sprite’s x attribute. It’s quite simple to control.
But how do the player ship’s controls work ?
The firing of keyboard events is key.
onkeydown is used to trigger player input and onkeyup is used to cancel any player input.
If the left or right arrow key are pressed and the onkeydown event is fired I consider increasing the ground speed and moving everything in the appropriate direction. But there’s one catch ! The speeder might be moving at full pelt in the opposite direction. What I didn’t want was to snap the speeder to the other direction. It leads to an awful emotional response in the player and to be honest is quite a cheap trick. What I wanted was Defender‘s smooth sliding. To achieve this I set an attribute on the player sprite – object.slowingdown.
So when the keyboard fires an event to move the speeder East or West I now check to see whether the speeder is in the process of slowing down. If it is I ignore the keyboard input. The impact on the player is minimal since the slowdown process is fast. In fact slowing down the landscape happens quite rapidly. I literally decrease the nGroundSpeed value by 6 pixels a time. I didn’t want the speeder sliding for miles before the player turned around.
In the game loop I watch for the slowingdown attribute and wait for the ground speed to reach just 1 pixel. Then I open up the controls to the player again. In the mean time I have registered the thrust attributes object.leftthrust / object.rightthrust accordingly.
The game loop flags the end of the slow down and instantly looks for the thrust attributes. If it finds them the speeder is instantly accelerating in the opposite direction.
One final thing to consider is the player opting not to thrust during the slow down. To cover this I set a object.cancelleftthrust / object.cancelrightthrust value so that the thrust code in the main game loop could override the thrust values if necessary when the onkeyup event fires.
I have played with the values quite a bit and in some cases the speeder slides beautifully for about 2 or 3 playfields. As enjoyable as this was from a spectator’s perspective it was hellish for the player. So I did 2 things. I increased the brake power of the speeder and widened the playfield. (It was originally 640 px wide and is now 950px wide). The effect is that the player can thrash it left and right and quickly respond to a probe coming in to view. Very, very satisfying to descend on a group of probes and blast them all to hell !
The Empire Strikes Back’s early sequences had some incredible photography. As a kid I was blown away by the emergence of the AT-AT walkers. I remember thinking that the cinema screen must have been a mile wide such was the nature of the shot. The imperial walker’s were stunning set against the snowy vistas of Hoth. I wanted the same sensation when playing my own game. Hopefully I’ve achieved some of it !