making a game engine is easier than you think
TRANSCRIPT
Making A Game Engine Is Easier Than You Think
(maybe)
• 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
Not an Anti-Talk
Do Not (Try To)Compete!
Benefits of 3rd party engines• Battle tested!
• Often quick to prototype
• Easier to hire!
• Deploy to X number of platforms with ease
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(!)
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
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
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
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
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
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
No frameworks!
• Frameworks lock you in
• Tend to clutter
• Hard to swap out parts
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
No frameworks Clutter & Dependencies
• Even modular frameworks tend to clutter
• Increases dependencies
• Makes it hard to swap out components that don’t work
Independent libraries
• Decreases individual dependencies
• Minimizes risk by minimizing dependencies
• Easier to on-board new people
• Easier to test
• Components can be swapped out(!)
Libraries @ Kotori
Statemachine
Animation
Asset Display
Input Material
Math
Rendering
Platform
Scene
Social
Sound Text
Tools
Libraries @ Kotori
• All these compile independently to a dll / .lib
• Can and have been ported & tested individually
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!
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
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!
Modern C++ is not terrible!auto, lambda, smart pointers, for loops, closures, better std library, etc
More Book Recommendations
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!
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, ..
Typedef important classes Allows you to swap out components more easily!
#include <ExternalMath/Vector.h>
namespace MyMath {
typedef ExternalMath::Vector3<float> Vector3f; }
Prototyping
• Don’t mix prototype and production code -> good development practice
• Prototyping helps you focus on game play
Prototyping Tools Survey Answers
• Pen & Paper • Cardboard • Powerpoint • Unity • Index Cards • Action Script / Flash • Construct • Basic C++ & OpenGL • Blender • …
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
Off-the-Shelf Editors Alternatives to the Swiss Army Knife
• 3D • Sony Authoring Tools Framework LevelEditor
Off-the-Shelf Editors Alternatives to the Swiss Army Knife
• 2D • Tiled • Overlap 2D • TexturePacker • PhysicsEditor • SpriteIlluminator • Spine • Spriter • Fusion Character Animator
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
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
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
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!
Commercial Components
• Granny 3D • PhysX • Havok • Bink • FMOD • WWISE • Miles Sound System • Beast • Enlighten • FBX SDK • Elephant
Survey
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
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.
