GDC Presentation: Scripting

When professor Hogue  first mentioned scripting to the class I assumed this was some new kind of new and complex way to code. I thought it would be another technical thing to learn about game engines, that would make me, as a designer, much more inclined to ignore it, or let it pass me by strictly due to its complex nature. I was surprised that I was actually completely wrong and the truth about scripting is the complete opposite of my initial thoughts.

Scripting use a programming language like C# but it allows your engine to execute code that is not part of the game code itself. The scripts run independently of the game code and are parsed through different programs like notepad which allows the parsed material to be changed without having to recompile code. In layman's terms, programmers can create a script in C++ or a language that can take in data that is parsed and it can appear to designers to be easier to interpret. For example; a programmer could make it so the program reads a text file to determine how many enemies would be created in a level and their stats. The programmer would make it so the compiler knows to read in the digits of the parsed .txt file but to the designer it would look something like:

#of enemies = 2
power of enemies = 3
speed of enemies = 5
That is just a very simple example but scripts are generally used to make some of the code more user friendly and easier to decipher.

Just an example of a basic .txt script

Getting a little more in depth with scripts, there are many different types of scripts. From watching the GDC video on scripts I am aware of a few. They are component, system, and data scripts.


Component scripts are kind of like a container for features that you can make work together. They can hold code or scripts. System scripts are grouped together in a system which helps allow them to be accessed much easier. The final script is a data script. Data scripts create a save state of the script, drive the system forward with data, and help determine structures for both.

Pic from GDC presentation of scripts

In Bullet Devil: Attack of the Elements we use scripts. They are used to load in particles. I posted previously on our enemy manager. Our enemy manager also used a script would load in values like velocity, spawn point, the power up they were going to drop, etc. Here is a bit of code taken from our particle manager.

emitter Point
    {
        name                    Ice
        angle                   180
        emission_rate           1
        time_to_live            1
        direction               1 1 0
        velocity                1
        duration                0.1
        repeat_delay_min        1
        repeat_delay_max        1
    }

This piece of code just shows a test of the ice particle effect that surrounds our main characters weapons. We plan to add more attributes like colour, so we can manipulate this script to create other effects like fire, water, earth, etc.

In conclusion, scripts are a really useful tool for programmers to make their code much easier for other members developing the game to understand. Scripts can cut development times by a lot since so many more people can design and implement stuff using scripts other than programmers dealing with their own messy code. There are also some disadvantages to using scripts like making too many so remember to use them sparingly.