#i3110

Here’s a REALLY quick run-through of a typical game engine’s run-time architecture:

*The colours are not representative of relationships between components.

**The black lines show connections/relationships between components.

This is a rough visual representation of run-time game engine architecture.

Everything is built in layers: the highest level is the game-specific subsystems and the lowest level is the game’s hardware. I’m going to go through the different components one at a time, starting from the lowest level and working my way up, giving a rough description of each.

The lowest level is the target Hardware, or whatever platform the game is meant to be played on. Typical platforms are PC, Xbox 360, Playstation,  3DS, Wii, etc. The only ones I currently know to use are PC and Android; they are the most user-friendly and accessible platforms to release games on. The hardware influences just about everything higher than it, because it dictates the interactions and capabilities of the game.

Device Drivers are next; they are low-level software components that are beneath the operating system and make it work. They manage hardware resources and make the transition between the operating system and the hardware easier.

The Operating System is always running, and is what users interact with. Windows is an example on the PC, and any game on the PC needs to be compatible with the operating system it is meant to work with (i.e. games made for Windows 7 may not work on Windows 8). On consoles, it's the same thing, even going so far as to interrupt gameplay in order to display messages, or give players access to their main menu. On Xbox, this may be the dashboard,  PS3 has the Xross media bar, and the 3DS has the home menu.

Third-Party SDKs has a bit more involved with it than the 3 lower levels. There are a number of third-party software development kits available, such as STL (Standard Template Library), BOOST, Loki, DirectX, OpenGL, Havok, PhsyX, etc. They are used for a variety of different purposes within the game engine, and often there are more than one implemented at once. For example, Bullet Physics may be in use for the physics part of the engine, and OpenGL for the graphics.

The Platform Independence Layer is a way of ensuring consistent behavior across all hardware platforms. It may include platform detection, atomic data types, collections and iterators, a file system, hi-res timer, threading library, graphics wrappers, and the physics/collision wrapper.

The Core Systems contains a handy collection of software utilities, or "core systems". A few facilities that may be provided here are: assertions, unit testing, memory allocation, math library, strings, movie player, parsers, random number generator, curves and surfaces library, object handles and unique IDs, and file I/O. Awful useful to have all bundled together in one convenient place.

The Resource Manager is always present in a game engine in some way or another. It is what provides the interface for dealing with any and all game assets and input data. Typically contains resources for 3D models, textures, materials, fonts, skeletons, collision, physics, and the game world or map.

The rendering engine is typically always the largest and most complex component of any game engine. There are so many different ways to make it work that there is no one "right way" to do it. One of the most common ways to implement it is by making a layered architecture of the low-level renderer, scene graph, visual effects, and front end.

The Low-Level Renderer takes care of all the raw rendering required in the engine. It focuses mostly on geometric primitives and spits them out as quickly and with as much quality as possible. It's subcomponents are: materials and shaders, static and dynamic lighting, cameras, texts and fonts, primitive submission, viewports and virtual screens, texture and surface management, and debug drawing.

The next level of the rendering engine is the Scene Graph or Culling Optimizations, a higher-level component which helps to limit the number of primitives depending on the visibility of the scene. This is where techniques like frustum culling and spatial subdivision are done. Occlusion is another commonly used technique.

The next level in the rendering engine is the Visual Effects layer. No modern game is complete without an array of visual effects such as particles, decals, shadows, and pretty shader effects. This takes care of all the specialized rendering needs of the visual effects. Some of the most common visual effects are: light mapping and dynamic shadows, HDR lighting, PRT lighting, subsurf, scatter, particles and decal systems, post effects (effects done on the entire screen after other rendering effects have already been applied), and environment mapping.

The Front End is the highest level in the engine renderer, and takes care of the 2D graphics display that is typically overlaid on the game scene. This has various uses: HUD, in-game menus, in-game GUI, wrappers or attract mode, in-game cinematics, and full-motion video are just a few examples.

Next to the engine renderer is the Profiling and Debugging Tools, which include recording and playback, memory and performance stats, and in-game menus or console. Profiling your game helps to optimize the performance.

It wouldn't be much of a game without Collision and Physics; that which defines player behavior and how things react to each other. This component defines the forces and constraints, ray or shape casting, the rigid bodies (always important :D), phantoms, shapes or collidables, physics or collision world, and ragdoll physics of the game.

