MIGs - Look into the Glacier 2 Engine

Just this past monday to thursday, the Montreal International Game Summit took place and Game Devs from all years decided to make the trip down. I will have an overview post of how MIGs went but for this particular post (since it's for Game Engines) I want to talk about one of presentations that took place that was particularly interesting.

Hitman Absolution is the first game released to use the new Glacier 2 Engine

Square Enix has several engines under their belt but the most recently created is the Glacier 2 engine.  Glacier 2 is not for license for other studios unlike a game engine like Unreal 3. This engine is only for Square Enix projects and doesn't include the Square Enix projects in Japan for Final Fantasy and other games. The engine currently only has no games currently released under it's belt but it will soon in the form of Hitman Absolution. Other projects are using it as well but I can't quite remember them all.

Why build a new engine?

This is one of the questions the speaker, Kasper Engelsoft addressed. The reason for having a new engine is of course to compete with advancing hardware and methods of rendering, algorithms and structure to put it in a broad sense. He stated that it also had several other important advantages as well. 

Kane & Lynch apparently used some messy code in order to get features the dev team wanted

One was to target previously problems with the first Glacier. The first Glacier appeared to have "hacks" where the programmers would just modify the code in messy, unstructured ways in order to make things work. We saw some sample code from a few games such as Kane & Lynch that proved this messiness. Glacier 2 is supposed to rectify this problem and include features that are already built in so that these sorts of hacks don't have to be done.

Glacier 2 hopes to rectify problems in the past Glacier Engine

Another thought that came to mind was why not just use another engine such as Unreal? Well this goes along with the points stated above. Not every engine has all the features a game needs or isn't tailored to do certain things that are crucial for a company's needs. Unreal might lack certain things that most games Square Enix is going to need, so that means having their own new engine will tailor it to exactly what they need.

Features!

With those questions out of the way, more content of what the new engine could do came to light. One of the most important parts of using an engine is that if it provides the right tools, it will increase the productivity of those using the engine dramatically.

One of the features the engine had was editing on the fly with the game rendered in a seperate window. Other engines do have this feature though such as Unreal and one audience member did not hesitate to point this out. They must have missed the point the engine is specifically tailored for their needs. Anyways I sidetracked but this feature is of course very useful but the best is when modifying things of the engine on the outside, it actually changed the source code at the same time as well. That means anything added in the visual editor could directly make changes to the source code and make things even faster since you wouldn't have to redefine things inside the source code. This was actually one of the highlight features the engine possessed.

Hitman Absolution uses Glacier 2 to render many NPCs with strong AI

I am going to be honest, from this point I can't say quite as much as I hadn't had much sleep the night before so I didn't hear everything that was said about the engine. We got a look into their code structure which looked very organised and clear in comparison to the code shown from the previous engine. We also got a look into their particle system as well as real time rendering of 500 completely dynamic NPCs with advanced AI. This was a feature brought into Hitman Absolution since Hitman was the one being demo'd at this time.

Conclusion

Unfortunately I wish had more to say and took notes but it was still a very interesting presentation. It was exciting to see the inner workings of a AAA engine first hand and understand  the reasons behind its creation as well. It provides great motivation to make our own engines seeing the capability these engines provide.

Havok - Friend or Foe? ~ Learning Havok

Havok is one of the tools we were provided with this year in order to create our GDW games. One should be excited at the prospect of having a chance to use a top quality, triple A engine. However once you get into it, you realize it won't be as easy as it seems to get Havok fully running and doing what you want it to do. Not to mention we aren't getting the real version of Havok, rather we are getting a free student version that doesn't have all the tools that we might be hoping for. One should think that simply having Havok would be only advantageous and it should be but when it becomes a requirement to have and it's not so straight forward to do, it begins to look more like foe then friend.

First off let's just see what Havok provides.

• Realistic Physics simulation, velocity, acceleration and forces
• Collision detection and collision response with objects of any shape and size
• Animation and skeletal animation
• Creation of it's own objects to be rendered
• Compatability with Maya for 3D modelling
• Sensors, events and callbacks
• Vehicle dynamics
• Rag dolls
• Constraints such as rope attachment
• And many others...

Now that's a lot of features it has and that means the engine has a ton of potential to do amazing things. The problem is that the documentation provided is while very long (1000+ pages) it is not very easy to understand and not very helpful. Many have agreed that the documentation Havok provides to learn it's tools is anything but straight forward. There are also so many things you have to learn about the whole system, that even implementing one of the tasks listed above is anything but easy. In order to correctly implement something, you either have to read through a ton of documentation and might still miss some things, or you're told by someone else.

The documentation isn't exactly straight forward even though it looks like it would

Sooooooo Complicated!

The free version of Havok did not really provide any tutorials to help and any online searching for such help  is extremely difficult. For example, I wanted to figure out how I would get collision response in our game so that when a player attacked an enemy, the enemy might lose health. First of all I looked into the Havok documentation for collision detection. It listed for me, at least a half a dozen things and didn't really fully explain which I should be using, nor how to implement them. So after searching that for some time, I gave up due to how difficult it was to comprehend.

They don't provide proper examples of how to use these for collision detection

I then went to search online for any help in how I might get collision detection in Havok. Again I was frustrated by the lack of any help online due to the wording I needed to use, or just otherwise lack of resources. Havok by itself does collision detection between it's "rigid bodies" but I needed to know how to access when they would collide. Havok would not provide for me a decent answer even with looking for all these resources. Nor do I remember seeing any obvious tutorials that would help show me.

But Demo Samples are useful

Havok demos are the main method of learning Havok

Thankfully not all hope was lost for the samples they provided were actually very helpful. These were pretty much the only way I learned how to use Havok. I finally managed to find out how I would implement my collision response after much searching through the demo samples. They provided source code in these samples so I was able to extract it, figure out how to use it and put it in my own engine. Thankfully this process itself wasn't too difficult as it mostly involved using inheritance and overriding certain functions. It's not that obvious at first though and takes a bit of time to figure out. You also have to take the source code from these projects and import it into your own projects.

The demos finally helped me learn how to use collisions. I turn the objects to blue when they hit.

Through this method I managed to figure out several useful things for our game such as collision detection, collision filtering, attaching rigid bodies to a set path, and a few others. However I wish there was an easier way to learn these things through tutorials or more resources from Havok. From what I've learned it seems like they simply provide the documentation for free students. But for those that pay the full price for Havok they get all features of Havok along with tech support to help teach people. That's the benefit they get while we are stuck with having to figure out everything with Havok by ourselves. Granted its a good learning experience but it makes things dreadfully slow to learn.

Also Havok Demos are very fun, particularly the vehicle demos

The only saving grace was the samples which were very helpful indeed. I know this blog hasn't been about actually learning much today and mostly more of a rant but this just highlights of what to expect if you ever get Havok. Be excited by the potential the system has but be prepared to have to learn a lot and use the samples a ton in order to fully use it.

How to Make a Basic AI - Seek & Wander

If anyone remembers in Super Mario 64, the goombas were different then their 2D counter parts. Instead of simply walking in a straight line, they actually did some somewhat more dynamic AI. They walked around and when you got close, they suddenly turned toward you and ran at you. This is a very basic AI that can work in a 3D game and today I'd like to show how it can be done.

First off let's break down what kind of behaviours the goomba is using. It uses two simple AI behaviours...

• Seek
• Wander

The seek behaviour means to head towards a designated target, simple enough. The behaviour is a little more complicated but it eventually involves the same thing. It seeks towards a target, but what it does is calculate a new target in front of itself whenever it's called to make it appear like its just walking around aimlessly.

Physics System

So we know what these behaviours are and they sound pretty simple. Before you just go ahead and make them we need to make sure we have a physics system of some sort. So let's say we have our "Goomba object", well if we want to accurately calculate forces for our AI, we need to make sure he adheres to some form of physics.  This physics system is not too complicated, in fact all it needs to consist of for us at this point is the following...

• Force
• Mass
• Acceleration
• Velocity (Speed)
• Position

You would give your goomba this physics system and give it an update function that applies these forces every frame. With the proper system, simply applying some force, will automatically do all the calculations to make the goomba move. So Force = Mass*acceleration, velocity += acceleration, position += velocity or something of the sort. So this means in our AI behaviours we would be calculating the forced required to go to our target.

Basic AI Systems - Pattern and Dynamic AI

A major factor in how believable the game world is, comes from the AI system. When you think about it, almost every game has AI in one form or another. Even a simple game such as Super Mario Bros. has AI,  very basic AI that follows the same pattern. Nowaways we have highly advanced AI, like the ones demonstrated in the Halo series, renowned for their AI. There are varying types of AI, they can be set patterns or they can be dynamic and changing based on the state of the game. The type of AI used is dependent on the type of game being made.

For my post about making a Basic AI Behaviour, click here

Pattern AI

At it's core, a patterned AI doesn't care about what the player is doing, it's not going to react specifically to you if you happen to be jumping, attacking, or dodging. The most they might react is if you happen to be near, it will activate their AI. This is the kind of AI that was featured a lot in games in the 90s and earlier.

The most basic versions of these come in the form of goombas in Super Mario Bros. Their AI pattern is to just walk ahead and if they run into an obstacle turn around. These enemies in particular don't care at all where you are.

Super Mario Bros - World 1-1 ~ The Goomba AI literally just walks forward

Another rather basic AI is the AI in turn based RPGs, notably Pokemon (the old games). They pretty much have no AI. Where pokemon will have a list of four moves, in most battles though they will simply use them at random, with no thought to strategy. Later games started to implement actual patterns in battles to make some good strategies but they were still mostly patterned.

Pokemon Red - The AI used to just randomly use whatever attacks where in their movelist

Dialogue in Games

How does dialogue enhance the experience of a game for us? What are it's advantages and it's disadvantages? What are the different ways we can go about bringing dialogue to life and bringing story to the players? As a follow up to my previous blog I want to talk about the difference between dialogue with audio, dialogue without and even games that feature no dialogue at all to convey the story.

Story has always been an important part in some games. A lot of games still have story of some sort even if they have no cutscenes or dialogue. Some games simply feature a "story" button featured in the main menu or something of the sort (though that's usually for flash games or lower budget quick games). For titles with larger budgets they usually have either cutscenes with dialogue & voice acting, cutscenes with only text dialogue, or the rare no dialogue and no text ones.

Action Only

These aren't too common and it's very important for these kinds of cutscenes to convey all the emotion and the messages they need with only character motions. It becomes very hard to pull this off for certain kinds of games, such as RPGs which usually have the largest of backstories. However there have been some very notable successes that have proven that you don't always need talking and text to convey what's going on in a scene.

The best example I have experienced of this is the Lego series games, such as Lego Star Wars, Lego Batman, Lego Indiana Jones, etc. In these games, the Lego characters do not talk at all but they have to re-enact scenes from the movies or settings they are in as though they were mimes. They are able to provide and make the emotions obviously in certain scenes such as worry, happiness, laughter, while still trying to stick to the character they are playing. They also have to use a lot of exaggerated gestures to convey more emotion as well.

Fragmentation - My memory has got some holes!

When I am talking about memory I do not mean the memory of our conscious self.  I instead mean memory that our computer uses. Our computer contains different kinds of memory, some of them faster to use and some of them slower. Fragmentation is like the title says, making our memory have holes in them. I will explain the whole process of fragmentation and how it does this but before we do that let's talk a bit about what kind of memory our computer has at it's disposal.

Memory

Our memory is responsible for allowing our computer to do all sorts of complex calculations at rates faster than a human possibly could. The more memory we have, the more things we can do at once and the faster we can do it. This applies for all of the programs that our computer has to use when it's being run, from a calculator, to a game. 

We generally have two types of memory, cache memory and RAM (Random Access Memory).

Cache Memory is the faster of the two and is located closest to the CPU in our computer. The CPU is what is doing our calculations, therefore the closer we are to the CPU, the faster our calculations. The problem with cache memory is that we have a lot less of it then we do of RAM. This means we want to perform as much calculation in cache memory as we can before resorting to RAM in order to be as fast and efficient as possible. We also have several layers of cache memory, the closest one labelled "L1" while the others being L2, L3, etc. L1 is the fastest layer while the others get progressively slower.

Random Access Memory is the slower of the two and located farther away from the CPU. However you can have much more of this kind of memory, and can frequently be seen in large 1-8 Gigabyte sticks now, with multiple of them on one computer.

Sound is important! ~ Audio in Games

We often take for granted the sound we hear in games. As our professor Bill Kaprolos taught us, sound is often a neglected part in games. Not just by designers at times but also by players as well. How often is it that people will play a game without the sound or replace the game's music with their own. Designers adding in sound in the last few months and thinking of it as an after thought. Not everyone does these but it's not uncommon for it to happen. For this post I'm going to take a look into how sound, from music, to dialogue, to sound effects and ambiance affect the game. I believe that a truly great game will have great sound to make it a truly complete experience.

Sound Effects

These are the bread and butter of pretty much every game now. These define the sounds your enemies and players will make in the world, the environmental reactions to your actions. This ranges from things such as character footsteps, sword slashes, gunshots, explosions and anything that is resulted from an action or visual change in the environment. It can be a scripted sequence like a bomb going off and setting off that explosion, or your character holding a gun and you, the player making the gun shoot by pressing the trigger.

The reason these are so important is because they are something you will hear a lot during your game, pretty much all the time. It means that they cannot be annoying, tedious or repetitive. They need to be designed in such a way that they make the experience for the player even better. They need to be satisfying and make sense with what's happening on screen.