Fighting Back!
In last week's article, we made our enemies a lot smarter. We gave them a breadth-first-search algorithm so they could find the shortest path to find us. This made it much harder to avoid them. This week, we fight back! We'll develop a mechanism so that our player can stun nearby enemies and bypass them.
None of the elements we're going to implement are particularly challenging in isolation. The focus this week is on maintaining a methodical development process. To that end, it'll help a lot to take a look at the Github Repository for this project when reading this article. The code for this part is on the part-7
branch.
We won't go over every detail in this article. Instead, each section will describe one discrete stage in developing these features. We'll examine the important parts, and give some high level guidelines for the rest. Then there will be a single commit, in case you want to examine anything else that changed.
Haskell is a great language for following a methodical process. This is especially true if you use the idea of compile driven development (CDD). If you've never written any Haskell before, you should try it out! Download our Beginners Checklist and get started! You can also read about CDD and other topics in our Haskell Brain series!
Feature Overview
To start, let's formalize the definition of our new feature.
- The player can stun all enemies within a 5x5 tile radius (ignoring walls) around them.
- This will stun enemies for a set duration of time. However, the stun duration will go down each time an enemy gets stunned.
- The player can only use the stun functionality once every few seconds. This delay should increase each time they use the stun.
- Enemies will move faster each time they recover from getting stunned.
- Stunned enemies appear as a different color
- Affected tiles briefly appear as a different color.
- When the player's stun is ready, their avatar should have an indicator.
It seems like there are a lot of different criteria here. But no need to worry! We'll follow our development process and it'll be fine! We'll need more state in our game for a lot of these changes. So, as we have in the past, let's start by modifying our World
and related types.
World State Modifications
The first big change is that we're going to add a Player
type to carry more information about our character. This will replace the playerLocation
field in our World
. It will have current location, as well as timer values related to our stun weapon. The first value will be the time remaining until we can use it again. The second value will be the next delay after we use it. This second value is the one that will increase each time we use the stun. We'll use Word
(unsigned int) values for all our timers.
data Player = Player
{ playerLocation :: Location
, playerCurrentStunDelay :: Word
, playerNextStunDelay :: Word
}
data World = World
{ worldPlayer :: Player
...
We'll add some similar new fields to the enemy. The first of these is a lagTime
. That is, the number of ticks an enemy will wait before moving. The more times we stun them, the lower this will go, and the faster they'll get. Then, just as we keep track of a stun delay for the player, each enemy will have a stun remaining time. (If the enemy is active, this will be 0). We'll also store the "next stun duration", like we did with the Player
. For the enemy, this delay will decrease each time the enemy gets stunned, so the game gets harder.
data Enemy = Enemy
{ enemyLocation :: Location
, enemyLagTime :: Word
, enemyNextStunDuration :: Word
, enemyCurrentStunTimer :: Word
}
Finally, we'll add a couple fields to our world. First, a list of locations affected by the stun. These will briefly highlight when we use the stun and then go away. Second, we need a worldTime
. This will help us keep track of when enemies should move.
data World = World
{ worldPlayer :: Player
, startLocation :: Location
, endLocation :: Location
, worldBoundaries :: Maze
, worldResult :: GameResult
, worldRandomGenerator :: StdGen
, worldEnemies :: [Enemy]
, stunCells :: [Location]
, worldTime :: Word
}
At this point, we should stop thinking about our new features for a second and get the rest of our code to compile. Here are the broad steps we need to take.
- Every instance of
playerLocation w
should change to accessplayerLocation (worldPlayer w)
. - We should make a
newPlayer
expression and use it whenever we re-initialize the world. - We should make a similar function
mkNewEnemy
. This should take a location and initialize an Enemy. - Any instances of
Enemy
constructors in pattern matches need the new arguments. Use wildcards for now. - Other places where we initialize the
World
should add extra arguments as well. Use the empty list for thestunCells
and 0 the world timer.
Take a look at this commit for details!
A Matter of Time
For the next step, we want to ensure all our time updates occur. Our game entities now have several fields that should be changing each tick. Our world timer should go up, our stun delay timers should go down. Let's start with a simple function that will increment the world timer:
incrementWorldTime :: World -> World
incrementWorldTime w = w { worldTime = worldTime w + 1 }
In our normal case of the update
function, we want to apply this increment:
updateFunc :: Float -> World -> World
updateFunc _ w
...
| otherwise = incrementWorldTime (w
{ worldRandomGenerator = newGen
, worldEnemies = newEnemies
})
Now there are some timers we'll want to decrement. Let's make a quick helper function:
decrementIfPositive :: Word -> Word
decrementIfPositive 0 = 0
decrementIfPositive x = x - 1
We can use this to create a function to update our player each tick. All we need to do is reduce the stun delay. We'll apply this function within our update
function for the world.
updatePlayerOnTick :: Player -> Player
updatePlayerOnTick p = p
{ playerCurrentStunDelay =
decrementIfPositive (playerCurrentStunDelay p)
}
updateFunc :: Float -> World -> World
updateFunc _ w
...
| otherwise = incrementWorldTime (w
{ worldPlayer = newPlayer
, ...
})
where
player = worldPlayer w
newPlayer = updatePlayerOnTick player
...
Now we need to change how we update enemies:
- The function needs the world time. Enemies should only move when the world time is a multiple of their lag time.
- Enemies should also only move if they aren't stunned.
- Reduce the stun timer if it exists.
updateEnemy
:: Word
-> Maze
-> Location
-> Enemy
-> State StdGen Enemy
updateEnemy time maze playerLocation
e@(Enemy location lagTime nextStun currentStun) =
if not shouldUpdate
then return e
else do
… -- Make the new move!
return (Enemy newLocation lagTime nextStun
(decrementIfPositive currentStun))
where
isUpdateTick = time `mod` lagTime == 0
shouldUpdate = isUpdateTick &&
currentStun == 0 &&
not (null potentialLocs)
potentialLocs = …
...
There are also a couple minor modifications elsewhere.
- The time step argument for the
play
function should now be 20 steps per second, not 1. - Enemies should start with 20 for their lag time.
We haven't affected the game yet, since we can't use the stun! This is the next step. But this is important groundwork for making everything work. Take a look at this commit for how this part went down.
Activating the Stun
Let's make that stun work! We'll do this with the space-bar key. Most of this logic will go into the event handler. Let's set up the point where we enter this command:
inputHandler :: Event -> World -> World
inputHandler event w
...
| otherwise = case event of
… -- (movement keys)
(EventKey (SpecialKey KeySpace) Down _ _) -> ...
What are all the different things that need to happen?
- Enemies within range should get stunned. This means they receive their "next stun timer" value for their current stun timer.
- Their "next stun timers" should decrease (let's say by 5 to a minimum of 20).
- Our player stun delay timer should get the "next" value as well. Then we'll increase the "next" value by 10.
- Our "stun cells" list should include all cells within range.
None of these things are challenging on their own. But combining them all is a bit tricky. Let's start with some mutation functions:
activatePlayerStun :: Player -> Player
activatePlayerStun (Player loc _ nextStunTimer) =
Player loc nextStunTimer (nextStunTimer + 10)
stunEnemy :: Enemy -> Enemy
stunEnemy (Enemy loc lag nextStun _) =
Enemy loc newLag newNextStun nextStun
where
newNextStun = max 20 (nextStun - 5)
newLag = max 10 (lag - 1)
Now we want to apply these mutators within our input handler. To start, let's remember that we should only be able to trigger any of this logic if the player's stun timer is already 0!
inputHandler :: Event -> World -> World
inputHandler event w
...
| otherwise = case event of
… -- (movement keys)
(EventKey (SpecialKey KeySpace) Down _ _) ->
if playerCurrentStunDelay currentPlayer /= 0 then w
else ...
Now let's add a helper that will give us all the locations affected by the stun. We want everything in a 5x5 grid around our player, but we also want bounds checking. Luckily, we can do all this with a neat list comprehension!
where
...
stunAffectedCells :: [Location]
stunAffectedCells =
let (cx, cy) = playerLocation currentPlayer
in [(x,y) | x <- [(cx-2)..(cx+2)], y <- [(cy-2)..(cy+2)],
x >= 0 && x <= 24, y >= 0 && y <= 24]
Now we'll make a wrapper around our enemy mutation to determine which enemies get stunned:
where
...
stunEnemyIfClose :: Enemy -> Enemy
stunEnemyIfClose e = if enemyLocation e `elem` stunAffectedCells
then stunEnemy e
else e
Now we can incorporate all our functions into a final update!
inputHandler :: Event -> World -> World
inputHandler event w
...
| otherwise = case event of
… -- (movement keys)
(EventKey (SpecialKey KeySpace) Down _ _) ->
if playerCurrentStunDelay currentPlayer /= 0
then w
else w
{ worldPlayer = activatePlayerStun currentPlayer
, worldEnemies = stunEnemyIfClose <$> worldEnemies w
, stunCells = stunAffectedCells
}
Other small updates:
- When initializing game objects, they should get default values for their "next" timers. For the player, we give 200 (10 seconds). For the enemies, we stun them for 60 ticks (3 seconds) initially.
- When updating the world, clear out the "stun cells". Use another mutator function to achieve this:
clearStunCells :: World -> World
clearStunCells w = w { stunCells = []}
Take a look at this commit for a review on this part!
Drawing the Changes
Our game works as expected now! But as our last update, let's make sure we represent these changes on the screen. This will make the game a much better experience. Here are some changes:
- Enemies will turn yellow when stunned
- Affected squares will flash teal
- Our player will have red inner circle when the stun is ready
Each of these is pretty simple! For our enemies, we'll add a little extra logic around what color to use, depending on the stun timer:
enemyPic :: Enemy -> Picture
enemyPic (Enemy loc _ _ currentStun) =
let enemyColor = if currentStun == 0 then orange else yellow
...
in Color enemyColor (Polygon [tl, tr, br, bl])
For the player, we'll add some similar logic. The indicator will be a smaller red circle inside of the normal black circle:
stunReadyCircle = if playerCurrentStunDelay (worldPlayer world) == 0
then Color red (Circle 5)
else Blank
playerMarker = translate px py (Pictures [stunReadyCircle, Circle 10])
Finally, for the walls, we need to check if a location is among the stunCells
. If so, we'll add a teal (cyan) background.
makeWallPictures :: (Location, CellBoundaries) -> [Picture]
makeWallPictures ((x,y), CellBoundaries up right down left) =
let coords = conversion (x,y)
tl = cellTopLeft coords
tr = cellTopRight coords
bl = cellBottomLeft coords
br = cellBottomRight coords
stunBackground = if (x, y) `elem` stunCells world
then Color cyan (Polygon [tl, tr, br, bl])
else Blank
in [ stunBackground
… (wall edges)
]
And that's all! We can now tell what is happening in our game, so we're done with these features! You can take a look at this commit for all the changes we made to the drawing!
Conclusion
Now our game is a lot more interesting. There's a lot of tuning we can do with various parameters to make our levels more and more competitive. For instance, how many enemies is appropriate per level? What's a good stun delay timer? If we're going to experiment with all these, we'll want to be able to load full game states from the file system. We've got a good start with serializing mazes. But now we want to include information about the player, enemies, and timers.
So next week, we'll go further and serialize our complete game state. We'll also look at how we parameterize the application and fix all the "magic numbers". This will add new options for customization and flexibility. It will also enable us to build a full game that gets harder as it goes on, and allow saving and loading of your progress.
Throughout this article (and series), we've tried to use a clean, precise development process. Read our Haskell Brain series to learn more about this! You can also download our Beginners Checklist if you are less familiar with the language!