Lets make our web calls from Unity more generic for easier extension in future
Time to get back into Unity and deserialise the data from our WebAPI
With IIS setup, we can build and deploy our WebAPI
Lets setup an EC2 server to host our WebAPI
Time to make our code more reusable through Generics
We adjust our SQL queries so they can be filtered to a specific level name and optionally by version
Lets get the last API call setup to see where players are getting spotted by enemies
We get the API call setup for PlayerPath_ByTime
Next up is PlayerPath_ByDistance
Now that we know more about MVC.NET, lets get data from our database starting with PlayerPath_ByClick and return JSON
A quick crash course in MVC.NET. If you are familiar with MVC.NET already then feel free to skip onto the next video.
Finally, we write a query to tell us what enemies spotted the player, and where both were positioned
Time to write a query to find where players were after moving a few units of Unity space
Let's write a query to tell us where players were over time
We write a query that will tell us where players have been clicking
Time to plan our next steps - what data do we need to get out of Spark?
With our MySQL server up and running, it's time to get Spark exporting data. But how do we get Spark to export SQL queries?
Lets take a look at how we can connect to our new MySQL server through MySQL Workbench
We setup a MySQL database on AWS to store our processed data
Now that we can join tables, we can write a query to get the completion rate of each level
The next video will require us to join two tables together, time to give a crash course on joins
Time to write a query that tells us what dates players are playing our game
Now lets write a query to tell us how many unique users have played each level
We write a query to find what level players are stopping on, based on the LevelStart event
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.