1. Making A Game Engine Is
Easier Than You Think
(maybe)

2. • SGI Mainframes
• Set top boxes (OpenTV)
• Embedded hardware
• Mobile (iOS / Android)
• Desktop (Windows / Mac /Unix / Linux)
• PS2 / Xbox 360
14+ years in Games and VR @gormlai

3. Kotori Studios Ltd
gorm@kotoristudios.com

4. Not an Anti-Talk

5. Do Not (Try To)Compete!

6. Benefits of 3rd party engines
• Battle tested!
• Often quick to prototype
• Easier to hire!
• Deploy to X number of platforms with ease

7. Hidden cost of 3rd party engines
• There is no such thing as cross platform!
• You have to wait for bug fixes
• Idiosyncracies can be hard to understand
• You cannot look inside the black box
• Sharing assets / source code can be hard
• Technical limitations
• You are entirely dependent on success of one
company(!)

8. Hidden cost of 3rd party engines
There is no such thing as cross-platform
Desktop versus Mobile
• Different input methods
• Requires redesign of UI
• Memory requirements
• I/O is slower on mobile
• GPU Capabilities
• Difference in player demographics
• Configuration options

9. Hidden cost of 3rd party engines
There is no such thing as cross-platform
iOS versus Android
• Difference in resolution ratios
• Difference in payment patterns
• GPU Capabilities
• Memory Requirements
• Game Center vs. Google Play Services
• Multi-tasking / backgrounding works differently

10. Hidden cost of 3rd party engines
Technical Limitations
• Engines have a payload that take up space
• Less performant than custom code
• Hard to control memory usage (important on mobile!)
• Hard to control asset loading (important on mobile!)
• Not all functionality may be exposed
• Vender and OS maker doesn’t follow same upgrade
cycle

11. Building your own tech is hard!
(but may be easier than you think!)
You have to have the right mindset
• Only build what you need!
• Refactor as you go
• Use design patterns

12. Building your own tech is hard!
(but may be easier than you think!)
You have to have the right skillset:
• You need the right skill set
• Experts at the programming language of your choice
• People who have used several engines
• People who know understand scene graphs
• Don’t be afraid of math
• Understand the production pipeline

13. It is all about architecture!
• Forget frameworks!
• Build separate libraries that work well together
(the unix idea)
• Use libraries like lego bricks to build an “engine”
pr. game

14. No frameworks!
• Frameworks lock you in
• Tend to clutter
• Hard to swap out parts

15. No frameworks
Lock In
• Take over the game-loop
• Forced to do things in a certain way
• Near impossible to swap out components
• Forced to live with bad as well as good components
• Risky for business as everything is dependent on one
thing

16. No frameworks
Clutter & Dependencies
• Even modular frameworks tend to clutter
• Increases dependencies
• Makes it hard to swap out components that don’t work

17. Independent libraries
• Decreases individual dependencies
• Minimizes risk by minimizing dependencies
• Easier to on-board new people
• Easier to test
• Components can be swapped out(!)

18. Libraries @ Kotori
Statemachine
Animation
AssetDisplay
InputMaterial
Math
Rendering
Platform
Scene
Social
Sound Text
Tools

19. Libraries @ Kotori
• All these compile independently to
a dll / .lib
• Can and have been ported & tested
individually

20. V0.1
Developing the components
• Design components and libraries
• Design interfaces
• Build wrappers around existing
libraries
• Focus on getting the pipeline up
and running as fast as possible!

21. V0.2
The Game is Running
• The content team can now start building
• You start to understand your needs better
• Exchange one or two components that are
essential to your game!
• Again, only build what you need

22. V1.0
1st Game has Shipped
• Libraries have been polished and are more mature
• Reuse, iterate and improve for next game
• Piece together in a new way for a new game!

23. Modern C++ is not terrible!
auto, lambda, smart pointers, for loops, closures, better
std library, etc

24. More Book Recommendations

25. Use open source
(ignore the lawyers!)
• The number of mature and well-tested open source
components have exploded!
• It is white box!
• Easy to avoid GPL / LGPL as they are no longer
trendy
• More permissive licenses are getting more common
place
• Do read the small print!

