Week 2 - What is a Game Engine?

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.

First Week

First Week

  
    Well, we had our first lecture for Game Engines.  Since it was the first lecture, most of the class was used for dealing with administrative stuff and course structure.  After we were done with that, we got into what we will be learning about and what we will be doing.  I have to say, once we started talking about the course, it got me really excited.  We will be using Havok as our physics engine, and Ogre for our graphics and rendering engine.

  
    These engines will help out greatly in improving the quality and mechanics within our game.  Before, we had to create our own engines from scratch, which was invaluable in providing us with knowledge of how engines work.  The caveat to this is that since we have such a short amount of time to create our game, our game engines lack the more advanced functions that these third party, pre-built engines have.  It also takes up a lot of time having to program in the basic engine functions like collisions, animations and physics calculations.  With these engines, we can now focus on adding more gameplay and creating better and more enjoyable game mechanics for our games.

    Now, with all that said, I still enjoy developing my own engines and I believe that learning how to build an engine and the basic functions that go into engines should be learned before you go using pre-built engines.  This will then allow you to understand what is going on within the engine and allow you to better use the engine to it's full extent.  It will also allow you to use the engine as an extension to/or a plug-in for your own engine.

    Now onto my game idea.....

    My game idea would be a puzzle game where you are a mouse with a solar staff.  The staff manipulates light and dark energy.  Each level would hold several different puzzles which would need to be solved by channeling these energies.  Some passages of the level might only be accessible when day turned to night, and vice versa.  You could change the time of day by using the necessary light or dark energy on a stone, situated in a central room.  From there, you would proceed to solve each puzzle until unlocking the final door.  These puzzles could be anything, from putting weights on switches, to completing a circuit.  Once all of the puzzles were solved, the door to the next level would open up.

    Entities apparent in the game would be a main character entity, as well as enemy entities.  Items within the game would be the solar staff and the different puzzle items (things like blocks to fill holes, wires to complete circuits, etc.).  The main feature of the game would be the ability to control dark and light energies (solve puzzles, change day to night, unlock passageways). 
 
    I think these features, mixed with the Havok and Ogre engines could produce a quality and enjoyable game to play.