Start Your Engines!

So I'm going to do my usual thing and work against the grain here by talking about something that's kind of related to our class but at the same time it's not something that we'd talk about at all really: Game Engines! This is sort of a field that's captured my interest and it can pertain to graphics as there are some engines specifically designed for rendering (i.e. OGRE) so I'm not entirely off the rails with this! Now, I get the feeling that this is going to be a rather long blog as I'm going to be starting off with just a run through of what Game Engines are and what they do, some examples of engines and a little bit about their development cycle (Source and Crystal Tools) and finally some of my own plans *insert evil laugh here* so without further preamble...

Disclaimer: I'm still pretty ignorant when it comes to a lot of this stuff so don't expect grade-A, dead on explanations.

Okay so what is a Game Engine? It's pretty much all there in the title: It's the engine for the game, it's the power house which can help get a game moving from the get go. In a way, it's pretty similar to a Framework (which are used as a jumping off point for engines)  however it comes with a lot more functionality that is designed to streamline the development cycle. One of the major things for engines is that they usually come equipped with the basic necessities for games such as audio, collision and so on. The three basic types of game engines are all-in-one engines, framework-based engines (such as Source) and graphics engines. From what I've understood the all-in-one engines are the ones sort of like Unity where you can make pretty much everything right off the bat with it without needing anything extra while the framework-based ones usually end up spawning some tools that can be utilized with them (i.e. The Source Engine comes equipped with the Hammer Editor which is a tool specifically for building levels that will work with in the engine, as evidence by the ever-increasing list of custom TF2 maps). Then graphic engines just specialize in the rendering process of games and can be used for pre-existing rendering techniques as well as managing scenes and what not. That's more or less a jumbled and quick breakdown of Engines

So like I had mentioned earlier I'm going to talk a bit about two game engines: One I know a fair bit about and the other which I don't know nearly as much about. Let's start with the one that I do know: Valve's Source Engine. So when you purchase a Source game (such as Team Fortress 2, Half-Life, etc.) you get access to a few of the Source engine tools. These include things such as the Hammer Editor, a model viewer, as well as some tools for making mods and so on. The Source Engine is constantly being updated and with it every game that is supported by it, as many owners of Valve games on Steam are aware of when they get little updates for all their games that generally don't do anything to the game itself. This engine is in constant development and because it's an in-house engine for Valve that they can constantly edit it with their own new tricks such as when they introduced a new method of rendering water in Left 4 Dead 2! One key difference between the development of the Source Engine and the next engine I'm going to go into to is that the Source Engine was initially built with a specific game in mind: Half-Life. This gave the team a clear goal when designing much of the features as they knew that they would have to prepare it to be specialized for first-person shooters; a fact which has held true decades later but has been expanded on with time.

So the next engine I'm going to talk about is one that I don't have a whole lot of info on and serves more as a warning for why you should have a single game in mind from the start: Square Enix's Crystal Tools Engine. So this engine has produced some pretty visually impressive games (the entire Final Fantasy XIII collection) and seems to work pretty well...Though, reading up on some stuff revealed that it had a somewhat shaky start off. The engine was initially built with Final Fantasy XIII in mind as the title for it to support but it quickly started taking on multiple projects within the company, each one demanding different specifications and causing the development team to loose track of what they needed to do. This would eventually result in them making it so that some games couldn't even include their assets! So I don't have much to say on this matter other than the fact that this does solidify the importance of having a game in mind from the start.

So that's my technical rambling that's probably missing the mark in a few places...If you want to verbally tear apart everything I've said and you happen to be Dr. Hogue or one of the more well-versed students at UOIT then feel free to tweet me and we can arrange a time to chat over coffee or something!

Now then, on to my last part: My own plans with this information!

...It's not that much of a secret, if you haven't figured it out now then that's genuinely surprising. Obviously I plan to try and begin my own game engine this coming summer. I don't plan to use it for GDW but instead for my own purposes outside of school. I've begun working on a game idea for this engine to be based around but it's still very early in the pre-production stage and with exams and Level-Up looming on the horizon I don't have much time to properly mull things over, so development is pretty much relegated to when I have spare brainpower. The way that things are looking to go, I'll have to put heavier emphasis on making smooth close-combat with irregular shapes which will require creating a more elaborate collision system that works more along the lines of your standard shooter (where each limb has its own box and such) as well as accounting for different shapes. Ideally I'd want to make something similar to Unity where I can toggle between different types of collision but simultaneously be able to add a lot of depth to it. Another heavy emphasis will be on real-time cutscene rendering so I'd like to have something set up that would allow me to easily create a camera track with speed control. I'd also want to put a lot of work into designing a good base for AI as I'll need support for friendly combat AI.