The Animation component of the engine is a necessity (as I've learned it's hard to work without it) in any engine. Whether you want sprites, morph targets, rigid body hierarchy, or skeletons, this is the part of the game engine which is supposed to deal with them. It includes: animation state tree and layers, inverse kinematics, game-specific post-processing, LERP and additive blending, animation playback, sub-skeletal animation, and animation decompression.

Human Interface Devices (or HID) are what allow the player to interact with the game and is what makes games different from other entertainment medias. Examples of HIDs are: keyboard and/or mouse, joypad, gamepad, steering wheel, WiiMote, dance pads, etc. It works with the game-specific interface as well as the physical device I/O.

The next level is the Audio of the game. No game is complete without a good soundtrack. Can you imagine a horror game without creepy music or an adventure game without that motivational music? This needs DSP or effects, a 3D audio model, and audio playback and management.

What's next? The Online Multiplayer and Networking component. This is where match-making (and not the lovey-dovey stuff) and game management, object authority policy, and game state replication are taken care of.

Gameplay Foundation Systems are another big part of the game engine which defines the rules of the game; the GAMEPLAY. It looks at the hierarchical object attachment, static world elements, dynamic game object model, real-time agent-based simulation, even or messaging system, world-loading streaming, scripting system, and high-level flow system. This is what makes the game what it is, and is in charge of most objects such as environments, characters, NPCs, enemies, props, camera, the list goes on. Game objects need to interact or communicate with each other, which is dictated by the event system in this component of the engine. Certain game logic and data can be specified using scripting, and AI foundations are often found here as well.

Finally, Game-Specific Subsystems is the highest level, and includes everything specific to the game itself. Examples of this include (but are not limited to): weapons, power-ups, vehicles, puzzles, Game-Specific Rendering, Player Mechanics, Game Cameras, AI, etc. This is where terrain rendering and water simulation rendering falls, as well as the collision manifold, player movement, fixed cameras, camera-relative controls, player-follow camera, AI goals and decision making, actions, and path finding.

Now that I have worked more with 2LoC I can almost answer that question...

In 2LoC, I expanded my solar system project to allow for the selection of each planet, focusing the camera on the selected planet, and displaying a description of the selected planet. I also implemented toggles for each of these features.

My solar system project contained a sun with 9 planets, 3 of which had moons. Instead of parenting the moons to the planets and the planets to the sun, I made all of the calculations manually. I placed the sun at the origin (0, 0), and each planet orbited around that. For the moons, I had them find the position of the planet they were orbiting, and orbit that position as opposed to the origin like the planets. This works well so long as the solar system stays on a relatively small scale and stays in place. If I were to do this properly I would parent them, but for the sake of this assignment there was no need.

The first thing I applied to my project was a way to render text to the screen. After loading in a font texture and specifying the order of characters in a wide string, it’s almost the same as any other object: it needs a material. What else does text need but a font size and colour? Another thing which differentiates text from certain other objects is that you must specify min and max filters and initialize the sprite sheet of letters and numbers.

Text objects can be aligned to the left, right or center; similar to in most word programs. Another feature is that you can set the vertical kerning value, which is the distance between lines.

Creating the text entity would look something like this, after creating the material and spritesheet:

textEntity =

       pref_gfx::DynamicText(v_entityMgr, v_compMgr)

              .Alignment(gfx_cs::alignment::k_align_center)                                             .VerticalKerning(-2.5f)

              .Create(L"The quick brown fox jumps over the lazy dog. 1234567890", f);

       textEntity->GetComponent<math_cs::Transformf32>()

              ->SetPosition(math_t::Vec3f32(-250.0f, 300.0f, 0));

       pref_gfx::Material(v_entityMgr, v_compMgr)

              .AddUniform(u_to.get())

              .Add(textEntity, vsSource, fsSource);

Notice that this text here is a dynamic text entity. This is because I needed to be able to change the text according to what planet was selected, and the easiest way to manage that was to change the text within the entity itself whenever needed. Static text works well enough for simply displaying text to the screen but for anything that requires changing the text, such as counters, dynamic text is what is needed. In my case, the contents of the text was dependent on the planet selected. I used dynamic text in order to be able to change the text as needed.

In order for the text to appear on the screen, the last thing I needed was a separate renderer. As opposed to the default renderer, I needed to enable blending so the text would render properly, and not be all blocky rectangles. For some reason, my blend function did not work, and though I was able to see the text, each letter had a tight black rectangle behind it. I was unable to rid the text of those boxes, so instead I made the rectangles the same colour as the background to make them less noticeable.

The last thing to make the text work was to create a separate camera just for the text. This camera cannot have perspective and can be at a different position from the main camera. IT registers what would effectively be the HUD of a game; in this case just a text description.

The next thing I implemented was an added feature to the arcball camera. I needed to be able to focus on the selected planet at the push of a button. The arcball camera has a focus feature which I was able to use. I made a function which took the position of the selected planet as well as the camera entity handle. This function changed the position of the camera so it was directly in front of the planet then set the camera’s focus to the planet. If you don’t set the focus to the planet, the camera continues to look at the sun and orbits around with the planet, only seeing it at points around the orbit. If you don’t set the position to follow the planet, the camera will simply rotate to follow the planet. After coming out of focus, the camera must again be set to its original position above the solar system and its focus set back to the sun, or the origin in my case.

My function looks something like this:

//change camera position + focus

void focusCamera(math_t::Vec3f planetPos, core_cs::entity_vptr m_cameraEntity)

{

       math_t::Vec3f position = planetPos;

       //increment position (so we can see the planet)

       position[0]++;

       position[2]++;

         //change position + focus of camera

       m_cameraEntity->GetComponent<math_cs::Transform>()->SetPosition(position);

       m_cameraEntity->GetComponent<gfx_cs::ArcBall>()->SetFocus(planetPos);

}

It has much of the same steps when setting it back to its original focus except for incrementing the position. The planet position gives the origin of the planet, so if I set the camera to that position, it will try to occupy the same space as the planet and you won’t see it at all.

One issue I had with the camera when I changed the focus was that it decided to zoom it to the scene when I was trying to rotate around. The way the arcball camera is supposed to work is ALT + left click drag allows you to rotate around the scene, ALT + right click drag allows you to zoom in or out, and ALT + middle click drag allows you to pan around the scene. In my case, the camera was trying to do multiple things at once. The effect was every time I hit the focus key, it would be zoomed in more than the time before. I have yet to find the solution, though the new distribution of the engine is meant to fix this problem.

Moving on to the last implementation needed for this problem, I had to find a way to allow the user to select a planet by clicking on it. For this purpose, I used a ray picking class. Ray picking is a technique which tracks the mouse’s location in a 3D scene. It traces a line between the 2D mouse coordinate on-screen and projects it straight along the perspective frustum into the scene. Using a cuboid and the entity handle of whatever object you are trying to detect, it is easy to specify a range and calculate whether or not the mouse is over the object, even in 3D space.

The math itself was given to me in a sample project, and I will not take it apart here. The sections I had to edit to serve my needs were where it registered where the mouse was and where it took in the entity handle and compared it to the mouse location. I did not want a flag to wave every time the mouse passed over an object, only when it was clicked on (left-click). This was a simple changing of when a flag was raised. The class I was given was only meant to register one entity; I had 10 objects to pass in and check against. The easiest way I found to do this was to pass in all my objects in an array, then the index was whichever planet that was intersecting the mouse. I needed this number in order to focus in to the correct planet, and to display the correct text description.

My intersection test function looked something like this:

bool Raypicker::intersectionTest(math_t::Ray3f ray, core_cs::entity_vptr m_entity)

{

       ray = ray * m_entity->GetComponent

       <math_cs::Transform>()->Invert().GetTransformation();

         return m_cuboid.Intersects(ray);

}

The “ray” in this function is the ray projected by the mouse into the scene. If the ray occupies any of the space also occupied by the entity passed in then it is intersecting with it. This returns a Boolean value (true or false) because in reality, either it is intersecting or it’s not. Simple, right? This function was called for each planet in the array; if it found an intersection with one of the first planets, it would not continue checking the rest. It cannot be intersecting with all the planets at once, therefore this was the easiest and most efficient method.

So that’s it for that project. I now have a solar system which has selectable planets that you can zoom/focus into as well as see a short descriptive text. In order to make this better, I would need to parent everything together into an appropriate hierarchy: moons to planets to the sun. When I focus the camera into a planet, ideally I would parent the camera to the planet. That way, you could rotate around the planet while in focus mode as opposed to having to disable the arcball camera control as I do now.

For my first experience working with 2LoC, I started real easy: lighting shaders and orbiting objects.

The first, I chose because I have looked into lighting shaders in detail before and know how they work. I am not an excellent coder, so being able to work with familiar content allowed me to focus more on the differences in working in the new engine.

So. Lighting. The task was to demonstrate the difference between per-vertex and per-fragment lighting, and be able to switch between then with a key press. Visually, the only difference between the 2 is that fragment lighting is smoother (by how much depends on the poly count of the geometry). Vertex lighting can lead to triangle-shaped shadows on the object, where fragment lighting is normally more correct and even.

Code-wise, the ONLY difference is when the calculation to determine the colour of the fragment is done. For vertex lighting, the lighting calculation is done in the vertex shader and the product of the resultant colour and the texture colour for that UV coordinate is found in the fragment shader. For fragment lighting ALL calculations are done inside the fragment shader, and the vertex shader becomes nothing more than a pass-thru shader. In fragment lighting, the lighting calculation is performed more often (there are more fragments than vertices), so it makes sense that it would lead to smoother shading.

My lighting function in 2LoC looked like this:

vec3 lighting (in vec3 nrm)

{

                //put it into world space

                nrm = normalize(u_modelMat * vec4(nrm, 0)).xyz;

                vec3 N = normalize(nrm);

                vec3 L = normalize(u_lightDir);

                float Lambert;

                  Lambert = max(0.0, dot(N, L));

                                return Lambert;

}

I won’t go into detail what this does here; see my blog post on shader lighting effects from last year: http://blogofagraphicsstudent.tumblr.com/post/76592168840/assignment-mayhem

There were a few crucial differences between the engine that I was working with last year and 2LoC that I found over the course of implementing these 2 shaders. The first (and easiest to fix) was that I did not have access to the model matrix. In 2LoC you need to enable the matrix before you can use it in any shaders (it is called u_modelMat).

The second big difference is in how the shaders are applied. In 2LoC you have to specify the shader path in a material, and if you need multiple different shader paths you also need multiple materials (same goes for different texture paths as well). 2LoC contains a lot of safeties, which makes sure that all external assets load properly, and if they don’t it will tell you exactly where you went wrong. They are helpful but new to me, so it makes my code a little hard to read at times.

Each material requires a reference to both the entity and component managers, texture path, light direction, and shader path. I needed to have a dummy entity to hold onto the different materials for me, as well as a separate material to start on; weird problems I’m not sure I found the correct solutions to (but they work!). For example, my material initializations looked like this:

auto materialvertexShader =

  pref_gfx::Material(entityMgr.get(), compMgr.get())

                  .AddUniform(u_to.get()) //texture path

                  .AddUniform(u_lightDir.get())

                  .Construct(vertexVS, vertexFS);

//same for materialfragmentShader

Switching between the materials merely requires that I have access to the virtual pointer of the object I want to change the material of, and the shared pointer of the materials I want to switch between.

And that’s the end of that assignment’s requirements. Moving on to orbiting objects.

The first thing I did for this project was create a class to create a sphere model with the proper material. I had to be able to create at least 12 spheres each with a different texture, and I did not want to have to write out an individual material for each of those. The information needed by the class was:

(String) folder path to OBJ model

(String) folder path to PNG texture

virtual pointers to both component pool and entity managers

(float) variables for position (x, y) and period (x = radius)

I decided against scaling my star/planets/moons in code and just had different OBJ models in my assets folder that were sized differently. That’s why I needed a path to the model as well as to its individual texture path. The managers are always important, and the float variables helped to position and define the behavior of each object. The position was determined by (x, y); I placed the sun at (0, 0) to make the orbiting easier and each of the planets were at different distances from the sun in a line. The moons I placed nearer to the sun due to the fact that I also used ‘x’ as the radius of each object’s orbit. The period was slightly different for each object (the sun’s orbit was 1, and the furthest planet from the sun had a period of 15. Each moon had a period between 1-3).

Each object had a rotation applied to it, along the (-1, 1, 0) axis (simple rotation; only complication was in normalizing the vector) as well as their orbit around the sun. Technically though, all of the planets are not orbiting around the sun, but around the origin (0, 0). The sun and the origin just happen to occupy the same space (coincidence? Nope)! For the orbit calculation, I simply had to find the position of the planet (or moon) around the origin. All I needed was the transform component of the object, its radius, and its period. The hardest part was figuring out how to convert to radians and where Mathf::PI was hiding.

The function ended up looking like this:

math_cs::transform_sptr planetTransform = planet->GetComponent<math_cs::Transform>();

math_cs::transform_sptr moonTransform = sphere->GetComponent<math_cs::Transform>();

pos[0] = radius * math::Sin(math_t::Radian(time / period * 2 * Mathf::PI));

                pos[1] = radius * math::Cos(math_t::Radian(time / period * 2 * Mathf::PI));

                pos += planetTransform->GetPosition();

                moonTransform->SetPosition(pos);

^This is the function for the moon calculation (which additionally needs to find the position of the planet around which it is orbiting and added that to its current position). That’s really all there is to it; just make sure that it’s not updating the position every frame (else it’ll go VERY fast), and this question is also complete.

I did not choose difficult questions to start on particularly because I am not strong in code. These questions helps build my understanding of 2LoC as well as build my confidence that I can succeed in this class. I’m looking forward to the harder questions, and may even try to implement my own version of Pong or Pacman J

Game Engine Design & Implementation

As the class that provides the engine that we must work with throughout the year, this is one of the most important classes this semester. We are given 2LoC, or “2 Lines of Code”, as created by our professor.

Before we can really get into the workings of the 2LoC engine, there are a few terms that it’s important to know, and know WELL. You have to know the basic coding practices in C++. Among the most important terms to know are: stack, heap, pointers, smart pointers, containers, iterators, templates, template inheritance, callback functions, macros and string manipulation. As the “artist” of the studio I never really focused as much on the coding portion of the course, so I’ll take this opportunity to take myself through a crash course in C++ before diving into the more heavy engine code.

First off are the differences between the stack and the heap. The stack functions like a command list, while the heap is essentially everything that is not the stack. The heap applies dynamic allocation of memory; information is stored in whatever place is readily available. If it were to have a graphical representation it would something like, well a heap.

There’s a lot to learn about what pointers are and how to use them. They can be incredibly useful, but they are a pain to fix when they aren’t used properly. A pointer is a variable that stores the address of the information you are looking for, instead of copying the information and putting it somewhere else.

Shared pointers are new this year, but extremely important to know before getting into 2LoC. They eliminate the need to use ‘new’ and ‘delete’ to create/destroy pointers; these can lead to memory leaks within your code. Every ‘new’ needs a corresponding ‘delete’; when it falls out of scope without being deleted, it produces memory leak. Also a feature of shared pointers is that if a pointer is deleted, the information at the address it was pointing to is only deleted if there are no other pointers to the same address.

A container is a way of storing more information under a single variable name. They group the information together and make it easier to use it, as long as they’re used properly. There are several different kinds of containers, each with their own advantages and disadvantages: arrays, lists and vectors are the most commonly used. Arrays can be described as a strip of information in memory. They use a simple indexing system that allows you to access any element in the array so long as you know the index. A list, instead of directly storing the information as would an array, will contain pointers to each element in the list.  A basic list will have each element pointing to the next element, and doubly linked lists will contain pointers to the previous element as well. You cannot access any element in the list without first going through all the previous elements first; because the information of each element could be stored anywhere in memory. A vector is similar to an array except that its size can change in run-time; its size is dynamic.

One way that you can keep track of your code is by using iterators. An iterator is an object that is iterated up or down by a specified scale to keep track of how many times something has been done. The most basic use of iterators is in a ‘for’ loop. Some of the most common operations performed on iterators are ++ and --, to add or subtract 1.

One thing that I never really fully understood until the end of last year was how to properly use templates. A template makes it so if you need to create similar functions or classes for different variable types, you don’t have to make more than just the one function or class. For example, a function to add two integers is very simple. But that function can only add integers; if you wanted to add two double values, you would need another function, and the same for floats. A template would allow you to make just one function that covers all types of objects, so long as they are supported. Essentially, it creates a “placeholder” for any given type. If you make a function which takes in and results in your placeholder type, it will work for any type you give it.

Another application of templates is template inheritance, which is similar to class inheritance. Anytime a class or template inherits from another class or template, it will always initialize the inheritance first then continue to go through the regular class/template activities. This aids in avoiding repeating code when multiple templates have similar functions, but are not identical.

