Jodo's i3110 Blog

[jodoi3110]

The Audio Callback for Audio Synchronization : GDC Presentation

Audio is a very important and often overlooked part of video games. In the past, audio was seen as a component that would be thrown in after the rest of the game was complete. Nowadays, audio is developed alongside the rest of the game.  The GDC presentation by Mathieu Pavageau from Ubisoft discusses the audio component of game engines. He discusses the audio not only from a game design perspective, but also from a code design and implementation perspective.  Musical Interactivity Pavageau begins by discussing musical interactivity. Musical interactivity refers to the music interacting and changing with gameplay. Using pre-recorded music is beneficial, but does have its down side. Pre-recorded music can be very high quality; but since it is pre-recorded, there is little dynamic change and interactivity. On the other hand, using a MIDI system allows music to be modified in real-time. This can be implemented using sound banks for your track clips. The down side to this is that it is lower quality than pre-recorded audio, and harder to implement. Synchronization Synchronization between video and audio on screen is extremely important. Updating a game with V-sync is useful in the precision of sounds to the current rendered frame. 

Since most monitors update at 60 frames per second, 17ms is the best time precision for audio.  If the audio system in an engine does not communicate with the video update, there will be no synchronization between the video and audio. Audio Callback Pavageau goes on to discuss the audio callback in the engine used for Rayman Origins. 

The system requires regular filling up of audio buffers for the hardware. Since Rayman Origins is cross-platform, Pavageau discusses the different in audio callback for the Wii/ WiiU, PS3, and Xbox 360. The audio callback time on the Wii is 3ms, where as the PS3 and 360 are 5ms. Therefore, the audio in Rayman Origins had to be synced bewteen 3-5ms.  The audio callback in Rayman Origins uses lockless programming. In essence, this means programming with multiple threads that access shared memory and cannot block each other. The advantages of this are stable audio - not affected by FPS drop, and consistent rhythmic behavior cross-platform. However it is also difficult to modify existing sound engines to use the audio callback.  Using the audio callback allowed Ubisoft to create dynamic multitracks and implement functions such as PlayOnNextBar or PlayOnNextBeat. Good audio interaction requires low level audio to share code with the game.  The synchronization of audio to video can allows for better interactivity and response, and Ubisoft is definitely on the right track.

[jodoi3110]

Filthy Hackery : Scripting Blog on Mike Lewis' AI Summit

The presentation given by Mike Lewis on domain specific languages (DSL) at GDC gives a good overview of scripting vs. coding, and scripting in AI.  The first discussion is that scripting is considered "filthy hackery". The argument behind this is that anything that can be scripted can be coded - and that games run in to problems when devs decide to fake something in scripting instead of actually coding it. The main argument against this is that often there isn't enough time to implement every system exactly how you want it, and most of the time faking it works. Therefore, we should focus not on avoiding faking it, but how we can fake it well. A domain specific language can simply be defined as: "a language designed to be highly adept at solving a specific class of problems." There are many advantages to using scripting languages. One of these advantages being that in some cases you don't need to recompile your entire engine to make small changes. This saves a ton of time, especially on large projects.  There are are 3 reasons defined in Lewis' presentation as to why to use DSLs for AI. Reason 1 is that "Program code will be cleanest when implemented in the same terms that domain specialists use when thinking about problems in the domain." Scripting simplifies code in a much more readable, and understandable manner. Instead of having complex algorithms coded such as the A* algorithm, we can use script to simplify the desired actions to how the designers would think of them. For example, if you want the player to damage an enemy.. in code you would have weapon checks, damage checks, collision checks, etc... But in a script you can just call something like "Damage enemy with weapon."  Reason 2 is that "we can minimize bugs by eliminating low-level concerns that do not directly apply to the problem we wish to solve." By removing irrelevant concerns, debugging becomes more simplified, and the problem at hand can be directly focused on. Reason 3 is similar to reason two and that is "we can maximize productivity by removing details and features that do not pertain to solving the problem."  Because AI often pertains to solving specific problems, and getting AI characters to execute specific actions, using DSL for them is especially useful. Scripting also comes with many perks. By moving away from low level code like C/C++, we can avoid things like manual memory management, complex syntax, and other complications like undefined behavior. Scripting is also much easier to understand for junior coders and designers. This can increase productivity, as more people will understand the implementation of systems, and be able to provide input. When designing a DSL for AI, you don't need to do anything out of the ordinary. The same methods that are commonly used for AI, can still be applied to your DSL. "Typically, when control flow can branch in AI code, this represents a point where a domain-specific concept has come into play; therefore the presence of branches tends to suggest the application of domain-specific logic." - Therefore when designing AI logic, you still identify the issue, and determine the proper decision-making logic to use. After this you should look for branch points in the AI and implement your scripting accordingly. Lewis also discusses a concept called "Granularity" which simply refers to the depth to which your DSL goes. If the granularity is too fine, we have a general language, and if it is too coarse we don't accomplish much. This is an important factor in the development of a DSL, and really is specific to the game it is being developed for.  When implementing a DSL you want your syntax to be nice and clean. Mike Lewis gives an example of good vs. bad syntax: 

