The theme of the Global Game Jam is no longer REDACTED, it is DECEPTION. We've got 8 teams all of whom have been very creative in their application of the themes and constraints to their game designs.
Our games (titles only - I don't want to accidentally spoil them with a lengthy description):
Quest for Stick
Press X to Not Die
Jumble is Trademarked
The Hunt Alone
The Last Bullfight (working title)
I've been on silent running for most of the day. The Jammers here have been super-productive. Rather than bugging them with interviews, I've been stalking them, trying to capture fun moments and interesting dialog on the webcam, as well as Twitter-stalking them. Oh, and I made sure they were fed.
A few of the teams created Twitter accounts for their games. @questforstick has been posting some intricate character artwork for their Shaman and for the boss enemy, the Eaglewhale.
@RunRunRunJump has been a prolific tweeter, posting each time changes are submitted to their version control server. I wonder if the avatar for their Twitter account has something to do with the game?
@abestein, Audio Director for the GAMBIT Game Lab has been obsessed with pork products:
"Jumble is Trademarked" started yesterday with Marleigh Norton, another programmer, and this picture. The team now has another programmer, their own audio designer, this first screenshot, and puzzles!
"The Hunt Alone" already has a video!
So far, that's all the dirt I've been able to dig up on these Jammers. "The Last Bullfight" and "Define Yourself" are working just as hard as the rest, but aren't being as obvious as posting pics or videos to the Twitter accounts that I'm aware of. I'll work on 'em some more tonight and see if I can get some material to share before the big reveal tomorrow.
Our games will be available from the our site's page at the Global Game Jam website tomorrow at 3pm. We'll be broadcasting the presentations live via the webcam and post video as soon as we have it. There's just over two more hours of work left today and then I can get some shut-eye!
As the coordinator for the GAMBIT-hosted site of the Global Game Jam, I am soooo happy I get to close things down at midnight. Yay for sleep and showers!
We'll have a few videos up tomorrow, but you can check out our live webcam, twitter feeds, and all that other real-time goodness that powers the web these days on our main Global Game Jam site.
Today, we had the keynote at 5pm sharp by Ste Curran from One Life Left. It was funny and inspirational - it definitely set the right mood for the game jam. Here's the full keynote via theGlobal Game Jam's Youtube Channel.
After the keynote, we gave the teams they're mandatory criteria: the global theme, the local theme, and the constraints.
The theme for all of the sites of the Global Game Jam is REDACTED (sorry - I'll post the theme once all the other global sites get it). The local theme that Doris Rusch and I picked out for our site is 'abstraction,' specifically, that any visual elements shouldn't be directly representational of anything. The constraints for our time zone were: RAIN, PLAIN, and SPAIN. Each game had to use one element from that list.
The Jammers had an hour and a half to mull these things over while they ate pizza (the food of game jam champions!). Some thought about it on their own, some formed small groups, but by the end, we had 28 ideas pitched. After the pitch process, the Jammers started placing themselves on teams. By 8PM, after a little ca-jiggering of the teams (making sure each had enough programmers and artists to get the job done) we ended up with 8 teams working on 8 games. I'll fill in about the chosen games later on, but here's a list of the ideas that didn't make the cut (just the one-line descriptions: the full video will be available tomorrow):
Alien Language Cellphone
House of Mirrors
Dressing Up Words/Sentences
It Rains Forever
Driving Through Rain
Zooming Moorish Architecture Game
Plain (the 3D FPS)
Fire vs Rain
Can You Paint with all the Colors of the Rain
My Fair Lady
This list is definitely not descriptive enough for to understand the range of ideas and creativity on display. Hopefully the video tomorrow will fill in the blanks.
As I write this, the Jammers have one and a half hours left to work today. They're all set up in lab spaces at their workstations hammering away on some amazing game designs. GAMBIT video-wunderkind Generoso Fierro will be interviewing a few of the Jammers tomorrow and we'll post these videos as soon as we can.
This weekend only, Global Game Jam 2010 LIVE at the GAMBIT Game Lab!
The Singapore-MIT GAMBIT Game Lab is proud to present, live for you, our site for the Global Game Jam 2010, representing the best timezone out there, GST-5!
Keep coming back here for riveting footage: are they going to make a new constructor for that class, or are they just going to inherit it from the base class? How many pixels do they have going in that flash game, 640x480 or are they going to let it go full screen?
Actually... it's going to be much better than that. We have 40 people from all over the Boston metro area, from our lab at MIT, from the Education Arcade, from other schools like Berklee College of Music, and a diverse number of independent game developers from the Boston Indies crowd as well as non-indies from Irrational Games, Turbine, and Harmonix Music Systems.
What happens when you lock a bunch of creative and talented people in a room and tell them to make a game in 48 hours? Tune in and see!
Like the rest of the world, we here at the GAMBIT Game Lab are shocked by the recent devastation in Haiti. One cannot help but wonder what it will take to rebuild the community leveled by this disaster. The people of Haiti need our help now, and we at GAMBIT have a plan!
February 26-28th, GAMBIT will be hosting the 2010 Complete Game-Completion Marathon to raise money for relief efforts in Haiti. Teams of players will gather at our MIT lab to attempt to complete a game in one sitting. Participants will independently seek sponsorship on a dollar/hour basis with all proceeds going directly to relief efforts in Haiti through Partners in Health, and with support from the MIT Public Service Center. The labs will be open 24 hours a day through the weekend to accommodate the teams, with snacks and refreshments available for the players.
How can you get involved? We need players or teams of players willing to marathon through some games for charity. Attached to this email is a registration form for the event. Each team will have one designated captain, who will receive correspondence from the lab regarding the event. Teams must make an estimation of the time required to "complete" a game. Completion of the game is defined by each team and can vary depending on participant availability. For example, one team may try to finish a game's story mode, while another may simply see how far they can get in 4 hours. The important part is raising sponsorship money, regardless of the duration of each team's specific "marathon."
GAMBIT will build a schedule for the weekend based on your team's preferences for start times and availability. In cases where scheduling preferences cannot be accommodated, a GAMBIT staff member will contact team captains directly. GAMBIT has plenty of gaming consoles, PCs, and physical space. However, we cannot guarantee that we will have the game and an available system for you to marathon with, so we encourage players to bring in their own system and copy of the game for the event. If a team cannot play at the GAMBIT lab at MIT over the event weekend, that's okay! We encourage players to still raise sponsorship money and to play at home if they can. If you cannot marathon, then we encourage you to consider sponsoring a player.
The registration deadline for the event is February 12th. Registrants will receive correspondence from GAMBIT confirming their registration and helping them to start collecting sponsor donations.
For questions about the event, a list of players eligible for sponsorship, or ideas for how you can get involved, please contact Abe Stein for more information. You can also check back to this blog post for updated information about the event. Please consider joining us for this fun and important event!
Do you like lego robots from the future? Do you want to witness teams win eternal glory, and save mankind? Do you want to a robot chase another one down, capture it, and drag it flailing back to a den of destruction?
Then come to 26-100 today from 7-10 PM. Witness the beauty, the talent, the unbridled creative genius of your fellow students as they battle it out for fabulous prizes.
Maslab (6.186/2.972) is an advanced vision-based robotics class offered every IAP. Robots are tasked with exploring an unknown playing field without human intervention using vision and other sensors. Robots must collect color-coded balls and place them into corresponding goals. Students choose their own materials, sensors and actuators. The course emphasizes machine vision, AI navigation, closed-loop control and mechanical design. Teams of 3-4 students have spent the bulk of their IAPs building their robots. Come see their hard work in action!
Ever wanted to see armies of virtual robots destroy each other in 3D?
That's exactly what will be happening at the 6.370 Final Tournament on Saturday, January 30th, from 7-9 PM in Kresge Auditorium. Strategy. Cunning. Power. Maybe even world domination. Come watch some of MIT's best programmers duke it out on the big screen and grab some free food and t-shirts.
BattleCode, developed for 6.370, is a real-time strategy game. Two teams of robots roam the screen managing resources and attacking each other with different kinds of weapons. However, in BattleCode each robot functions autonomously; under the hood it runs a Java virtual machine loaded up with its team's player program. Robots in the game communicate by radio and must work together to accomplish their goals.
The first of the five video interviews with Kevin Driscoll.
In it, Kevin explains what his group was trying to do with Picopoke, who plays Picopoke, whether or not Picopoke can actually be considered a game, and why they chose to build it on Facebook. The videos aren't very long (the longest is just over two minutes, the shortest is less than 45 seconds) and they're all very informative, so go check 'em out!
I'd like to extend my warmest gratitude to Kevin for sitting down with me for the interview and for sharing his insight, and to Claxton for all his hard work and much-appreciated assistance! Oh, and Kevin, if you're reading this, appreciate the weather out there in sunny LA. Right now Boston's a big, sloppy, melty mess...
You know one of the cool things about working at GAMBIT? There's all these neat people, making games for me to play. Case in point, I just heard Ahmed Wali Aqeel, one our interns from last summer, worked on a game for the iPhone called The Shady Puzzle. For only 99 cents! So of course I bought it.
Anyone who's ever played Griddlers or the like will immediately get it. Wikipedia tells me this class of puzzle is called a "Nonogram". That's your vocabulary word for the day. You're welcome.
A cell phone picture of a cell phone. How recursive.
All in all, it's a fine little app. The puzzles are fun and well suited to the iPhone. There's some nice polish there in terms of page turn animations and such. I bought the game around 9:30am and had it completely finished by the time I went home at 5pm. Yes, I did do some work that day too, so I'd guess it took me about 2-3 hours to beat all the puzzles. Note I was already an expert in these puzzles before I started, so your mileage may vary. There's replay potential there as well, where it keeps track of your best time on solving a particular puzzle. It's been about three days, and I've beaten all the boards a few times now.
This is what the main menu looks like when all the puzzles are beaten. I am mighty. Or neurotic. Perhaps both.
A few gentle suggestions for the next version.
More Puzzles! Ahmed tells me more are coming in the next release, which is scheduled for next (this?) week.
Usability Improvements. While actually playing the game is fairly simple, there's some other interactions around it that could use a bit of work. It took me a while to figure out how to start a puzzle, for example, and I find the achievements page to be rather inscrutable. Clearly I achieved something, but what I don't know. Also, the guess feature is hard to use. Which is perhaps as it should be, since guessing is for WIMPS, but somehow I don't think that's what the developers were going for.
My fascination with Demon's Souls has spurned a quest to discover where the hell its brilliance came from. Most people say it's a descendant of King's Field, the cult first-person RPG series Demon's Souls developer, From Software, did some years ago. I have only really played one King's Field game, King's Field: The Ancient City for PS2, and not for very long. Although there is some resemblance, I think another series, one that isn't as well-known outside Japan, may be the real ancestor.
Shadow Tower was another first-person RPG series by From Software, one I'd never heard of until I began poking around the Internet. Some descriptions I read made them seem a lot more like Demon's Souls than King's Field, so I tracked them down to see for myself.
There are two games in the series: Shadow Tower for the PS1 and Shadow Tower Abyss for the PS2. I managed to grab them both off ebay and played each for a few hours. Shadow Tower is available in English. Shadow Tower Abyss isn't. This a shame because Abyss is by far the superior game, and the one that is, I feel, much closer in style, atmosphere, and gameplay to Demon's Souls.
The first game is okay. The controls are the clunky non-freelook ones common to many Japanese first-person games, but otherwise Shadow Tower does feel like a somewhat slower, awkward Demon's Souls. Weapon degradation is a major aspect of the game, and encounters with minor enemies can be pretty epic. And, of course, you upgrade weapons by collecting souls, although in Shadow Tower you actually have to pick them up as items. The importance of blocking is also another big similarity, with you being able to map a weapon to one hand and a shield to the other. It doesn't even remotely approach the sublime combat system of Demon's Souls, but you can definitely see the template being set.
The world is rather non-linear and rewarding of exploration. While I am not one to bash PS1-era graphics for being what they are, I do feel that the ones in Shadow Tower are somewhat repetitive. Like Demon's Souls there is no map, but unlike Demon's Souls a lot of environments look the same. This can make the game pretty tedious unless you are prepared to make a paper map as you play. From what I played the game seems actually less linear than Demon's Souls, with more alternate paths available.
The story for Shadow Tower is extremely minimal. There is a tower that is, er, forbidden. You go in. That's it. The games does contain some of Demon's Souls's brooding sense of silence and loneliness. (Like Demon's Souls there is no music.) The environment does seem to be imbued with some elements of narrative. There is writing you come across from past explorers, which looks a lot like the player messages in Demon's Souls, only here they are just baked in as part of the story.
One of the biggest arguments for this game being an ancestor to Demon's Souls is the intro cinematic, which features a knight getting the crap beat out of him by a variety of monsters. The game really seems to suggest a similar sense of mortality and exhausting on the part of the protagonist that was one of Demon's Souls main distinguishing features. People familiar with Demon's Souls's non-U.S. box art will remember the knight riddled with arrows, ambiguously either dead or battle fatigued to the point of collapse. One gets the sense that Shadow Tower was an early attempt to create a player experience shaped around similar ideas.
Shadow Tower Abyss is very similar to its predecessor, except that it has superior art direction, narrative design, and usability design. The real good news is that it has an option for dual-analog Western-style controls, which is something King's Field never had. In this mode the weapon buttons are the trigger buttons, and players can switch back and forth on the fly between weapons in the right or left hand. (I didn't get a shield in Shadow Tower Abyss, but I'd be surprised if there aren't any.) This makes it almost identical to Demon's Souls's control scheme, which makes the gameplay nice and fluid.
Shadow Tower Abyss has firearms, which is probably the biggest thing which makes it feel different from both Demon's Souls and the original Shadow Tower. It takes place in the present day, and you begin the game with a gun. It isn't designed at all like an FPS though. Guns are useful, but they run out of ammo, which is why you need to deck yourself out with the knives, swords, and other melee weapons you find. It feels like you are an FPS-protagonist who somehow wandered into a Demon's Souls-like game, which is interesting. Functionally speaking the game is not that different, since firearms basically take the place of bows, but it's still an intriguing twist.
The story and world in Shadow Tower Abyss really makes me wish my Japanese was better. The thought and detail put into its environmental narrative is much closer to Demon's Souls than the first Shadow Tower. It's use of sound, light, and color is also closer to Demon's Souls in terms of establishing a mood, and suggesting danger around the next corner. There are a fair amount of NPCs, all of whom you can kill for no reason if you wish. I wandered around for a while just trying to figure out what the fuck was going on, where I was, and just what all these creepy tunnels were built for. The game has a fairly Lovecraftian vibe, with you basically thrown into this scary cave which leads you deeper and deeper into a complex netherworld. In this sense Shadow Tower Abyss really reminded me of Hell Night, another (wonderful) game I played recently that also achieved a similar effect, what I'd called the 'Ultima Underworld Effect'. These are games that really make me feel like I'm a normal human being trapped in a cave or some other such subterranian world, which is where a lot of their elemental power comes from. The lack of load screens helps this feeling a lot, as does the non-linear space design. You really feel like an explorer, not some videogame badass who's just in it for the asskickery.
If I had to recommend one of these games, I'd obviously recommend Shadow Tower Abyss. It can probably be played and completed without understanding much Japanese, and the world and feeling it creates is thick and memorable. It's no Demon's Souls, but it's recognizably similar and effective in what it does. If you want to trace the design heritage of From Software's towering masterpiece, Shadow Tower Abyss is a great place to start, possibly a better place than King's Field.
This Friday's Games at GAMBIT is all about camp. Or what we have loosely defined as "camp," anyway. These games are all extremely entertaining and have enough cheese to enhance the flavor but not enough to induce digestive distress.
Um, moving on...
Games featured include:
Metal Wolf Chaos
And as usual, whatever else we feel like. Join us from 4:00 - 6:00pm in the GAMBIT game lab.
The Gygax family has begun raising funds to erect a monument in honor of the late E. Gary Gygax. Current plans are to seek a location in Library Park, located on the lakefront in Lake Geneva, Wisconsin.
GYGAX MEMORIAL FUND is a non-profit charity and will seek donations from corporate and individual donors.
A bronze bust of Gary, facing the lake, is the proposed memorial. We hope to incorporate gaming elements into the design, with a bench for viewing and reflecting. Final details of the design and site are pending, and will go forward after being approved by the Lake Geneva City Council. We hope to break ground in 2011.
Gary encouraged millions of men and women to excel in literature, math and science all by making it fun for them to open a book in order to excel at the game. Please take a moment to tell us how Gary affected your life as part of the testimonial we will be presenting to the Lake Geneva City Council with our request for the site.
Huali Fu, Muhammad Mohsin, Jonathan Zhan, Alexander Chong, and Leonard Mah are familiar names to GAMBIT... some of them participated in the GAMBIT Summer Program of 2008, others were interns/freelancers in the Singapore Lab. They've started up their own indie game company, The Dumpling Dimension, and I've been playing their first iPhone game, Bee Spelled, now available on the iTunes App Store!
It's a word search game, but unlike Boggle, letters don't need to be adjacent to make words. If you don't use a letter in one round, it'll stick around for the next. It's up to you to decide which to use and which to conserve. Just the other night I had the letters for "P-U-S-I-L-L-A-_-I-M-O-U-S" and 4 other less-useful characters. This had me agonizing for a while; if you spell short words, you lose your combo multipliers and that lexical masterpiece you've been building up won't have the impact that it could have had.
Long words, however, help you with combat. Your avatar, a bee named Chub, is up against 10 lolcats and spambots. They will chew away at your health bar and you'll have to use green tiles to stay in the game, blue tiles to keep them at bay, and red tiles to dish out additional fire damage. It's a tough balancing act; if you finish off an opponent too quickly, you're losing opportunities to rack up more points, but you can't afford to take too much damage yourself. Completing the game is no big deal, even in hard mode, but finding the right balance of healing and damage to maximize your score gets trickier at the higher difficulties.
You can probably tell I've been playing it a lot. The meme-referencing jokes are funny, possibly a little too contemporary, but hey, software updates may keep the NPC exchanges fresh and up-to-date with the latest 4chan trends. In the meantime, you've got the online leaderboards for competition. It's just a dollar, so if you have an iPhone or iPod Touch, check it out!
There's only one game released this past decade that made the sort of impression upon me that earns it a place on this list. I've loved plenty of games in the past 10 years, but only one that really changed my idea of what videogames can be...
Metal Gear Solid 2: Sons of Liberty (Playstation 2, 2001)
My feelings about Metal Gear Solid 2 are intense to the point of incoherence... much like the game itself. A lot of why I love the game has to do with when it was released, which was right after 9/11. For me the game served a function that must have been similar to the film Dr. Strangelove when it was released at the height of the Cold War. As daring, irreverent political commentaries in games go, there is MGS2 and then there's nothing. Okay, well maybe there's Fallout 2, the game that ends with you wiping out the last remnants of a fascist, genocidal U.S. government. But that's just the end of the game. MGS2 is a balls-out 'fuck you' to America's worst dystopian impulses from the moment you press 'start' to the moment the final credits roll. That it seemed to be about America's post-9/11 nationalist hysteria was, of course, an accident of its release timing. But that doesn't change the fact that it functioned so well as a bombastic parody of Bush's new world order.
Because of MGS2 I still think of the people who run my government as "The Patriots": the faceless, powerful elite that are just out of democracy's reach. Whereas games like Deus Ex gave me the same old international conspiracy theories I'd seen in the X-Files, MGS2 gave me a deliciously national conspiracy theory: a horrifically corrupt U.S. government with a puppet democracy and a global censorhip agenda. The Patriots were responsible for everything in MGS2, including the game's intentionally linear design. You follow their instructions and do everything they ask you to, and thereby prove you are willing to be controlled. It's the same game design-as-mind control metaphor Bioshock would use years later, only MGS2 never contradicts itself by pretending rebellion from within the constraints of a designed system is possible. As the authors of your "game" The Patriots' stranglehold on you is absolute, a fact which they rub in your face by the end. A videogame is not a democracy, because the player does not have the ability to rewite the rules. But you don't really want a democracy anyway, do you? Not if you're being sufficiently entertained...
The way MGS2 positioned videogames, with their coyly disguised limits, as metaphors for similar kinds of deceptive government was, in a word, brilliant. It really did have a lasting effect on how I think about both games and government, which to this day is rather cynical. I suppose I feel as incredulous about Warren Spector's utopian notions of "shared authorship" as I do about Obama's promises of hope and change. They are nice promises, but really what does it mean to say a choice is "meaningful" when it is someone else deciding what "meaningful" means? Is the choice between the Left and Right in America a meaningful one? Is the ability to choose between path A or B in Mass Effect a meaningful one? Both game companies and politicians would like us to believe so, but it is important to recognize that these "choices" have been pre-defined within limits we, in fact, have no ability to influence.
MGS2 darkened my view of games forever, and it still remains a remarkable example of astonishingly irreverent political commentary in a mainstream videogame. My demand that games be controversial on political subjects as well as hijack massive commercial budgets for the sake of naked personal statements is due entirely to MGS2. Splinter Cell, Call of Duty, and even Fallout 3 are inferior versions of MGS2 by this metric. In fact, nearly all games are inferior by this metric.
There are many, many games that remain important to me that I have not included on this list. Stuff like Super Punch-Out, Gunstar Heroes, Ikaruga, Snatcher, Symphony of the Night and many other of my favorite games are not ones I can really trace back to a "taste genesis", a prototypical game experience that I feel prepared me for loving these games. Looking at the games that influenced your taste is not really an exercise in listing all the games you love, but listing the games that determined the types of games you love. That's why Ikaruga is not on the list in spite of being one of my favorite games ever: because my love of it in no way lead to a love of shmups.
While I like games of all sorts of genres, there are certain types of games I keep coming back to, certain groups of aesthetic choices I tend to look for my enjoyment in. The games I listed--Frantic Freddie, Super Mario Bros., Ultima: Exodus, Bionic Commando, Ultima VII, System Shock, Thief, and Metal Gear Solid 2-- are not necessarily even my favorite examples of the game types they represent. But they are the ones that helped me developed the road map by which I found some of the best games I've ever played, and, more importantly, the tools to understand why I like them.
Ultima VII -->Arcanum, Fallout 1/2, Majora's Mask, Planescape: Torment
Final Fantasy VI -->Suikoden 1/2, Odin Sphere
System Shock --> Metroid Prime, Demon's Souls, Silent Hill 1/2, Hellnight
Thief -->Metal Gear Solid 3, Hitman 2
Metal Gear Solid 2 -->Killer7, Eversion, Passage, Shadow of the Colossus
Join us at GAMBIT this Friday for games filled with the baddest warriors of feudal Japan. The Samurai and the Ninja can be found performing feats such as honorable one-on-one combat, stealth assassinations, fighting through hordes of demons, and even utilizing the destructive power of giant pinballs.
Game selections will include:
Tenchu: Shadow Assassin
Way of the Samurai 3
In addition, we will be staging an early play-test of our live action game being developed for the Penny Arcade Expo East! We are in need of volunteers.
Be there, 4:00 to 6:00 in GAMBIT (third floor of NE25). There will be cookies!
Ultima VII was the reason I got into PC gaming. For a 13-year-old who had been weened almost exclusively on Nintendo, the deep dark world of The Black Gate was transcendental. It was clearly for adults, but not in the crass, pandering way most games are now. Blood and sex is all handled in a witty fashion, and you don't get the sense the developers were impressed with themselves simply for having it. It was, just like everything else in Ultima VII, just part of an astonishingly rich world. Ultima VII was the first time I'd ever seen a game with no loading screen, with characters who weren't just signposts, and with party members who responded dryly and dynamically to many of your actions. My love of persistent, seamless game worlds and witty, complex dialogue comes entirely from Ultima VII. Any Elder Scrolls, Grand Theft Auto game, and, yes, most Bioware games are inferior versions of Ultima VII to me.
Final Fantasy VI (SNES, 1994)
Final Fantays VI was the first game I played that really moved me. This probably had something to do with the fact that I was an emotionally sensitive teenager, but I think it also had something to do with the game's delicate (and arguably unique) sense of loss and tragedy. Unlike all other RPGs I know you don't stop the end of the world in FFVI. It happens, and it has a devastating effect on the group of characters you have gotten to know. The completely non-linear final sections of the game, in which the player has to slog through a dying world in an effort to pull their friends (kicking and screaming if necessary) back towards hope, remain some of the most emotionally intense hours I've spent with a controller in my hand.
It may be nostalgia talking, but I feel that FFVI's melodramatic indulgences have aged a bit better than many other Japanese RPGs, largely because of the pixel art graphics and understated nature of the characters. Very few games in my experience earn the right to engage in the sort of emotion Final Fantasy VI does, and it's probably the main reason I like melodrama in games but hate it when it's done badly.
System Shock (PC, 1994)
System Shock is probably the most immersive experience I've had with a game, period. To me System Shock isn't so much a game as it is a place, a place I remember going. Though I had a very similar experience with Ultima Underworld (a game which System Shock is basically a cyberpunk re-skinning of), System Shock still looms larger in my imagination as the game which made me consciously realize what a first-person suspense story set in a virtual interactive environment could be.
The implementation of a rogue A.I. as a metaphor for the game's designers was a masterstroke which made otherwise pedestrian use of game conventions (puzzles, power-ups, etc.) into a secret engine which fueled the narrative. Matching wits with the game became matching wits with SHODAN, which allowed for all kinds of devious reversals and thwarted expectations without the player's suspension of disbelief so much as shuddering. This all built towards a sublime final moment in which you literally lock wits--as in, you lock consciousnesses--with SHODAN via a cyberspace terminal connected directly to your brain. Having failed to destroy each other physically you face her on her home turf: as software. SHODAN attempts to overwrite your mind--which is expressed visually as her face overwriting your computer screen, pixel by pixel, while you desperately try to delete her mind from the inside out. It's stuff like this that not only makes System Shock a phenomenally memorable game, but also one of the best game-based examples of cyberpunk fiction that I am aware of.
System Shock also did wonderful things with keeping physical space coherent without resorting to putting the player on-rails. There were no load screens that weren't disguised, no cut-scenes that weren't explained as either remote surveillance footage or recorded messages. None of the games which later borrowed these devices (with the possible exception of Portal) used them as holistically or as consistently as System Shock did. My demand for complete coherence in fictional 3D spaces as well as my taste for environmental narratives--real ones that require detective work, not ones that are handed to you on rails--comes from System Shock. Games like Half-Life, Half-Life 2, Bioshock, and especially System Shock 2 are all inferior versions of System Shock as far as I'm concerned.
Thief: The Dark Project (PC, 1998)
Since stealth games are the closest thing I have to a favorite game genre, I suppose I should include Thief: The Dark Project. Also by the makers of System Shock, Thief was great for a lot of the same reasons, but several new ones as well. The biggest thing I took away from it, I think, was the idea that stealth games are in a sense nerd revenge fantasies. They are about a smart weak person taking down a bunch of strong dumb people. Garrett's internal monologue in Thief is about how I imagined my own internal monologue in high school: full of smug superiority, mute rage, and ample wit. This might be why the dumb A.I. (still smarter than a lot of game A.I.) never registered as a flaw to me: the opportunity to taken down idiotic meatheads was clearly a feature, not a bug.
Aside from this Thief impressed upon me, subconsciously perhaps, the notion that violence in games doesn't have to be a foregone conclusion. The stealth genre is one that is basically predicated on the idea that violence is a choice, which might explain why I find its natural contours so appealing. Violence is after all a brutish solution to any given problem. But Thief wasn't boring enough to suggest alternatives based on moral grounds. Rather it suggested that pacifism can be more about narcissism than morality... an intriguing notion that probably speaks more closely to the real reasons behind the behavior of players (such as myself) who obsessively refuse to kill. It's not about right and wrong. It's about one drop of blood ruining my masterpiece. An artist like Garrett--like me--is clearly above such a thing.
Thief is one of the reasons I'm not particularly impressed by many stealth games, but why I try every one I can find in hopes they will generate the complex set of feelings and ideas thatitdid. Certain games in the Hitman and Metal Gear series approach this, but none of them quite achieve Thief's sense of exquisitely smug empowerment.
GAMBIT alumnus and Fire Hose Games Grand Poobah Eitan Glinert will be presenting an online seminar for IGDA members on January 27th. Here's a quick description from the Fire Hose Games blog:
What do you do if you have no artist, no funding, and the design isn't even complete? Prototype! In this webinar, Eitan will share some ideas for rapid, iterative prototyping, including how we used it in the development of Slam Bolt Scrappers. You'll even get to see some of the super early builds we developed using this process. And of course there will be plenty of dinosaurs as well.
MIT researcher Nick Montfort is digging into the origins of the word "Zork," the name of the seminal text adventure game that started Infocom and, in turn, the rest of the Boston game industry.
It seems reasonable to pursue this question, and reasonable that there would be some discernable answer. After all, there's a whole official document, RFC 3092, explaining the etymology of "foobar." It could be interesting to know what sort of nonsense word "zork" is, since it's quite a different thing, with very different resonances, to borrow a "nonsense" term from Edward Lear or Lewis Carroll as opposed to Hugo Ball or Tristan Tzara. "Zork," of course, doesn't seem to derive from either humorous English nonsense poetry or Dada; the possibilities for its origins are more complex.
Spoiler alert: Nick doesn't arrive a specific conclusion as to the source of the word "Zork", but his detective work is fascinating to read. His article also links to Peter Samson's 1959 TMRC dictionary, a treasure trove of early hacker slang.
There is a theory in psychology that we go through life looking for surrogates of our parents. Similarly, one can imagine that many of the games we encounter early in our lives are the standards by which we consciously or unconsciously judge games afterward. We perhaps look for the games which shaped our tastes in every new game we play... and are usually disappointed when we don't find what we want.
Looking at the games which shaped us helps us understand why we like certain games and dislike others, or, to be more specific, why we see certain games as inferior versions of other games. I don't think this is anything to be ashamed of, as long as one doesn't pretend there's any objectivity to be hand in this process. We like what we like for complex reasons that were formed reflexively and unconsciously, by our natural gravitation towards certain works of art. Discovering why we gravitate towards some things and not others is a process of self-discovery, and one that is arguably required to intelligent criticism.
Frantic Freddie (C64, 1983)
The first game I remember playing for any significant amount of time. I have no idea how it shaped by gaming tastes other than being the first time I became genuinely obsessed with a game. I never did finish it.
Super Mario Bros. (NES, 1985)
The fist game I can remember that pulled me into a fictional world. I remember going to Chucky Cheese with my parents and dropping endless quarters on a Play Choice 10 just to play the first level of Super Mario Bros. I don't know why I found it so captivating, but I distinctly remember reality dropping away and be being only aware of what was happening inside the arcade cabinet. It was like reading a book or being underwater.
Ultima: Exodus (NES, 1987)
My first RPG and, interestingly, a twice-translated port of a port. Ultima: Exodus for the NES was a surprisingly faithful re-creation of Richard Garriott's pioneering original. All the Japanese developer (Pony Canyon) did was make it cuter. I didn't think much about it at the time, but my experience with the NES Ultima: Exodus--which was, ironically, my first exposure to "Western"-style open-world RPGs--may have profoundly altered the course of my taste development as I got older. I probably wouldn't have gotten into PC gaming if I hadn't first experienced a taste of it on the NES. I wouldn't have known what Ultima was, so I wouldn't have gone crazy when I saw the Ultima VII box in a PC store a few years later. (VII?! Holy shit! It was like getting a game from THE FUTURE!) To this day I am one of the few people I know who loves both Japanese and Western game design aesthetics about equally, who gets just as excited about Final Fantasy as Ultima, who doesn't regard one as an inferior version of the other. I think this has a lot to do with the fact that my first "Western" game was filtered through Japanese sensibilities.
Bionic Commando (NES, 1988)
Bionic Commando was the first game with a story and characters I really loved. They weren't complex at all, but for some reasons the game's presentation--with game design logic being totally dictated by dramatic logic (and not, as is usually the case, vice versa)--enthralled my friends and I to no end when we were 11. This game is still the reason I never mind an irregular difficulty curve as long as it makes sense story-wise. If the last boss is flesh and blood and I have a bazooka... well... he shouldn't take more than one hit, should he? Certainly not if he's Hitler.
Marleigh and Philip's paper on fun in the workplace, submitted to CSCW 2010 Conference workshop "Fun, seriously?" got a nice little shout out from Henriette Cramer out in the blogosphere.
Marleigh and Philip's paper, cheekily titled "You Get Paid to Do That?" can be read here along with the other papers accepted to the workshop. It is about how much fun we have at work, and it uses verbiage culled from noted scholars Bill S. Preston, Esquire and Ted "Theodore" Logan. It is a hoot. You should go read it.
And Henriette, so glad you liked the paper. Thanks for the mention!
That is right folks, Jan. 29-31 GAMBIT is playing host as a site for the 2010 Global Game Jam. We will be welcoming developers and non-developers from both the MIT community and the greater Boston area as we convene for a weekend of game development mischief.
The International Game Developers Association organizes the weekend event, as sites around the world host ad hoc teams of volunteers who will design and produce in 1 weekend a game based on a mystery theme. The theme is revealed at 5PM on Friday the 29th, and teams will be formed that evening for work through the weekend.
Unfortunately, GAMBIT has already been registered to capacity for this winter's event, but if you are interested we encourage you to head over to the Global Game Jam webpage, as we know both Norhteastern University and Worcester Polytechnic Institute are hosting jams as well.
The Jan. 29-31 weekend event, organized by the International Game Developers Association, features volunteer teams of video game designers across six continents, working together for two days and nights as they create games from scratch. In the process, they uncover new possibilities for game styles, execution, and collaboration that future designers can utilize.
Philip Tan, U.S. Executive Director of GAMBIT, said that the Global Game Jam creates an opportunity to prototype new kinds of games, ones that by necessity are more experimental. "Game jams don't give you enough time to mope. It's hard enough to come up with an idea and prototype it without worrying about whether it's good enough."
"Community and creativity are what it's all about," said William Uricchio, Director of MIT's Comparative Media Studies program and Lead Principal Investigator at GAMBIT. "With the Global Game Jam, GAMBIT continues its efforts to promote fresh thinking about games -- and to draw on global talents to do so. GAMBIT has been playing an increasingly important role as a place where the local gaming community meets, and the Game Jam will give the lab a chance to redouble its efforts, fueled by caffeine and a brilliant mix of people."
"The Global Game Jam is not really a competition," Tan added. "It's all done for the heady thrill of getting together with fellow game-makers and creating something playful." He urges the participants to get some rest on the first and second nights. "The intensity is what makes it fun, but I'm sending folks home in between days," he said. "Being around developers in the lab every day, we know the final result can be better with some pacing, clear thinking, and, seriously, a bit of sleep."
MIT's jam site at 5 Cambridge Center won't be limited to those with MIT ties. "GAMBIT's goal is to share insights, experiences, and findings with the rest of the game development community," Tan said. "The Global Game Jam is a great opportunity for local developers and enthusiasts to make games together with the students and staff of the lab."
With luck, some really amazing games from our site will join scores of other games from the weekend on the Global Game Jam website on Sunday, January 31st.
Dream logic is a distinct entity from the rational thinking we encounter in everyday life. For our most recent project, the prototyping team explored the prototypical dream experience in order to exploit this unique thinking for a dream-based game.
An important aspect of dream logic is the concept of dualism. Extraordinary tasks are common in the dreamscape and are quite trivial for the dreamer. Trivial tasks, however, can become enormously difficult. When we last left our protagonist, the downtrodden supermarket clerk, his everyday tasks had surged into the realm of impossible. The shopping carts he attempted to herd plagued him with puzzles and the gibberish-speaking customers demanded he sort out their nonsensical purchases.
Now our super(market) hero must restock the abundance of items removed from the shelves. Unfortunately these items don't want to be restocked. To get back at him, they're moving around his back, violating space and time. The goal of the boy (and player) is to determine the method behind the item's madness and to order them according to his manager's instructions.
There were four 'aisles' on which items could appear. Aisles were represented by a card. Items were listed on sticky-notes and posted on the card so that they could be moved easily between aisles. There were four thematic aisles/cards: breakfast, meat, produce, and snacks. These themes were not explicitly explained to the player.
The player was instructed (via writing on the first aisle) that there goal was to arrange items in the first aisle as follows: Cereal, Poptarts, Oatmeal, Cream of Wheat (in that order). The sticky-note items in the aisle did not reflect this order and were as follows: Cereal, Poptarts, Chips, Cream of Wheat.
Players were allowed to 'move' between aisles by requesting to view a different card. They had to first return the current card to the GM before receiving the new aisle. Player's were allowed to 'carry' items between items by removing the sticky note for that item and holding on to it while switching cards. Players were allowed to carry more than one item at a time but were not explicitly told so. Once in a new aisle, players could remove items in exchange for an item they were carrying.
Once players had located the desired item in one of the other aisles, they could return to the first aisle. The desired item could always be located in the aisle of the replacement item. E.g., if Chips replaced Oatmeal, the Oatmeal could be found in the Snack aisle.
Upon returning to the first aisle, players discovered that another item had been replaced (Poptarts -> Rhubarb). To find the target item, the player would need to determine the pattern, i.e., that the target item simply switched places with the distracter item and that these items all belonged to a theme aisle.
One major flaw in this design was the lack of a win-condition. The designer implemented the ideas with the intention of providing a proof-of-concept, rather than a game. While the idea was well represented, the implementation wasn't fun for the player. Two proposed win conditions included the following:
The player picks up all of the items from the first aisle and carries them with them as they traverse the other aisles so that they cannot switch places with the distracters.
The distracter items switch places with the target items according to some trend/ rule and the player has to figure out this rule.
Furthermore, this prototype did not lend itself well to the idea of including the character's story and motivations into the mechanics. Thus, the idea was placed by the wayside to explore other ideas more characteristic of the true gameplay.
Continuing the recent theme of blog posts about dream logic, I thought I'd discuss the prototype that I came up with for this game.
This prototype was another attempt to explore the strange ways that meanings or properties that are assigned to various objects in dreams, and the way that those meanings affect the dreamworld. For example, if a slug, which is associated with the property of sliminess or slipperiness (as mentioned in a previous blog entry), is put in a grocery cart, it might cause the cart to lose traction and become difficult to control, not because of any physical effect like slug slime ending up on the cart's wheels, but simply because putting a slug in a receptacle extends the property of slipperiness to that receptacle.
In this prototype, the player takes on the role of a stocker in a supermarket where the aisles of the store are unhappy. Each aisle has its own problem or set of problems (for example, one aisle might be feeling lonely, while another aisle might be on fire) which are related to the items found in that aisle or, in some cases, items that should be in an aisle but aren't. The player must figure out how to re-arrange the objects in the aisles so that the problems are resolved. To do this, it is necessary to understand the "logic" that governs how each item affects the aisles. Unfortunately, since this is a dream, the logic is rarely straightforward.
For example, in one iteration, Aisle 3 was crazy because almonds were stored there (why would almonds make an aisle crazy? Because they're nuts! Ha!), and removing the almonds restored the aisle's sanity. In some cases, the aisle's problem was more reasonable (after all, what sense does it make for something like a supermarket aisle to be crazy?) and it was the solution that was dream-logic based: for example, it's conceivable that there could be a fire in a grocery store aisle, but only in a dream would it make sense to put out the fire by opening an umbrella in that aisle and thus causing it to rain.
Originally, this prototype was a little unfocused. In addition to solving the aisles' problems, the first version required the player to be able to push a grocery cart to the end of the aisles to collect some sort of prize there. However, the objects in the aisles also served as obstacles to the cart's progress, so to get to the end of each aisle required a complicated shuffling of objects between aisles that would allow the cart enough room to move around while still keeping the aisles happy. It didn't really work; I think I was trying to add in too many systems at once on the first attempt. It might have had the potential to be an interesting spatial reasoning game, or a more complicated version of that puzzle where a guy has a fox, a goose and a bag of corn on one side of a river but a boat that can only hold one of them besides himself, but in the end, neither of those were actually what the prototype was meant to explore. So, the idea of objects as obstacles was pretty much abandoned after that.
The second version retained the idea of having to push a grocery cart to the end of the aisles, but now the only requirement was that the aisles be happy (I guess an unhappy aisle would refuse to let a grocery cart through? The reasoning behind this was never really fleshed out, which in retrospect probably should have tipped me off to the brokenness of this aspect of the prototype). However, during the play through, it came out that there was really no good reason to have this cart-pushing requirement: there was nothing to explain why exactly the player character wants to push a cart to the end of the aisles. Sure, there's a bar of gold or some other prize there, but that is itself a problem: what are bars of gold doing floating around a grocery store? They were just there to provide the player with a reason to push the cart to the end of the aisle, and that brings us back to the question of why it's necessary to make the character push a cart down the aisle. Maybe in later prototypes, or in the actual dream logic game, some story might be added that explains why pushing a cart down aisles is a good thing to do, but at this point in the process it made more sense just to tell the player that their goal is to make the aisles happy. Happy aisles = happy customers, or something.
So, in the final version of this prototype, there was no mention of carts or obstacles or anything like that, just some unhappy aisles with a handful of items in each. Also, by this point, the aisles' woes, the objects, and their interaction with each other had gotten a little more focused and often more intricate. There wasn't any wordplay in this version, for example, since it had been pointed out that puns don't play a part in many people's dreams, so although the idea of almonds making an aisle "nuts" had a sort of silly logic to it, it wasn't exactly dream logic. One of the more complicated puzzles in this iteration involved an aisle containing, I believe, a top hat, a cactus, and a clock, and that aisle was on fire. To put out the fire, the player not only had to bring over an umbrella from a different aisle to make it start to rain, he/she also had to remove the cactus from the aisle, because cacti are associated with deserts and while the cactus was in that aisle the air would be too dry for sufficient rain to fall.
This was the last version of this prototype that was created, because the semester was ending, but an idea that would be good to explore in the future (suggested by the game's owner) would be to have the objects in the aisles relate somehow to who the character is, and what kind of life he leads outside the dream. For example, one of the objects in the last version was a top hat that could produce rabbits---maybe that item was included because the character is actually an amateur magician. If so, there could also be items like giant playing cards, and puzzles revolving around the suits (maybe one of the puzzles requires a DIAMOND ring?) or conflict among the face cards (is there strife in the Court? Are the king and queen mad at each other?).
Well, today is my last day so I thought I'd do one final summary of my experiences with Visual3D.
A few times I asked on the Visual3D forum for solutions to problems I was having with the engine. If someone in the community couldn't solve it (which was usually the case), an actual developer of Visual3D would answer my questions and help me until the problem was solved. This was an amazingly helpful asset.
This may go away once Visual3D gets out of Beta, but by then hopefully the documentation will be better and the community will be larger and more experienced.
One of my favorite things about Visual3D was that a user could choose their level of involvement in the code. A user could probably make an entire game by just using the GUI and scripting language. On the other hand, a user could make a game while only using the GUI to import assets and view their scene. Any combination of the two strategies would work as well, with the user only going into code when they need it.
The flexibility of the system was a major asset to Visual3D and would make it useful to anyone regardless of experience level.
Visual3D has a really nice GUI interface for making games. Most of the current documentation is related to the GUI, so it seems like the focus of the developers rather than code.
The GUI was really useful for debugging also, since I could click on any object in the scene and view it's attributes as well as change them while the simulation was running.
There is a lot of scripting you can do in the GUI which I didn't get much into (I did more C# code in the background rather than their scripting language), but it seems like this would be really useful for someone without too much programming experience.
Visual3D has a lot of features that make it very powerful. For example, the AI engine is very easy to use and to create behaviors with. Making the enemy follow the avatar took about 2 lines of new code, which was pretty amazing. There is also a way-point system built into the GUI.
This was the big one.
Even though I could see all the good things about Visual3D and it had a ton of amazing features, I would keep getting stuck because of a lack of documentation. This wouldn't have been as big of a problem if I had had access to the source code, but since I didn't, I had to base most of my code off their sample demos.
One problem I ran into was trying to turn the model independent of the camera. It turned out that I had to use the Spatial object of the model, and once I knew this, manipulating object's size, position, and orientation was unbelievably easy. However, there was no documentation to point me in the right direction and the sample code didn't highlight this fact.
I wish that there had been some basic tutorials saying how the developers meant for certain tools to be used just to point me in the right direction.
I think that once Visual3D has some basic documentation, it will be an excellent system for anybody to use regardless of experience level.
Uh... Importing Models
This goes in the "uh" category because I'm not sure if the problem was with Visual3D or with my lack of knowledge of Maya. I had a problem importing animations that were attached to the skeleton from Maya to Visual3D. Without animation, Visual3D would not move the models as characters. But again, this was probably my own personal failing at understanding Maya, and it seems like Visual3D doesn't make this process hard.
tldr: I think that once Visual3D has some basic documentation, it will be an excellent system for anybody to use regardless of experience level.
I can't believe the semester is over already! And I really can't believe that I have a mostly-working prototype of Abandon in Unity. Here's a screenshot of my version of level 15, "Hopscotch", side by side with the same level in Abandon:
Along the way, I've tried to record some of the day-to-day bugs and challenges of learning to use Unity. Here are some issues I had during the learning process that I may not have specifically mentioned:
There doesn't seem to be any sort of ambient light available. The closest thing to it is a directional light, which shines in only one direction but shines in that direction all over the gamespace. The only other light options are point light and spotlight.
Unity's version of C# seems to have nonstandard capitalization requirements. I found this out when I tried to use Caryn's text reader program and it refused to work until I changed a few capitals. In general, capitalization is very important to the scripting syntax.
The scale of an object given in the inspector view is its local scale--that is, the size of the object relative to its original size. Likewise, if an object is the child of another object, the xyz coordinates given will be its position relative to its parent. This can make it difficult to determine an object's global location or relative size.
Every object in a scene will have a Transform, so a lot of the functions that you might think would belong to the GameObject class, such as IsChildOf, are actually under Transform. I forgot this a lot. Very often Unity would tell me a function I had used didn't exist, and the fix would turn out to be changing gameObject.Function() to gameObject.transform.Function().
The output buffer displays at the bottom of the screen (not the top, as the video tutorials claim), and you have to click on it if you want to view more than one line at a time.
The vector Vector3.forward points along the z axis, but in the default perspective view in the scene view, this is not the direction you are facing. I had some trouble with that when I tried to write keyboard input using the arrow keys and the player seemed to be going in the wrong direction. The game view looks in whichever direction the camera is looking.
If you create a variable in a method and never use it, Unity will send you a warning... but if you create an instance variable and never use it, you will not be reminded to do anything about it.
The main documentation page has links to a number of useful resources, including the Unity script reference, the user manual, and the reference manual--and no, I don't know what the difference is between the last two. I especially recommend watching the video tutorials before getting started, to give yourself some idea of how Unity works and where to begin. They also explain how to navigate the scene view, and some basic concepts like parenting which will be very useful later.
The Unity documentation is generally helpful, but in some respects lacking. It's easy to look up a particular command, but not so easy to find the command that does what you want to do. For reference, here are some especially useful pages from the script reference and the manuals:
When all else fails, your best option is to try the Unity forums. I got answers to a lot of my questions that way, and everyone who posted was very friendly and helpful.
Now that I know more about Unity, there are some things I would have done differently when I made the game. For example, if I had known about the CharacterController component sooner, I would have taken some time to learn how to use it, which might have worked better with the physics functions than using a collider.
Applications for the GAMBIT Summer Program 2010 are now closed.
Secondary tests are due January 29th!
Thank you to everyone who applied to our Summer Program! We are reviewing applications and responding as quickly as possible. It may take a day or two to get all the applications sorted out and secondary tests emailed out.
Potential Artists, Audio Designers, Producers, Programmers and Quality Assurance Leads (Testing) will be sent a secondary test, due by or on January 29th. This year, there is no secondary test for Game Designer Applicants. If you indicated an interest for more than one role, you will be sent only one test, for your primary interest.
If you receive the wrong test, or if you need assistance, please contact gambitsummer AT gmail DOT com for assistance.
The Next Step:
After the tests are received, they will be reviewed by the GAMBIT Staff. Starting in mid-February, applicants will be contacted to arrange interview times. Interviews will occur during late February and early March. Once the interview process is complete, offers will start going out to successful applicants.
So far this semester, the prototyping team has worked on a game about fate, a zombie game with more-realistic-than-usual NPC behavior, a one-button, purely audio game, a game about words, and a game that uses dream logic---so we've been kept pretty busy over the past couple months. These games have all been the projects of other researchers at the lab, to whom we loaned some of our brainstorming/prototyping power. For the past week or so, we've been trying something different, and working on a game that we came up with entirely on our own, from brainstorming on out.
We've made a few starts on this project at different times in the past--one of the walls in our room is still covered with game ideas from a brainstorming session weeks ago (some highlights: "Black Plague--the game!"; a human-harvesting game, with you as a vampire -- think Harvest Moon plus fangs; "Bacon Games!"; an MIT fighting game), and I know there's at least one GoogleDoc floating around the internet somewhere that has even more brainstorms on it. So we're not short on game ideas, is what I'm saying.
But it's actually been a little difficult to move on to the next steps, partly because we've been busy with other stuff, but possibly also just *because* we had so many ideas. I think each of us has our own set of favorites, without necessarily a lot of overlap between our sets, so we've never been able to settle on a particular idea or set of ideas that we've all wanted to explore further. I know we've sat down multiple times to talk about what kind of game we want to make, and half of us end up talking about bears and the other half talking about a tiny person trapped in a fridge. What eventually ended up happening was much less organized; during a break in between other projects someone said "Let's make a resource management game", someone else said "Yeah!", and the third person present at the time was cool with the idea, and suddenly that was our new project. So maybe that's the best way to do it: rather than generating a bunch of ideas for games and then trying to pick between them, figure out some unifying concept -- theme, mechanic, whatever -- that everyone agrees is interesting, and work from there.
After throwing out a few ideas on what our resource management game could be about, we settled on an idea that had come up in previous brainstorming sessions, of a leaf-cutter ant colony. We latched onto that idea pretty quickly, possibly because an ant colony that gathers leaves lends itself well to resource management: having to gather leaves to nourish the fungus that the colony feeds on (it turns out that's what leaf-cutter ants do with the leaves they cut: they chew it up and use it to cultivate fungus), figuring out whether you should increase the number of soldier ants or harvester ants or fungus-farming ants (real life conveniently provides us with a number of pre-built classes in the form of castes in leaf-cutter ant colonies) and whether you can actually afford such an increase, and so on, provides a wealth of interesting decisions for the player to make.
However, this sounds a lot like a classic RTS mapped onto an anthill, which could be an interesting fictional backdrop but might not provide much innovation in terms of gameplay. So, we've been trying to come up with some ways of adding to this concept. Here are a few we've thought of:
-Scent trails: Give instructions to the colony/ants that aren't explicit -- players draw a path from x to y and ants will bring resources from y to x continuously (assuming here that x is the hill and y is the site of some resource). Players might also sabotage opponents by breaking their trails or re-routing their trails into confusing paths or endless loops.
-Leaf-cutting: Like a kindergartener, the fungus likes its food to be cut into particular shapes, but cutting some shapes of leaves is harder/more dangerous than cutting others; cutting larger leaves is harder. Or possibly you have to cut leaves so that they'll fit down the ant hill tunnels, but not so that leaf transport is inefficient, with each ant carrying a tiny piece of leaf.
-Impostor ants: An impostor has infiltrated the colony and has to simultaneously blend in and bring down the colony/kill the queen; the regular ants have to figure out who the impostor is and stop him/her
We're hoping to have a second well-prototyped game by the end of the semester, similar to the work we did on the cat scaring game earlier in the semester. The process is not easy: an ant colony is a complex system---multiple interacting complex systems, even--so there are a lot of possible paths for us to go down. So far, we've each tried to focus on some aspect that interests us. In my case, I think the scent trails idea is most interesting. It might be getting a little bit away from the resource management idea, or maybe just backgrounding it a bit, but I can see players competing to build trails to strategically important spots, taking turns to place paths or disrupt another player's existing trails. It might be worth investigating a restriction on what players are allowed to see--if you can only see your own scent trails, you'll have to figure out what other players are up to by watching what their ants are doing. Or maybe you can't see their ants until those ants cross your scent trail, since your awareness of the world probably ought to depend on what your ants can see. I'm also intrigued by the concept of having to cut leaves into particular shapes so they'll fit down a tunnel or comply with another type of restriction, which keeps the focus on the resources but adds another dimension to the game and the player's concerns.
Currently (besides looking very different), the game behaves very much like Abandon besides some small differences. Collisions and enemy wake-ups now work, and enemies will die as well as hurt the player when hit.
The actual attack and damage interactions were very easy to implement, as combat is essentially built into the base Avatar classes.
Another element that was implemented was the dynamic spotlight. When the player is damaged the light changes size in accordance to the player's health. The change in light also affects its sensors size, so a smaller light will have a smaller sensor radius.
The next step is to implement basic AI. All that it will be at first is an enemy heading towards the player's location with no path-finding to avoid walls or other obstacles.
So far I can see two possibilities. I have created a script in the GUI, but I can't seem to figure out how to call it from the C# code and cause an enemy to perform it. The problem with doing it in the GUI is that enemies are created from text files, and are not dragged into the scene by the GUI. So the script would have to be added to the enemy object itself from the GUI. Hopefully this will be relatively straight forward.
The other option is to do it all from the C# code, which seems like a lot more work, but might be the only way to do it in code.
Under-slept, over-exited, and inspired by caffeine, I decided to make a board game based on leaf cutter ants. With a (kinda) twist: one of the players is an impostor! This actually happens in ant colonies, other insects or even other types of ants will live in colonies, mimicking the ant's chemical signature to pass as the local ants, and partaking in destructive behavior.
In a slightly cartoon-ified take on this phenomenon, what might an impostor with the colony's worst interests at heart do? It might set misleading scent trails or erase existing ones. It might take food for itself. It might frolic with parasites and introduce them into the colony. It might dig towards a water source to flood the colony. It might kill ants if there are no witnesses. I might eat more than its fair share. It might be all around unpleasant.
So how to turn this into a board game? I took the model of Shadows over Camelot, a game where the players must compete against the game. This model works well for a game that takes place in an ant colony
So, though a hack I managed to get the main character to finally see enemies.
The problem I was having was that when I tried to create the main character in a way that allowed their perception to work, it wouldn't show the model (I have no idea why).
So my workaround was to create an invisible triggered area that had a spotlight in it. The triggered area follows the hero around so that it looks like the hero has perception themselves.
The only problem with this is that the area constantly triggers on the hero (every frame), so I can fix that in two ways.
1) Hope that it doesn't create any lag (which it doesn't right now) and just take care of that case with an if statement.
2) Change it so that the hero is the only thing percepting, so that I can make the hero non-perceptible. I'm not sure however, how this will affect AI. Hopefully AI won't rely on perception of creatures for path-finding and the like.
So, right now my play is to go with 1 until I see any problems. Since it works right now, there's no reason to mess with it as there's not much semester left and there are probably more important things for me to spend my time on.
My next step is to actually make the interactions between the hero and the enemies.
I also looked a little into the AI system and am confused. There seem to be a number of ways to do it, both through the GUI with scripts and code in Visual Studio. The tutorials on the subject seem to be up to date, although I haven't tested them yet so I can't be sure.
I've had some trouble getting the chasers to work with the setup script... but on the plus side, I figured out how to program in some cheat codes. I can now skip to the next level or restart the current one. For testing purposes, of course.
At first I had trouble getting the script to choose a mesh based on the list in the pino file. As a temporary fix I just used one mesh as the default, which led to the player being chased by a horde of tiny bathtubs, but now I think I'm back on track to reproducing the meshes in the original game. I was using Resources.Load to select the correct mesh and load it into the script, but it kept returning Null. The problem, as it turned out, wasn't Unity's fault; some of the meshes had different names than were listed in the pino file, so I was sending Unity on a snipe hunt looking for toilet or robot when the mesh I really wanted was toilet_bowl or robot2.
Now that the script is loading the meshes properly, I don't have to go with the tedious alternative of creating a prefab for every single object. I do, however, have to make sure that the script adds all the necessary components--since I'm not using prefabs, the objects won't come with the script, collider, and tags built right in. This proved to be more of a challenge than I had anticipated. For one thing, it turned out that the Resources folder contained both object files and Maya binaries, and they all had the same names, so half the time I would get the wrong kind of file! I moved all the object files into another folder so Unity wouldn't get confused.
For some reason, even after I fixed all this, the car object was still refusing to use physics functions. When I added rigidbodies, it disappeared entirely--I think it may have fallen through the floor. I'm still not sure what's going on there.
Oh, and in other news, I finally changed the player's collider so she can't climb the walls, but I still had a bug where the player could slip through the walls at some of the corners. I changed the walls from planes to blocks, and somehow she's still getting through. Some of the chasers are also managing to climb the walls and make mischief. At least it got rid of the weird effect where the player's aura would wake up a chaser on the opposite side of a wall.
Remember back in the "Instantiating prefabs" entry, when I mentioned that Unity doesn't like casting instances of a prefab (which are of type Object) to GameObject? This has gone from a minor annoyance to an actual problem. A lot of the things I want to do to these objects require GameObject functions.
I did find a way around it, though. For objects like the walls and floor, I don't know how many I'm going to need, so I need to create them from the script. But for objects like the player avatar, since I'm only going to make one, I don't need to know the prefab; all I have to do is create one ahead of time, then move it to the appropriate location using the script. So instead of having a Transform object in the script and setting it to the prefab, the script now has instance variable
public GameObject avatar;
Then I simply created an instance of the avatar in Unity and dragged it from the hierarchy to the inspector. The script will use the same avatar every time it sets up a level.
(Update: Someone on the Unity forums has come up with the answer! Just in time, too, since I can't use this workaround when creating the chasers.)
Just got over one of the big hurdles: Unity now loads levels from a text file!
To make the code easier to test along the way, I actually wrote the series of functions used by level loading backwards. I started with the code to create a tile, given the locations of the walls... then the function that finds the locations of the walls, given an integer tile code and a char to indicate direction... then the code to parse an input string into an integer and a char... and finally, I adapted Caryn's text file reading function to create a 2D array of input strings. Despite all the testing, no is more surprised than I am that it worked in the end. In the process, I learned a lot of new and annoying things about Unity. Such as that it apparently has its own set of capitalization conventions for C#, which differ from the usual C# syntax.
Here's a simple level I created to test the tiling functions:
Here's a picture of the Abandon level Waterfalls, the first level I tried reading from a text file, loaded into Unity.
After getting to the point where the program could read in a text file, I found out that the code that decided where to put the walls was buggy, so I fixed it and made some other adjustments. Here's the level in Unity after the changes:
And finally, for comparison, here's a partial view of the same level in Abandon:
I'm working on getting Unity to start with an empty screen and build everything from scratch with scripts. I've quickly discovered that it's not possible to build everything from scratch. Prefabs are very helpful (you can see the Unity documentation on creating them here), but it's still necessary to use the inspector to some degree.
For example, I built a prefab of the player. I can notify the script that it needs to create a prefab by including it as an instance variable:
public Transform avatar;
and then creating an instance of it in the code:
Object ob = Instantiate (avatar, new Vector3(0, 0, 0), Quaternion.identity);
(The Vector3 gives the initial location.) However, you may notice that the prefab is never assigned a value. It is necessary to go to the project view and click and drag the appropriate prefab onto the variable name in the Inspector. For this reason, it's important for the instance variable to be made public, because otherwise it will not appear in the Inspector.
The nice thing about this is that the prefab comes with the player's scripts and components already attached. The same goes for other prefab objects in the scene, which means that once I get the script to instantiate all objects, I can immediately start playing, since the keyboard input functions are in the player script.
Important note: When creating an instance of a prefab this way, be very careful about making changes to it in the script! I found out the hard way that if you make changes to avatar instead of ob, the prefab itself changes, which can make wild and wacky things happen if you try to run the script more than once--especially if you want to, say, scale the object. This has become something of a headache, because for some reason Unity makes a fuss about casting ob to a GameObject, which would make it easier to work with.
The Instantiate function is similar to (but not quite the same as) the CreatePrimitive function, which is the equivalent function for creating primitive shapes such as planes and cubes. A big advantage of CreatePrimitive is that the object it returns is already a GameObject, avoiding the casting problem.
I spent the first half of the semester working on GumBeat so I am a recent addition to the Game Engine Team and have spent the last few weeks getting up to speed on Unity and failing to get anywhere with Visual3D.
Lets get the bad news over with first.
Visual3D is great software if you want to drag-and-drop premade skies and dinosaurs onto a scene. Other than that, I don't think it's worth using. The interface is very unintuitive. You can drag and drop premade primitives (and skies and dinosaurs) into a default scene very easily, but it's unclear where to go from there.
I tried simple things like putting a cube and a spotlight in my scene. The cube was super shiny and the spotlight wouldn't cast shadows. Both of them have oodles of options in a handy panel on the right but when I tried to change the default values for say, the range of the light, it snapped back to the default value. Unless I could figure out how to edit it graphically in the scene view, nothing happened.
The documentation for Visual3D is outdated and spotty. They have an old wiki and a few video tutorials but no obvious API or reference documentation.
Pros: Dinosaurs, premade 3D environments and some particle systems.
Also you can drag objects connected to the ground and they follow the topography of the surface, which is handy for object placement.
Cons: little useful documentation, unintuitive interface, confusing controls.
Unity was much easier to use. They have extensive reference and scripting documentation (although it is not always quite as useful as it appears) and useful tutorials that walk you through the basics of using Unity and scripting.
Since Naomi had been working on making physics work, I decided to try making physics-less collisions. Using only scripting, I wanted to detect when two objects collided and push one of them back so they were no longer intersecting.
The Unity interface is easy to use, especially after reading the introductory tutorials. You can create primitive objects and drag-and-drop within a menu to set objects as children, add scripts, etc. You can even expose variables in scripts and then assign an object to that variable by dragging in the GUI.
The Unity scripting reference was easy to use and click through, although sometimes it did not give quite as much information as I wanted. I never saw a clear diagram of object hierarchy, which would have been useful, but I figured most of it out in the end.
Unity provides the concept of "triggers", which I used instead of collision detection since turning off physics also turned off collisions. When an object enters a trigger (any object with the trigger attribute enabled) they both call the "onTriggerEnter" function. I used this to detect collisions and did some simple vector math to transform the moving "character" back outside the bounding box.
Unity wasn't all fun and games though, it too has a few annoying quirks. Most obvious was it's arbitrary placement of created objects in the 3D space. Making a cube involved hunting down where Unity had placed it and dragging it back to where it was supposed to be. Also when testing it gives you the option to click "play" to see what your game behaves like. You can change variables and scripts while in this mode, but no changes are saved. Sometimes this is useful for testing purposes, more often it was annoying when changes you thought you made didn't get saved.
Pros: interface was well explained by tutorials, although not always intuitive. Drag-and-drop controls make scene building and simple scripting easy
Cons: arbitrary placement of new objects, not saving during testing
Recently, the team finished several prototypes focused on the NPC and player interactions for Matt's zombie game. Our designs examined how various NPCs with distinct character traits could affect a player's actions, as well as transfer information to the player, while trying to accomplish some goal (building barricades, reuniting with your party, etc.). After we presented Matt with our prototypes, he brought up a very interesting idea that I think the team should consider at some point in the future.
What would happen if the player was removed from the equation? How would the NPCs interact with each other?
I have always wondered why more games haven't considered creating NPCs that are more than shopkeepers or useless polygons that take up space in battles. What if they could perform tasks without needed the player to constantly guide them or follow their own goals? Looking at The Sims as an example, non-playable Sims complete their wants and needs without needing to interact with the human player as well as form relationships with other non-playable Sims. It would be interesting to bring that concept into other games where NPC free-will could possibly benefit the player and eliminate the anger (that at least I always feel) towards weak, useless characters.
I believe a problem with many games is that NPCs are almost an after-thought, not givent