I’m planning on implementing a scripting language in Unity. Insane right? Unity already comes with effectively three scripting languages - doesn’t it?
Yes. Yes it does. But what I’m planning on implementing is something far more high level than the C# and friends that power unity.
To get some idea of what I am talking about I need to go historic.
Back in 1993 I joined a UK Game Dev called Argonaut Software. They were famous at the time for pushing 3D games with the original Starglider and Starglider 2.
Soon after Argonaut started working with Nintendo on something special. That something special was a game called Starfox and the Super FX.
This relationship meant that some of the programming/tech guys got to go out to Kyoto and work with Nintendo.
This was a time when Japan was way ahead of the rest of the world in terms of game design. For years they had ‘Planners’, whereas in the UK the industry grew up on games made by a coder and sometimes an artist. For the Japanese, having planners on their team meant that they had members of the team that were purely focused on what the game should be and how the game should play.
Dylan Cuthbert was one of the programmers on the original Starfox and was also finishing off Starfox 2 at Argonaut’s London office. It was here that I first saw the scripting language that they used for those games.
It was one step up from Assembler. From what I remember it was a series of three letter acronym and values that ran in sequence to control the flow of the levels and the individual objects. I can’t remember if it was compiled but since it was so close to Assembler it probably went straight into some kind of byte code interpretor.
Being programming savvy, but not what I’d consider a real game programmer, the scripting language (or Strategy Language I think it was called) appealed to me because I could have direct input on the game without having to have written the engine.
For the next few projects we implemented increasing sophisticated ‘Strat Languages’. Creature Shock DX (apologies to the 12 people that played this) took some of the concepts of Starfox Strat Language and started to bring them into a more high level language. This all culminated with the development of Croc for the PS1.
Croc had a pretty sophisticated Strat Language that powered every object in the game. For the first time everything from ‘Croc’, right down to the Crystals he collected was written in ASL (Argonaut Strat Language). It was a high level language that was very readable and very designer friendly.
ASL (and the ‘Croc engine’) powered a bunch of games at Argonaut from Croc 2 to the Disney games we did and ASL went on to integrated into the PS2/Xbox engine that Argonaut. By the time Argonaut Software came to an end a very sophisticated version of ASL was being used in both Catwoman and I-Ninja.
A few years later I was working on a FF7:Dirge of Cerberus - Lost Episode for Square Enix over at Ideaworks3D in London.
Being their first ‘non-port, non-driving game’ project we didn’t have a lot of tech to build the game on. Knowing we needed a scripting language we decided to build on top of LUA. LUA was great because it meant we didn’t have to create something from scratch to deal with all the standard programming stuff like loops, variable usages etc. We also built tools on top of Maya to turn it into a level editor for the game.
A LUA/Maya combination was also used on the Clone Wars project I did over at Lucas Singapore.
This brings me to Unity. Unity is essentially a streamlined version of the tools we used on Dirge. The missing component is the inclusion of a high level scripting language, tuned to dealing with game play. Simply put, a game script deals with fundamental things such as:
- Setting game states
- Setting trigger events
- Responding to input
- Moving characters to relative positions
- Moving characters along paths
- Setting up and controlling different types of collisions
- Setting camera positions
- Spawning Objects
- Handling death
etc.
Here’s what a script that sets up a small cutscene at the beginning of a level might look like:
function introCutScene()
setCutSceneMode(true)
wait(2)
setCamera("CameraAnim_Intro")
cameraSetTarget("CameraAnim_Intro", player)
textBoxMessage("Come with me if you want to live...")
wait(60)
textBoxMessage("Not likely Mister")
wait(60)
setCutSceneMode(false)
playAnim(player, "Idlenoaim", true)
setPlayerControl(true)
}A script that controls a game level looks a lot like an extended version of this script. Simple put, it’ll wait for a player to trigger something in the scene and react with a small amount of script. This could be a collision box trigger in the scene or an event like killing 100 enemies.
A good example of a somewhat arcane scripting language is Pokescript, which has allowed Pokemon hackers to experiment with creating their own Pokemon games.
History lesson over, I still need to answer why I’d want to build something like this in Unity?
For me there’s three sides to game programming. The first is the engine. This is the code that deals with rendering the scene, lights, textures, sound, input, IO etc. That’s Unity.
Second is the game code. That’s code that uses the engine to make game specific stuff happen. For example any special physics you need, or implementing code to deal with a context sensitive input or path finding for example. Basically the code that is the foundation of your game. Unity also does a great job in providing the tools to make the game code.
Finally you have the code that delivers the game experience. The enemy AI, the scripted events, that platform that simply moves up and down. Now - Unity does all this, but I feel more comfortable with a level of abstraction.
See for me, even though these three elements all work together I always see them as different boxes. If the game engine is working - great, don’t mess with it. If the game code is working - wonderful, leave it alone.
With those two in place you are free to input into these fully functional boxes with your game scripts. Here you’re directly working with the scene and writing bits of code to make it come alive. That’s where the designer in me is most happy.
The great thing about Unity is that I don’t have to be an engine coder. I only have to be a bit of a game coder. And with a simplified scripting language built on top - I can be all designer and have a reusable game engine that is focused on making fun.
To be clear - I’m not talking about anything more than a series of simple functions written in C# that are focuses purely on scripting events in the scene. It’ll simply be a reusable library that will allow me to be a designer again - not a programmer.
I’ll let you know how I get on.