Bad: player.health -= weapon.get_damage(); Good: damage player with weapon This is not only easier to read, but is much easier to parse, and maps directly to the appropriate concept.  There are a ton of benefits to using DSL's, not only for the programmers, but for almost the entire dev team. Junior programmers can do critical AI work, designers can write logic directly, it is easier on the code reviewers, and there is a fast turnaround from Quality Assurance.  All in all, scripting shouldn't be seen as filthy hackery, but as an asset for simplification and convenience of programming design and implementation.

[jodoi3110]

Particles in Ogre

If you know me, you know that I love particle engines. So naturally, I took on the role of implementing the particles in our GDW game. After doing some online research i figured out how to implement particles in Ogre using scripts! Ogre loads the particle scripts as .particle files. I prefer to make mine in notepad++. There are a few key elements that each particle script should contain. The particles require a quota which defines the maximum amount of particles to be released in one 'burst'. The second element is a material. Materials have their own script which access the textures required to texture the particles. For example:

material blogMaterialExample{       technique{                    pass{                            lighting off                            scene_blend add                            depth_write off

                           texture_unit{                                       texture blogMaterial.png                                               }                              }                          } } Then the particles need to be defined basic parameters such as width, height, culling, and their render type. Next, we create the actual emitter for the particles. Ogre supports multiple types of emitters such as Box, Point, and Ring. The emitter contains attributes such as colour, direction, emission rate, velocity, duration, etc.  On top of all that, we can add affectors, which change particle attributes once they've been emitted. All of this information is saved in a .particle script as a template. The layout for this is as follows: particle_system blogExampleTemplate{ particle stuff emitter stuff affector stuff } Now in our code, we can have Ogre load in our template. The cool thing about the way Ogre handles particle scripts is that all of the particle scripts can be saved in one .particle file! Ogre simply searches for the specified template name in the .particle file. The same goes for material files. To define a new system in Ogre, we use the keyword ParticleSystem. After that is created, we load it in to our scene using CreateParticleSystem("definedname", "templatename"). We also need a scene node to attach our system to, so we use SceneNode and create a node to make a child of our root. After that, we simply attach our system to our new scene node, and our particles have been implemented. Here's some pseudo code to help you out: ParticleSystem blogParticles = sceneManager->createParticleSystem("blog", "blogExampleTemplate") SceneNode particleNode = getRootSceneNode->createChildNode("blogSystem")

particleNode->attach(blogParticles); Once your system is implemented you can use additional Ogre commands to help you manage it. Here is a screen shot of a stream for a spaceship that I just created!

We plan to use this for our GDW game to make it nice and pretty :) Well that's about all there is for this blog. Have a nice day :D

[jodoi3110]

Insomniac Games : Nagivation

In a previous blog I discussed AI, and as a part of that, navigation. Essentially, navigation is about getting an object from point A to point B. Whether that object is a camera, or NPC, we need to somehow define it a path between the two points that when interpolated along, will look smooth and natural.  Insomniac Games has brought us tons of great games like the Ratchet and Clank and Resistance series. In this blog I will be discussing how navigation is done in the Insomniac Engine. I will be basing the majority of my information off of the talk given by Reddy Sambavaram at GDC11 about AI and navigation in the Insomniac Engine. Importance of Good Navigation

Good navigation is important for multiple reasons. The first and most major reason is to create immersive and NPCs. NPC personality is very important in player immersion, and navigation and movement perception plays a large role in that. AI has shifted from scripted navigation to be more dynamic. This relieves implementation burdens on designers. Navigation in Insomniac

