Scene Graphs

What are scene graphs?

A scene graph is a graphical scene data that forms a hierarchy made up of nodes and edges. Scene graphs specifies the relationships between objects in a game. Its like a tree that contains parent nodes and child nodes. Take a look at this scene graph below.

Lets say for example you have a dining table set with chairs around. The parent node would of course be the dining set and the chairs would be children of the dining set. This is the same idea with scene graphs for games. If we were doing a scene graph about gameplay then we would make gameplay the root node. That root node would then become a parent of all the other components that help make up gameplay. Examples could be like physics, characters, enemies, etc. Scene graphs allows us to organize objects, organize primitives, group transformation, and group effects such as shaders.

Scene graphs provide a great framework for a team to organize their work. In games, scene graphs help programmers be able to organize the overall structure of the game. It really causes one the think about all the necessary components before actually starting the implementation. Sometimes when a group of gamers get together and gather up all of these great ideas and yet still were not able to get it done because of lack of data. You cannot have one thing before the other. That is why scene graphs are important to have. They are like the core of game engines. They feed geometry to the renderer. They should also gather information based on spacial proximity and render-state coherency.

Scene graphs provide 4 key benefits:

• Performance
• Productivity
• Portability
• Scalability.

It is a great framework to build on for any 3D game. It encourages game developers to be more aware of the components being used in the game engine.

Conclusion

Scene graphs are beneficial and very useful for any 3D game. It sure helped us at the beginning of our studio game development. We had a very lengthy scene graph that I thought was very over whelming but it was great to see how we were constantly referring back to it as we continued developing our game.  

Threading

What is it?

Sometimes in games, it is very useful and effective to have a variety of sections of code running on one processor. But what if there was a way that programmers can have more than one paths of execution? What if there actually was a way that code could be run on different processors? This is the idea that threading brings. A thread is simply a path of execution. Single path execution run through single-threaded programs whereas multiple paths run through multi-threaded programs.

Single-threads are computed one at a time whereas multi-threads can all run at once. One thing these threads have in common is that both single and multi have a single core. Threads also have to be able to handle their own execution. On another note, they have two callbacks, "suspend" and "resume".

 There are two specific types of threading:

• Kernel threads
• User-Level threads

Kernel-Threading & User-level Threading

Kernel-threading is the lowest operating system. It handles the scheduling in the execution process. The thing is with kernel-threading is that they manage the operating system and maps the user-level threads. So in a way kernel can incorporate user-level threads too while being managed by the CPU. User-level threading operates in user-space. These user-level threads are processed using a One-to-One or Many-to-One format.

Why Use threads?

Using threads give more efficiently on single or multiple executions. They allow us to use multiple tasks at once like receiving and computing input.They also take advantage of multiple CPUs. Not to mention they are quite simple to program. Here is an example done in class.

Example
pthread_create(do Physics)

void do Physics()
{

while(1)
{
if (press)
pthread_cancel
}
}

Once the thread exits the loop dies.

AI

So what is AI?

When you think of AI, what kind of terms or aspects would actually go well with AI? Well AI can be used for enemies, decisions, and rules. AI takes those things and brings them into a realistic perspective. According to Ian Millington, AI or Artificial Intelligence is about making computers able to perform thinking tasks that humans and animals are capable of. Its providing an illusion of  NPCs or non-player characters to be doing a human-like behaviour trait. AI gives an illusion of the characters being intelligent. Examples include characters getting out of the way when something is about to run into them or running towards a soccer ball when it gets near them. Of course we all know that nothing really has an artificial intelligent mindset. We can only make the computer mimick or follow human behaviour.

Most modern games address 3 basic needs:

• Movement
• Decision Making
• Strategy

Movement

Algorithms that turn decisions into some kind of motion. This is where NPCs actually moves around in the game world. In order for NPCs to look intelligent we have to use physics. 

Seek Behaviour is when you have a character that is seeking another character. It calculates the direction from the initial position to the target position. It also requires some sort of velocity  as it moves from each location to another.

Flee Behaviour is the opposite of seek behaviour. Instead of trying to find the character you are trying to run away from the character.

Arriving Behaviour is used with seek because when we finally get to the player we want a realistic look to it by making the character slow down.

Wandering Behaviour allows the character to move in a direction of a current orientation with a maximum speed at each time step.

Pathfinding is another way in which a character can get from point A to point B. In order for this to happen we use graphs in the game world. The graphs filled up with nodes in which characters can move from one node to another using A*.

Decision Making

This involves what kind of behaviours should the character does in case this happens. What to do next? Programmers have to include a range of behaviours like standing, sitting, walking, attacking, wandering, and so forth in the computer but there is still a matter of knowing where and when to execute these types of behaviours. 

AI in AEOLUS

For this semester, we used turrets as the enemy of our game Aeolus. When the player flies within a certain distance, the heads of the turrets will turn towards the player and shoot lasers at them. For next semester we will be introducing much more enemies in our game that will somewhat  have a similar behaviour as the turrets or maybe have multiple behaviour if we can think of any because it is a helicopter combat game. Despite that, we definitely will be trying out new things in the near future for Aeolus.

Conclusion

Sims is a good example of a game that uses AI. NPCs wander around the game world until the player's Sim comes into contact with them. Same thing goes for any FIFA soccer game. The characters will run in the direction the ball is heading but will not actually be running towards it. All of these things allow a game to give off the illusion to its players and therefore gives good gameplay. 

Scripting

The first time I even heard about scripting I thought, "Is that like more code that we will have to memorize or something?" I was thinking a real script that you would memorize before perform on stage or something. Clearly I was thinking way outside of what it initially was. Scripting turned out to be much more interesting than that.

What is scripting?

A scripting language can be defined as a programming language whose primary purpose is to permit users to control and customize the behaviour of a software application. In scripting language you can generally define a game logic in a separate file completely different from the used programming language in your game. Scripting allows for flexibility in engine code. You can literally include many game-specific things like levels camera control, cut-scenes, and AI behaviours into a scripting language. Not to mention that it lessens the amount of work a programmer has because a chunk of the game logic is designed by level designers. This way the engine core doesn't seem that complex anymore. Well, to me it still is, but scripting lets you see programming in a much simpler way.

Interpreted Scripts

Interpreted scripting language is a type of ASCII text file that executes instructions without compiling a program into machine-language instructions. The interpreter reads the file line by line and parses, interprets, and executes each line on the fly. Examples include PERL, Ruby, and Python.

Compiled Scripts

Compiled scripts is a compiler that translates our code into machine code. This is how we get bytecode. Bytecode is a type of instruction that the interpreter can understand. C++ and C are examples of compiled scripts because they both need a a compiler that creates the bytecode. 

Video

In this class we watched a video to learn more about scripting and how it is used in games. We looked at the video game Flirting with the Dark Side. Scripting pros include: iteration time, expressiveness, and designer-accessibility. Scripting cons include: performance and designer-accessibility. More or less scripting is the main aspect in game engine design. It is primarily the glue that brings everything together. A script is the pillar of the engine. The main production goal was to use a scripting language called Lua, which can be used to create first-class systems from the ground up.

Lua uses very simple syntax and is stack-based in which you can push and pop values. This is why the creators of Flirting with the Dark Side had three parts: component scripts, system scripts, and data. They had these component soups and system soups which contained animations, AI behaviours, physics, and so on were organized in a list or a stack. However, you need 'glue' code in C++ in order to call functions in Lua. This is as simple as it gets in programming.

Advantages of Scripting

Scripting are a relatively easy language to learn and use in your game engine. So in retrospect, it was good place for my programming skills to grow. Since I am an artist, my programming skills are in need of improvement and I really wanted to contribute to our studio game this semester in programming. So when my group members asked me if I wanted to script, I was so excited. Scripting also makes the game engine less complex and development of certain attributes in the game are made much faster. On a further note you can concentrate more on the game design, art, and tweaks that make a game look amazing and epic.

My experience with Scripting

So for our GDW game, I was assigned to script particle systems in Ogre. I have never scripted before so this was truly a cool and exciting time for me. First off, I did my research on a particular website called http://www.ogre3d.org/tikiwiki/tiki-index.php?page=-particle. This website helped me a lot since I was able to see a few examples as to how to format my script and add extra attributes as well. Here is the .particle and file for the smoke script I did.

particle_system Smoke
{
material Smoke1Mat
particle_width 3
particle_height 3
cull_each false
quota 500 //Max particles at once
billboard_type point

emitter Point
{
angle 23
emission_rate 100
        time_to_live    1.4
depth 20
position 0 0 0
        direction       0 1 0
        velocity_min    1.5
        velocity_max    12
        colour 0.0 0.0 0.0 0.1

}

    affector Scaler
    {
        rate 1.1
    }

affector ColourFader
    {
        alpha -0.04
    }

affector LinearForce
{
force_vector 0 -0.2 0
}

affector Rotator
{
rotation_range_start        10
        rotation_range_end          360
        rotation_speed_range_start     -5
        rotation_speed_range_end       10
}

}

The outcome of this smoke particle made me so happy. It looks so real. I was so excited to show my studio members the next day. They were impressed and I was assigned to do all of the particles that will be used in our game. The game is going to be about war so there will be many particle effects flying around the game such as fire, debris blown by the wind, explosions, and the list goes on and on. We have even discussed using particles in the main menu just to make it look more pretty. All in all, scripting has allowed me to finally contribute the few programming skills I have. It feels good to be an artist/script programmer.

Conclusion

Scripting is a light-weight language that is interpreted in other high performance languages like C++. It allows game developers to incorporate game-specific items and encourages game design customization to make your game more unique and controllable.

Navigation Mesh

When making a game there are certain things which are highly taken into account like engine fundamentals and basic gameplay. However, how can one go about creating a path that defines where a character should go and how to get there? This is why we use navigation meshes.

What is a Navigation Mesh?

It is a path defined as a series of nodes. This path can define the areas in which a character, enemy, or any dynamic object can walk through in the game world. So if an enemy needs to go from point A to point B, it can follow through the various nodes to get there. An example of this would be if an enemy is following the main character to intercept and fight, he or she needs to be directed to the best way to get there through these series of nodes. It would not look very realistic if the enemy were to follow a path that is a straight line. And what if something was in the way like a wall or a rock? Remember the nodes will be positioned in a way based on the design of the game world. If the nodes were a straight line the enemy would not get to the destination very easily unless you want your enemy to run through walls and what not that's your own decision. The point is you want your characters' walkabouts to look as realistic as possible.

As you can see in the first image that there is a destination depicted by Node A and Node B. The path used to get from Node A to Node B is shown in yellow. In addition, the nodes themselves form triangular meshes because they are a great representation for larger and more complex environments in the game world. 

Video

I this specific class Professor Hogue showed us a video about navigation meshes. We looked at how the makers of Resistance 2: Fall of Man used their navigation mesh. So I am going to give a hopefully detailed description of what I learned from this video.

Navigation Usage & Path-finding

The use of navigation can be great for any character to go to a specific point. So, like I said earlier realistic movements from point A to point B. It is great for valid target scanning and AI threat perception. Through navigation meshes you can have various world representations no matter how complex there are. You can even have them if the field is aggressively evolving in the game world.

Resistance:Fall of Man

In this game, the makers used a designer laid navigation mesh in Maya. They used the tools to build a convex poly mesh for runtime. Initially they wanted to have a poly mesh to be used with A* pathfinding algorithm. This did not end well at all bottle-necking and having only an eight player A* navigation at a time. Those were some of the issues they worked on for Resistance 2. 

Resistance 2

Early goals for this game included fixing  PPU bottle-neck, having a 9x nav-mesh poly load target, and removing AI load restrictions. An eight player co-op mode was planned as well. One improvement included using a 3-sided poly mesh instead of a 8-sided poly mesh. This prevented any overlapping within the polygons of the mesh not cause any confusion with the A* navigation. Path caching was added as well. 

Resistance 3

In Resistance 3, the makers included a Bezier curve to be computed from each node for a smoother interpolation. So for example, if an enemy were the turn around a corner, they will not have a sharp turn. They will have a smooth curved turn for the bend point.

Conclusion

Navigation meshes allow game developers to incorporate immersive and fun NPCs in their games. It also brings more realism in character movements from node to another. I think Insomniac has done a fantastic job in generating navigation meshes in their AI. Of course there is still need for improvement, but with the knowledge and skills known to game developers now we can pretty much pull off something awesome either way.

What's a Game without Gameplay

So in the past few blogs we learned about game engines and its fundamentals. We learned about the different types of game engines out there and that they are used to make a programmers' life much simpler by not creating an entire engine from scratch. We learned about the different patterns such as Singleton, Factory, and State patterns that can be used in a game engine. However, what is missing? We have all of these components as to how to create and set up a game engine but we still can't Do Anything with it. You know what we need? We need gameplay. You cannot have a game without gameplay. Gameplay defines a game. Without gameplay you just have a bunch of functions or tools that do nothing in the engine. Its like a car that contains all the engine components, yet it doesn't have a foot pedal so you can actually move it. Useless. Like where's the fun? Where's the experience? What's the person supposed to do? These are the things you want to think about when you use the term gameplay.

What is Gameplay?

Gameplay can be described as the overall experience of playing a game. It defines the mechanics available for the user. It basically is a system provided for the player to use game engine. Gameplay allows the players to actually do something on the game.

Game World

In order to incorporate gameplay you have to include a virtual game world for it to take place. The world has to types of elements; Dynamic & Static. Dynamic elements are things that move around in your game. Examples include characters, objects, power-ups, particles, and so on. Static elements are things that do not move around or interactively effect the game. Examples include terrains, sky boxes, and so on. Gameplay tends to focus on Dynamic elements because those are the things that move around and actively effect the game.

World Chunks is a very large virtual world in which they are divided into chunks. In most games, the player can only go through one chunk at a time, but then again its based on the type of game being played.

High-Level Game Flow

High-level game flow is a sequence or tree of the objectives for the players. It shows the the process for each objective for both successes and failures.

Tool-Side Design vs Runtime Design

So we have gameplay which uses either dynamic elements or static elements, but how can the player actually use the dynamic elements? We have to have something called game objects models. Game object models are facilities provided by the game engine in order to simulate dynamic elements.

In order to include these game object models we have different designs to implement them. Tool-side design is the set of game objects in which the designers have made using the engine within the virtual world. Tools are a necessity in engine creation. When you think about it the game engine itself is made up of tools. A lot of tools. Alongside these tools you need a specific type of design to use them or manipulate them for the actual gameplay. This is how we get runtime design. Runtime design is defined by the already existing language provided by the programmers and is used to implement the tool-side design. That being said, the runtime design has to be able to handle many types of inputs from the players as well as tool objectives to eventually incorporate the tools provided from the tool design model to provide a reasonable gameplay system. Examples include scripting, messaging and event handling, or level management and streaming, and real-time simulation of object behaviours, etc...

Conclusion

So long story short, gameplay defines a game. Gameplay has to take place in a virtual which incorporates either dynamic elements and system elements. Within these elements we have object models that are implemented through runtime and tool-side designs. Each of these aspects help make gameplay.

Design Patterns

In this lecture we learned about design patterns. Design patterns are like the solutions to making your programming easier to control. They can prevent long and tiresome amounts of code by allowing you to use reusable ones. That is why we revised OOP in the last class. Using inheritances, classes and polymorphisms can solve the problem of having way too much code in your game. It is a good way ease up the load in your programming by using design patterns. Professor Hogue described four different types of patterns that can be used in our game this year.

Singleton

A singleton pattern is a class that instantiates an object one time. So instead of using a globally defined object, you can use a static variable in your singleton class. That way the object will only have one instance. Hence the word "Singleton", "single". Get it? 

Facade

A facade pattern is a set of classes interact with each other in a subsystem. Only one class exchanges data with another class within another subsystem containing interactive classes.

State

State patterns is like a using switches() and enums. It's like having a group of code do its own set of instructions. In the end, you will eventually merge the states together by calling them in an update().