Callback functions are another thing that I neglected to learn properly until the end of the year. You pass a function A as an argument to another function B. In turn, that function B calls function A. Simple enough to use once you get the jist of it, but hard to grasp its uses the first time you have it described to it. One possible use is for if you want to call a function when the user presses a key.

What is a macro? A macro works like a text replacement within a project. This works well with constants that will remain the same for the duration of the project. You define a value that you want to replace a word with. For example #define PI 3.14.

There are many different things one can do within string manipulation. You can return the numerical value of the string, compare or concatenate 2 different strings, output strings, find the length of said string, replace a string, etc. I won’t go into too many details here, but you can do a lot with strings. They even have their own class in the standard library.

Another important element that has yet to be mentioned is scene graphs. They are easier to read and understand than just data on a screen, and are an excellent way of representing the hierarchy of a scene. Perhaps an example would be easier to explain. If 2 planets of 2 moons each revolve around a star, what would that look like in data? Well I don’t know, but the scene graph would look something like the graph below. Scene graphs make it easy to see just what objects are parented to which other objects as well as what transforms affect each object.

What is a thread?

A thread is a path of execution through the program. In a single-threaded program, there is always a single path of execution. While in a multi-threaded program, there are two or more paths of execution.

Threading is basically running different sections of code on different processes simultaneously.

Single – threaded program:

When using a single-threaded program, only one task can be done at a time and the program waits until a task is finished before starting another one.

Multi – threaded program:

Multi-threading is a widespread programming and execution model that allows multiple threads to exist within the context of a single process. 

There are essentially two reasons to use multithreading.

The oldest reason, which has been confounding programmers for decades, is to get better latency behavior out of a system. If the application is processing some data then it can't respond to other events.

The second reason to use multithreading -- and the most important for less latency-sensitive applications -- is that multithreading is literally the only way to squeeze out the maximum performance on modern CPUs. 

1:1 (Kernel-level threading):

Kernel – level threading supported directly by the kernel: kernel can run them on multiple processors in parallel.

  Threads created by the user are in 1-1 correspondence with schedulable entities in the kernel. This is the simplest possible threading implementation.

A kernel thread is the "lightest" unit of kernel scheduling. At least one kernel thread exists within each process. If multiple kernel threads can exist within a process, then they share the same memory and file resources.

N: 1 (User-level threading):

These are threads managed by user-level threads library: requires less overhead than kernel-level threads.

An N: 1 model implies that all application-level threads map to a single kernel-level scheduled entity; the kernel has no knowledge of the application threads. With this approach, context switching can be done very quickly and, in addition, it can be implemented even on simple kernels which do not support threading. 

Multi – threading models:

Mapping user – level threads to kernel – level threads/ processes is called multi – threading models. Types are:

One – to – One

Many – to – One

Many – to – Many

  One – to – One:

Each user-level thread maps to a separate kernel thread. Therefore, creating a user thread implies creating a kernel thread (more overhead than a new user-level thread in the same user process).

Many – to – One:

Many user-level threads mapped to single kernel thread. Can be used on systems that do not support multi-threading in the kernel.

  A really interesting explanation of threading:

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. 

At first, I knew what scripting was, but didn’t know how to explain it. I would just give examples of the scripting languages I know, such as Mel, C#, JavaScript or Python. But I figured out what it is, what are the types, and how you can use it…

  What is scripting?

Scripting is basically a high-level programming language that is interpreted by another program at runtime rather than compiled by the computer's processor as other programming languages are. Scripting languages, which can be embedded within HTML, commonly are used to add functionality to a Web page, such as different menu styles or graphic displays or to serve dynamic advertisements.

  In our game, we use scripting for Particle systems, material attributes etc.

At first I assumed, it is going to be exactly like c++ code, and more complicated, but it is actually really easy.

  Specialised scripting languages include:

  Perl (Practical Extraction and Report Language): This is a popular string processing language for writing small scripts for system administrators and web site maintainers. Much web development is now done using Perl.

  Hypertalk is another example. It is the underlying scripting language of HyperCard.

  Lingo is the scripting language of Macromedia Director, an authoring system for developing high-performance multimedia content and applications for CDs, DVDs and the Internet.

  AppleScript, a scripting language for the Macintosh allows the user to send commands to the operating system to, for example open applications, carry out complex data operations.

  JavaScript, perhaps the most publicised and well-known scripting language was initially developed by Netscape as LiveScript to allow more functionality and enhancement to web page authoring that raw HTML could not accommodate. A standard version of JavaScript was later developed to work in both Netscape and Microsoft's Internet Explorer, thus making the language to a large extent, universal. This means that JavaScript code can run on any platform that has a JavaScript interpreter.

  VBScript, a cut-down version of Visual Basic, used to enhance the features of web pages in Internet Explorer.

  Scripting languages are becoming more popular due to the emergence of web-based applications.

