Lecture 9: Game Engine Basics

# Creación de Videojuegos

### Game Engine Basics

---

# Game Engines

---

# What is a Game Engine

* Games are typically split between an engine and content 
  
  * The engine can usually support multiple different games (theoretically) 
  
  * Extensions to the game don't require changes to the engine (ideally)
  
  * Engine provides components for loading content, rendering, physics, networking, AI, sound, etc.
  
---

# Why?

* Rendering, physics, etc. are reusable components
  
  * Good software engineering practice says they should be written separately
  
  * The game itself becomes smaller, and easier to change 
  
  * It becomes easier to make more games
  
  * Game Engine can be licensed

---

# How do I write a Game Engine?

## Don't!

---

# But let's talk about how you would

---

# This is all you need (basically)

```C#

while (true)
{
    foreach(GameObject go in scene)
    {
        go.Update();
    }
    scene.Render();
    FrameSync();
}

```

---

# What's this?

```C#
foreach(GameObject go in scene)
```

* A GameObject is an entity in the game 
 
 - Can be concrete, like an enemy
 
 - Or abstract, like physics, networking, input, ...
 
 * The Scene is the collection of GameObjects that is currently loaded/active
 
---

# What's this?

```C#
go.Update();
```

* Every GameObject has an Update method, which is called every frame
   
   * Can be used to move or animate the game object, run AI behavior, sound effects, etc. 
   
---

# Moving

```C#
   public void Update()
   {
       position += new Vector3(3,0,0)*Time.deltaTime;
   }
```

* Every frame the game object is moved in x direction 
  
  * Time.deltaTime represents the time since the last frame
  
  * The movement speed is 3 units per second 
  
---

# Are there any problems with doing everything in Update()?

---

# Frames Per Second (FPS)

* Ideally we want at least 25 FPS 
 
 * That means we have 40 ms per frame 
 
 * All Update() methods together need to need less than 40ms
 
 * We are also rendering things
 
 * What about slow calculations?
 
---

# Threads

* Idea: Run computationally expensive calculations in their own thread 
  
  * Exchange information between threads using shared data structures
  
  * Access to data structures has to be synchronized to avoid consistency problems
  
  * What could possibly go wrong?
  
---

# Synchronization problems

* Thread A moves an object forward at a constant rate 
  
  * Thread B calculates the route for the object, and then moves it onto that route 
  
  * Which order are they going to be executed in?
  
  * How long does thread B need?
  
---

# One solution: Messaging

* Only one (main) thread is allowed to touch the object's location
 
 * Other threads can request movement by sending a message to the main thread 
 
 * Can still do expensive computations in threads, but can not manipulate the scene
 
 * Main thread can rate-limit message processing
 
---

# Fixed Updates

* Some subsystems (like physics) benefit from a (pretty) fixed update rate 
  
  * Instead of doing physics calculations *every* frame, they are just done every n milliseconds 
  
  * In your main loop you check if the necessary time between updates has passed
  
  * May need to interrupt `Update` if it takes too long
  
---

# Using a Game Engine

* Programming in this setting is very different from regular programming
  
  * In most programs you have one main thread of execution 
  
  * Now you have dozens of objects each with its own little routine to do things 
  
  * Physics collisions cause events to happen 
  
---

# Using a Game Engine

* When you get used to it, this way of coding is actually very nice 
  
  * Consider each game object separately, and implement its behavior separately
  
  * If you need some global state, make *one* GameManager object or similar that stores it 
  
  * Think of it in terms of "if x then y" (like in your GDD), for each game object
  
---

# Scenes

---

# Scenes

```C#
    scene.Render();
```

* Many game objects will have representations on screeen
  
  * 2D/3D graphics, GUI Elements, particle effects, etc.
  
  * Where do we actually get all of these things from?
  
---

# Scene graph

* Scene
    - Living Room
       * Fireplace
          - Wood
          - Fire
       * Carpet 
       * Couch
       * Player
          - Avatar
          - Weapon 
          - Pet
    
    - Hallway
       * Ceiling light
       * Coat hanger
       
---

# Scene graph

* Spatial (or logical) grouping of game objects 
  
  * May load, move, manipulate entire sub-trees at once 
  
  * For example: Moving the player also moves their weapon and pet
  
---

# Building a scene graph

* Load scene from file (e.g. XML)
  
  * Load 2D/3D models from model file 
  
  * Supported formats determined by game engine
  
---

# How do you ...

* Shoot a bullet?
      - Create a Bullet Game Object
      - Update() moves the bullet forward
      - A physics collision removes the bullet from the scene
      - Or use a raycast
  * Detect collisions?
      - Physics subsystem calculates collisions
      - When a collision is found a message is sent to the objects involved
  * Make a multiplayer-game?
      - Networking runs in a thread 
      - Other player moves: message is sent to GameObject representation of that player
  * Change levels?
      - Load a new scene
      
---

# Game Engines

---

# 2D

- PyGame
  
  - Ren'Py
  
  - GameMaker
  
  - RPGMaker

---

# 3D

- id Tech

- Ogre3D
  
  - CryEngine
  
  - Lumberyard
  
  - Unreal
  
---

# 2D and 3D: Unity

---

# References

* <a href="https://www.gamedev.net/articles/programming/general-and-gameplay-programming/making-a-game-engine-core-design-principles-r3210/">Making a Game Engine: Core Design Principles</a>
 
 * <a href="https://www.gamasutra.com/blogs/AhmedKhalifa/20170315/293689/Game_Engines_Galore.php">Game Engine Overview</a>