Scripting: The What and the Why.

Recently in one of our lectures presented by Dr. Hogue, we went over an exciting topic that is sure to benefit our game creation dramatically.  This topic was of course, scripting!  He went over the various uses of scripting, the different types of languages used for scripting, and how we as students will be able to include scripting into our games to save time and effort.  For this blog post, I will first be outlining what scripting is, then outlining some of the scripting languages used currently, and finally, finishing off with how our GDW group will be using scripting to our benefit!

Up until this point in our education, coding in C++ has been a pretty straight forward task.  We write the code in our .cpp files and .h files, then compile the program and run it to see if it functions.  It is a system that has worked for all these years, even though it is inefficient.  If a small change is made in the code and the programmer wishes to test it, the project must re-compile all over again to see if the change was a success.  For smaller projects, this time does not seem like large burden to the programmer, however, when a team is assembling a large project (such as our games), having to re-compile after each change can mean substantial amounts of down time.  To help combat this problem, scripting was introduced to the mainstream programming scene.

Scripts in themselves are generally small text files written separately from the main code base.  These small texts are then taken and compiled at run time, outputting some option for the user.  This allows for the rapid development of minor changes in the project, while also making the engines core behaviours simpler for the programmer. For a non-programming type like myself, this also meant that I could write code in scripting language, which I found much easier to understand and interpret for my small tasks.

Now before a script can be written, the user must realize that there are two different types of scripts that can be written.  These scripts are:

Interpreted

Interpreted scripts are usually intended for smaller tasks, as the process of "sticking together" a succession of compiled programs, is not very ideal for larger projects.  Interpreted scripts is a program where a logically sequenced series of operating system commands are handled piece by piece, using a command interpreter.  This interpreter does this, by going through the scripting code line by line, examining what is occurring at each stage.  These lines are then parsed, interpreted using the operating system and executed as they are passed over.  This is why larger systems generally stray away from using the interpreted scripting method.

Compiled

Compile scripts are what programmers use when they need to handle a larger task, but still do not wish to compile the project as a whole because of time constraints.  Similar to how C++ functions, for this style of scripting to function, we need to use a compiler that creates bytecode from the written script.  This bytecode that is written in a special format, in which the interpreter can load the bytecode and understand what is occuring in the script.  From this stage, the bytecode in loaded into a virtual machine that is residing in the script application.  While this bytecode is being loaded in, the project can run in a piece by piece format, saving the programmer their most valuable resource, time!

Since we had all of the benefits of scripting sitting in front of us, we as a Studio decided that using scripting in our program would be the most efficient method of completing this project on time.  Without the fear of needing to make large changes to the code to justify re-compiling, we as a group figured we could have a semi flexible game idea that allowed for constant modification and testing when a new idea was formed.  The only issue we had was which scripting language would we want to use?

Now, we planned on using scripting to cover the majority of our workload.  This would include using scripting for things such as previewing character animations, testing level design layouts and concepts, as well as previewing different mechanics for our game and how they would function in code.  Since we knew this all had to fit within the abilities of what our scripting language was capable of, we needed to make the smartest decision.  In class, Dr. Hogue outline many of the different languages used today.  The list was as follows:

• Lua
• Python
• GameMonkey
• Squirrel
• AngelScript
• SpiderMonkey
• Ruby
• Gmae Maker Language
• Unreal Script

Needless to say, we had a tough choice to make.  Since our programmer James was going to be using the language the most, we first and foremost wanted to be sure that he was comfortable working with the language we chose.  So, after careful deliberation and a some time looking into each language, we all settled on the decision to use the Lua programming language.  

   

Even though it is not the most exciting Logo

Since we were starting with a fresh new language that we had little to no skill in, we decided that our first task should be to find suitable knowledge sources to use.  As it would turn out, the Lua website provided many of the resources we needed.  In their documentation section, the website provides many sourced written documents, including topics such as the implementation of Lua and the design of the programming language as a whole.  These sources were a great benefit for us, as it gave the team a starting point to work from.  When it came to specific problems we ran into with production involving Lua, Youtube came in to save the day.  Many users have uploaded visual demos, that helped us to work through our problems, when the documentation did not cover the issue, or was too difficult for us beginners.

An example of an issue our team came across very early on in the use of Lua, was the lack of libraries being included in the Lua pack itself.  Without these libraries, there would really be no use in using Lua, as it would not properly run and compile.  So, the team was faced with yet another choice.  Do we attempt to create our own libraries, or do we seek out a 3rd party one to download?  While discussing this among the group, James was able to put the issue to rest by locating a pack of Lua libraries that would successfully run and compile our scripts.

Although it seems like a lot of work to learn and implement scripts into our games for the year, it has truly proven to be an invaluable resource.  Not only has it saved the team a substantial amount of time compilation wise, but it also allows us to rapidly implement, test and either scrap or keep new ideas for our game.  The benefits have far outweighed the cons and I am greatly that this knowledge was included in the teachings for our Game Engines class.