Major advantages of scripting languages include:

  Ease of learning and using

Minimum programming knowledge or experience required

Allows complex tasks to be performed in relatively few steps

Allows simple creation and editing in a variety of text editors

Allows the addition of dynamic and interactive activities to web pages

Editing and running code is fast.

  I recently wrote C# scripts in unity for a side scrolling game. This actually turned out to look pretty good. I made it randomly generate platforms, and recycle them when they are no longer visible in the field of view.

  Let’s just look now at a basic lerp function in C#:

  public class FinishedLightLerp : MonoBehaviour

{

    public float smooth;

        private Vector3 newPosition;

    private float newIntensity;

    private Color newColour;

        void Awake ()

    {

        newPosition = transform.position;

        newIntensity = light.intensity;

        newColour = light.color;

    }

        void Update ()

    {

        PositionChanging();

        IntensityChanging();

    }

            void PositionChanging ()

    {

        Vector3 positionA = new Vector3(-5, 3, 0);

        Vector3 positionB = new Vector3(5, 3, 0);

                if(Input.GetKeyDown(KeyCode.Q))

            newPosition = positionA;

        if(Input.GetKeyDown(KeyCode.E))

            newPosition = positionB;

                transform.position = Vector3.Lerp(transform.position, newPosition, smooth * Time.deltaTime);

    }

            void IntensityChanging ()

    {

        float intensityA = 0.5f;

        float intensityB = 5f;

                if(Input.GetKeyDown(KeyCode.A))

            newIntensity = intensityA;

        if(Input.GetKeyDown(KeyCode.D))

            newIntensity = intensityB;

                light.intensity = Mathf.Lerp(light.intensity, newIntensity, smooth * Time.deltaTime);

   }

  I am sure there are better ways to write this function and in better scripting languages too I guess. But since this is one I am currently learning, I just decided to go with that.

  I also found really good books and tutorials, to help you get started and probably for a lot more things in terms of scripting. Just to share a few for you al to look at:

  http://wiki.roblox.com/index.php/Scripting_Book

http://www.freewebs.com/campelmxna/tutorials.htm

http://www.tutorialspoint.com/python/

  Conclusion:

What is a navigation mesh?

In many games, a character needs to be able to travel automatically from its current position to a desired destination. In some cases, this will be a simple matter of moving in a straight line or along a preset path but there are also game worlds based around buildings, forests or other settings where the route to the target is not so direct. In games like these, some control logic is needed to allow the character to make decisions at each point along its journey to choose its next step. The process of choosing a character's movements around the game world like this is known as navigation.

There are various techniques that can be used to navigate a character to its destination, some of which involve an element of trial and error with mistakes and wrong turnings. Often though, the desired behaviour is to make the character appear to be planning its path intelligently, taking the most direct or advantageous route. This requires a bit of artificial intelligence (AI) to establish the best way to get from the starting point to the destination. This task in game AI is known as pathfinding.

A pathfinding system needs a way to represent which parts of the game world can be reached by a character and also a way to determine the possible routes between any two points and choose the best. A mesh (similar to the ones used for 3D graphics) is a good solution to both problems. The reachable area is defined by the polygons of the mesh, while the possible paths through the mesh are conveniently broken down into hops between adjacent polygons.

A navigation mesh is a set of polygons that describe the “walkable” surface of a 3D environment. Algorithms have been developed to abstract the information required to generate Navigation Meshes for any given map.

  Useful video on generating Nav Meshes:

http://www.youtube.com/watch?feature=player_embedded&v=ACLuXWkpJhU

