EmberQuest: Building an Octane Role Playing Game
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 24 | |
| Author | ||
| License | 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. | |
| Identifiers | 10.5446/46568 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 20203 / 24
2
5
8
10
11
13
15
16
17
19
20
23
24
00:00
Linker (computing)RhombusShape (magazine)CodeBuildingMusical ensembleComputer animationJSON
00:21
Game theoryBuildingGame theorySoftware developer
00:46
Software developerSoftware developerMereologyMultiplication signComputer animationMeeting/Interview
01:08
Revision controlRight angleCodeMeeting/Interview
01:36
Graphical user interfaceSoftware frameworkBookmark (World Wide Web)Game theoryVideo gameMeeting/Interview
02:04
FamilyDegree (graph theory)FamilyWave packetPrisoner's dilemmaComputer animationMeeting/Interview
02:27
FamilyDegree (graph theory)Open sourceProjective planeRight angleCodeGame theoryComputer animation
03:02
Descriptive statisticsGame theoryAdventure gameMultiplication signMeeting/Interview
03:25
Cache (computing)Graph (mathematics)View (database)Bounded variationMeeting/InterviewComputer animation
03:53
Network topologyGraph (mathematics)Shape (magazine)Inheritance (object-oriented programming)Game theory1 (number)State of matterCache (computing)Meeting/InterviewComputer animation
04:42
Web pageWindowWechselseitige InformationCarry (arithmetic)Maxima and minimaContrast (vision)KnotEvent horizonCache (computing)Coordinate systemGeometryRight angleGame theoryParsingNatural languageInteractive televisionPlug-in (computing)Multiplication signInformation
05:45
Ocean currentSoftware frameworkMultiplication signComputer animation
06:09
CodeGame theoryRevision controlComputer animation
06:41
Web browserComputer animationMeeting/Interview
07:03
Decision theorySoftware developerEuclidean vectorMiniDiscGame theoryCache (computing)Monster groupComputer animation
07:38
Game theoryMonster groupSquare numberHexagon
08:13
Proof theoryLevel (video gaming)Proof theoryHexagonComputer animationMeeting/Interview
08:32
Field (computer science)1 (number)View (database)HexagonDot productTrigonometryWhiteboardMathematicsProof theoryMultiplication signAlgorithmGame theoryCodeComputer animation
09:38
Field (computer science)Open setWhiteboardDisk read-and-write headRange (statistics)Copyright infringementView (database)RandomizationMachine visionCodeGroup actionNetwork topologyObject (grammar)HexagonForestDirection (geometry)Analytic continuationSummierbarkeitProof theoryComputer animationMeeting/Interview
11:25
Power (physics)Multiplication signOcean currentMechanism designFood energyGame theoryPoint (geometry)Moment (mathematics)Adventure gameComputer animation
11:53
Monster group
12:25
BootingRing (mathematics)BootingCategory of beingElectronic visual displayDemo (music)Different (Kate Ryan album)Software developerElectronic mailing listSoftware testingHidden Markov modelConnectivity (graph theory)Markup languageComputer animation
13:48
TrailVideo gameGame theoryCategory of beingComputer animation
14:14
Task (computing)Concurrency (computer science)Sample (statistics)Concurrency (computer science)Task (computing)Object (grammar)Multiplication signCategory of beingDisk read-and-write headCodeGame theoryGreen's functionTrailKey (cryptography)Social classRing (mathematics)Computer animation
15:20
Moment of inertiaSoftware frameworkMultiplication signLevel (video gaming)FamilyGame theoryDifferent (Kate Ryan album)Electronic program guideDemosceneWeb 2.0Online helpRevision controlDemo (music)MathematicsCollisionBlogComputer animation
16:23
Game theoryEinbettung <Mathematik>Cartesian coordinate systemGame theorySoftware frameworkMobile WebCollisionPhysicalismCodeProof theoryLecture/Conference
17:04
Source codeGame theorySoftware frameworkMobile WebGame theoryGoodness of fitSource codeControl flowComputer animation
17:24
LogicWhiteboardCartesian coordinate systemConnectivity (graph theory)Game theoryDemosceneService (economics)Electric generatorInstallation artLecture/ConferenceMeeting/Interview
17:55
Game theoryConfiguration spaceConnectivity (graph theory)Service (economics)Type theoryObject (grammar)Context awarenessBit rateWeb browserStructural loadPhysicalismDemosceneLecture/Conference
18:39
Game theoryNumberServer (computing)CASE <Informatik>Web browserObject (grammar)Medical imagingCollisionMusical ensemble
19:19
Video game consoleBit rateFrame problemRaster graphicsRWE DeaWeb 2.0Multiplication signVideo game consoleWeb browserComputer clusterMeeting/Interview
19:41
Greatest elementObject-oriented programmingTouchscreenPhysicalismService (economics)CodeCode refactoring
20:01
Analytic continuationService (economics)Group actionPhysicalismMereologyCollisionObject (grammar)Game theoryMultilaterationGreatest elementMeeting/Interview
20:25
PhysicalismComputer clusterComputer animationLecture/Conference
20:47
SpacetimeKey (cryptography)Right angleFloppy diskCASE <Informatik>Game theoryEngineering physicsBEEP
21:29
Medical imagingDifferent (Kate Ryan album)Computing platformUniform resource locatorTouchscreen
21:50
Computing platformMereologyCollisionGroup actionTouchscreenTouch typingComputer animation
22:15
Functional (mathematics)CASE <Informatik>HookingGame theoryInteractive televisionTouch typingService (economics)Game controllerLevel (video gaming)Group actionRoutingSystem callCartesian coordinate systemSource codeComputer animation
23:12
Game theoryDemo (music)Source codeMultiplication signCode
23:32
Concurrency (computer science)Electronic program guideCategory of beingGame theoryLibrary (computing)Multiplication signPower (physics)TrailTask (computing)Concurrency (computer science)Mechanism designComputer animationLecture/Conference
24:08
Bookmark (World Wide Web)Game theorySoftware developerVideo gameSoftware framework
24:59
Computer animationLecture/Conference
Transcript: English(auto-generated)
00:21
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
00:44
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
01:06
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
01:27
thought it was magic. Having the right tools empowered me to write better code. Thank you, John Resnick. I've been using... I've seen a lot of the JavaScript frameworks come and go. Of course, Ember is my favorite. Before I
01:48
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
02:00
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
02:25
me as a sharpshooter last year. Surprise! I enjoy writing code. I also
02:41
like geocaching. That's my geocaching name right there, Team Unrose. Can you guess which two of these were my inspiration to write a game? Coding, of course, and geocaching. Now, some of you may already be familiar with geocaching, while others are probably wondering what it is.
03:03
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, anytime adventure that can take you to amazing and beautiful
03:24
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
03:45
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
04:03
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
04:25
different states and 21 countries. Recently, I found two new ones in the Bahamas. I'll buy one, get two for free, cruise. Now, I know what some of you are thinking. What does this have to do with running a game? Well, sometimes the
04:44
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
05:01
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.
05:24
It took care of all the natural language parsing for me. Having the tools, the right 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,
05:41
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 1.13, 1.12. I had never heard of it. I was like, OK, whatever. It had to be better than my current JavaScript
06:03
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.
06:22
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?
06:43
GeoQuest 2? Nah, Ember Quest. Cool. Let's begin. We'll run Ember new EmberQuest. Don't worry, I'm on my home Wi-Fi. It's pretty fast. OK, done. Now open a browser. Congratulations, you made it. Nice.
07:08
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
07:26
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. OK, what will I
07:41
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,
08:02
sounds, inventory, fog of war, pathfinding, monsters, combat, saving the game, enemy AI. Makes my brain hurt. Too many things to think about. OK, well, let's just start with a
08:21
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
08:44
place the hexagons on a canvas. The light colored hexes are the ones that the player ship 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 path following results in purple for
09:03
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 in that I'll find
09:23
a path to a target hex way across this big board in about four milliseconds or less. OK, 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
09:42
island. Our ship is docked, waiting for us to go aboard and take a look around the sea. There's a pirate galleon on patrol. I've lowered his aggression so he shouldn't
10:04
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 on our
10:21
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
10:41
some directions. Normally, we could see up to three hexes away, as you can see in the clearing. You've probably noticed 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
11:01
removed most of the enemies for this demo, but keep our enemy, keep your eyes open for any surprises. Now look, a castle. Let's go in. Our hero has found a cave. The field of vision is easier to see in the tight fine finds
11:20
of the narrow passageways. Now you've 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
11:40
replenish over time. I'll talk about how Ember helps with that in a moment. I'm going to speed up our adventure 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 in the lava. I think I
12:07
hear something around the corner. Oh no, it's a monster. Look out. Oh, it appears that we have died.
12:24
Let's try again. Before we go around that corner again, what do we have in our package JSON? I mean inventory that could help in our battle. We have a few different categories. For weapons, we already own a
12:43
crossbar bow and a simple sword, but I guess they aren't very powerful. We're wearing some boots, her hat, temperature glasses. They're pretty cool. What's
13:01
an other? 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 CLI
13:23
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
13:40
quick list of inventory items to display. It was 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.
14:05
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
14:21
outstanding add on has saved me and probably some of you a lot of time when trying to use third party packages. I'm using, 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 divulge my secret weapon is the ring of concurrency, better
14:42
known as Ember concurrency. EmberQuest 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
15:00
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
15:22
we have that have been very helpful to me are the different resources of resources available when I needed help. The Ember blog, Ember times were always very informative and timely. Discord is there when it's 3 a.m. and I need help right now. And finally, Ember guides with all the
15:43
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 a lot been going on behind the scenes of this demo. WebGL, Canvas, Web Audio,
16:02
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
16:22
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
16:42
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 from my proof of concept and plug it into my Phaser add on and
17:02
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 EmberQuest and do just that. Let's make a
17:23
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
17:41
generate a toaster scene, a 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 HPS, we'll place the
18:03
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 to
18:21
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 had 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
18:43
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
19:02
objects are created, and update runs every game tick. This is typically where you will 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
19:21
look at, but at least we know it's running. The console reports we are using WebGL and Web audio. Nice. And we're running a full 60 frames per second. Time to add our hero. Refresh the
19:40
browser. There he is. 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
20:04
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 just we can detect collisions later. Now we have some ground, but he's still
20:21
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, feet first. We need a way to move around. This is actually pretty
20:41
easy. Bazer 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
21:04
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 them do that and make your own floppy bird or floppy Tomster in your case.
21:22
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
21:42
ground image loaded, so we're just reusing that image. We'll just place the new platforms 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
22:03
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 collectStar callback
22:21
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
22:40
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 collectStar callback is in our Amber service. We can do anything we want here. Call other Amber services, transition to another route,
23:01
and 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 your, for Amber Phaser online. Okay, great. But wait, it's not
23:25
lunchtime yet. What about AmberQuest? 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
23:42
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
24:01
on his game mechanics. And finally, we kept him informed with Amber guides. Now, time for a rematch. Yes, we victory. Now that he's out
24:31
of the way, let's take a peek around the corner. There's a chest. Congratulations, our
24:41
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.