lecture outline lecture outline
play

Lecture outline Lecture outline Run Run-time game architecture - PowerPoint PPT Presentation

Lecture outline Lecture outline Run Run-time game architecture revisited time game architecture revisited Game Engine Architecture Game Engine Architecture a very complicated multilayered system a very complicated multilayered


  1. Lecture outline Lecture outline � Run Run-time game architecture revisited time game architecture revisited � Game Engine Architecture Game Engine Architecture � a very complicated multilayered system a very complicated multilayered system � Spring 2017 Spring 2017 � subsystems within subsystems subsystems within subsystems � � Low Low-level engine systems level engine systems 2. Game engine basic support systems 2 . Game engine basic support systems � � need subsystem initialization and shutdown need subsystem initialization and shutdown � � use different implementation strategies: static use different implementation strategies: static � Juha Vihavainen Juha Vihavainen vs. dynamic objects vs. dynamic objects University of Helsinki University of Helsinki � Controlling the Controlling the main loop Controlling the Controlling the main loop main loop main loop � [Gregory, Ch [Gregory, Ch. . 5 5.1: .1: Subsystem start Subsystem start- -up and shut up and shut- -down, down, � simulation of a game world and its entities simulation of a game world and its entities � 7.1 7.1 - - 7.3 7.3 Game loops Game loops � real real-time discrete time discrete updates updates of game entities of game entities Ch. 15.7 Events and message Ch. 15.7 Events and message- -passing passing ] ] � � co co-operative multitasking operative multitasking system for games system for games [ [McShaffry McShaffry, Ch. 5: , Ch. 5: Game initialization and shutdown Game initialization and shutdown , , � Ch. 7: Controlling the main loop + cooperative multitasking Ch. 7: Controlling the main loop + cooperative multitasking ] ] 21.2.2017 21.2.2017 Juha Vihavainen / University of Helsinki Juha Vihavainen / University of Helsinki 2 21.2.2017 21.2.2017 Juha Vihavainen / University of Helsinki Juha Vihavainen / University of Helsinki 3

  2. Run Run-time game architecture (simpl.from Gregory, 2014) time game architecture (simpl.from Gregory, 2014) Engine core support systems Engine core support systems Question : where is the game loop ? Game Game-specific specific subsystems subsystems � � � Starting up and shutting down the engine Starting up and shutting down the engine � vehicles vehicles, , weapons weapons, , cameras cameras, , game game-specific specific rendering rendering (water water), AI, etc. ), AI, etc. � � interdependencies between subsystems => => ordering of � interdependencies between subsystems ordering of Gameplay foundations Gameplay foundations � � � initializations and final release (e.g., file system, logging) initializations and final release (e.g., file system, logging) � game game flow flow system/FSM system/FSM, , scripting scripting, event/msg , event/msg system system, , loading/streaming loading/streaming, , � real real-time time agent agent-based based simulation simulation � Handling access to file systems Handling access to file systems � Game model & view support Game model & view support: skeletal animation, rendering : skeletal animation, rendering engine engine (scene scene � � � wrapping native file system for portability wrapping native file system for portability graphs graphs, , particles particles, , lighting lighting), physics/collisions, audio , IO, ), physics/collisions, audio , IO, online online multiplayer multiplayer � Game assets Game assets (multimedia (multimedia resources resources) � support streaming (loading data on support streaming (loading data on- -the the- -fly/on background) fly/on background) � � � � 3D 3D models models, , textures textures, , materials materials, , fonts fonts, , physics physics parameters parameters, , world world maps maps, etc. , etc. � � Loading and providing access to different kinds of assets (files) Loading and providing access to different kinds of assets (files) Core programming Core programming systems systems (for any large (for any large-scale C++ application/system) scale C++ application/system) � � � � meshes, textures, animations, audio (e.g., in UPK package) � meshes, textures, animations, audio (e.g., in UPK package) meshes, textures, animations, audio (e.g., in UPK package) meshes, textures, animations, audio (e.g., in UPK package) � start/shut start/shut, asserts start/shut start/shut, asserts , asserts, , asserts, , testing , testing testing, testing, , mem , mem mem. mem. . alloc . alloc alloc., alloc., ., string/hashed ., string/hashed string/hashed ids, string/hashed ids, ids, profiling ids, profiling profiling, profiling, , math , math math, math, , , � � � debugging, debugging , logging logging, , engine engine config config., ., RTTI/refl./serialization RTTI/refl./serialization, , object object ids ids, files.. , files.. � Development tools for game programming Development tools for game programming � Platform Platform-independence independence layer layer: : detection detection, , file file system system, , timer timer, , threading threading , , wrappers wrappers.. .. � � � debugging, logging, RTTI, low debugging, logging, RTTI, low- -level resource handling level resource handling 3rd 3rd-party SDKs party SDKs: DirectX/OpenGL/Vulkan, PhysX/Bullet/ODE.., : DirectX/OpenGL/Vulkan, PhysX/Bullet/ODE.., Boost Boost++, ++, � � � (memory, strings, files), math, object handles.. (memory, strings, files), math, object handles.. STLPort, Kynapse AI, STLPort , Kynapse AI, Havok Havok animation animation 21.2.2017 21.2.2017 Juha Vihavainen / University of Helsinki Juha Vihavainen / University of Helsinki 5 21.2.2017 21.2.2017 Juha Vihavainen / University of Helsinki Juha Vihavainen / University of Helsinki 6 on demand, with static static locals Use Use construction construction on demand, with locals Initialization of subsystems Initialization of subsystems class class GRenderEngine { . . . GRenderEngine { . . . // game // Consider the following approach: Consider the following approach: game render render manager manager static GRenderEngine& static GRenderEngine& Get Get () { () { class GRenderEngine { class GRenderEngine { // game renderer // Construction done once only Construction done once only game renderer ( or whatever or whatever ) static GRenderEngine instance static GRenderEngine instance; ; return return instance instance; public: public: } } GRenderEngine () GRenderEngine () GRenderEngine () GRenderEngine () { / { / * start up the render manager { / * start up the render manager { / start up the render manager * / } start up the render manager * / } / } / } Ensure the initializations Ensure the initializations Ensure the initializations Ensure the initializations GRenderEngine GRenderEngine () { () { ~ GRenderEngine () ~ GRenderEngine () { / { / * shut down the manager * / } / } * shut down the manager GraphicsDeviceMgr:: GraphicsDeviceMgr::Get Get (); TextureMgr (); TextureMgr::Get ::Get (); (); . . . . . . / * now . . * / / now set set up up the the render render manager manager . . . . }; }; } . . . . . . ~ GRenderEngine () { ~ GRenderEngine () { / * shut manager * / / } shut down down the the manager GRenderEngine Renderer; // note singleton = global instance GRenderEngine Renderer; // note singleton = global instance }; }; }; }; This Renderer Renderer is created before and destroyed after the is created before and destroyed after the main () main () � This � � Order Order of of destruction destruction depends depends on on calling calling constructors constructors in the in the right right order order � � But remember that constructors and destructors of global objects But remember that constructors and destructors of global objects in in looking Get Get() () allocates � I Innocent nnocent- -looking allocates and and initializes initializes heavy heavy- -weight weight objects objects � � different compilation units are executed in unpredictable order are executed in unpredictable order different compilation units � S Still till cannot cannot prevent prevent some some destructor destructor calling calling on a on a destroyed destroyed singleton singleton => => subsystems depending and using each other may not work � subsystems depending and using each other may not work 21.2.2017 21.2.2017 Juha Vihavainen / University of Helsinki Juha Vihavainen / University of Helsinki 7 21.2.2017 21.2.2017 Juha Vihavainen / University of Helsinki Juha Vihavainen / University of Helsinki 8

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend