We adjust the last query to give us levels and level versions
Let's find out the average time players spend in our levels. There are two ways to do this, so we need to define the question a little more.
We want to know how many sessions have occurred against our levels
Now lets write a query that tells us how many times each level has been started
We write a query to tell us how many players have played our game
It seems the build we used to generate our test data had a bug, we've got no testing data! Let's fix that.
Time to plan out what SQL queries we'll be writing over the next few videos
A very handy feature of DataBricks Notebooks is their data charting. We take a quick look at how to use them with our data
Our EC2 servers are up and running, time to play our game on them. NOTE: there is a bug with this build that blocks tracking events. This gets corrected in Video32.
Our game data currently only has one user and we don't have a device farm to get more. We show how you can use AWS EC2 servers as devices to get more test data.
SQL is Richard's favorite language! In case you aren't familiar with it, we give a crash course so you to can find new language love!
Time to get back into Spark and learn more about how it works and how it can be used.
The last event to setup is when players complete a level
Our Enemy can see through walls, time to take that super-power away.
We want to see where players are spotted in our levels, and which enemy did the spotting
Finally we setup the distance based tracking events
Now we'll setup time based tracking in our levels
There are 3 ways we will capture how players move through our levels. We setup Click based tracking
In this video, we setup the LevelStart event
Before setting up the analytics capture events, we plan out what events we'll capture and what data will go with them.
With the data loaded into Spark, we have a quick exploration of the format
Now that the raw data is hosted on S3 and we have an Apache Spark cluster, lets load the data into our Notebook
We'll be running our Apache Spark clusters on DataBricks. In this video we take a quick look at the interface
For easier debugging, we'll log the captured events to the console.
All of the events we will be capturing have a common base set of data. In this video we setup and populate the base object
In this video we take advantage of AWS Mobile Analytics data export to save our raw captured data to S3
Now lets get the AWS Mobile Analytics code setup in Unity
The game is ready, it's time to add data capture! We setup the AWS Mobile Analytics service
Set up an account, and very importantly, get some security setup
We need a way to switch between levels, so in this video we'll setup a Level Manager
Finally we give the Enemy a way to "see" the player
Next we get the Enemy to patrol between it's patrol points
It's time to get an Enemy into the game for the player to avoid
Completing the coding required to get the player moving to where the player clicks
In this video we get the player moving to where the player clicks
In this video, Richard gives a quick course overview of the technology used and the data pipeline
In this video we create our main game component that wraps our game setup and game board sub-components.
In this video we build the component, markup, and interaction logic of our game setup component - which is used to set game options.
We wrap up our game setup component by implementing the styles for the markup we’re generating.
In this video we stub out all of the rest of the components we need to finish the client. In addition, we wire them all up to the game board component.
The first sub component we implement is our card component, which will be used frequently on our game board.
The next component we implement is our stacks, which are used to display the currently played cards in the game.
Our final component is our player hand. In this video, we wrap up all of the rest of our React code that we will be writing in this course.
This video goes over the high level architecture of our server code.
We start off our implementation of the diff function with a basic test harness.
Our next diff function will handle diffing arrays.
We finish our simple diff function with being able to handle objects.
Next up we implement our merge function that accepts diffs in the form of those generated by the makeDiff function.
In this video we load up our cards into a special data structure.
Our first “room” that we implement is the application. In this video, we also create our client class and hook it into socket.io so that the server can now send actions directly to the clients.
This video completes the app store, by integrating it into the SET_VIEW action as well as socket.io connection events.
Next up we implement the server-side code for our lobby, and see how we will be handling events from the client.
Now we stub out a few of the classes we’ll need for our game implementation and finish our implementation of the lobby.
The first game handlers that we implement are for setting game options and sending messages.
Next up we implement many of the core bits of the game logic.
The final bit of server code we have to write is the state machine for the game!
In this video we wrap up the project with showing how to deploy our application to Heroku, as well as demonstrating some of the potential issues that may come up.
Now we’re going to see how JSX can be used to create our shadow DOM, instead of having to rely in createElement.
This video goes over what component state is and how we can properly handle events in our React applications.
We finish our counter application example by talking about how we can modify a component’s state.
We start our todo example by putting together a basic form that allows us to toggle a checkbox.
Next up we take a look at how we can create stateless components.
One of the most important things to be able to do in React is to render lists of elements. In this video we go over how to do that.
Now we take a look at how we can handle events in React.
We wrap up our todo application with a discussion of how to deal with forms and component lifecycle events.
We kick off our project by creating some of the basic folders and files that will be needed to continue building our build system.
Before we continue with configuring our project, we need to install and configure the core babel compiler as well as the babel plugins that we will be using in this course.
With Babel installed and configured, we can move on to setting up eslint.
With eslint configured properly, we then integrate it into our editor to provide instant feedback while we work.
Now we install gulp, and configure it to allow us to compile our server code. We also take a look at how we can use sourcemaps in node applications.
With our build step out of the way, we now implement our watch and run tasks for our server - allowing us to be able to have our server be restarted automatically on file changes.
This video shows a basic way that we can hook unit tests into our application using the jasmine testing framework.
In this video we create a basic express app that servers out a templated view as well as our app’s favicon image.
To speed up the next few videos, in this video we install all the necessary packages for webpack.
Now we put together the configuration for our webpack client build.
In this video we finish the production configuration, integrate the webpack compiler with our gulpfile, and include font awesome into our project.
Next up we implement our final gulp tasks, and integrate them into being able to launch an entire development environment with a single command. We also setup the webpack dev server to serve out our client code when in development.
With our development server running, we next put together our configuration for hot module replacement; allowing us to hot-reload our styles without having to refresh the browser window.
Before we can take a look at hot-reloading our components, first we must install react and react-dom and take a look at how we will be using them in the context of our module loader.
We finish our build pipeline with enabling hot module replacement for react components.
We take a look at how we can debug our client code inside of both chrome and Visual Studio Code.
Finally we see how we can debug node applications inside of Visual Studio Code with sourcemap support.
To conclude this section, we recap how to work with the project structure we created in this section. This video is for people who wish to use the bundled project structure starter pack instead of going through the set themselves.
To start with, we install the rest of the NPM packages that we will be using in this course. We also switch from using babel-runtime to using babel-polyfill, as well as change a potentially annoying eslint rule.
The first thing we do is configure react-router to instantiate the proper top-level components for the two screens that we will have in this project (lobby and game).
Before we start implementing our components, we have to style our application’s base layout.
We kick off our implementation of the lobby component with our JSX markup and styles for our sidebar buttons as well as our game list.
Before finishing our lobby, we take a look at how we can use react to create reusable input controls.
We finish our lobby by implementing our chat box.
Before we start implementing our dispatcher, stores and actions, we look at a high level overview of how our client-side architecture will come together.
We start off our implementation of the dispatcher with unit tests that describe the API surface of our dispatcher.
With our tests out of the way, we put together the implementation of the dispatcher.
In this video we stub out our store classes.
To finish off our basic infrastructure for our action framework, we need a way to access our dispatcher and stores from within certain components in our application. In this video, we use React contexts to achieve that.
Our first action and store observable will be for our implementation of a dialog subsystem. In this video, we implement the dialog action as well as the observable sequence for keeping track of them being open.