EmberQuest: Building an Octane Role Playing Game
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Monroe, Dan
EmberQuest: Building an Octane Role Playing Game by Dan Monroe Journey with me as I discuss how Ember Octane made building an RPG easier. There are many challenges to make a playable game; rendering maps, moving the player and monsters, player inventory, combat. Never fear, we have magic on our side! We'll use a Glimmering component for the main viewport, mini world map, Path Finding, and Fog of War. The magic of Ember-Concurrency will help drive moving and combat. The wizardry of Ember-Auto-Import will allow the use of Konva to draw on our HTML5 canvas. Together, with the magic Octane sword I've named Tracked, we'll level-up and complete our EmberQuest!
 Good morning! Welcome to EmberQuest. During this session, I'm going to show you how you can build the next Fortnite and make a million dollars. Okay, maybe not Fortnite, and a million dollars is up to you. I will show you how I wrote a game with EmberOctane. Then I'll provide you with some tools so you can too. My name is Dan Monroe. I'm a full stack developer at Cardinal Health in Dublin, Ohio. Before Cardinal Health, I worked for Walt Disney, Compuserve, AOL, and Netscape. I've been using JavaScript for a very long time. Over two decades, I've seen the good parts and a lot of the bad. I've written a lot of the bad. I'm sorry. I wrote JavaScript for years before the first version of jQuery was ever released. It was tedious. When jQuery came out, I thought it was magic. Having the right tools empowered me to write better code. Thank you, John Rezik. I've seen a lot of the JavaScript frameworks come and go. Of course, Ember is my favorite. Before I get into the game portion of this talk, I want to tell you why I wanted to build a game. Why did I decide that not sleeping was a good idea? I had numerous hobbies in my life. Some of them were my inspiration, my family, training in Taekwondo, a scare actor at the blood prison on a house. During Halloween, the prison where they shot the movie Shawshank Redemption turns into a haunted house called Blood Prison. I'm one of the actors. This is me as a sharpshooter last year. Surprise, I enjoy writing code. I also contribute to a few open source projects. You can too. It's not as scary as a haunted house. You should try it. I also like geocaching. That's my geocaching name right there. Can you guess which two of these are my inspiration to write a game? Coding, of course. And geocaching. Some of you may have already been familiar with geocaching, while others are probably wondering what it is. Geocaching is the world's largest treasure hunt. It was the main inspiration for me to write a game. Let me give a brief description of what it is so we can get into how it ties into Ember and writing a game. Geocaching is an any day, any time adventure that can take you to amazing and beautiful places. Or even just to a place in your town that you have never been to before. There are millions of geocaches worldwide. The way it works is simple. Just go to geocaching.com and choose the geocache you want to find, like this one just outside the Oregon Convention Center. Then navigate to its GPS location. What you're looking for varies. Geocaches come in different shapes, sizes, and difficulties. I learned to ascend tall trees and repel all because of geocaching. The highest tree I ever climbed was over 200 feet. Super fun. After you find it, you sign a logbook inside. When you're done, put the cache back where you found it for the next person to find. Then you post your find online. So far I have found almost 2,000 geocaches in 47 different states and 21 countries. Recently I found two new ones in the Bahamas. On our buy one, get two for free crews. Now, I know what some of you were thinking. What does this have to do with running a game? Well, sometimes the cache does not give you the exact coordinates. These are called puzzle caches. The geocache player has to decrypt a cipher or solve a puzzle just to get the real coordinates. I have hidden a few of these myself. My first one was an interactive fiction game similar to Zork or Enchanter from the early 80s. I know, I'm old. It was called GeoQuest. I started to write it in Java and soon discovered that it was hard. Then I found a tool called Inform. Inform, along with its plug-ins or add-ons, made it easy and fun to write. It took care of all the natural language parsing for me. Having the tools, the write tools, empowered me to build the game, I envisioned without having to worry about details. However, I still wanted to do a graphics-based game, but the tools were not easily available to me at the time. Now for Ember. I was introduced to Ember after joining my current team about four years ago. I think it was Ember 113, 112. I had never heard of it. I was like, okay, whatever. It has to be better than my current JavaScript framework. Well, after using it a short time, it was like magic. Yes, I'm having fun again. The community was awesome, code's fun, and everyone is eager to help me when I have questions. Fast forward, or I guess backwards. Ember Octane is in Canary release. I tried it out and thought to myself, this new version is pretty cool. Immediately I wondered if I could finally write the RPG geocaching puzzle game that I've always wanted to write. But what should I call it? GeoQuest 2? Nah, EmberQuest. Cool. Let's begin. We'll run Ember New EmberQuest. Don't worry, I'm on my home Wi-Fi. It's pretty fast. Okay, done. Now open up browser. Congratulations, you made it. Nice. Now what? Let's see. I want to make a game a geocacher will play online. It's going to be a role-playing game where the virtual player goes exploring, solves puzzles, fights monsters, all on a journey to find chests. Hidden throughout the game. When they find it and open a chest, they'll be given the real physical coordinates of caches they can find in real life. Okay, what will I need? Well, I need a player. I'll need some way to interact with the game. I'll need a world for the player to explore. Now should I use hexagons or squares to draw the map? I'm going to need a lot of things. Graphics, dialogues, sounds, inventory, fog of war, pathfinding, monsters, combat, saving the game, enemy AI. Makes my brain hurt. Too many things to think about. Okay, well let's just start with a simple proof of concept. We'll use hexagons for our map and see if we can get fog of war or what the player can see and pathfinding implemented. This is pretty far along my proof of concept. It demonstrates fog of war, build of view, and pathfinding. I coded all the math to draw and place the hexagon on a canvas. The light colored hexes are the ones that the player can see while the little island is blocking the player's view. In this debug view, when the player moves around the island, the field of view is updated. It shows me the pathfinding results in purple for each hex I move over with the mouse. At the same time, I use trigonometry to draw the green and red dots that represent which hexes the player can see in his line of sight and which ones are blocked. The pathfinding uses the A star algorithm. It's pretty fast and I'll find a path to a target hex way across this big board in about 4 milliseconds or less. Okay, time to start working on the real game. We'll add some better graphics and a few months. We find our hero on the shore of the same island. Our ship is docked, waiting for us to go board and take a look around the sea. There's a pirate galleon on patrol. He lowered his aggression so he shouldn't bother us. He has several assigned hex coordinates to patrol at random. Since he has a lot of the same pathfinding code for my proof of concept, he finds a path to his next coordinate all by himself. I don't have to do anything. Let's leave the pirate patrol and continue our tour. There's another dock. We'll go ashore and explore. Leaving the path and into the forest, we can get a glimpse at the sum of the fog of war. The tall, thick trees have impaired our vision, restricting our view in some directions. Normally, we can see up to three hexes away as you can see in the clearing. You'll probably notice that as he moves, hexes that were previously seen become slightly opaque. We will also only see objects and creatures within our site range. I've removed most of the enemies for this demo, but keep our eyes open for any surprises. Now look, a castle. Let's go in. Our hero is found a cave. The field of vision is easier to see in the tight fine finds of the narrow passageways. You probably noticed the two bars above our head. The green bar is the current health of our hero. The blue bar represents his current power or energy. Some activities like walking through rough terrain or fighting will drain his energy. Both the health bar and power bar will replenish over time. I'll talk about how Ember helps with that in a moment. I'm going to speed up our cavern tour so we can get to the point where I can begin to show you how Ember is helping me with some of the game mechanics. Whoa, don't fall on the lava. Hmm, I think I hear something around the corner. Oh no, it's a monster. Look out. Uh oh, it appears that we have died. Let's try again. Before we go around that corner again, what do we have in our package Jason, I mean inventory, that can help in our battle. We have a few different categories. For weapons, we already own a crossbar, bow, and a simple sword, but I guess they aren't very powerful. We're wearing some boots for hat, topster glasses. They're pretty cool. What's another? Hmm, looks like we have a bevel fish. Interesting. Well, that's about it. However, there appears to be a few things we can buy or install that might help our hero in our fight and with our development. We need to develop faster. Ember's CLI Mirage is a terrific add-on that has always been there for me when I want to do a quick demo. Without having a back end, mock up a component and to provide data for my test. Let's add that. I use Mirage to create a quick list of inventory items to display. It's what's driving this inventory demo. How about a better weapon? Hammer, katana, oh, tract! Definitely going to use that. You've already heard from other speakers how wonderful it is. It truly has made life a lot easier. There are a few track properties within the game. There are many others, but these are specific to the player's health. We'll see them used shortly. What's this? Wand of wishing. Ah, Ember auto-import. Another outstanding add-on that has saved me and probably some of you a lot of time when trying to use third-party packages. I'm using it to pull in a special package, but that's a secret for now. One last magic item I want to talk about before I move to Volg, my secret weapon, is the Ring of Concurrency, better known as Ember Concurrency. Ember Quest uses it in many places. Here are some of the concurrency tasks within the game. This is a closer look at the Reload Health task. This is in a base class, so each interactive object in the game has this task. All the properties it uses are tracked. Whenever the player or enemy takes damage, this task will heal it over time. As it heals, the green health bar above their heads will automatically update. Pretty simple code that keeps our hero healthy. Some more things that have been very helpful to me are the different resources available when I needed help. The Ember blog, Ember Times, were always very informative and timely. Discord is there when it's 3AM and I need help right now. And finally, Ember Guides, with all the different versions available to me whenever I need it. Thank you all to keep them up to date. Now, it's time to reveal my secret weapon. It's been a long, there has been a lot going on behind the scenes of this demo. WebGL, Canvas, Web Audio, level changes, sprite collisions, etc. I wish I could take credit for managing all that on my own. But it's hard by myself and I'd like to see my family at least a few minutes a day. My secret weapon is there's a game framework wrapped up within EmberQuest. It's called Phaser. I have written an add-on that will easily inject Phaser into your Ember application. This is available right now for you to use to make your own games. For those who may have never heard of it, Phaser is a desktop and mobile HTML5 game framework. A lot of the stuff I was managing on my own in my proof of concept, Phaser now takes care of it for me. For EmberQuest, it takes care of all the physics, sprite collisions, sounds, and camera movements. I was able to copy all my fog of war and pathfinding code for my proof of concept and plug it into my Phaser add-on and it still worked great. Phaser is not new. It's been around for a while, but this talk isn't about Phaser. You can go to phaser.io if you want to learn more. It's a good source of documentation and examples when you're ready to build your own game. Now, let's take a break from EmberQuest and do just that. Let's make a small game together. We'll go back to our new Ember application we started with earlier. And install EmberPhaser. This will give us a new GeneratePhaser scene blueprint. A scene is similar to a component within Ember. Let's generate a toaster scene, compster scene, and an Ember service to put our game logic in. And finally, the component to display the game board. All we need in the component is the Ember game service. In the HBS, we'll place the EmberPhaser component passing in the Phaser configuration in our Ember service. The game configuration is a simple JSON object. A type of Phaser auto is the rendering context. It will automatically try WebGL, but if the browser or device doesn't support it, it will fall back into Canvas. For this game, we're going to need some physics. Objects will fall downwards to the ground at a moderate rate. And finally, we have to tell it which scene to render when the game loads. This will be the scene we generated earlier. For any scene in Phaser, there are a number of lifecycle hooks available for you to override. In most cases, you only need to use three. Preload, create, update. Preload is where you will load your game assets, such as images, sprites, sounds, music. Create is where the game objects are created. And update runs every game dick. This is typically where you handle player movement and sprite collisions. To make sure we have everything wired up correctly, I'll add a sky image as our background. I'll run Ember serve and open our browser. Not much to look at, but at least we know it's running. Console reports we are using WebGL and WebAudio. Nice. And we're running a full 60 frames per second. Time to add our hero. Refresh your browser. There he is. Oops. And there he goes. Now we know that our physics are working, but we haven't defined anything for him to land on, so he just falls through the bottom of the screen. Before we get much further, let's refactor our scene and move the code to our Ember service. Here in our service, we are loading the game assets, creating a ground and the player. The ground will be part of a static group. The group is in a physics object, so we can detect collisions later. Now we have some ground, but he's still falling through the bottom. We need to detect when the player hits the ground. By adding a physics collider, we ensure that our player and the ground will not overlap each other. Now he'll land on the ground. Feed first. We need a way to move around. This is actually pretty easy. Baser will try to run the update lifecycle once per tick. This is where we add player movement. Before we can move, we'll set up which keyboard keys will move the player. We'll set the typical A and D for left and right, and let the player decide to use either the W or the space bar to jump. When the A key is down, move the player to the left. When the D key is down, move right. Otherwise, stop the left and right movement. Also, we can only jump when our feet are touching the ground. Although, feel free to let him do that and make your own floppy bird or floppy composter in your case. It's your game. We just need to take care of up, since the physics engine will bring us back down. Okay, we're getting there. Let's quickly add more things to jump on. We'll add three platforms to jump on. We already had the ground image loaded, so we're just reusing that image. We'll just place the new platform at different locations on the screen. Since the platforms are part of the ground group, the collision detector does not allow them to fall through. Now we need a goal for our player. We'll create some stars the player can collect. We'll be sure to add another collider between the stars and the platforms, so the stars will also land on the ground. When they appear on the screen, they'll have a slight bounce. When the player sprite touches a star, it will call the collect star callback function. This is our hook into letting us control more of the game interaction with our amber service. In this case, the function will increase the player's score and check to see if all the stars have been collected. If so, it will recreate all the stars and move to the next level. After the first level, we'll add a bomb that the player will need to avoid. When the player collides with a bomb, the game is over. The collect star callback is in our amber service. We can do anything we want here. Call other amber services, transition to another route, anything you might do in other amber applications that you may have done in the past. You have control. That's it. We now have a fully functioning game. The complete source code for this game can be found as demo 2 in the API docs for Ember Phaser Online. Okay, great. But wait. It's not launch time yet. What about Ember Quest? I think we have some unfinished business to attend there. When we left our hero, he had just fought a fight with a nasty villain, but we powered up his inventory to better prepare him for battle. We used Ember Mirage to make us more nimble. Ember concurrently tasked to help regain his health and power. We armed him with Ember Track properties. We used Ember Auto Import to use third party libraries. We gave him Ember Phaser so he can concentrate on his game mechanics. And finally, we kept him informed with Ember Guides. Now, time for a rematch. Yes! We've won! Now that he's out of the way, let's take a peek around the corner. There's a chest. Congratulations! Our player found a chest. The game will tell him the actual coordinates of the geocache. You can go out and find it in real life. And us, as developers, are empowered with the tools we need to make the game we envisioned in our minds using our favorite JavaScript framework, Ember. Thank you.
 Good morning! Welcome to EmberQuest. During this session, I'm going to show you how you  can build the next Fortnite and make a million dollars. Okay, maybe not Fortnite, and a million  dollars is up to you. I will show you how I wrote a game with EmberOctane. Then I'll  provide you with some tools so you can too. My name is Dan Monroe. I'm a full stack developer  at Cardinal Health in Dublin, Ohio. Before Cardinal Health, I worked for Walt Disney,  Compuserve, AOL, and Netscape. I've been using JavaScript for a very long time. Over two  decades, I've seen the good parts and a lot of the bad. I've written a lot of the bad.  I'm sorry. I wrote JavaScript for years before the first version of jQuery was ever released.  It was tedious. When jQuery came out, I thought it was magic. Having the right tools empowered  me to write better code. Thank you, John Rezik. I've seen a lot of the JavaScript frameworks  come and go. Of course, Ember is my favorite. Before I get into the game portion of this  talk, I want to tell you why I wanted to build a game. Why did I decide that not sleeping  was a good idea? I had numerous hobbies in my life. Some of them were my inspiration,  my family, training in Taekwondo, a scare actor at the blood prison on a house. During  Halloween, the prison where they shot the movie Shawshank Redemption turns into a haunted  house called Blood Prison. I'm one of the actors. This is me as a sharpshooter last  year. Surprise, I enjoy writing code. I also contribute to a few open source projects.  You can too. It's not as scary as a haunted house. You should try it. I also like geocaching.  That's my geocaching name right there. Can you guess which two of these are my inspiration  to write a game? Coding, of course. And geocaching. Some of you may have already been familiar  with geocaching, while others are probably wondering what it is. Geocaching is the world's  largest treasure hunt. It was the main inspiration for me to write a game. Let me give a brief  description of what it is so we can get into how it ties into Ember and writing a game.  Geocaching is an any day, any time adventure that can take you to amazing and beautiful  places. Or even just to a place in your town that you have never been to before. There  are millions of geocaches worldwide. The way it works is simple. Just go to geocaching.com  and choose the geocache you want to find, like this one just outside the Oregon Convention  Center. Then navigate to its GPS location. What you're looking for varies. Geocaches  come in different shapes, sizes, and difficulties. I learned to ascend tall trees and repel all  because of geocaching. The highest tree I ever climbed was over 200 feet. Super fun.  After you find it, you sign a logbook inside. When you're done, put the cache back where  you found it for the next person to find. Then you post your find online. So far I have  found almost 2,000 geocaches in 47 different states and 21 countries. Recently I found  two new ones in the Bahamas. On our buy one, get two for free crews. Now, I know what some  of you were thinking. What does this have to do with running a game? Well, sometimes  the cache does not give you the exact coordinates. These are called puzzle caches. The geocache  player has to decrypt a cipher or solve a puzzle just to get the real coordinates. I  have hidden a few of these myself. My first one was an interactive fiction game similar  to Zork or Enchanter from the early 80s. I know, I'm old. It was called GeoQuest. I  started to write it in Java and soon discovered that it was hard. Then I found a tool called  Inform. Inform, along with its plug-ins or add-ons, made it easy and fun to write. It  took care of all the natural language parsing for me. Having the tools, the write tools,  empowered me to build the game, I envisioned without having to worry about details. However,  I still wanted to do a graphics-based game, but the tools were not easily available to  me at the time. Now for Ember. I was introduced to Ember after joining my current team about  four years ago. I think it was Ember 113, 112. I had never heard of it. I was like,  okay, whatever. It has to be better than my current JavaScript framework. Well, after  using it a short time, it was like magic. Yes, I'm having fun again. The community was  awesome, code's fun, and everyone is eager to help me when I have questions. Fast forward,  or I guess backwards. Ember Octane is in Canary release. I tried it out and thought to myself,  this new version is pretty cool. Immediately I wondered if I could finally write the RPG  geocaching puzzle game that I've always wanted to write. But what should I call it? GeoQuest  2? Nah, EmberQuest. Cool. Let's begin. We'll run Ember New EmberQuest. Don't worry, I'm  on my home Wi-Fi. It's pretty fast. Okay, done. Now open up browser. Congratulations,  you made it. Nice. Now what? Let's see. I want to make a game a geocacher will play  online. It's going to be a role-playing game where the virtual player goes exploring, solves  puzzles, fights monsters, all on a journey to find chests. Hidden throughout the game.  When they find it and open a chest, they'll be given the real physical coordinates of  caches they can find in real life. Okay, what will I need? Well, I need a player. I'll need  some way to interact with the game. I'll need a world for the player to explore. Now should  I use hexagons or squares to draw the map? I'm going to need a lot of things. Graphics,  dialogues, sounds, inventory, fog of war, pathfinding, monsters, combat, saving the  game, enemy AI. Makes my brain hurt. Too many things to think about. Okay, well let's just  start with a simple proof of concept. We'll use hexagons for our map and see if we can  get fog of war or what the player can see and pathfinding implemented. This is pretty  far along my proof of concept. It demonstrates fog of war, build of view, and pathfinding.  I coded all the math to draw and place the hexagon on a canvas. The light colored hexes  are the ones that the player can see while the little island is blocking the player's  view. In this debug view, when the player moves around the island, the field of view  is updated. It shows me the pathfinding results in purple for each hex I move over with the  mouse. At the same time, I use trigonometry to draw the green and red dots that represent  which hexes the player can see in his line of sight and which ones are blocked. The pathfinding  uses the A star algorithm. It's pretty fast and I'll find a path to a target hex way  across this big board in about 4 milliseconds or less. Okay, time to start working on the  real game. We'll add some better graphics and a few months. We find our hero on the  shore of the same island. Our ship is docked, waiting for us to go board and take a look  around the sea. There's a pirate galleon on patrol. He lowered his aggression so he shouldn't  bother us. He has several assigned hex coordinates to patrol at random. Since he has a lot of  the same pathfinding code for my proof of concept, he finds a path to his next coordinate  all by himself. I don't have to do anything. Let's leave the pirate patrol and continue  our tour. There's another dock. We'll go ashore and explore. Leaving the path and into the  forest, we can get a glimpse at the sum of the fog of war. The tall, thick trees have  impaired our vision, restricting our view in some directions. Normally, we can see up  to three hexes away as you can see in the clearing. You'll probably notice that as he  moves, hexes that were previously seen become slightly opaque. We will also only see objects  and creatures within our site range. I've removed most of the enemies for this demo,  but keep our eyes open for any surprises. Now look, a castle. Let's go in. Our hero  is found a cave. The field of vision is easier to see in the tight fine finds of the narrow  passageways. You probably noticed the two bars above our head. The green bar is the  current health of our hero. The blue bar represents his current power or energy. Some activities  like walking through rough terrain or fighting will drain his energy. Both the health bar  and power bar will replenish over time. I'll talk about how Ember helps with that in a  moment. I'm going to speed up our cavern tour so we can get to the point where I can begin  to show you how Ember is helping me with some of the game mechanics.  Whoa, don't fall on the lava. Hmm, I think I hear something around the corner. Oh no,  it's a monster. Look out. Uh oh, it appears that we have died. Let's try again. Before  we go around that corner again, what do we have in our package Jason, I mean inventory,  that can help in our battle. We have a few different categories. For weapons, we already  own a crossbar, bow, and a simple sword, but I guess they aren't very powerful. We're  wearing some boots for hat, topster glasses. They're pretty cool. What's another? Hmm,  looks like we have a bevel fish. Interesting. Well, that's about it. However, there appears  to be a few things we can buy or install that might help our hero in our fight and with  our development. We need to develop faster. Ember's CLI Mirage is a terrific add-on that  has always been there for me when I want to do a quick demo. Without having a back end,  mock up a component and to provide data for my test. Let's add that. I use Mirage to create  a quick list of inventory items to display. It's what's driving this inventory demo.  How about a better weapon? Hammer, katana, oh, tract! Definitely going to use that. You've  already heard from other speakers how wonderful it is. It truly has made life a lot easier.  There are a few track properties within the game. There are many others, but these are  specific to the player's health. We'll see them used shortly. What's this? Wand of  wishing. Ah, Ember auto-import. Another outstanding add-on that has saved me and probably some  of you a lot of time when trying to use third-party packages. I'm using it to pull in a special  package, but that's a secret for now. One last magic item I want to talk about before  I move to Volg, my secret weapon, is the Ring of Concurrency, better known as Ember Concurrency.  Ember Quest uses it in many places. Here are some of the concurrency tasks within the game.  This is a closer look at the Reload Health task. This is in a base class, so each interactive  object in the game has this task. All the properties it uses are tracked. Whenever the  player or enemy takes damage, this task will heal it over time. As it heals, the green  health bar above their heads will automatically update. Pretty simple code that keeps our  hero healthy. Some more things that have been very helpful  to me are the different resources available when I needed help. The Ember blog, Ember  Times, were always very informative and timely. Discord is there when it's 3AM and I need  help right now. And finally, Ember Guides, with all the different versions available  to me whenever I need it. Thank you all to keep them up to date.  Now, it's time to reveal my secret weapon. It's been a long, there has been a lot going  on behind the scenes of this demo. WebGL, Canvas, Web Audio, level changes, sprite collisions,  etc. I wish I could take credit for managing all that on my own. But it's hard by myself  and I'd like to see my family at least a few minutes a day.  My secret weapon is there's a game framework wrapped up within EmberQuest. It's called  Phaser. I have written an add-on that will easily inject Phaser into your Ember application.  This is available right now for you to use to make your own games.  For those who may have never heard of it, Phaser is a desktop and mobile HTML5 game  framework. A lot of the stuff I was managing on my own in my proof of concept, Phaser now  takes care of it for me. For EmberQuest, it takes care of all the physics, sprite collisions,  sounds, and camera movements. I was able to copy all my fog of war and pathfinding code  for my proof of concept and plug it into my Phaser add-on and it still worked great.  Phaser is not new. It's been around for a while, but this talk isn't about Phaser.  You can go to phaser.io if you want to learn more. It's a good source of documentation  and examples when you're ready to build your own game.  Now, let's take a break from EmberQuest and do just that. Let's make a small game together.  We'll go back to our new Ember application we started with earlier. And install EmberPhaser.  This will give us a new GeneratePhaser scene blueprint. A scene is similar to a component  within Ember. Let's generate a toaster scene, compster scene, and an Ember service to put  our game logic in. And finally, the component to display the game board.  All we need in the component is the Ember game service. In the HBS, we'll place the  EmberPhaser component passing in the Phaser configuration in our Ember service. The game  configuration is a simple JSON object. A type of Phaser auto is the rendering context.  It will automatically try WebGL, but if the browser or device doesn't support it, it  will fall back into Canvas. For this game, we're going to need some physics. Objects  will fall downwards to the ground at a moderate rate.  And finally, we have to tell it which scene to render when the game loads. This will be  the scene we generated earlier. For any scene in Phaser, there are a number  of lifecycle hooks available for you to override. In most cases, you only need to use three.  Preload, create, update. Preload is where you will load your game assets, such as images,  sprites, sounds, music. Create is where the game objects are created. And update runs  every game dick. This is typically where you handle player movement and sprite collisions.  To make sure we have everything wired up correctly, I'll add a sky image as our background.  I'll run Ember serve and open our browser. Not much to look at, but at least we know  it's running. Console reports we are using WebGL and WebAudio. Nice.  And we're running a full 60 frames per second. Time to add our hero. Refresh your browser.  There he is. Oops. And there he goes. Now we know that our physics are working, but  we haven't defined anything for him to land on, so he just falls through the bottom of  the screen. Before we get much further, let's refactor  our scene and move the code to our Ember service. Here in our service, we are loading  the game assets, creating a ground and the player. The ground will be part of a static  group. The group is in a physics object, so we can detect collisions later.  Now we have some ground, but he's still falling through the bottom. We need to detect when  the player hits the ground. By adding a physics collider, we ensure that our player and the  ground will not overlap each other. Now he'll land on the ground. Feed first.  We need a way to move around. This is actually pretty easy. Baser will try to run the update  lifecycle once per tick. This is where we add player movement. Before we can move, we'll  set up which keyboard keys will move the player. We'll set the typical A and D for left and  right, and let the player decide to use either the W or the space bar to jump.  When the A key is down, move the player to the left. When the D key is down, move right.  Otherwise, stop the left and right movement. Also, we can only jump when our feet are touching  the ground. Although, feel free to let him do that and make your own floppy bird or floppy  composter in your case. It's your game. We just need to take care of up, since the physics  engine will bring us back down. Okay, we're getting there. Let's quickly  add more things to jump on. We'll add three platforms to jump on. We already had the ground  image loaded, so we're just reusing that image. We'll just place the new platform at different  locations on the screen. Since the platforms are part of the ground group, the collision  detector does not allow them to fall through. Now we need a goal for our player. We'll  create some stars the player can collect. We'll be sure to add another collider between  the stars and the platforms, so the stars will also land on the ground. When they appear  on the screen, they'll have a slight bounce. When the player sprite touches a star, it  will call the collect star callback function. This is our hook into letting us control more  of the game interaction with our amber service. In this case, the function will increase the  player's score and check to see if all the stars have been collected. If so, it will  recreate all the stars and move to the next level. After the first level, we'll add a  bomb that the player will need to avoid. When the player collides with a bomb, the game  is over. The collect star callback is in our amber service. We can do anything we want  here. Call other amber services, transition to another route, anything you might do in  other amber applications that you may have done in the past. You have control. That's  it. We now have a fully functioning game. The complete source code for this game can  be found as demo 2 in the API docs for Ember Phaser Online. Okay, great. But wait. It's  not launch time yet. What about Ember Quest? I think we have some unfinished business to  attend there. When we left our hero, he had just fought a fight with a nasty villain, but  we powered up his inventory to better prepare him for battle. We used Ember Mirage to make  us more nimble. Ember concurrently tasked to help regain his health and power. We armed  him with Ember Track properties. We used Ember Auto Import to use third party libraries.  We gave him Ember Phaser so he can concentrate on his game mechanics. And finally, we kept  him informed with Ember Guides. Now, time for a rematch.  Yes! We've won! Now that he's out of the way, let's take a peek around the corner.  There's a chest. Congratulations! Our player found a chest. The game will tell him the  actual coordinates of the geocache. You can go out and find it in real life. And us, as  developers, are empowered with the tools we need to make the game we envisioned in our  minds using our favorite JavaScript framework, Ember. Thank you.
Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_0_527.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_528_1151.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_1152_4919.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_4920_5123.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_5124_5279.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_5280_7847.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_7848_10031.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_10032_10259.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_10260_11615.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_11616_14099.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_14100_16703.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_16704_16811.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_16812_17123.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_17124_17855.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_17856_30623.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_30624_30803.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_30804_30983.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_30984_32219.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_32220_32747.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_32748_33011.png Virtual_EmberConf_2020__EmberQuest__Building_an_Oc_Ld1xnQWkqPU_33012_37563.png