  Navigation mesh in the Insominiac Engine:

(by Reddy Sambavaram)

Games are striving for a more immersive and fun experience and, Non-Playable-Characters in the game play a huge role in it. The ability for NPCs to perceive the world around them and react according to situation is a fundamental element of the game. How AI navigates is often how design gives personality to the AI/NPC in the game. The industry is moving away from heavily scripted AI to more dynamic and innate movement solution.

Usually AI usage comes in as few commands into the system

-          Go-to command to NPC

-          NPC should first figure out its location coordinates

-          Get the destination’s coordinates

-          Find a path to destination (given some parameters)

-          Scan for impending dynamic obstacles and avoid them

NPC also uses system to scan for targets to feed it back to AI logic and to monitor threat perception by AI & player. It is also used to determine ‘spawn’ locations in the level and for level reuse and to contain gameplay sections.

  Various world representations have been used

-          2D Grid

-          way-point graph

-          way-volume graph

-          poly-mesh/nav-mesh

-          combination of above

But the nav-mesh gained considerable current reception. The A* algorithm and its mods are typically used for path-finding on the navigation world.

  Insomniac Engine on PS3 uses nav-mesh

nav-mesh representation

*designer laid out the entire level nav-mesh in maya

*polys as nodes and edges as connections for A*

*nav was one of the big bottle necks on PPU

*max soft limit of 8 navigating NPCs at a given time

*lod system was put in place so NPCs at a distance did not use nav and

 went to great lengths to stagger the nav queries across frames even with above limits

*well, it was different production cycle for PS3 launch

  * If you look at RFOM levels 3 RFOM levels shared a theme (which shared  a theme like a city)  and wanted that to make one Resistance2 level

*level streaming took care of rendering but nav was monolithic for whole level

*design planned to increase nav poly density by 3x

*remove ai lod so bots can nav from a distance

*we were making 8 player co-op mode which implied enough NPCs to keep 8 players engaged in some encounters

  Path-finding was changed to consider more parameters ability to jump up/down various distances we use one nav-mesh for varied size NPCs. A* considered NPC’s threshold clearance when searching design used above, feature to selective path among ai. Preferred corner radius (maintains radius away from boundary) full-frame deferred nav queries. Game-play code was changed to  use nav data as queries ai synced previous frame results and set the query for next frame’s needs code was streamlined to batch all nav queries nav query data access was also isolated for concurrency needs. Readied for SPU offloading of nav processing. 

Our steering in R2 was very light weight/simple which barely managed to satisfy ours needs at the time. Design wanted NPCs to run all the time (grims run at 7-8m/s). This posed issues while cornering when animation did not slow down enough. NPC has to not only get to first bend point but also need to orient towards the next bend point in the path

  *nav SPU job computed bezier approach curve for the bend point start curve tangent is computed by doing a swept sphere check for the specified distance in the current NPC facing direction end curve tangents is computed by doing back projection swept sphere check from first bend point in the opposite direction of second bend pt bezier curve is computed using above tangents NPC always aimed for the mid point of the curve for smoother approach

*swept sphere checks against nav-mesh boundary ensured that curve stayed on nav-mesh maintained NPC threshold from boundary

find point on mesh query kept threshold distance in result if it didn’t move by threshold move the result on plane update the threshold sphere

rolled in the grim’s cache into the frame work and spu job was changed to find & smooth path. Computing the bezier curve for all queries compute obstacles and their escape tangents help accumulate list of all obstacles, over all queries and max NPC threshold radius thus avoiding each obstacle cache. All nav-mesh boundary edges intersecting each obstacle given its max NPC threshold compute closest point on edge for each nav-mesh boundary edge in above for each path query’s obstacle look into its boundary edge and its closest point and flag tangent if NPC threshold will be violated. Nav SPU job was split into steps as in above (ultimately turned into shaders). Custom links are non-mesh links used for jumps, ladders, tunnels, tele-porting connections.

Traditional approach:

Implemented as point to point links approaches need tweaking if nav-mesh underlying it moved level layout got slightly changed does not fit nicely in A* or path smoothing creates issues when dynamic obstacle is near the link design thinks in terms of walk-able areas not points

Our approach:

Place a custom clue box/OOBB with a special front face. More tolerant scheme and designer  intent is preserved as long as front face of link-box intersects nav-mesh it is valid

  Designer can extend the usage of custom-override-polys to remove nav-mesh in unwanted areas close holes in un-wanted nav-mesh (because of hole in scene) modification tends to preserve designer modification even when the level is tweaked and also when nav-mesh is regenerated

Generation algorithm can be tweaked to punch sleeping-dynamic elements from the nav mesh

To cut costs in current gen console we plan on using nav mesh as render geom.

And clear the voxel data for the obstacles and generate nav mesh on the fly