by Annie | May 11, 2011 | Game Design
Remember these logic puzzles? You’re given a brief story and a few seemingly unhelpful hints (e.g., Wanda’s partner doesn’t like roses), and then you have to proceed through the hints, crossing off the non-solutions until you arrive at the solution. Lately, I feel like I’ve been working through a logic puzzle, only in script. At first, implementing Chip’s animations seemed easy. We only had five animations: walk, jump, throw a ball, hang by his chin, and die. Sounds easy enough, right? That’s what I thought too. Very quickly, I realized that these animations weren’t mutually exclusive. Chip might jump and throw at the same time, making for a very twitchy looking Chip. Back at the animation boards, we knew we had to separate out Chip’s body parts in order to run simultaneous animations. But which body parts? And from which animations? Here comes the logic puzzle. Regardless of what Chip’s doing (walking, jumping, etc.), if he throws a ball, the throw animation should play. So first and foremost, his arm needed to be a separate piece. Next came the more nitty gritty. When Chip is jumping, even though he’s also moving forward, he’s no longer walking. Similarly, when chin hanging, even with forward inputs, Chip should not be walking. And above all, if Chip is dying, he shouldn’t be doing anything else. After a few days piecing it all together, Chip has come alive and is now quite...
by Annie | Apr 13, 2011 | Game Design, Illustration Station
To say I’ve learned a lot about scripting over the past several weeks is an understatement. I’ve gone from struggling to create basic character movement to creating functions that can “think” on their own. But most of all, I’ve learned that programming is not just about working hard, but more importantly, about working smart. One of my recent tasks has been to design and implement a level select map. After plotting the levels on the map, my first instinct was to script the individual events for each level. So, for example, if level 3 was just completed, the spotlight for the next level would need to go on the level 4 marker. If Chip is on the raft between levels 3 and 4, he can go to the right for level 4, get back on the raft and go left for the bonus level, or get on the raft and go up to get back to level 3. But he would not be able to go past level 4. As you can imagine, the list of conditionals and events needed for each spot quickly grew quite lengthy. The solution? Work smart. I stepped back and analyzed the commonalities amongst the different stopping points on the map. Chip would need to stop at level markers, but also rafts and corners as well. But he would only be able to launch into a level while currently standing on a level marker. As the patterns started to emerge, I was able to formulate functions and algorithms so the code would work for me, rather than the other way around. It didn’t come without...
by Annie | Jan 19, 2011 | Game Design
Did you know that the first software bug was an actual insect? Indeed, in 1947, Grace Hopper found a moth trapped in a relay of the Mark II at the computation laboratory at Harvard. And people have been debugging ever since. As we prepare for our final game projects, one plan we must prepare is a testing plan, complete with an estimate of the total number of bugs in our game. Wait a minute. Estimate the number of bugs before the code has been written? Seems like a prophecy waiting to be fulfilled. Why not just write code that’s bug-free? While this did occur to me, I imagine that most seasoned programmers would laugh in my face. Programming is a combination of trial and error, critical thinking, and on-the-fly problem solving. Throw in some time constraints, changing requirements, and evolving ideas, and things are bound to get hairy pretty quickly. I guess all I can do is brace myself and code...
by Annie | Jan 18, 2011 | Game Design
You know how some people seem to have a knack for languages? They effortlessly learn new terms, nail pronunciations, and possess a seemingly limitless memory. I am definitely not one of those people. My first language was Mandarin. I’m told I was quite the talker when I was little, telling stories to strangers left and right. I could read and write over 500 Chinese characters by age three. Of course, most of that was lost when I moved to the U.S. at the age of four. Nowadays, I can barely guess my way through a simple newspaper article. I went on to study Latin all four years of high school, progressing through advanced classical texts and nabbing prizes in Latin exams and competitions. Now? I can barely remember what carpe diem means. In college, I decided to give Mandarin another shot. I was still fluent in speaking and listening but struggled with reading and writing. A few courses later, I was writing essays and reading short novels. But as with before, as soon as those courses ended, my memory of the vocabulary quickly dissipated. So how does all this relate to games? As a game designer, I’m constantly learning new languages, not only in terms of new game mechanics terms and design vocabulary, but also in terms of different scripting languages. I am by no means a great programmer, but I can say unequivocally that I love learning scripting. I find an unexplainable beauty in the process of breaking down the most complex events and actions into simple if/then statement building blocks. While world languages may be based on verb...
by Annie | Dec 14, 2010 | Game Design
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...
