Most of us play countless games every day, but rarely do we get to see the bones behind a game, the gears that make a game run.
UDK predominantly uses visual scripting in the form of kismet to trigger events in game. For example, you can use an actor factory node to spawn enemies in your level or a teleport node to instantaneously move things around.
Chromattack consists of hundreds of such nodes responsible for spawning enemies, attaching objects to them, having them move on various paths, and enabling them to take different types of damage at different times. Then there’s additional scripting for random floor tile colors, camera movement, and player abilities like shooting and speed.
Here’s a closer look at some of the simpler pieces of kismet behind Chromattack:
To create each enemy, I pass several objects into a sequence called “CreatePawn.”
Inside the CreatePawn sequence, I use the external variables to execute a variety of events, including attaching objects to the enemy, checking when they get hit, and playing sounds and particle effects.
Here’s a close-up of the section that checks for when the enemy takes damage. When the enemy takes a certain amount of damage, check if the enemy is on a floor tile that matches its color. If so, kill all the enemies on screen. If not, kill just the enemy itself.
In addition, each enemy needs to move to random locations at different times. The movement sequence is triggered immediately after each enemy is created. The enemy chooses one of three possible speeds, then picks a random destination and repeats the process.
After hundreds of hours spent scripting in UDK, here are a few lessons I’ve learned:
1. Logs are your friends.
Unlike Unity and Visual Studio, UDK doesn’t always throw up error flags when you do something wrong. If you send it on an endless loop, UDK will likely yell at you, but otherwise, it will follow your instructions without complaints. This is good and bad. Good because you can jump into the level right away and see the results of your scripting. Bad because you don’t often know exactly what went wrong and where.
The solution: logs. When scripting, I’ve learned that I need to log as much as possible to “see” what the code is doing. You can’t always tell exactly what the computer is thinking and trying to do just by watching things happen in your level. Logs are like x-rays for your code, exposing it for what it truly is.
2. Creative solutions are a must.
It’s easy to design a cool mechanic but much harder to implement it well. Though UDK offers a wide variety of options, some in-game events require creative scripting. For example, to create the top-down vertical scrolling camera in Chromattack, I attached the camera at a certain offset to a bot off screen and had the bot run on a very long path. Every so often, the bot would hit a trigger, thus moving certain floor tiles from the back to the front and reassigning them different colors. Creative solutions.
3. Organization is key.
With hundreds of pieces of code, organization is key. Comments and labels help tremendously. Spending just a day or two away from the code can make you completely forget why you did what you did previously, which means you spend precious time trying to re-figure out something you’ve already done instead of spending time coding something new. It’s happened to me, and I can assure you that it’s no fun.