     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Playing TAGD: The Texas Aggie Game Developers' One-Week Game Competition [The games introduced in this Student Feature are available for free download at: http://www.gettagd.com/file_archive.php?projectid=8] Introduction Allow me to introduce myself - my name is Lars Doucet, and I'm a member of the Texas Aggie Game Developers. We're a Student Organization at Texas A&M University in College Station, Texas. From our website [www.gettagd.com]: "Realizing that getting a job in the games industry with solely a degree in Computer Science was simply not realistic, this organization was established by Jacob Foshee to help students learn and gain experience in game development." The majority of the members are Computer Science or Engineering majors (with a handful of Architecture majors). Most of us are undergraduates, too. Against all expectations, we also have two three (!) female members who show up regularly of their own free will. Most importantly, we aren't getting school credit for this, and have to find the time to work on this stuff in-between studying, life, and work. It has become clear to us that the only way to learn game design is to do it. Even if our school were to offer game design courses, I have my doubts as to how good they would be. There's no teacher like experience, and game-industry internships are hard to come by. TAGD's focus so far has been attending conventions, and working on our annual "Big Game" project. We've worked on 3 "Big Game" projects so far, where members of the club work on one big team project from start to finish. The first two were rather spectacular failures, but the third one, titled ...And then the World was Consumed by Monsters, was a success, in that it was a complete, functional game. We also entered it in the Student Showcase of the Indie Gaming Festival! We didn't receive a lot of praise or attention, but we'll just see about that next year... (we'll get you, USC, and your little Cloud too!) We've found, though, that "Big Game" projects aren't enough. Monsters was a technically complete game, but it was kind of a bland experience, which is probably why we were overlooked by the judges. We needed something to give us a shot in the arm, transforming more of our members into active participants, something to encourage experimentation and learn design in a hands-on way... Something like the “ One-Week-Competition.” The Competition The one week game competition idea was rather simple: "you have to make a game in one week. This means you must only use libraries or small utilities and create a new game, you may not use preexisting game code and just tweak a few things." There were $200 dollars in prizes (half donated by Microsoft, half from TAGD) for the top 4 games, the winning categories being: Technical Challenge, Most Fun, Best Overall, and the Audience Award. The judge for all awards besides Audience was Jacob Foshee, our club's founder, who has since graduated but keeps in touch. The competition's goal was to get some energy and creativity flowing early in the semester; also, this would be the first time many club members had actually finished a game of their own (an indescribable feeling for first-timers!) This competition encourages people to go out on their own and get their feet wet instead of waiting for the club to tell them what to do on the next "Big Game." In the end, about a dozen people worked on their one-week games, but only seven were functional and working for presentation on the day of the competition. Of these seven, one unfortunately didn't run on most machines and was therefore disqualified. That left six solid entries, which I will briefly mention here, and which are downloadable from our website if you'd like to check them out in more detail. The contestants are:
Fortitude People who worked on game: Danny Dyer
Game Concept: "You must carefully stack blocks that fall to build up a tower that will protect your cannon. When the blocks stop falling you have to aim and try to hit the other cannon. You only have one shot at a time, so aim carefully." Thoughts: Danny built this game in a rather short time with interesting results. His goal was to implement some basic physics but without the usual headaches that such technology usually involves. As for the graphics, Danny says, "of course 3D. For some reason I seem to always stray towards doing everything in 3D with shaders ... I guess that's what I'm comfortable with now." This is interesting, as Danny was the only one to make a 3D game (at least, the only one who actually finished one). In terms of what succeeded, Danny's game is complete and shows off all the intended gameplay. As for what didn't succeed, Danny says, "The gameplay wasn't very balanced and the controls just didn't feel as tight as I would have liked." In my opinion, Danny's game was a pretty big technical challenge for a one-week game. I personally feel that the 3D aspect was a detraction and made the essentially 2D gameplay difficult to visualize and execute. (If you've ever played the 3D version of Scorched Earth, you know what I mean - it's hard to visualize artillery trajectories in 3D). It might have been more successful if it was done in 2D, and might have taken less time to finish. Danny told me that the reason he used the PhysX SDK was that it let him use a pre-built physics module, thus decreasing the time necessary to spend on that aspect of the game. He mentions the hardest thing to do was trying to keep from adding "cool features," and just stick to the basic functionality and keep working on it long enough to finish the thing, a problem most of the contestants mentioned about their respective entries. In the end, his project was the most technically ambitious of them all, as everything else was a straight-up 2D game. He also had a technically complete and functional game, so Jacob decided to give him the Technical Challenge award for going out on a limb and taking a risk. The Adventures of the Compacting Garbage Collector People who worked on game: Luke Wagner
Game concept: The game is "...loosely based on the concepts of garbage collection and the user experience of a frozen process." The game models a garbage collecting algorithm trying to clean up the mess left by an inefficient Java program. The player controls the garbage collector, manifested as a little tractor-like machine. You move around a grid of blocks representing your program's available memory. A distant, god-like "user" will occasionally start using memory blocks, and turn them green. When the "user" is finished with them, they turn into little trash cans. You can push trash cans together and then draw a line around them to clear the garbage and free up that memory again. However, as long as you are drawing that line, the "user's" program freezes and he starts to get irritated. But if you don't clean it up, the garbage accumulates past a certain point, and that starts to irritate him, too. You must balance his impatience with freezing the program so you can clean up garbage, and his irritation with living in his own filth. If his program stays frozen for too long while you work, or if too much garbage accumulates, the "user" gets fed up and your game ends. Thoughts: This is a great little title, as it is a really cool model of a computer process many of us take for granted, and in that sense is almost "edutainment." (As well as a bit of an inside geek joke) Luke says about his game, "I wanted to let the user understand just how frustrating it is to clean up after someone who will not, for the life of them, properly dispose of their trash." The crunch time made it difficult to achieve masterfully thought-out code hacks: "When your development schedule is 2 days, careful use of OO analysis and design loses its importance." This game succeeds in that it is actually a fairly deep little strategy game (especially for a one-week title!) and, unlike some of the other entries, can be played for more than a minute without losing interest. This game is the sort of thing I could see being packaged with an operating system and loaded up whenever I feel like reaching for Solitaire or Minesweeper. It seems the game's main feature was also its greatest challenge to design - "hardness of the game, speed of play, skill required, and fun, all hung in a delicate balance determined by a bunch of parameters. I found it difficult to give fast and exact gameplay, as one would reap from other simple games, without making it ridiculously hard." says Luke. With another week to work on the game, Luke would have liked to extend the metaphor of garbage collection, potentially demonstrating generational garbage collection, "since that's what's realistically being done today." GravShot People who worked on game: Landon Gray
Game Concept: The idea of GravShot is similar to the classic QBASIC game Gorillas or Scorched Earth for DOS, but with a twist. Each of you controls a little world with an enormous planetary cannon. The two planets are on either side of a huge asteroid field, and are trying to hit each other with their inter-planetary artillery. You input angle and velocity, and your cannon fires away. However, the twist is that the planets and asteroids have gravity that affects the trajectory of your munitions and bend its path as it flies. You have to visualize how the gravity will affect your shots so that you can navigate the asteroids and get your weapon to hit your opponent. Thoughts: Landon said his goals were two-fold. "First, I wanted it to work and be reliable. Second, it had to have replay value with random environments. The math was pretty simple so I had more time to work on graphics, which ended up more comical since realism would be too [time] consuming. I kept referring to the style and simplicity of Worms in the end." The game was well-received, and is lots of fun to play. I've seen similar games, but I don't think Landon was aware of their existence. Also, this one has a lot of things to like about it in particular - the theme and graphical polish really brings something out. (I believe that a well-executed theme is essential for games that are otherwise entirely abstract.) The game has a lot of replay value - you can literally play it for hours; it's got that "just one more game!" effect, when you try and get revenge on your friend for that unbelievable shot he pulled off last turn. The hardest thing for Landon was programming and design (keeping in mind that Landon is also an artist, so artwork isn't particularly difficult for him). Says Landon: "Maybe because of using Actionscript, the debugging and tweaking ate up most of my time before I even started the art. Having a good design and gameplay plan from the beginning would have helped with the programming and art content."
Landon was surprised by "How good I became at my own game. Without cheats installed, I had to test out scenarios over and over, learning patterns and loopholes in my design." GravShot was Jacob's favorite game. He awarded it, "Best Overall."
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Introduction
Features
|
|
|