26. Use open source
Answers from the survey
LibRocket, ZLib, Nothings Public domain projects, Ogg-Vorbis
(non-stb), SDL, Cocos 2D X, FBX SDK, Cricket Audio, Freetype,
GLEW, GLM, libpng, freetype2, ODE, jingle, Newton Game
Dynamics, Open Asset Import Library, SFML, Ant Tweak Bar, Allegro
5, Mono Game, Pugixml, Box 2D, Geometric Tools, GLFW,
NoiseLib, Bullet Physics, Gl3w, libcurl, rapidxml, rapidjson,
angelscript, Metal, LibGCM, libGDX, Raknet, lwjgl, Opus, Cal3d,
FreeImagePlus, TinyXML, Irrlicht, BGFX, Lua, libjpg, npk,
Berkelium, mysql, Collada, Cryptopp, Gdal, Awesomium, ..

27. Typedef important classes
Allows you to swap out components more easily!
#include <ExternalMath/Vector.h>
namespace MyMath
{
typedef ExternalMath::Vector3<float> Vector3f;
}

28. Prototyping
• Don’t mix prototype and production code -> good
development practice
• Prototyping helps you focus on game play

30. Prototyping Tools
Survey Answers
• Pen & Paper
• Cardboard
• Powerpoint
• Unity
• Index Cards
• Action Script / Flash
• Construct
• Basic C++ & OpenGL
• Blender
• …

33. Building the Editor
Alternatives to the Swiss Army Knife
• Build game as dynamic / static library OR
• Embed editor in game
• Build editor of reusable components (widgets, etc),
exactly like the game
• Editor can be build using a different programming
language:
• .Net (C# / F#) with WPF / Windows Forms
• Objective-C with UIKit
• C++ using a GUI Library
• etc

34. Off-the-Shelf Editors
Alternatives to the Swiss Army Knife
• 3D
• Sony Authoring Tools Framework LevelEditor

35. Off-the-Shelf Editors
Alternatives to the Swiss Army Knife
• 2D
• Tiled
• Overlap 2D
• TexturePacker
• PhysicsEditor
• SpriteIlluminator
• Spine
• Spriter
• Fusion Character Animator

36. Do You Need A Game Editor?
Alternatives to the Swiss Army Knife
• Data-Driven Design
• Use a mix of tools to drive game changes
• Hard to avoid scripting language

37. Focus on the Pipeline
How Fast Can The Team Iterate?
• From Photoshop / Audacity to Game
• Open Asset Import Library
• libpng, libjpg, ogg-vorbis,
• Generate derived formats behind the scenes
• From 3D modelling package to Game
• FBX SDK
• Collada
• Open Asset Import Library

38. Focus on the Pipeline
How Fast Can The Team Iterate?
• Adding GameState
• Exporting state from Visual Design
• UI Layouting
• Design in your favourite tool, using known
conventions (folder structure, layers, xml tags,
etc)
• Hot loading

39. Focus on the Pipeline
Scripting
• Many scripting language offerings
• Hold long does it take to see my changes?
• .Net / JVM has recompile-on-the-fly built in!

41. Commercial Components
• Granny 3D
• PhysX
• Havok
• Bink
• FMOD
• WWISE
• Miles Sound System
• Beast
• Enlighten
• FBX SDK
• Elephant

42. Survey

49. Comments
positive
Tried all the major engines, they're good for basic
manipulations but once you want to do more
advanced stuff, such as loading a level in a
background thread, there is a huge learning curve
and a huge dependency on the developer
community which sometimes consists of students
responding to forum questions. Absolutely not the
way I'd want to work.
1. performance tuned to game
2. ability to alter code to suit my needs
3. ability to tune load times/etc.. Which i
consider to be massively important on an ios
game. Using <engine name> and making user
wait for ages to load - isnt on.
Independence, control, ability to target emerging platforms
No blackbox portion in my code base. Save a ton of time from debugging and finding out why shit blew up.
Building a game as a service, with a
lifetime of 2+ years it's safer to have
control over your tech.
Workflow, features adopted for your type
of games, not a one size fits all solution.
Possible to adapt and render pipeline to suit project

50. Comments
negative
Some people never ship games, just keep tweaking the engine.
- Investment ( hours spent creating it, and
keeping it up to date)
- Hires will not know the tech, vs. e.g. many
people know Unity already
- You're not learning a "standard skill" that
might be a wanted one down the road ( e.g.
Unity development skills)
One step forwards, Four steps
backwards ... 80 percent of resources
spent on the pursuit of technological
dead ends, unavoidable consequence
of working outside the conventional
scope
The time to build it!
Tool development is time-consuming, and
good tools = good games.
Overall, we've now found that maintaining
our own engine is too expensive and puts
us at a competitive disadvantage.
Bug fixing and maintenance takes a lot of time which could be spent on games itself
Hard for new hires to learn.
C++ programmers are rare.

51. ?@gormlai
gorm@kotoristudios.com