Making A Game Engine Is Easier Than You Think
•
2 j'aime•4,391 vues
This is a talk I gave at the Develop Conference 2015 in Brighton. It is a an attempt at making a balanced talk on when it makes sense to make your own technology, and what it takes to get you there.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Making A Game Engine Is Easier Than You Think
Similaire à Making A Game Engine Is Easier Than You Think (20)
Dernier
Dernier (20)
Making A Game Engine Is Easier Than You Think
- 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
- 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
- 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.