There are various approaches to navigation such as a 2D grid approach, which involves moving the object between cells on the grid. Another way is to define nodes in the scene for the NPC to traverse between. Nav-meshes have grown to be one of the more popular algorithms for navigation. To assist in the creation of nav-meshes, Insomniac created their own tool that generates the mesh for them. This tool allowed Insomniac to create special nodes for enemies for behaviors such as jumping down ledges and on to buildings.

The most commonly used algorithm is the A* algorithm, which happens to be the choice of Insomniac Games. Navigation meshes were laid on top of the scene in Maya, and the polygons from the mesh were used as nodes in A*. As long as two polys share an edge, it means that the NPC can traverse between them. This proved to be a lot of stress on the PPU for Insomniac, as they could only support up to 8 navigating NPC's at one time. To optimize this, they cached paths to be reused in the calculation of new paths. They also took their navmesh in to Maya and separated it in to clusters to be processed on the SPU. They also switched from using convex polys to simple triangles to reduce the amount of computations needed in calculating the paths. Optimization by Insomniac resulted in cache hits more than 90% of the time. Which means that their A* algorithm was taking up less than 10% of the navigation's computational budget. Steering Insomniac faced some trouble with steering behavior in Resistance 2. Because of the games design, the enemies had to be running basically all the time. They ran at around 8 meters per second which caused an conflict between the AI having to go to the bend point in the path and orient itself correctly to the next bend point. Because of their speed, they didn't have enough time to make a smooth transition. To fix this, Insomniac introduced a bezier curve approach. The orientation of the NPC was checked with a tangent in a reverse direction of the corner bend, and a bezier curve was created. Moving the NPC along the bezier curve allowed enough time for it to arrive at the bend point and orient itself toward the next bend point. AI and navigation has been far from perfected. However the team at Insomniac has done an excellent job of optimizing their navigation and NPC behavior.

[jodoi3110]

Cameras In Games

A good camera system can make or break a game. Simply put, cameras are used to control the player's sight.  Quantity

Some games require a very small amount of cameras, and some require a very large amount.

A few types of games that require a small sum of cameras are first person shooters and fighting games. In a first person shooter, you are looking constantly through the perspective of the player. To immerse the player further in to the game, and to stick true to the style of the game, there should be little to no camera switching. In a fighting game, the player is usually able to see close to the entire map. Many fighting games have mini cut scenes that interrupt gameplay, and many of those require some camera switching. However a lot of those are just a single camera that moves around the player or players while a specific animation is played. On the other hand, in games such as adventure and puzzle you will generally find multiple cameras. Adventure and puzzle games often attempt to control the view of the player at certain times to achieve some desired result. Games such as Darksiders, have cutscenes at multiple points throughout the level to denote a significant event. Many of these cutscenes require for the switching between multiple camera locators. In this type of game you will also see a lot of switching between 3D action to 2D platformer, to arena. In the 3D action mode, there will be one camera, which follows the player. The 2D platformer style works similarly, however the camera is restricted to an orthographic view of the scene. Arena style play is generally a top down view of the player in an arena of enemies. You will often see camera switching in adventure and puzzle games when the player enters a new zone or puzzle area.  Movement The way the camera in a game is moved is dependent on the type of game and the intended feeling of the game.  One of the most basic ways to have the camera follow the player is to have it at a offset distance from the player, with its orientation always facing the player. To make the camera follow the player, all you need to do is change the position vector of the camera relative to world space at the same rate as the players changing position. One way to make this technique a little more interesting is to have the camera on a 'spring'. The spring defines certain flexibility attributes for the cameras distance from the player as the player moves. The effect achieved by this is the camera will seem to zoom in and out and move around the player as the player moves and rotates. Using springs can result in a very good looking camera or an extremely hard to follow, shaky, silly looking camera - it requires a lot of tweaking to get just right. Another way to set up game cameras is with multiple nodes placed throughout the scene. Each one of these nodes specifies a location for the camera. When the player moves within a certain proximity of a node, the camera will switch to that nodes position. If you don't desire a hard switch between camera positions, you can interpolate the cameras position to the next node using LERP, and its orientation relative to the player with SLERP.  Finally, you can set up your cameras on rails. The rails are predefined paths that the camera follows. For example, if you wanted the camera to follow the player as he ran up a set of stairs, you might attach the camera to a rail going along those stairs that it moved along as the player ran up. 

Effects

Many video games use the camera to add to the intensity of the game. Playing around with the zoom and focus of the camera is a good way to change player focus or give direction to a scene. This is often seen in puzzle games. Sometimes a puzzle is unclear, but then the cameras focus changes and the solution is revealed to the player. This is a very good technique to use for "real time" cutscenes where you want the player looking at a specific animation. Camera shaking is also very common in games. Shaking the camera or constantly changing its orientation can simulate the player being in a dazed state, or something like an explosion, where you want the screen to shake.

[jodoi3110]

AI in Games

AI (Artificial Intelligence) is used in almost every game to give non player characters or objects the illusion of intelligence. There are multiple types of AI, spanning from combat AI, to movement AI, to puzzle solving AI. The artificial intelligence in most modern games focuses on the ability to move characters, the ability to make decisions on where and how to move, and the ability to think tactically or strategically.  Movement One of the most important aspects for artificial intelligence in most games is the ability for the AI system to be able to move NPC's. The movement algorithms for the AI system need to interact with the strategy system and the decision system. The strategy system tells the AI how to react to a certain scenario, and what its possible options are in terms of actions such as movement. The decision making system for the AI, then decides how it will choose from these possible options. In terms of movement, the AI will often choose the shortest path to its goal. A very common path finding technique for AI is with the use of a navigation mesh. A navigation mesh is a low poly mesh that is placed over top of the regular world mesh, and used for collision and to define paths. The reason that a navmesh is used separately from the regular mesh in this case, is to reduce computations. There are two ways to sample from a navmesh. One is to define paths along the edges of the polygons, and another is to define nodes on the vertices of the polygons for the character to interpolate between. There are multiple types of movement behavior for AI. The most popular being seek, flee, and patrol behavior. 

A seek algorithm will take the position vector of the NPC, relative to the position vector of its target, and move the character or object toward its target. To do this, a path is defined by the AI system and then a position, direction, and velocity are requested by the algorithm. The defined path may change as the target for the character changes. A more advanced version of seek behavior that is often seen in games is pursue behavior. Pursue behavior attempts to predict where the player will be next, and attempts to cut them off. The opposite of this type of behavior being evade. Flee behavior can be seen as the opposite as seek behavior. The intent of a flee algorithm is to move a character away from its target (run away from the player). It operates almost exactly the same as seek behavior, but with a negative velocity.  Patrol, or wandering behavior, is mostly to give a character life, and increase the dynamics of a level. It moves the character in the direction of their current orientation, but sets a small random offset for orientation and updates. This makes the character seem like they are aimlessly wandering around. Some games use predefined paths for patrol behavior. This is especially common in games where you are trying to avoid being spotted by NPC's. Generally, the velocity is set lower while in a patrol or wandering state, and then increased when the character is in seek or flee behavior.  To add some realism to the AI system, arriving behavior and steering behavior are often added.  Arriving behavior handles the event of the character arriving its goal. Often, the character will overshoot its target and have to backtrack, this can cause problems such as constant wiggling of the character. The solution to this is to continuously compare the distance of the character to that of its target. If the character is within a certain radius of the target, decrease velocity. Steering behavior is used to add realism to the turning of the character. In many cases, it is undesirable to have the character constantly facing its target, especially if the target moves. Steering the character turns him smoothly, rather than just snapping his orientation to a certain vector. This is often accomplished by changing the acceleration vector of the character as he is turning. Decision making and strategy

There are a ton of different algorithms for decision making and strategy for artificial intelligence. They differ from game to game, so there is no definite way to say how its done. However, there are some similarities between games in the decision making and strategy portion of AI.  Decision making is the core portion of AI, as it tells the AI what to do and when/ how to do it. Part of a good decision making system is defining different AI states. Popular states for AI include: idle, aware, intrigued, alert, aggressive, fleeing, and dead.  The idle state often calls upon the patrol behavior for the AI. The character will be set to play predefined idle animations or walk around, not making any decisions on how to react next. An aware state means that the character will actively be searching for targets. It is like idle, but there are constant calculations for sight, and position relative to a target.  A character will move from the aware state to an intrigued state if it notices something is out of place. The AI will tell the character to abandon its current behavior and seek toward the point of interest.  If the target of the character is spotted, or another defined trigger is activated, the AI will switch from the intrigued state to an alert state. Now the AI is aware of a certain presence or happening, and will begin to carry out its behavior, such as seeking the player. Once the AI is within a certain threshold of its goal (it has seeked the player), it will switch to an aggressive state. The AI will recognize that it is close enough to engage in combat with the player, and begin executing combat algorithms accordingly. During flee behavior, the AI will recognize that it needs to exit combat or escape the target or player, and begin to use its flee or escape algorithm. Dead behavior is similar to that of idle, but the NPC object may execute specific animations, or be deleted/ respawned upon its death. More about AI will be discussed in further blogs. References: http://software.intel.com/en-us/articles/designing-artificial-intelligence-for-games-part-1 , Dr. Andrew Hogue INFR3110 lecture slides

[jodoi3110]

Game Engines: Design Patterns

When referring to object oriented programming, design patterns are essentially organised solutions to common problems. They are used as a generic practice and are not specific to one coding language. A design pattern helps with the neatness of code, and relationships between the internal classes. Learning the various design patterns is practically useful for many reasons. Design patterns can increase speed in development, and make larger chunks of the code easier to re-use. As well, design patterns help a ton with the debugging process. Knowing how all the internal systems are working will help you track down and deal with those bugs. (Neater code = quicker debugging!)  Design patterns aren't just some heavenly pass to super easy to read and debug code though... They do have their downsides. Using a specific design pattern can limit creativity, as well as restrict design to a specific pattern which may not be optimal for your project.  Four different types of design patterns are singleton, facade, state, and factory.  The singleton pattern refers to an object that is only allowed to have one instance. Singleton patterns are useful for things that you want to be consistent throughout your code, such as global parameters for a physics system. Singletons can sometimes be a pain to use, as they can unnecessarily apply restrictions to your code. A singleton pattern is created by creating a class with a single static member variable. The class houses a function that gets the instance of the class. The facade pattern is seen as a manager, which operates as a simplified interface linking together a large sum of related classes. For example: You have a graphical subsystem and an audio subsystem. Each made up of multiple classes that have to relate to each other. Instead of having a jumbled mess of tangled classes, use a facade to link the two subsystems together, and have the classes operate internally in their own subsystems, and together through the facade.

The state pattern is mostly used in the place of a switch(). This pattern is a huge help for managing game states. Essentially, you have one state manager class which manages the state switching.  AI_STATE<---attack ^---flee ^---patrol Finally, the factory pattern essentially operates like a factory. Instead of creating all game entities separately, you have a factory class which can create instances of the entities. This cleans up your code a ton, as you have a singular place to create objects. This type of pattern also makes your code very reusable and helps with memory allocation. I am excited to see how we can implement these design patterns in the subsystems in our GDW game.  That`s all for this blog! See ya next time.

[jodoi3110]

Introduction to Game Engines

What is a game engine? Why should we use a game engine? How do I choose a game engine? - I will try to answer these questions in my blog... keep in mind that I am no expert on engines; however I will try my best to cover the basics. Before game engines, a video game was coded from the ground up and meant to operate as a standalone entity. By this I mean that each video game created without using a game engine was usually made from scratch; minus recycled code and assets. A game engine is a framework in which a game can be programmed over top of. It consists of multiple pre-programmed functions that are a part of a SDK (software development kit). These functions make the process of developing a game much quicker. In computer hardware terms, you can kind of think of a game engine as a motherboard. Alone the motherboard doesn't do much, but it operates as the piece that houses and connects many of the necessary components of a computer. Just like computers with the same motherboard will have similarities, games programmed in the same engine will also have similarities.  A game engine is not an easy tool to use for just anybody. Despite my simplistic description of an engine, it still requires a ton of work and programming knowledge to produce a decent piece of software. Many game engines require a lot of work just to be able to run. Why use a game engine? .. Many game engines require a licence to use. The licence can be anywhere between free and upwards of $750'000 depending on the engine you choose and the licence type. This can make anyone hesitant on their decision to use an engine. However some companies will provide their engine for free, if you are not planning to redistribute your finished product.  If you have time to spare, are a relatively decent programmer, and want an engine suited to your needs, you can take the time to try to program your own engine. Programming your own engine means that you will know exactly how to use it.. making applications that you program in the future much faster to produce. So why use a game engine? Well a game engine will provide you with the necessary tools and subsystems to speed up the production of your game.  Finally, how do you choose an engine? Different engines are suited to different applications. For example, if you want to make a 2D platformer - puzzle game, don't choose an engine that is known for making 3D first person shooters. You need to research what engines are the best for the scope and style of your project.  Well that is all for this blog... I will continue to pump out blogs on game engines until the end of the year.