I apologize for the large chunk of text above as this was more me trying to plan it out for myself as well as I find I do develop my ideas better my trying to explain them to others. I'd rather not edit the above area or delete it as I think it does explain a bit more about me as a person...But to summarize it:

Things I will need to emphasize
-A larger variety of collision with varying depths of complexity
-A method of better controlling cutscenes
-A strong AI-base

I also plan on making my engine a framework-style engine so that I can produce some tools to better work with it. Ideally I'd want to create the following:
-A model viewer/render tester: So that I can experiment with different shaders while making sure they run in-game and produce the intended results
-A custom level editor: Ideally one that can take in OBJs and allow me to set up different types of triggers and such
-A cutscene creator: Something similar to the level editor except that I could create a track for the camera to follow and control its speed as it progresses. I also would like to make it so that I could export custom animations for the scene as well as load in level layouts so that I could experiment with moving characters around and seeing how the scene plays out before exporting it as a file type that's easy for the engine to read in at the necessary time.

I recognize that a few of these are probably very unrealistic given my current skill level and I'll probably have a lot of optimization errors in my first pass. I also know that it won't even be close to being a quarter finished by the end of the summer but that doesn't really matter in the end. At the end of the day, even if it doesn't work out I'll still hopefully have learned something or driven myself so crazy that it won't matter anymore!

On that note I'm going to wrap up this post. Now I just need to think of another topic to write about as I already have my final post planned out to some degree. Cheers for now!

Side-note: I am well aware that we take Game Engines in 3rd year, I'll be picking up the copy of my textbook from home after Level-Up. I also know I could have just waited before starting something like this, but as Dan Buckstein can attest: I very rarely wait until it gets taught in class.

Ramble Ramble Ramble

So last time on this blog: I had mentioned either talking about mo-cap data or portals and did a lot of ranting on AI! This time: I'm going to talk incoherently about different stuff and doing the Portals for Portal will randomly be explained somewhere in the middle. So if I'm going to ramble then what's the point of this blog post, you ask? Simple! I'm going to take this chance to talk about a lot of small things which I don't think I could use for an entire blog post or which would mean retreading ground I've already covered. So without further adieu...

Reflections!

What do I mean by reflections? I mean making something like a mirror that renders in real time. Doing this is a pretty simple 2-part process so I'll just walk through it with some explanations along the way.

Part 1 - Render the scene from the point of view of the mirror, to do this you want to first get the vector between the camera and the mirror in question, this gives you your viewing angle which you will then reflect along the normal vector of the mirror to give you a reflection viewing angle. The actual equation you would want to use here is: V - 2 * (V dot N) * N. This vector is the direction that your mirror camera is looking at, once you have this you simply calculate the Up vector and you can generate a View Matrix for your mirror. Use this view matrix to render the entire scene once, storing it into a Framebuffer Object. Now that you have the scene the mirror sees, move on to the next step!

Part 2 - Now that we have the scene that the mirror sees, we render the scene like we do normally and apply the FBO texture from the previous pass to the mirror: It will now display the reflection in real time and it will change based on the position of the player's camera.

Now that we have reflections working, we can apply some fun stuff to it. For example, we could make a rippling surface as if it's on a lake, to do this we have multiple options: We could use a tesselation shader and use a ripple texture as a displacement map; We could use an algorithm to change how we sample the image, making it distort in places to simulate a ripple appearance; We could also use surface normals to change how the light reflects off of it to make it appear like there's troughs and crests to fool the player into thinking it's rippling.

Portals!

So the portals that we did in class are pretty similar to how you would do a reflection: You're just rendering the scene from a different point of view. In this case you're taking the direction vector between the viewer's position and the position of the portal they're looking through and rotating it so that it matches the orientation of the portal they're looking out of. Then you render the scene from the position of the out-Portal with the direction you calculated previously to a FBO and apply that FBO's texture to the in-Portal.

For added effects such as the rings they have in Portal, make a texture and it so that you have a pass through colour (i.e. just set the alphas to be 0) and a discard colour (i.e. black, blue, etc.) and when you go to render the portal, send in the FBO texture as well as the portal texture. While sampling, if the sampled UV for the portal texture is the discard value then nothing is drawn while if it's the pass through colour the FBO is rendered and then anything else is blended based on alphas. This results in the fragment shader cropping away any unwanted pieces so that it blends in smoothly with anything behind it such as the walls.

Uniquely Shaped Meters!

So this is something I found interesting, it's a technique for creating functioning meters (i.e. player health) that have unique shapes such as being circular or just a wavy line. Basically what happens is you have two textures which are being sampled from: The actual, rendered texture and a 'cutoff' texture. The cutoff texture matches up with the rendered texture and is just a smooth gradient from 1.0 to 0.0 in the direction you want the meter to go. When you render the meter you would pass in a normalized value to use as your cutoff value.

