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