1. Mark Nelson mjas@itu.dk What are game engines? Fall 2013 www.itu.dkwww.itu.dk

2. What’s a game engine? Try #1  Real-time graphics engine?  Maybe w/ physics?  Possible features  Realistic water  Shadows  Reflections  Destructible terrain

3. What’s a game engine? Try #2  Integrated game builder?  Possible features  IDE  Level editor  3d modeling  Asset pipeline  Debugging  Scripting

4. Engines are lots of things  Libraries  Frameworks  Collaboration/integration architectures  Generic game shells  Tools

5. No engine  In the olden days, you might code a game by:  Writing code  that implements  the game

6. Engine as library  It’s sometimes nice to reuse code  Collision detection  Physics  Sprite blitting  AI

7. Engine as library

8.  Bottom-up game-engine development  Write a game, then another one  An engine is whatever you can reuse  Can you package that up into a library (or middleware)?

9. Engine as library  Engine as way of outsourcing complex but modular stuff  What do you need that is hard to implement, but could be plugged in if you had it?  AI, fancy graphics, advanced simulations, advanced physics

10. Engine as framework  Libraries let us reuse stuff we call out to  Can we reuse some of the structure, too?  Check input  Update positions  Calculate dynamics  Redraw screen  Manage memory  Sync network state

11. Engine as library v. framework  Defining feature of frameworks is inversion of control  And, they’re opinionated about it Your game Library Framework Your game

12. Engine as framework  Defines classes of stuff, and you plug in the specifics  Sprites, objects, levels, events, behaviors  Customize by extending or overriding classes  Instead of bottom-up abstraction, pattern-matching abstraction

13. In-class exercise  You are a 1-person programming team wanting to make a small-budget game. Do you code from scratch? Use an existing engine? If it depends, what does it depend on?  You are a 50-person team with a large budget. What about now?  [take 5 minutes to discuss]

14. Engine as collaboration/integration arch.  A lot of people work on a modern game  They produce a lot of different stuff  Level designer  Dialog-tree writer  3d modeler  Graphics programmer  AI programmer  Network programmer  NPC behavior scripter

15. Engine as collaboration/integration arch.  How do we plug all this stuff together?  An engine architecture provides modularity and interfaces  Asset pipelines  Required functionality  Dependencies  Division of responsibilities

16. Engine as collaboration/integration arch.  One big boundary: code v. non-code  Architecturally: code v. data  Socially: programmers v. non-programmers  (Lots of other boundaries and interfaces.)

17. Engine as generic game  Codification of genre conventions  ”A Zelda-style engine”  ”A platformer engine”  Everything but the game  A very opinionated framework

18. “Final Fantasy engine”

19. “Quake 3 engine”

20. Platformer engine

21. “Civ 5 engine” ?

22. Spectrum of engine genericity  Many engines are a mix of ’engine’ and ’game’  Cleaner separation in more established genres  Cleaner separation from game content than dynamics

23. Engine as game-development tool  Unity as a game-development environment  Library, framework, editor, tools  Most engines have an associated toolchain  Some 3rd party, e.g. Maya  Some custom, e.g. level editor  Spectrum of wizardry  RPG Builder, Game Maker  Unity  UDK

24. Exercise for next week  Choose an existing game and think about what engine features would make it easy to program similar games  An existing engine?  Something new?  Was the game already built on an engine (if known)?  How generalizable is the game?  (I’ll ask in class next week, but you won’t be graded or need to hand the exercise in.)