 Good morning. Welcome to Ember Quest. 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 Ember Octane. 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, CopyServe, 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 haunted 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, T. Monroe's. Can you guess which two of these are my inspiration to write a game? Coding, of course, and geocaching. Now, 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, 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 catch 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, and our buy one get two for free crews. Now, I know what some of you are 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 the 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 plugins 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, Ember Quest. Cool. Let's begin. We'll run Ember New Ember Quest. Don't worry, I'm on my home Wi-Fi. It's pretty fast. Okay, done. Now open our 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 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 in my proof of concept. It demonstrates fog of war, field 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 four milliseconds or less. Okay, time to start working on the real game. We'll add some better graphics and a few months. Once, we find our hero on the shore of the same island. Our ship is docked, waiting for us to do a little 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 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 sight range. I've removed most of the enemies for this demo, but keep our eyes open for any surprises. Hey, 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. Now, 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. I think I hear something around the corner. Oh no! It's a monster! Look out! 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 tests. 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, tracked! Definitely going to use that. Now you've already heard from other speakers how wonderful it is. It truly has made life a lot easier. Here 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 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 Ember Quest. 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 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 Ember Quest, 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 are ready to build your own game. Now let's take a break from Ember Quest 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 Ember Phaser. This will give us a new generate Phaser 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 Ember Phaser 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 life cycle hooks available for you to override. In most cases, you only need to use three. Preload, Create, Update. Preload is where you 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 in 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. The 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, training a ground and the player. The ground will be part of a static group. The group is in the 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. Be first. We need a way to move around. This is actually pretty easy. Bezier 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 him 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 the 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 two in the API docs for amber phaser online. Okay, great, but wait, it's not launch time yet. What about amber 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 amber mirage to make us more nimble, amber concurrency tasks to help regain his health and power. We armed him with amber track properties. We used amber auto import to use third party libraries. We gave him amber phaser so he can concentrate on his game mechanics. And finally kept him informed with amber guides. Now, time for a rematch. Yes, we victory. 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, amber. Thank you.