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.