What is a Game Engine?
In our second week, we started to talk about what a game engine actually is. There are many different types of game engines (Unity, Havok, Unreal) and each engine can handle different aspects of the game (Havok - Physics and animtion; Unity - Phyics, animation and rendering; Ogre - Rengering). Engines deal with the core elements and calculations for your game, such as: data structures, timers, memory management, resource management, compression/decompression, encryption/decryption, math utilities, file I/O and other utilities.
The great thing about engines, is the ability to reuse them for different games. You can take one engine, and build multiple different games around it. Now, obviously tweaking will need to be done to get the desired result for whatever you may be using it for, but it saves you a whole lot of time, especially since you will not need to rewrite a completely new engine for each game you develop.
As you can see with the above image, there are multiple different engines talking to each other, but each engine can be taken and used in a different project (again with minor tweaking). This is one of the many attractive qualities when using engines. You will also notice that each engine has a specific duty. One might handle animation, and another scripting. You can develop "complete" engines which handle everything in one package, but many games use an already developed engine which may handle a specific task, and plug it in or build additional components to develop something entirely their own.
We also touched on scene graph's which are considered the core of an engine. Scene Graph's allow us to organize objects, primitives, allow grouping, group transformations and effects. Their job is to feed geometry to the renderer, which is later rendered to the screen.
Finally we went over subversions and UML diagrams. Subversions are important to monitor, since many programmers will be working on an engine at one time, so it is important when submitting your code to identify what code version you are working on, and what version is currently in the repository. UML diagrams are incredibly helpful when you are working with engines, especially when you wish to identify which systems you want communicating with eachother, and what those subsystems contain in terms of functionality.
For my next blog post, I will be covering singletons, and how managers can organize create efficient communication within the subsystems.
Finally we went over subversions and UML diagrams. Subversions are important to monitor, since many programmers will be working on an engine at one time, so it is important when submitting your code to identify what code version you are working on, and what version is currently in the repository. UML diagrams are incredibly helpful when you are working with engines, especially when you wish to identify which systems you want communicating with eachother, and what those subsystems contain in terms of functionality.
For my next blog post, I will be covering singletons, and how managers can organize create efficient communication within the subsystems.
No comments:
Post a Comment