From 562a9a52d599d9a05f871404050968a5fd282640 Mon Sep 17 00:00:00 2001 From: elioat Date: Wed, 23 Aug 2023 07:52:19 -0400 Subject: * --- .../broughlike-tutorial/stage5.html | 704 +++++++++++++++++++++ 1 file changed, 704 insertions(+) create mode 100644 js/games/nluqo.github.io/broughlike-tutorial/stage5.html (limited to 'js/games/nluqo.github.io/broughlike-tutorial/stage5.html') diff --git a/js/games/nluqo.github.io/broughlike-tutorial/stage5.html b/js/games/nluqo.github.io/broughlike-tutorial/stage5.html new file mode 100644 index 0000000..3e6e08e --- /dev/null +++ b/js/games/nluqo.github.io/broughlike-tutorial/stage5.html @@ -0,0 +1,704 @@ + + + + Broughlike tutorial - Stage 5 + + + +
+
+ JavaScript Broughlike Tutorial + Previously: Monsters - Part 2 +
+

Stage 5: Game Lifecycle: drawing text, title screen, failure condition, and moving between levels

+ Currently, when monsters are killed they are immediately deleted from the game. That's great, but there is no code to handle player death. Let's tackle that now. +

Game state

+ We'll add the concept of a + 
gameState
+ so we can model the game as a finite state machine with four states. +

+ Our four states: + + "Finite state machine" sounds super complicated. It's not. + + Just think about a title screen. That's a state. Then when the actual game is running, that's a state. Clearly different things are displayed on the title screen versus the game proper. And pressing a specific button in-game and pressing it on the title screen do different things. So that's all we're trying to accomplish. +

+ To make this work, we need to only do two things. +
    +
  1. When needed, switch states simply by setting 
    gameState
    to a different state name
    2. +
  2. Use conditionals checking the value of 
    gameState
    to wrap behavior that should only occur in specific states
    3. + +
+
index.html
+
+
+
+
+
+
+
+
+
+
+
+
+ + When our spritesheet image loads, we want to switch to showing the title screen which is accomplished by assigning a function to + 
spritesheet.onload
+ (we'll write that + 
showTitle
+ function below next). But what's our first state? Unsurprisingly, we're initializing + 
gameState
+ to "loading" because that's the first thing that happens. +

+ While we're here, we're adding some variables related to the game lifecycle: + 
startingHp
+ and + 
numLevels
. +

+ Within the + 
onkeypress
+ handler, you can see where we're starting to add transitions between game states when buttons are pressed and also restricting when gameplay actions can take place (only when "running"). +

+ Lastly, we're moving out some code related to setting the + 
player
+ location and generating a level. If we're going to have multiple levels, it no longer makes sense to do these things only once. +

+ + There are several small changes to add to game.js: + +
game.js
+
+
+
+
+
+
+
+
+
+
+
+
+
+ In + 
draw
, + we restrict our draw operations to when the game is running OR when the player just died. +

+ In + 
tick
, + we change to the "dead" state when we detect that the player has died. +

+ In + 
showTitle
, + we draw a semi-transparent black background, which will function as our title screen for now. Then we change to the "title" state. +

+ In + 
startGame
, + we jump to the first floor, call 
startLevel
, and we change to the "running" state. +

+ In + 
startLevel
, + we move over the code that we took out of index.html. Also 
player
gets initalized with + 
hp
+ equal to the value passed in + 
playerHp
. This value starts as 3, but in a little bit we'll use this function to persist player HP across levels. +

+ Now load up the game. You'll see the "title screen", a black box for now. When you hit a key, the game will start running. And if you were to die, everything would freeze until you pressed another key... leading back to the title screen, this time overlaid semitransparently over the game. That's the whole state machine right there working! +

Spawning more monsters

+ It's not easy to die in this game. No monsters spawn after the first two. Let's make it harder. + +
game.js
+
+
+
+
+
+
+ 
...
+
+
+
+
+ + We're using two new global variables. + + + After every spawn, + 
spawnRate
+ is decremented so that monsters come out even faster. + + Tweaking the initial value of + 
spawnRate
+ will have a massive impact on the game's design (try a value of 1 for some real fun). +

+ Try that out and see how you like the spawn behavior. +

Teleport counter

+ One more rough edge to smooth out. Monsters can spawn right next to us and immediately start attacking. It's also very weird to see monsters spawning in the middle of the map with no explanation. +

+ One convenient explanation is that these monsters are being "teleported" into the map. While each monster is teleporting, which will take one extra turn, they will be unable to do anything. Think of this as equivalent to Magic's "summoning sickness". +

+ To visually demonstrate this, we need a teleporting sprite. Let's draw that before getting to the code. +

Drawing the teleport sprite

+
+ There's not much to this one. We draw a spiral, add swirly limbs, and outline it. + +
+ + To integrate this teleporting thing, we'll use a counter just like we did with + 
spawnCounter
. + This should look familiar. You can do a hell of a lot of work with only boolean flags for statuses and integer counters for longer lasting effects. + +
monster.js
+
+ +
+
+
+
+
+
+
+ + 
...
+ +
+
+
+
+
+ + 
...
+ +
+
+
+
+ The monsters are teleporting in and spawning nicely... eventually leading to an unwillable scenario. Let's give the player an exit from this situation. +

Drawing the exit sprite

+
+ I tried drawing something resembling a portal. + +
+ + Our + 
Exit
+ tile is a pretty basic object, but it does need to do something (i.e. go to the next level) whenever the player moves onto it. It's within the monster code that we determine when we're stepping on something, but after that point it's best to delegate to the tiles themselves. Each tile will know exactly what to do when stepped on. + +
tile.js
+
+ +
+
+
+
+
+ + Notice that we need an empty + 
stepOn
+ method for + 
Floor
too because monsters will be stepping on them as well. It won't do anything for now but it's nice to leave a little reminder comment to finish up the behavior later. We'll never need this method for a + 
Wall
+ because monsters don't step on those. And unlike in other languages we don't need this method on the base object in order to call it on the subclasses. +

+ Now what happens when the player steps on the + 
Exit
? If we were already on the last level, we jump to the title screen. Otherwise, we start a new level with 1 extra HP. +

+ Two more pieces to tie it all together: triggering + 
stepOn
+ and creating the + 
Exit
+ tile. + + +
monster.js
+
+
+
+
+
+
game.js
+
+
+
+
+
+ + With these small additions, the game has some real structure to it. +

Title time

+ The title screen is seriously lacking though. I don't want to do anything too crazy for the title screen, but at the very least it needs some text. +

+ If you're trying to draw UI elements for a browser game, I would typically recommend trying it with HTML. You've got a lot of functionality out of the box with HTML & CSS, built up over decades. But for a few simple lines of text, the canvas will do just fine. +

+ Drawing text on the canvas is not much different from drawing images. The important bit here is at the end: + 
ctx.fillText
. + All we need to pass is what text to draw and where. + +
game.js
+
+
+
+ + The first two lines of our function set the font color and size. The string + 
"px monospace"
+ might look a little cryptic. We're actually writing a bit of CSS : we specify a font size in "px" units (pixels) and specify the type of font we want, which is "monospace". +

+ We're going to leave the Y position up to the caller, but to make things easier this function will handle X. We're going to draw text in two places basically: justified centered on the title screen and on the far right (where the UI is) during play. The + 
centered
+ variable lets us toggle between these two. +

+ So what does this line mean exactly? +

+ 
textX = (canvas.width-ctx.measureText(text).width)/2;
+

+ When you want to center any element, whether on the canvas or in HTML, the calculation is the same. For X: half the container width minus half the content width. For Y: half the container height minus half the content height. The reason is obvious when you see it: +

+ + +

+ This is a good example of where HTML & CSS would be a lot easier to use! For one there are many easy ways to center things in CSS (there weren't for about 20 years but now there certainly are). And for two getting the width or height of an HTML element is very easy. None of this + 
measureText
+ nonsense. Did you know there isn't even a way to measure the height? Ugh! +

+ Anyway, enough ranting... let's draw some text. + +
game.js
+
+
+
+
+
+ + 
...
+ +
+
+
+
+ + + To review the arguments to our + 
drawText
+ function + + Whew! That's a mouthful, but trust me when I say it's preventing us from duplicating a lot of code. +

+ We're drawing the level number on the UI during play and drawing the name of the game on the title screen. I chose a silly name. I'm sure you can do better. +

+ Try it out. I think it's looking good. At this point, the game can be considered a fully playable and complete game. It's just not very interesting yet. We'll get there. + + In the next section, we'll be adding treasure and score mechanics. +
+ + + + + + + + + \ No newline at end of file -- cgit 1.4.1-2-gfad0