Game Engines 2021W Lecture 3

Notes

Lecture 3
---------

what is the best game engine?
 - and what does this question even mean?

If time and effort are no object, the best game engine is the one you built yourself.

Why?

 - it supports exactly what you want to do with minimum effort
 - because if you built it, why wouldn't it be that way? :-)

So, we don't nowadays build our own game engines because we want to save
time and money
 - current game engines are very powerful, would take a huge amount
   of personal/team effort to duplicate

Nevertheless, some teams do maintain their own engines
 - licensing
 - you already have it
 - it is known to the team
   - in-house knowledge facilitates customization
 - it is suited to the type of games your team makes

For "interesting" game development, the most important game engine feature is
extensibility/customization

games, at their heart, are rule-based systems
 - the rules are the heart of gameplay
 - the rest is the interface

game engines inherently limit the kinds of rule-based systems you can build
 - because they are built with certain assumptions about what a "game" looks like
 - they have to make those assumptions in order to speed up game development

So using a game engine makes lots of tasks easier, but at the same time
it gets in your way the moment you want to do something "different"
 - an interesting game is one that is doing something different from
   past games
 - kind of like research, if it is the same as what has happened before,
   why not just play the old game?

What sort of games/game mechanics will be challenging to implement in
most game engines (unless there is a specific extension)?
 - procedural generation (code-generated levels)
    - you're going to be doing this on your own mostly
 - detailed simulation games (beyond physics)
 - AI based (other than simple rules-based AI)
 - economic simulations/reactive worlds

Game engines are built to facilitate specific parts of games
 - graphics and sound
 - movement of objects/appearance of scenery in 2D/3D
 - keyboard/mouse/controller input
 - networking

Note that the assumption of objects moving in 2D/3D space can be limiting
 - what if the space doesn't follow normal physics rules?
    - non-euclidean games
 - dynamic particle/surface movement?
 - time as a dimension?

The space of possible 2D/3D images/animations >> 2D/3D easy to build in a game engine
 - they have assumptions on what you want to build

2 games come to mind
 - Portal
   - changes spatial relationships fundamentally w/ portals
 - Braid
   - can reverse time, turns platforming into a puzzle game
     - but is also a game mechanic, because some things don't reverse
 - fez
   - bizzare spatial arrangements


How do we get game engines?
 - built to facilitate the creation of specific games
 - then are slowly generalized to deal with other games
   - never completely escape their origins, although
     they can grow beyond them

How does this compare with general software development?
 - this is exactly what has happened with mainstream software development
 - we have tools/libraries/frameworks to support standand applications
   - really, facilitate key interface and functional pieces
   - as developers, you often more assemble pieces than code components

When you make a GUI, you use standard libraries/frameworks
 - get consistent interfaces this way, users know how they work
 - don't want to change the rules

But with games, we often *want* to change the rules
 - if it is completely predictable, it's boring
 - learning is key to games
   - simple games have replay value because we're learning about other people
     as well as the rules
   - basis of competitions

speed running is all about testing the limits of the rules of games
 - exploit the bugs!

when you make a game, you are playing with rules
 - game engines implement specific rules
 - you're going to want to change some of them to make an "interesting" game
 - changing rules => extending the engine

What does software engineering tell us about extensible systems?
 - we know that dealing with legacy code is hard
   - legacy code => code we didn't write (or forgot about)
 - modifying any software system means dealing with some degree of legacy
   code, i.e., other people's code
 - true for game engines as for anything else

We have a strategy for working with other people's code, abstraction
 - just have to learn the interface, not the implementation
 - but all interfaces are leaky
   - reveal details of implementation
   - constrained by implementation
   - huge source of bugs

So, if you can't write your own engine, the best engine is the one that
 - makes standard things easy
 - facilitates doing custom things in the easiest way possible

Note these two requirements can be contradictory

What are the arguments in favor of dynamic typing?
(Static typing is so much better because it catches errors, right?)
 - JavaScript, LISP, Python
 - quick development of prototypes
   - why?

Dynamically-typed systems are inherently more extensible
 - because they don't assume anything about data types
 - will just try, and throw errors if something doesn't work

Static typing
 - the type of all symbols is known at compile time

dynamic typing
 - type of data associated with symbols is only known at runtime
 - a symbol can refer to any data

Dynamic typing facilitates programs that adapt and change to new tasks

Statically-typed languages have very complex mechanisms to try and get
the benefits of dynamic typing with more safety
 - templates, generics

Godot does use dynamic typing natively
 - but supports statically-typed languages

But I'm thinking more philosophically

Lisp is the ancestor of most dynamically-typed languages
 - JavaScript is, roughly, just Lisp in drag (C-style syntax)

What was Lisp used for?
 - artificial intelligence

Why?
 - flexible representations/rules

With game engines, we ideally want as few constraints on what we can create
 - should be flexibly extensible
 - so, we should be able to adapt existing facilities to new purposes

This sort of flexibility is facilitated by uniform building blocks
 - think legos

For game development, you want to deal with legos as much as possbile
 - avoid melting plastic when you can

Godot is more flexible than most game engines because of key design choices
 - focus on generic nodes
 - dynamically-typed extension language
 - editor built in game engine
    - editor itself is extensible/modifiable in same way as games