Poo Bear - Mr. Robot Programming
We Just Clicked...
Stopping any sound effect sample at the wrong point can always generate a popping noise. What I normally do is fade a sample out over a few frames rather than stop it immediately, which seems to do the trick. However, we came across a problem with a fews samples - during normal playback they would loop perfectly, but now and then we could hear a popping noise. It turned out that this was caused as the sample started up; because the sample wasn't at zero amplitude at the loop transition, on start it would go from nothing to high amplitude instantly and cause a pop - even though it otherwise looped perfectly. We had to fix this by changing any sample loops to transition round zero amplitude.
HIGH AMPLITUDE TRANSITION: This loops fine during playback, but clicks when it initially starts up.
ZERO AMPLITUDE TRANSITION: The sample now loops and starts up without clicking.
The Dark Side Of Scripting
Scripting allows you to control the flow of the game via extrenal text files containing Lua script. This means you don't have to re-compile the game code to change something. Great. A scripting language is said to be "higher level" than C++ which in itself is higher level than C or assembly or machine code. What that actually means is it takes less code at each higher level to do the same thing and you move away from the hard details of how something is done and begin to focus instead on what you want. The result is code that gets slower because you are relying on the compiler or other libraries to interpret what you've asked for and actually do something. So an assembly language program might require a thousand lines of code to do something, whereas a script might do it in two lines, but the assembly language version could be 10-100 times faster.
Of potentially greater importance is the time to get something working. There is a saying, if you have written more than 50 lines of code then there will be bugs and the chances of you finding every single one fall rapidly as the number of lines increases further. I've seen one example where an application was written in C++ and took 2 years to build with 100k lines of code. Soon after it was scrapped due to the inability of the authors to properly maintain and extend it. The app was redone using a scripting language in 3 months and only 5k lines of code. As the application's speed was not an issue the scripting language was more than up to the job. As computers get faster and projects get larger the speed disadvantage of scripts disappear, far outweighed by the ability to get things done quickly.
Scripting languages are also far easier to extend than C/C++ because they are typeless. What does this mean? Well typed languages like C/C++ require you to say exactly what all your variables/data are and what should be done with them before they are used. This means you end up with lots of bits of software that only work when connected to specific other bits. So you cannot just take something out of one game and use it another because chances are it relies on other bits of the current game to function and it only connects to other bits of the current game.
Scripting languages are also platform independant because they work at such a high level that they don't care about the underlying hardware. C and C++ do care about the hardware and great care has to be taken if you want to get things working on another platform.
So scripting languages are great then?
Well, not quite. Scripting languages are best described as glue. Strange term. What I mean is they cannot really do anything on their own. You have to write code in C/C++ called components, these are tools that actually make something happen i.e. display a button on screen, move your character, etc. The scripting language can glue these components together and coordinate them to make things happen. Like a conductor in an orchestra. Scripting languages aren't really setup to define complex objects, only control them. Unlike C/C++ which has powerful compilers, built in mechanisms for managing complexity and sophisticated debuggers.
So anything complicated, time critical or hardware specific cannot and should not be done in a script. All those tools need creating in components that the script can call. It's very difficult to keep your scripts small and you will very soon have a large component tool kit that quickly get out of hand.
Scripts aren't compiled like C/C++ they are loaded and executed when needed, which is both a blessing and a nightmare. Simple errors that are unavoidable only show up when the script executes. If that means travelling through 50 rooms to get to test the new one only to find it crashes due to a simple typo then you can waste a lot of time.
Scripts are typeless meaning any variable name can represent anything and there is no compiler to check what you are doing. So if you simply spell something wrong then the script interpreter will assume you want to make a new object. This object will then be automatically set to some valid default state (like zero or nil) and then everything will happily continue as though nothing is wrong. Half the time this causes a crash and half the time it doesn't, you'll just get behaviour you weren't really expecting and no obvious explanation.
Add this to the fact you have no debugger to check what is going on and you can get in very deep trouble very quickly.
It wont be too bad surely?
Still, the scripts are meant to be small and light, I'm a programmer so I know what I'm doing. It wont be too bad surely?
Part of the big attraction of scripting languages is they allow changes to be made to the game without a recompile. That implies you don't really need the programmer writing the script, I mean if I'm writing all the script why don't I just do it in C++? So now you have a very delicate error prone system being used by non-programmers. I would hope any programmer reading this would now be very scared.
It isn't all doom and gloom though:
- Make sure you spend a lot of time thinking about how you will debug scripts and how you can bullet proof them.
- Put a system in place so you can execute any new scripts as easily as possible i.e. a special menu that lets you skip to any point in the game, etc.
- If non-programmers are using the script then try and find tech-savy people, write very good documentation, test regularly and make sure these people stay with the project until the end as their experience is priceless.
- If a script has more than 50 lines in it then look at it very carefully because you probably need new component tools or to rethink the ones you do have.
Plus, even if the programmer is writing everything it is still worth considering scripts. Hard coding things into the game will have a tendency to make the game inflexible, it doesn't have to be that way, but its difficult to stop it happening. As soon as you start using scripts the tendancy will switch and it will feel easier and more natural to create flexible systems. The game becomes "data driven". This means you're creating the intruments not the econductor, he is sitting outside the game code in all those script text files. Scripts are no easy option or silver bullet, embrace them but be prepared!
What about the future?
Windows vista will ship with C# built in, this is a very powerful scripting language Microsoft created. They will also integrate it with Visual Studio which means it should have a powerful debugger just like C++ does now. C# also contains object orientated functionality like C++ which means it does have the ability to express and manage complex systems directly. It can also communicate with DirectX. All this means you could write your entire game in C# and it would run perfectly well. In theory that means you can get the same game in less time, wouldn't that be fantastic. Bear in mind that vista demands and encourages more powerful PC hardware i.e. it's a 64bit operating system with much better support for threads so all those 64bit dual core cpu's will finally get to stretch their legs properly.
There is also an update (will people see it as that?) for C++ called D, it takes a lot of advanced features from the standard template library and integrates them into the language, as well as doing away with explicit memory management by including a garbage collector. On paper it sounds great and when I heard about it I was surprised it hasn't been picked up by Microsoft or GNU and pushed harder (perhaps there are copyright or patent issues). The current implementation can call into C functions so it doesn't mean throwing all your old code and libraries away. It would be easier to use if you could call into C++ code too, perhaps that will be added one day. It is already in serious use too, I believe the new space station manager game shorthike is being developed with it, amongst others.
Digital Mars D
Fost - Mr. Robot Art
As seen last month in placeholder art form, here's the final Hub Room (hopefully an improvement ;) )
We always thought it was important for the hub to be something special, and so every piece of art used in the hub is unique - you could even make a zone out of it if you wanted. Also all the control panels have little animated sections embedded in them. Some things just put a smile on your face when you see them, and all the robots walking around in the hub do that for me :D
We are also starting to use overlay decals on the floor all about the game. These use a 'modulatex2' screen blend mode - basically grey does nothing, white doubles the brightness of whatever is behind it, and black goes black. We can drop these all over the floor to break up the regular patterns a little, and because they use a multiplicative blend mode, they work with whatever lighting is affecting the scene behind them. In the hub they are used to put the Eidolon Insignia on the floor, and zone symbols next to the doors. I'm working on more signage for the rest of the ship - it's something I've wanted to do for many years (wow, I'm sad!) after I saw the fantastic amount of background detail Ron Cobb put into the ship signage for 'Alien'. Ron Cobb has to be my favourite designer of space ship paraphenalia, and he's been a huge influence on me.
This month's mini development tip - Since identifying one of my biggest time losses as being the act of finding files I need on my machine, I've discovered a quick way to get through files alphabetically. When browsing a folder, I always knew you could press any key on the keyboard to skip to that letter, but what I didn't know was that if you press another key quickly enough, it will skip to the first file beginning with that two letter combination. E.g: if you were searching for a file called 'needle.tga' you would press 'n' and 'e' quickly. Great when you are trying to get to one file in a folder full of hundreds. Probably been in Windows since win3.1 and everybody knows, but it was news to me :)
The whole mindcore zone is now starting to look extremely flashy, blinky and stroby (if that's a word :) ). I really wanted to give the mindcore the feel of the ghost hack rooms; since this is where the two games finally come together. So that means lots of time spent fiddling about with texture animation and vertex shader values. we aren't doing anything particularly clever here, just lots of multi-layer texture scrolling combined in different ways. Take the following wall section from the mindcore as an example:
- click image for flash anim...
All the animation is created by scrolling this sinewave texture:
horizontally through the model. The texture is scaled massively along its horizontal axis (u) and scrolled incredibly fast. Each vertical bar is offset slightly and scaled differently so they all flick at different times.
Ghost Hack Sentinels
I've finally started to work on the enemies on ghost hack. They all use lots of morphing animation and texture animation (pretty much like all the backdrop scenery in ghost hack), so they take quite a while to make. Since we are supposed to be inside the ship's computer in data form, everything is represented by abstract shapes, including these attack programs which act like antibodies; cleansing the system of any unwanted intruders (i.e. you :) ). Here's some animations of the current 'wait' states of the models.
*Note: You can click on the pics for a flash animation, but, you'll have to excuse the occasion 'flick' in the animation - whilst the models loop in game, it's impossible to line everything up for a perfect looping video.
Controlled Specular Highlights
For a while, we've had a problem where specular lighting doesn't work in the game, but does in the viewer. It turned out to be the camera position being passed through to the vertex shader differently. Now specular highlights are in, I've gone through and re-exported all the robots so they have an alpha map that controls the reflection. In today's world of self-shadowed normal mapped per-pixel lighting this is a pretty aged technique, but I've always liked having the ability to separate out the specular lighting and control it using texture alpha. You can get a kind of controlled metallicism, and it can all be done in one pass. Basically we are now doing:
Stage1: diffuse lighting, Modulate2x with the texture. Pass through texture alpha to the next stage.
Stage2: specular lighting, modulatealpha_addcolor with current.
So, the texture alpha controls how bright specular highlights are. I think there may be some really old cards that don't support 'modulatealpha_addcolor' mode, but they are pretty much prehistoric. :)
Pretty subtle result, but I like it, you probably can't see a massive difference in the shots, but it looks best in motion.
Specular Control Map
Without Specular Highlights
With Specular Highlights
I've constantly been surprised how well the lighting has turned out in Mr. Robot; now that it's possible to use high polycount models, there's far more subtle light differentiation across a mesh.