Cutoff Texture

Render Texture with Base

So say you have a cutoff texture that just goes from black to white in a smooth gradient and it's rendering the player health, the player currently has 750/1250HP. This means that the player is currently at 60% health and so you would pass in a value of 0.6. Now, when it goes to check if it should render the health meter, it will sample from the cutoff texture and if the value is 0.6 or less, it will then proceed to sample from the render texture and output the appropriate colour. If the value is greater, it will simply not render the fragment. I like this technique a lot because it just gives you a lot of versatility in how you might want to render things such as timers or health bars or ammo...It just gives you and your artists a lot of flexibility!

Dual Quaternions!

Yeah...No...Not this time. They warrant a full blog post.

So that's my rambling for the night, I hope you enjoyed me try to blunder my way through how to do simple graphics stuff that I find kind of interesting and fun...

I actually don't have anything witty to say here so I'm just going to put a picture of Phong just to make this blog look longer than it is. Cheers!

AI...Whats the A stand for?

So I'm starting to run out of topics that interest me for Graphics (and which haven't been covered pretty well in class) so I'm going to take a bit of a break and talk about a programming topic near and dear to my heart: AI!

So last term I talked to Dan Buckstein about some AI stuff and he put me down an interesting path, one filled with weirdly named terms like Fuzzy Logic, and I've gotten the chance to apply a few the fun concepts that I picked up from him. My absolute favourite is Finite State Machines, which are basically anything that can have multiple states which the system will transition between once certain conditions are met. The most basic example of a FSM is a light which switches between on and off when the light switch is put into different positions. Of course, they can get a lot more complex than that (for example, games are FSMs themselves) but for this blog I'll be talking strictly in terms of how they can be applied for AI.

For our enemies in our GDW game, I use a combination of polymorphism and states allowing me to reduce a large portion of the update function for each enemy to just one simple line:

currentState->Execute(dt, this);

Where the variable currentState is a pointer of the root State class, dt is the change in time for the update and this is a pointer to the enemy currently being updated. Now what does this do? Well, firstly I'm going to break down the root State class. This class has 3 functions: Enter, Execute and Exit. Enter is called only when a new state is entered, Execute is called during each update and Exit is called when the current state is being exited. Each state also has a BehaviourTag enumerator so that we can keep track of which state an enemy is in. Now that we have our root class defined, we can derive all other behaviours from it, in this case we have a FollowPath state, MeleeAttack state and Death state. Each one has its own unique Execute function (i.e. the FollowPath state will find the path to the enemies target and follow it while the Death state will count down the enemies death timer) which essentially allows us to swap out the enemies update function while being able to recycle the code between multiple enemy types! I tried to make it a bit more efficient by also making each derived state a singleton as this relies on making a static pointer in an object to its self which is returned with the GetInstance function. This way, we will always only have one instance of each state and won't have to create new ones when we want to change states.

Now then, for another interesting topic which was mentioned earlier: Fuzzy Logic! This is effectively the blending of different behaviours of similar natures. For example, say we have three behaviours which dictate how an enemy will move, these behaviours are Seek, Flee and Wander. The Seek behaviour has the enemy heading directly towards a point or entity, Flee has it moving in the completely opposite direction from a point or entity and Wander has it choosing a random point and moving towards it. These behaviours all return a normalized Vector3 for the enemy to use as a movement direction. By adding weights to each output which sum up to a value of 1.0, we can simulate more than these three behaviours. For example: 0.5 to Seek and 0.5 to Flee will make the enemy stand still while 0.5 to Flee and 0.5 to Wander will make the enemy seem like it's trying to avoid the player but it isn't actively fleeing from them. That's sort of the quick and dirty info for Fuzzy Logic. Unfortunately I have yet to actually apply it with code and only know this bit of theory regarding it but I look forward to getting that opportunity!

So yeah, there's my blog on all the fun AI stuff that I've learned and applied this year. I've greatly enjoyed using FSMs as they help clean up the code drastically, they're highly reusable and they're just so much more flexible than having a collection of if else statements in the update function of an enemy. I hope you've enjoyed reading me ramble on for a...LONG time. I apologize for the length of this blog, but I didn't want to do another that was broken up into two parts.

Next blog: Either BVHs and Mo-cap or Thinking With Portals!

Note:
In regards to the title, if you don't know the reference here it is: http://youtu.be/WnTGaTbR7C0?t=1m33s

Note 2:
Most of this informatoin is what I can recall from Programming Game AI By Example by Mat Buckland, a fantastic book which I was given the chance to borrow and which I keep meaning to purchase for myself.