by Annie | Dec 2, 2010 | Game Design
No one gets a game right the first time. Why? Because what you envision to be fun is often quite dull. The difference between good and great designers is the willingness to let go of the original vision and iterate again and again for the good of the game. For the past three weeks, I’ve been working on a top-down shooter using UDK. Though the main premise of the game – the fact that it’s top-down and that you shoot things – remains intact, pretty much every other factor has been changed and rechanged. Here are some of the various changes the game has gone through: Version 1 In this version, you control a colored circle and must shoot circles of other colors. You can collide with other circles of your own color. Some circles are one solid color, and others have a different colored core. If you collide with circle whose outer ring matches your color, you change into their core color. For example, if you’re green, and you collide with a circle that’s green on the outside and yellow on the inside, you become yellow. Version 2 In the previous version, the game goal was unclear, so in this version, the addition of navigation toward a certain location adds elements of strategy. Along your path, there will be obstacles of certain colors. Thus, you must ensure that your circle is a certain color at certain times. For example, you would have to become blue to go through a blue tunnel. Version 3 Instead of navigational obstacles, make the colored circles themselves the obstacles. The game is now...
by Annie | Nov 22, 2010 | Game Design
Okay, so maybe game design doesn’t have trenches per se, at least not the same as in teaching, but as students, we’re definitely on the frontlines. Just ask any of the guys in my class who have pulled all nighters at school, alternating between Red Bulls and naps on the floor, eager to add in that extra feature or refine the core mechanic just a bit more. On second thought, I think this counts as trenches. After hundreds of hours spent designing, scripting, and testing levels, I can safely say that I know a bit more about level design than I did when I arrived in Vancouver 6 months ago. Here are a few lessons for the road: 1. Put railings on things. As it turns out, players don’t particularly like to fall off the edge of your level into the abyss of nothingness for no apparent reason. Just like in real life, virtual navigation requires railings, gates, and appropriately sized stairs. Now you know. 2. Think before you script. It’s easy to get lost in a sea of code, coming up with “creative” and often unelegant solutions to simple problems. Always script with a plan. Break down your goal into the base components, then link them together in logical ways. Use your brain. 3. Save often. Save progressively. Save progressively often. For my last level, I made well over 100 progressive saves over the course of five weeks. Not too bad, but I’m already on version 22 just 2 days into my current level. Why? Because you never know. Undos are not always as reliable as you think,...
by Annie | Nov 12, 2010 | Game Design
3am the night before our latest UDK level was due, half the class was still in the classroom. Most would stay overnight, camping out at school from 9am Monday through midnight the next night. Five weeks may sound like a long time to complete a 5-10 minute single player experience, but when you have to create everything from the concept and layout to mechanics and scripting from scratch, even ten weeks sounds like a tight squeeze. My Factory Frenzy level has certainly come a long way, from the original puzzle idea when I was first learning kismet, to the tentative cell diagram, and finally, to the finished level, complete with cinematics, sound effects, enemies, and a boss puzzle. You start the level by taking a helicopter ride from an island to a nearby factory. You’re prompted to shoot the colored panels to get through the factory. You soon encounter enemies, lit up with red lights. As you shoot them, you neutralize them, turning them green. Eventually, you make your way to the main assembly line area, where you start in on the first puzzle. You must stand on the moving platforms of the conveyor belts to shoot the panels of the same color, all while dodging enemy fire. Be careful though – the enemies in this area don’t stay permanently neutralized; after a certain period, their green lights blink, and then they reactivate and turn red again. After shooting all the colored panels in the required sequence, you progress to the boss puzzle, a Simon Says game of sorts. You must remember the codes you’re given in order to...
by Annie | Nov 5, 2010 | Game Design
How does virtuality differ from reality? In reality, we may or may not remember everything that happens. In the virtual world, we can track, record, and measure every single action, choice, and event and thus reward players appropriately to effectively manipulate future actions, choices, and events. In his TED talk, Tom Chatfield outlines 7 ways games engage the brain, which can be applied to every field from education to the business world. Take a...
by Annie | Nov 4, 2010 | Game Design
The first time I heard of a game designer working on enemy AI, I thought, pfft, how hard could it be? Throw some enemies in, make them go places, and have them shoot things. However, in reality, the process is turning out to be much more complex than I’d originally anticipated. It turns out that enemies are pretty dumb. Essentially, they’re pieces of furniture in a game that can move around and do stuff. Only, they don’t inherently know how to do anything. Without a brain, they need every action, every behavior, every simulated choice to be explicitly programmed into them. Want an enemy to move around? Well, where should they start? Where exactly should they go? How fast should they move? What if they run into something or someone along the way? Should they continue running in the same loop, or should some action cause them to change their movement? The more questions that are asked and answered about an enemy, the more seemingly sophisticated he’ll be. Here are some of the enemy AI components I’ve been fiddling around with in my latest level: Movement This involves placing specific path nodes to tell each enemy exactly where to go, when to go there, how quickly to get there, in what order to move to the path nodes, and how long to continue in this pattern. Basically, path nodes serve as enemy bait, meaning each enemy needs several path nodes to keep them busy and make them appear like they have half a brain. Firing patterns Each enemy needs a weapon and specific directions on how to use it....
