AI Engineer World's Fair 2026
The Next Game Engine Won't Have a Manual
Read the talk
The Next Game Engine Won’t Have a Manual
Nereu turns requests for robots, rain, and camera movement into reusable engine behavior, with an asset tag system and scene context tailored to the user’s editing focus.
From a talk by Arturo Nunez
Start with a robot
Ask for a robot, choose one, and press play. Nothing happens yet. The asset is in the scene, but being a robot does not tell the engine how it should behave. In Arturo Nunez’s recorded demonstration of Nereu, its assistant, Bibi, first finds robot assets through their tags or descriptions. Arturo selects one to become the character the player will control.
The next instruction supplies the missing behavior: “Make this robot move with WASD and animate it”. Bibi applies the request, and the character moves. The user describes an interaction familiar from playing games without first learning how to import a model or write its movement code.
The scene grows through the same conversational process:
- Add buildings. The asset library offers futuristic buildings, a warehouse or store, and a castle. Choosing among them feels more like assembling toys or Lego than committing to a finished game design.
- Add rain. The request creates a particle system configured to look like rain.
- Follow the character. Without a following camera, the robot can leave the view. Bibi adds and configures a camera targeting the main character, keeping it visible as it moves.
Each request maps a recognizable game idea onto concrete engine machinery. The user still decides what belongs in the scene and what it should do.
Arturo estimates that this recorded scene-building sequence could be completed in a couple of minutes, with the assets already supplied and without learning to code or import them. That is the promise behind a game engine without a manual: reach a playable interaction using the vocabulary of the game itself.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Making games should be fun, too
Arturo’s motivation comes from repeatedly watching developers encounter the same obstacles. He describes almost a decade at Unity, where challenges that initially seemed interesting became frustrating through repetition. He subsequently worked at MongoDB, explored AI and data management, and helped a startup with version control for game assets. The recurring question was why creators should spend so much energy solving familiar infrastructure problems again.
A commercial release is not everyone’s desired destination. A creator can spend years making a game and then discover how difficult it is to sell in a crowded market. For someone treating game development as a creative outlet, the process itself needs to be rewarding.
That process demands an unusually broad set of skills: programming, 3D modeling, rendering, music, animation, and real-time camera composition. Large teams can distribute those responsibilities; small teams require people to wear several hats. Even a technically successful implementation leaves the hardest design requirement unresolved: the game has to be fun. Arturo wants that enjoyment to extend to the developer, instead of letting production and sales pressure displace the craft. Making games should not require becoming a professional game developer first.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Describe game intent instead of engine setup
Powerful engines and powerful language models do not automatically make game creation accessible. Connecting an agent to Unity or Unreal can still require the user to know the engine’s vocabulary and ask for the right code. Arturo’s example is a following camera: he has seen LLM demonstrations generate essentially equivalent camera logic repeatedly. The request is about game design, but the assistant’s working context pulls it toward implementing engine details.
A conventional controllable character illustrates the accumulated setup. Import a mesh, give it a renderer and animator, add a rigid body and collider for physics, attach an audio source, and then supply movement logic and game rules. Much of this is recurring work, yet the creator must still understand component descriptions and the many settings exposed by the editor.
The proposed abstraction is an asset with intent tags. Rendering and, where appropriate, physics remain underneath. Above them, tags describe what the asset means in the game: a character, animated, able to double jump. The vocabulary resembles a player tutorial—press A to jump, then press A again in the air to double jump. Event rules use the same level of description: collecting a coin increases the score.
| Concern | Engine-facing description | Game-facing description |
|---|---|---|
| Appearance | Mesh, renderer, animator | Animated character |
| Movement | Physics components and movement logic | Character that can double jump |
| Rules | Game-rule implementation | Collect a coin to increase the score |
The intent layer does not eliminate rendering or physics. It makes those systems available without requiring every creator to configure their underlying parts.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
How the asset tag system selects behavior
Nereu calls this mechanism the asset tag system, or ATS. It draws on entity component systems and data-oriented design: describe objects through data, then let systems query that data to decide which objects they should process. Instead of generating a separate movement implementation for every asset, a shared system finds assets carrying the relevant combination of tags.
The diagram shows a car tagged vehicle, player, and driveable, alongside a building with no tags. Its UpdateVehicleMovement system acts on the matching car; the building remains still. A minimal JavaScript expression of that selection rule looks like this, using the slide’s driveable spelling:
javascript
const assets = [
{
id: "car",
tags: new Set(["vehicle", "player", "driveable"]),
},
{
id: "building",
tags: new Set(),
},
];
const requiredTags = ["vehicle", "player", "driveable"];
function selectMovementTargets(world) {
return world.filter((asset) =>
requiredTags.every((tag) => asset.tags.has(tag))
);
}
const movementTargets = selectMovementTargets(assets);
// The car matches; the untagged building does not.
The reusable part is the query and the system behind it. An asset’s visual appearance does not determine whether it qualifies for a behavior.
That separation permits a deliberately playful example: give a building vehicle and drivable tags, and it can become a participant in a Mario Kart-style game. A building need not be scenery just because its model looks like architecture. For the particular player-controlled query above, it would also need the player tag.
Bibi helps users discover and apply these capabilities. If someone does not know how to make a car move, the assistant knows the available tools and tags and can apply the appropriate ones to the referenced asset. The engine already owns the behavior; the assistant connects the user’s request to it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From a request to a scene update
The assistant’s update loop combines familiar agent mechanics with a constrained engine interface:
- Receive the request. The user describes what they want to change.
- Assemble context. Nereu includes scene information, asset themes such as robots or medieval objects, and the user’s description of the intended game.
- Call tools. The agent makes calls that add or remove tags.
- Apply the built-in behavior. The engine’s existing systems interpret those tags.
This gives the model a vocabulary of supported operations rather than requiring it to invent the implementation for each request.
Nereu intentionally has no user scripting system in the version described. The engine itself is JavaScript running in the browser, so developers willing to extend it can do so, but ordinary users are not expected to write scripts. The interaction ends with updates to the scene.
The difficult design work is deciding which tags and systems can express games across genres and across different descriptions of the same intention. A request for a scary platformer includes both mechanics and mood. Making it feel scary can require changes to lighting and post-processing, not just movement rules. Supporting that request means decomposing its meaning into engine capabilities that can work together.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Building the engine and teaching its assistant
Arturo describes building at an unfamiliar scale and speed through daily work with AI. He discusses ideas with Claude, then brings in domain expertise. For a lighting feature, for example, he asks an industry friend who specializes in lighting and uses that knowledge to shape the tools. Simplification is part of the work: settings and features he rarely sees people use are candidates for removal.
As tools are built, their definitions are supplied to Bibi, keeping the assistant informed about the engine’s growing capabilities. The development loop therefore connects two uses of AI: helping Arturo build Nereu, and helping Nereu’s users build games. At the time of the talk, he tentatively describes the product as a closed alpha, with a small group using it and providing feedback that starts the next iteration.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Describe the library, then focus the scene context
The assistant needs useful descriptions of assets before it can find them. Arturo reports a library of approximately 6,000–7,000 assets. Initially, he had their names and 3D files, which was not enough to make manual descriptions practical. He took screenshots and passed them through a vision model to describe and tag objects such as astronauts, knights, and castles. Vision supports asset preparation; the interactive assistant primarily uses an LLM.
Once assets are assembled into a scene, sending all their state to the model creates another problem. Arturo estimates roughly 100 assets in the example scene, many of them grass that could be ignored. Including every object at full detail would enlarge the context without necessarily helping the assistant understand the current edit.
Nereu borrows an analogy from rendering: level of detail. An object close to the camera may use a higher-quality texture, material, and model. A sufficiently distant object can use a much simpler representation—even a cube in Arturo’s example—because the viewer cannot distinguish the missing detail. The same principle can guide how much information an assistant receives about each object.
When the user selects a knight, the editing focus helps establish which surrounding objects deserve more detail. High-priority objects can be represented with their tags and the values of settings on those tags. Other nearby objects can receive a shorter description, such as identifying an object as a player and giving its position, without including its entire state.
| Context priority | Information supplied |
|---|---|
| Higher relevance to the edit | Tags and tag-setting values |
| Lower-detail nearby context | Brief identity and position |
As the user moves around and modifies the scene, Nereu updates the context supplied to the assistant. The useful transfer from rendering is selective fidelity: retain enough detail for the current task, and change that allocation as the focus changes.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the creator involved
Bibi’s purpose is to get people unstuck while they make a game. Arturo does not want this product to generate complete games in one shot that nobody subsequently plays, even though he acknowledges demand for one-shot generation elsewhere. He wants people to enjoy creating something and share it with friends and family.
Learning the language of game design is part of that goal. Learning programming is not a prerequisite or the intended curriculum, although some users have told Arturo that using the tool helped them understand programming concepts that had previously been unclear. The creative activity remains the center of the experience.
World models offer a different direction: generating interactive worlds on the fly. Arturo expects that direction to become a distinct medium, even if people continue to call its results video games. He argues that real-time world-model generation at 4K and 60 frames per second remains far away. This is his forecast about a demanding target; he identifies physics simulation as an additional challenge while remaining enthusiastic about the work.
At the close, Arturo offers to add interested people to the waitlist, including those who want to share the tool with children or friends. His own testing captures the experience he wants to enable: bring in an astronaut, add a dinosaur, and make them walk around. It recalls the enjoyment that brought him into game development roughly two decades earlier, before that work began to feel disappointing. Building and playing with Nereu has made it fun again, and he wants more people to experience that pleasure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Further reading
Arturo's introduction to Unity's Entity Component System, with project files and further reading on data-oriented design.
Unity's versioned manual explains how simpler meshes and billboards reduce rendering work for distant objects.
DeepMind's announcement describes interactive generated worlds at 720p and 24 frames per second, along with consistency and interaction limits.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hello. Hi, everyone. Thank you for being here.
- 0:16
Um, let's start the presentation. Uh, I really appreciate you having interest in, in learning more about, uh, game development. So today, I'm going to talk about how I think the next game engine won't have a manual, and, uh, at the end, you'll see what I mean by, by this.
- 0:33
My name is Arturo. I'm, uh, working on this tool called Nereu, and, uh, first, I want to show you kind of, like, how it works today, uh, so you get a glimpse of what I mean by all this.
- 0:47
Um, so we, we, we, we can start asking for what we want and describing something like, "Okay, I want to add a robot." Um, okay, so I ask my, uh, assistant to help me add a robot.
- 1:06
It found some assets that are robots or have been tagged as robots or the description are, uh, a robot. In this case, I want to have a character. It's going to be the character that I will be controlling.
- 1:19
Um, if I try to play right now, it won't do anything. I still need to tell what I want. I need to describe, "Oh, okay, I, I want this to be, uh, to move with WASD, and I want it to be animated, uh, have some sort of animation."
- 1:34
So I will describe that to my, um, assistant, uh, which is called Bibi, by the way, and I'm saying, "Make this robot move with WASD and animate it," as I, as I mentioned.
- 1:47
These descriptions are pretty common if you know or if you've played games. You just describe what you want the, the thing to, to do, and it's language that, uh, people who play games kind of understand.
- 2:01
Uh, you don't need to, to code or you don't need to, uh, learn about importing models or anything like that. The focus is on making the game. So now we have our character moving.
- 2:11
I want to continue, um, uh, describing my game, building my game, so I want to add some buildings. Uh, in this case, we have, like, a library of, of assets that might match the description of a building.
- 2:24
Mm, we could have, like, futuristic buildings, something like this, uh, warehouse or, or store. Uh, maybe we can use a, a castle. The idea here is that we can le- uh, let our imagination go wild.
- 2:39
It doesn't need to be, uh, you know, like a, m- the, the, the, the, the perfect game or anything. It's kind of like playing a game, playing with toys, playing with, with Legos or, or something like that.
- 2:51
I'm saying I want it to, to, to, to have some rain, so I just describe the rain, and it will spawn a particle system that's set up or configured as, as, as rain.
- 3:03
Uh, the last thing is I want a camera to follow my character because if I move around, it will go out of the, of the, of the view, and I won't be able to, to see it.
- 3:14
So it added a camera. It configured it. It's looking at my main character, and I have a game without knowing how to code or import assets or anything besides just knowing, uh, what I want because I, I know the, the language of, of building, building games.
- 3:32
That's the idea. Uh, so making games or getting to this point with a, a, a regular tool, it's very difficult. Um, I, I recorded this demo, but you could do this in just a couple of minutes without knowing anything, just describing.
- 3:49
All the assets are there for you. Uh, but if you were to follow the traditional workflow, you will need to know, uh, other things. Sorry, I, before jump- continuing, I, I want to mention, uh, why am I speaking here, and you can decide if, uh, you, you want to, to pay more attention or less attention to, to
- 4:09
myself. I worked at Unity, a game engine company, for almost 10 years, so I saw a lot of people building games and struggling with the same things over and over.
- 4:19
At first it was fun. The challenges were fun, but after seeing them thousands of times, it was like, "Okay, this is not fun. I don't think people should spend their energy and, and, and time, uh, re- uh, reinventing the same wheel."
- 4:33
So then I, I, I was part of MongoDB. Then I, I was learning about, uh, more AI topics and how to, uh, you know, manage data and all that stuff, and I was helping a startup to manage, uh, or, and handle, uh, version control of assets of, of games.
- 4:49
So as I said, I've been... I've seen people make games. I've made games, and, uh, I think
- 4:57
I want to, to, to, to, to let more people have fun and, and, and experience the joy of making games without getting frustrated and without, uh, you know, spending two, three years releasing something, realizing that it's difficult to, to, to, to sell g- a game.
- 5:14
There's a lot of competition, and of course, if you want to do that, I'm not preventing you from doing that. But a lot of people, I think it's, it's just an, a creative outlet, making games, and, uh, the game itself should be the, the, the, the thing, right?
- 5:28
Like, um, uh, enjoying the process rather than the end product. Okay, so as I was, I, I was saying before, making a game, uh, requires a lot of skills, a lot of knowledge.
- 5:40
It's very, it's very difficult. You need to know programming, 3D modeling, rendering, music, animation, and so many other things. You either have a huge team that, uh, complement each other, or if it's just you or you have a small team, uh, people need to wear multiple hats.
- 5:59
And honestly, it's very difficult to find someone that's great at game design and also great at, uh, rendering and great at composition of cameras in real time. So, um, on top of that, the game has to be fun, right?
- 6:14
If, if it works and technically works, if it's not fun, uh-
- 6:20
Honestly, people won't play it. And I, I think fun should be for the player, but also for the developers. In recent years, I think, uh, it's become more about producing more and trying to sell more, uh, rather than, than, than the, the craft of making games.
- 6:36
And I don't think you need to be a, a, a professional game developer to be able to, to make games. The same as with, with, um, uh, AI assistants to write code.
- 6:47
Now you don't need to be a programmer to, to build whatever you want. The same for, for games. There are other challenges, but, um, that's my, my thought. Now, there are powerful engines, Unreal, Unity, and there are powerful LLMs and agents, but I think still it's hard.
- 7:04
It's hard because I think we're just, uh, building a bridge between two worlds, and it's not optimal, and you still need to know kind of like what to ask in the vocabulary of an engine, in the voc-vocabulary of, of code.
- 7:19
Otherwise, uh, the, the, the, the, the LLM goes, uh, rogue and does stuff and reinvents the wheel over and, and over. Uh, this is the, the point, right? Like if I say, "I want a camera that follows this character," I've seen the, the demos, and L- the LLM reinvents the wheel every single time where when the result
- 7:39
is going to be essentially the, the same. Uh, by default, the context is on the game engine, uh, rather than on the game design part, and I think we should flip that idea.
- 7:51
So in a current engine, if you want to control a character, you need to have a mesh, uh, uh, import a mesh, and think about, uh, so many things, a renderer, an animator, a rigid body, and collider for physics, an audio source, and then you add your movement logic and your game rules.
- 8:09
Uh, most of that is just boilerplate that every single game out there has, or every character in every single game out there has. But somehow, developers need to understand and read the descriptions of those components and what the hundreds of, of, of, of sliders do, uh, in, in, in a game.
- 8:28
So I think the, the, the, the, the goal should be just to think, okay, everything is just an asset. Everything has to be rendered on screen. Everything has physics most of the time.
- 8:41
Uh, and you just add tags to describe the intent of those, those assets in your game. So I want this to be a character, to be animated, to double jump, and this is the language of...
- 8:53
that we use when we play games, right? Like, uh, the tutorial tells you, "Oh, press A to jump and press A again while you're in the air to do a double jump."
- 9:03
That's, that's the language that we should be using. And, uh, also defining what happens when, when even- an event occurs. Like in this case, oh, when you collect a coin, I want you to increase the score.
- 9:14
And, uh, of course, the physics and the rendering still happen, but, uh, we're, we're, we're building, uh, on a layer on top to make it more accessible for more people to, to build, uh, games.
- 9:28
Um, and the engine knows what to do with these tags because these, these systems, and this system comes from something that we're calling the ATS or asset tag system.
- 9:41
Comes from the idea from game development called a Entity component system, uh, data-oriented design, which means we just describe objects, uh, with, with, uh, in, uh, components or in this case with tags.
- 9:55
And then there are systems that query for all the assets in the, in the world and say, "Okay, this, uh... I'm, I'm going to move all the objects that have the vehicle, the player, and the drivable tag."
- 10:10
So that's how, how it works, and all the games can recycle this. In the... on the, on the right, you see that there's a building. It doesn't have tags, so it's not going to move.
- 10:20
But nothing prevents you from adding the, the vehicle and drivable tag to your building, and then you have a, a building that you can put in a Mario Kart style of game.
- 10:30
Uh, nothing prevents you from, from doing that and as I said, like letting your imagination go, go wild. Uh, the assistant, the AI assistant essentially helps you get unstuck.
- 10:40
Like if I don't know how to make the car moves, uh, I just ask it, and it knows, understands, like what are the tools available, what are the tags available, and then it, uh, a- applies them to, to the, to the, to the asset that I'm talking about.
- 10:54
Uh, how it is driven, and this is, this is pretty common, um, concept from, from, um, agents. You just type your query. You, uh... well, we build the, the, the prompt using context from the scene, uh, but also some extra context, um, based on, for example, what type of assets are on your game.
- 11:16
If you're using robots, if you're using something like medieval, et cetera, we fe- um, we, we append that to the, to the, to the context. We also, uh, allow the, the user to describe the type of game that they want to, to make, so that's also part of what, um, uh, is, is appended into the, into the,
- 11:34
the context. And then the agent just performs calls and appends or removes the, the tags. All these, uh, tags and all these systems are built into the, the, the, the engine.
- 11:47
Um, we don't have a scripting, uh, system in there. That's on purpose. But it's just JavaScript and runs on the, on the browser, so whoever wants to extend, they can.
- 11:58
Nothing prevents them from, from doing that. But for most users, uh, that shouldn't be the, the case. And, uh, yeah, all the updates to the scene happen, and that's how, how it works.
- 12:09
Honestly is... the, the, the challenging part is the composing- Games, uh, into these tags and into these systems because, uh, there are a lot of genres, there are a lot of, uh, ways to describe the same game.
- 12:24
There are things like the mood of the game, like I want to make a, a platformer, but that feels, uh, like scary. Well, that also touches on things like, um, like, uh, the post-processing effects and things like the, uh, lighting, et cetera.
- 12:38
So those, those things are the things that we're decomposing to, to, to, um, drive the, the engine. How I'm building this, well, it's,
- 12:49
it's the first time that I build something of this scale at this speed and using, uh, you know, mostly working with, with an AI, um, daily, and I'm sure everyone uses, uh, Claude Code or something similar.
- 13:02
Uh, the way it, it works is I bring all this stuff that is on my mind, and I talk to the, to, to Claude, and we discuss that part.
- 13:12
Then I go to... Let's say, if I'm focusing on something related to, to, to, um, lighting, I talk to some friend on the industry who focuses on that, and I ask questions, and then I bring that in, and then we build those tools.
- 13:25
And I kind of like say, "I don't think we need this setting. I don't think we need this feature. I haven't seen a lot of users using those things, so let's get rid of them in order to simplify the, the, the engine."
- 13:37
Uh, we build it. Then as we build, we give, uh, the definition of the tools to the, to the assistant. So every time, uh, we add new tools, the assistant knows the, the tools that we're, we're adding.
- 13:50
And, um, yeah, uh, right now it's, it's kind of like still in closed alpha. I don't even know how to call it at this point, but some people are using it, giving feedback, and, uh, then we go back to square one.
- 14:04
Um, one thing that I, I think it's worth sharing also in, in, in, in this presentation is the, the way of assembling this context because, yeah, we're using an LLM mostly.
- 14:16
Uh, I've used, uh, also vision models mostly to tag the, the assets that we have because it's like six or 7,000 assets. I could not manually tag them all and explain like, "Oh, this is a, a, a, an astronaut, and this is a, a, a knight, and this is a castle, and this is whatever."
- 14:34
I just have the names and the, and the, and the 3D file. So I took a screenshot and ran, uh, a vision model to describe the, those. But it's mostly an, an LLM, what's, uh, what we're using.
- 14:48
And if we feed the entire scene to the LLM, the context grows a lot. Let's say in this, in this scene, I think I had like 100 assets, 100 things, uh, being there, but most of them are like grass that we could ignore.
- 15:04
It doesn't really make sense. But, uh, this is simple, like, like scene. But what we're, we're using here to, to assemble the context is something that's very well known in, in the, in the game dev world, which is called level of details, uh, which means if I'm close to an object, uh, or, or it's close in, in
- 15:23
sight to, to myself, I'm going to render it with a higher quality texture, with a higher quality material, um, with a higher quality model, in many cases. Something that's too far away from the camera, I'm just going to maybe just put a, a, a cube, and the user won't be able to, to tell because it's so far
- 15:41
away. So we're using something similar to assemble the context. In this case, if the user is editing the, the, the game, you can see that maybe, uh, well, uh, it's, it's, it's clicking on the, on the knight, right?
- 15:54
So the things that are around it might have a higher priority, so we feed them, uh, information about the tags that they, they have and the, the values of the, of the settings on, on those tags.
- 16:06
Things that are nearby, we just say, "Okay, there's a something, uh, that's a player, uh, here at this position, uh, but I'm not going to send you the entire, entire, uh, context in there."
- 16:19
Okay? And as a, as a user keeps moving around and modifies things, then we update that, uh, and feed the, the, the, the assistant with more relevant, um, information about, about the game.
- 16:34
Okay. So just to start wrapping up, I, I, I, I think this assistant called Bibi should be kind of like the, the...
- 16:44
Something that ons- gets people on stock from making the game. Uh, I don't want us to one-shot games that nobody is going to play, and, uh, I don't see the point in, in that.
- 16:56
There's, in the industry, of course, uh, the need for, for games that are one-shotted, but here the idea is that we allow people to make games and experience that and have fun and, uh, share that, those games with their families and friends and, and, and that.
- 17:11
And of course, that they learn along the way the language of making games, the language of game design, not necessarily the coding or programming. Al- although, uh, people have used it, this and say like, "Oh yeah, I can understand now concept that I didn't understand before of programming," but, uh, that was not the, the, the initial goal.
- 17:32
Um, there's another kind of like branch of, of engines or tools that are, are being used called, uh, world models, which are being generated on the, on the fly and, and some people...
- 17:44
I think there's another session later talking about these and how games can be achieved with, uh, world models. I think that's going to be a different medium, even if we call them video games.
- 17:54
Uh, there are many challenges. Uh, games, uh, for instance, in these days, they have to render 60 frames per second, and doing that at 4K resolutions in real time, uh, with a, with a world model, I think it's ta- it's still far away.
- 18:10
And on top of that, uh, rendering physics and on, and, well, t- sorry, simulating physics and stuff, it's very difficult, but I think it's exciting what's going on. Um, so that's it.
- 18:23
If you want to play around, if you want to share this with your kids or friends or, or whoever, uh, I, I can add you to the, to the wait list.
- 18:33
Um, it's... Honestly, it's been very fun to make, but also whenever I want to test something and I just play around and, and, and bring in, um, an astronaut and bring in a dinosaur and make them just walk around, it's, it's so much fun.
- 18:49
It's, uh, it's, it's kind of like what got me into game development I think like 20 years ago. And I progressed throughout my career. I started getting like kind of disappointed, like, "Oh, I don't...
- 19:01
This is not fun anymore," so I'm having fun again, and I want to share that with, uh, more people. So thank you so much, and I'll be outside if you have questions, want to chat more about games or whatever.
- 19:12
Thank you so much for your time. [audience applauding] [outro music]