This decreases the amount of errors which occur in your program. 

Factory

A factory pattern is a single point of a class entrance for the creation objects. It's just like an actual factory that builds many of the same products. When it is ready to be manufactured it is shipped to its location. The same thing is with a factory pattern, it creates many objects  for specific function. Factory pattern is also good for organizing memory allocation.

Design patterns are a very good practice to use especially if you like order and neatness in your code. You can use these kinds of patterns to further improve your programming style.

3D Engine Fundamentals

What is a Game Engine???

Now when Professor Hogue asked us this question, I knew the answer but for some reason I couldn't put it into words. Apparently, the rest of the class had almost the same impression as I, so right away we had to form groups and have a clear and formal idea as to what a game engine is. In my own opinion, a game engine system of all data and components used in a game in order for it to work. It is the most important part of the game; without it the game will not be a game. I like the example of a car that Professor Hogue gave us in class. He said think about a car and whether it would be the same without the engine. Of course not, a car needs an engine in order for it to drive otherwise its just useless. It's the same idea with a game. Without a game engine, you cannot do anything on it. 

A game engine has to manage the data of the game as well as coordinate data with sub-components of the engine, manage flow of data, enable user input, etc...

Game Engines were not as famous as they are today. Games used to be made without any game engines up until the 1990s when 3D computer graphics started to become popular. It is a good thing it is popular today too. Can you imagine what it would be like without engines??? Game companies would've had to make their game from scratch EVERY TIME. It scares me just thinking about it.

Types of Game Engines

• Ogre
• Havok
• TorqueX
• Delta3D
• Panda3D
• Crystal Space
• WildMagic

These are just a few free game engines discussed in class. I can't wait to use Havok and Ogre in class this year for our game. Also, CrystalSpace looks like a cool and awesome engine to check out as well. Clearly they named the engine after me.

Review of OOP

We also revised object-oriented programming. Which is a very good way to program because it allows you incorporate classes, inheritance, and polymorphism which enables a programmer to re-use code rather than writing new ones every time. It makes programming easier to code, easier to maintain, and easier to debug. So, in other words less stress. 

Pointers, are another topic we quickly reviewed as well. In game engines, it is important that interfaces are small, few, and explicit. 

Basically Lecture 2 is mostly revision but I'm glad we went through them in class because we will be using all of these attributes in the implementation of our game.

Game Idea

Well it is back to school and Professor Hogue has assigned us to write blogs again which I think is terribly fantastic.

Game Idea

Our game idea for this year is a helicopter combat game. This game will involve the player having to accomplish various missions in order to retrieve high-tech weapons for upcoming levels and tasks. This game is set in a futuristic war world so the designs of the helicopter and the weapons will be slightly different to what they look like now. The helicopter as well as other machinery will most likely have different architecture but still recognizable to the player or players.

Story Idea

Our story will probably be about a potential war that has occurred. The players will be assigned to fly a helicopter and complete tasks including defeating an enemy or rescuing people or simply picking up supplies. There will be a combat facility where players can have training or practice. However, this is just an idea. As time goes by, we will develop our story.

Here is quick example of a HUD I had in mind in our game. I did mention earlier that the helicopter will look different than it does regularly because of the set time we have in planned. So forgive me that the helicopter looks normal for now. There will be a defined style in which it will be drawn and modeled.

We will be using 2Loc as our wrapper for this years game. 2Loc includes physics, collisions, particles, camera control, and all sorts of engine blocks needed for our game.

Game engines we will be using are Havok and Ogre. Both these game engines are very new to me so it's going to be a challenge learning how they work. However, I do consider myself a fast learner so in the event, I am excited about learning these engines.

With Havok, our game will have a highly optimized collision detection library. Havok will give our game a more realistic virtual world. In addition, it is free for education and works well with Maya.

Ogre(Object-Oreinted Graphics Rendering Engine) is a very good 3D rendering engine. This will help with our fight scenes in which the players have to fire their weapons at specific target or whatever the case may be.

All in all, Havok and Ogre are both interesting game engines that require hard work in order for our game to succeed, so I'm up for the challenge this year.