RETO MEIER: Welcome to "Build Out," where real engineers face
off building fake products.
Today's challenge-- The Virtual Earth.
I'm Reto Meier, the perpetual winner, which means this is--
COLT MCANLIS: --Colt McAnlis, the only one of us
who's actually built a virtual world.
So whose earth rocks?
Find out now on "Build Out."
[MUSIC PLAYING]
You know the Northern Hemisphere points up, right?
RETO MEIER: Not in my world.
Southern Hemisphere forever.
Influenced by Neal Stephenson's global Metaverse,
my virtual earth builds on Google Earth
to build a fully interactive, global, virtual environment,
based on real-time updates returned
for millions of drone-based sensors deployed
all across the physical world.
We collect environmental data from millions
of basketball-sized autonomous drones
with environmental sensors, 360-degree Lidar, and cameras.
When you log in, everything will look and feel
as though you were actually there,
except all the people will be replaced
with virtual inhabitants.
So let's start with the balloon drones.
I'm going to build them with Android Things
as a software platform, and add TensorFlow models to control
the autonomous flight and privacy algorithms, that'll
remove people from the camera images.
We're going to send those images and the Lidar data
into Google Cloud Storage buckets
and use Pub/Sub to send notifications
about those new uploads to a specialized,
containerized application hosted as a Kubernetes service.
That will spin up, or horizontally
scale as many copies of my application
called pods, that I need to process
the incoming queue of images.
The rank and scale of incoming imagery
will vary over time, effectively creating a queue of data
to be processed.
We can use preemptible VMs here to save significant costs.
The real-time sensor data will also use Pub/Sub.
This time to publish, stream, and throttle data
from each sensor, guaranteeing its delivered into Dataflow.
Dataflow is a serverless, fully-managed data processing
service that lets us use the Apache Beam
SDKs to perform continuous computation
over an incoming data stream.
We're going to use it here to create a moving
window over the data, combining the results
of multiple, nearby drones over a fixed period,
to calculate an accurate topographic map
of environmental conditions which it will then
publish as a new Pub/Sub stream, which in turn, triggers
another Kubernetes service.
This container behind the service
is designed to process the environmental sensor readings,
also using preemptible VMs to create our virtual climate
and weather.
The process results from both Kubernetes and Alpha Services
are then stored in Spanner.
Spanner's strong consistency and horizontal scalability
is critical in a virtual environment that
can be modified by both real-world changes
and changes made by globally distributed users.
Another Kubernetes service takes all the virtual world data
and combines it to construct a server-based interactive
virtual environment.
The client side is built as an Android app.
The app will have a Daydream UI to provide
the immersive environment.
We'll keep an open socket with the server to receive updates.
And we'll send back any changes we
make to apply them server-side to Spanner,
so that it can then be reflected across all
of the other clients.
The speech recognition and Translate API
is, in short, everyone in the virtual earth
can communicate in real time, no matter what
their native language.
And finally, we send all the user analytics to BigQuery.
We use streaming inserts, so we can
analyze how people are interacting
with that virtual earth, and create a Data Studio
dashboard to keep track of current usage patterns
over time.
There you have it.
Do you want to escape a world in which red balloons float
on every street corner?
Try my virtual world.
COLT MCANLIS: Well, all right.
Nice to see you go first for a change.
How'd that feel?
RETO MEIER: It felt good.
It was nice not to be constrained
by your architecture for a change.
You ready to take a swing?
COLT MCANLIS: Listen, I got paid for the better part of a decade
to make video games.
Let's get this party started.
Now, my build isn't expecting you to run around
in a realistic 3D environment.
If Reto had ever read any real sci-fi,
he'd know that's not how this works.
In real sci-fi, they sit down, jack in,
and start running around in a virtual space.
So that's what we're going to build--
a virtual space.
My metaverse is a virtual reality MMORPG.
Your player can explore the wonders
of my beautifully rendered fantasy world with a pet dragon
by your side.
My world looks better than the real world,
so we don't care about Reto's real world.
And we're going to ditch all the sensor
stuff that's used to create those 3D environments.
Yes, even the real-time weather stuff.
See, if I live in Seattle and it rains all the time,
the last thing I want to do is go
into a game where it's raining.
So let's get rid of all of that.
Now, I like the Babel Fish idea of translation and speech.
That's actually super cool.
So I'm going to table that for now,
so we can get to the meat of things.
This leaves us with a few overlapping pieces.
First off, yeah, got to agree that Daydream
running on Android is the best place for this.
However, Daydream by itself is not a proper game engine.
I'm going to use Unity to act as a client-side game code
interface between the user and the Daydream system.
This also means that for our coding, scripting, and artwork,
they'll all be in a file format that Unity can understand.
Now, we're going to roll the dice on this one
and say that, along with our content generation,
we'll end up with some sort of system or governing
body that decides how and where new zones and regions are
added.
We're also going to need an update staging area, where
new content and fixes can be stored and pushed
to the clients and servers.
We'll use a combination of Spanner
and cloud storage to hold both the relational items as well
as the binary data.
We'll also put in a GCF frontend, which
allows the client to check for updates
and get a list of the things it needs
to connect to in cloud storage to download and update.
And just to make sure that you are who you say you are,
we're going to add an App Engine frontend instance, which
will leverage cloud IAM to authenticate and identify
the user and communicate with the account management
database, which may include some sensitive information
like billing and contact data.
For my application, we're going with App Engine Flex.
For some services, I can just use the provided run times,
but I can also customize it with my own Docker images
if we need some specific functionality.
By the way, this whole thing is very important
if we're trying to make a metaverse-level game engine.
As a user enters a game zone, we'll
figure out their closest region that we're deployed in
and connect them directly to a world shard that's
backed by a GAE Flex instance.
These world shards will help align things
like player and NPC movement and keep all the attached clients
coordinated, so you don't see people clipping through walls.
Now, along with that, we'll have a separate game service, which
is hosted on another cluster.
This is responsible for things like trades, auction houses,
guilds, and some basic types of combat organization.
To accomplish all that, we'll synchronize
the state between the instances, using the awesomeness
of Cloud Spanner.
Now, another great reason to use App Engine Flex is it
has horizontal scaling, without having
to worry about cluster resource constraints.
So that, combined with Spanner, means
that I can scale to the levels I need,
without having to page a bunch of SREs
to punch a hole in the wall and plug
in new servers in the middle of the night.
Now, for situations where we're using custom Docker images,
we'll also add a path to the Container Registry
to host new container images to be used for these services.
Otherwise, we can handle service code deployments
through standard rollout processes.
Now, finally, let's add that chat service.
Much like Reto's build, I like the idea
of adding auto translation systems in there.
I actually think he got that part right.
So there you have it.
A somewhat modern approach to building, scaling,
updating, and interacting with a massive metaverse environment.
And with the time I have left, let's talk
about how to add things like microtransactions,
in-game advertisements, and a hot key
that'll bring food to your door, so you don't even
have to leave the game.
RETO MEIER: Just couldn't resist, could you?
COLT MCANLIS: I'm a creature of habit.
RETO MEIER: Now, it's your turn to decide
which build was better--
my transformative rendering of our world, a boon to science,
and knowledge, and understanding,
and Colt's mildly addictive MMORPG.
COLT MCANLIS: Your build was so convoluted,
I was expecting you to put a 3D printer inside VR.
In any case, it's not up to us.
It's up to you, the viewer.
Leave a comment below the video to say which one of our builds
is better.
And don't forget to check out the "Build Out" podcast,
where we take a deep dive into the technology
behind these builds.
RETO MEIER: Thanks for watching.
I'm Reto Meier.
COLT MCANLIS: And I'm Colt McAnlis.
Always remember, perf matters.
[MUSIC PLAYING]