Checking the Flixel web site for new code drops from Saltsman is routine at this point. When committing my code back to Perforce, I've found it easier to separate the "updating my project to the latest version of Flixel" from the "adding new functionality" stage. So first I check out the Flixel directory, then I check out any individual code files that need to be edited to accommodate changes in Flixel, if any. It's a bad idea to commit any code that results in a broken build. It's more time-consuming than simply checking out the entire project, updating Flixel, and checking it all back in, but I'm trying to train myself in good team-coding habits. However, I haven't decided if I should also be checking out the compiled runtime directory when I'm updating Flixel, since every new version of Flixel would necessarily change that too, but Perforce has a habit of yelling at me when I do that.
Any opinions would be welcome!
Bad dudes
The next step in Tim's tutorial is the addition of enemies. This involves creating an "Enemy" class, which is much like the "Player" class, only instead of keyhandling functions, Tim lays out the logic for basic AI. Jump if the Player is higher, turn towards the player ninja, and move. There's a lot of code to limit bunny-hopping: the enemy must be on the ground and two seconds must pass between enemy jumps. So now I have a new enemy sprite, but... where's the code to actually insert them into the level?
There's a step missing from the tutorial, it seems. Re-using some of the code for inserting the player sprite into the sprite layer, a second green ninja successfully appears, following my player ninja like a little puppy dog. At this point, there's no code to handle damage, so we quickly become best friends. My hastily-created level design turns out to be a pretty tricky obstacle course for the enemy, requiring pixel-perfect jumps that the AI wasn't designed to handle. I spend a couple of minutes trying to coax it to higher platforms, impressed how Tim's small set of rules created fairly entertaining enemy behavior.
Shuriken
Satisfied, I move on to adding ninja throwing stars. Time to put the puppy dog to sleep. At the end of every chapter in Tim's tutorial, he displays the entire code listing of all the classes that changed as a secondary check. That's where I actually find his implementation for adding enemies to the sprite layer. Instead of adding a single object, he creates an array for enemies and just pushes one into the array for now. This is a nice, flexible approach, that anticipates hordes of ninja enemies for the future. This bodes well for my player ninja, due to the Law of Inverse Ninjitsu.
Ninja stars are basically a static image, but Tim demonstrates Flixel's ability to rotate sprites here. Tim loads the ninja star image pretty much the same way he loaded previous animated characters into memory, but Saltsman has actually provided an easy way to do it by passing the image reference as a parameter to the sprite constructor. There's something to be said about consistency for readability, but I'm keeping a mental note to try out the constructor parameter in the future, just for kicks.
'Tis but a flesh wound!
Tim also adds code to handle damage here. The ninja stars are capable of altering the health variable of enemy ninja sprites, and the enemy ninjas themselves get to hurt the player ninja by bumping into them. The Player class keeps track of the last time the player ninja received damage with a variable called _hurt_counter, so there's a couple seconds of temporary invulnerability while the player flees to safety. Collisions, however, are handled in the PlayState class (basically the main game loop) so PlayState needs to know _hurt_counter to figure out if it should take damage. Turns out _hurt_counter is private to Player, so I need to change it to public. Just for kicks, I try a different approach, doing the collision test in Player instead of exposing private class variables, and I get the same behavior. For the sake of keeping up with Tim's tutorial, though, I revert back to his version.
The ninja stars also give Tim the opportunity to show off FlxEmitters for particle effects. When the stars hit a surface, they throw out a shower of white sparks. They look good and I notice a slight motion-blur effect on the particles, but that might be due to my LCD screen than in code. No worries, I'll take it! As for the spinny rotation of the ninja stars, that doesn't look too hot due to aliasing from the chunky resolution of the game. I crank up the angular velocity of the ninja stars so they look more deadly, at least. (Re: Storm Shadow in G.I. Joe.)
I've highlighted a couple of quirky observations about Flixel code after the jump. It's easier to use actual class names to make my point, but it's definitely less comfortable to read. I'll try to be less jargony in my next post.
Saltsman's tutorial is more of an intro to Flex Builder IDE than Flixel, but the window-by-window detail is pretty reassuring for a first timer. Now I'm moving on to Seifer Tim's tutorial, which was recently updated to reflect the changes in Flixel 1.47. This tutorial is intended to walk a new Flixel coder through a basic game where you have ninjas throwing stars at each other. The tutorial also has a couple of handy tilemaps and sprite sheets for the new demo characters, simplifying the process of identifying which frames you need to use for running/attacking/dying, and setting up some basic logic for Mario Bros-style inertial physics.
Once bitten, twice shy
A quick check to the github tells me that Flixel was updated again. Seifer Tim's tutorial is already out of date, because Flixel is now at 1.48! Thankfully, the changes are minor, and don't appear to affect Tim's instructions for steps I through IV. I check out my project in Perforce and start to edit my old code.
When it comes to editing the level, however, there's one problem: Tim's tutorial points me at Mappy, which is a Windows-based tile editor. It looks great, but I'm on a Mac! Also, no one seems to have uploaded any examples of what a Flixel map file actually looks like, so I can't even use a text editor to start creating it instead. A quick search through the Flixel forums yields Flan, which is a Flixel-specific, square grid editor. It's more complex than I expected -- Flan has a button for each function, so there are a LOT of buttons, hidden between different screens of options. It employs a Photoshop-like concept of "layers" of tilemaps, based on Flixel's own FlxLayer abstraction. So I create a new layer, try to set it to 40x30 as Tim's tutorial recommends, but the new map size never seems to take. Turns out that there's an "Apply Changes" button at the bottom of the Layer options window, but you've got to resize the window to see it.
Eventually, I figure out how to import Tim's demo tile images, draw out a map, and export it as a CSV. Flan auto-generates a filename and creates a CSV file with the following data:
... etc. This goes on for a while. That's my map! And now you know what a Flixel map looks like.
Retyping Tim's code line by line, I realize that it prescribes a fairly large chunk of coding before I'll be able to compile and see any results. This is a little scary; I like to verify that my code is compiler-clean as often as possible, and generating a class that doesn't get used until I significantly edit another class is like walking blindfolded. However, once I've typed in enough, my little ninja appears on screen! I can even steer him a little before he drops off into nothingness.
Where's the level?
I pull out a line of code from Saltsman's old tutorial to throw the string on screen, and nothing shows up. I try to poke around the code that embeds map.txt in the game, learning a bit about taking a class loaded as an octet-stream and turning it into a string, but something very weird starts to happen with Flex. It begins insisting that I hadn't closed a brace, but I squint and squint and can't find where that missing brace would go. Recopying and pasting Tim's code from the wiki into my project solves that problem. (Shrug)
Now the 1's and 0's are showing up on my screen, and I can turn the text-drawing routine off. The map is still nowhere to be found, and my ninja still falls off the screen. Wondering if my Player class might be at fault, I turn off gravity for a moment. That stops the ninja falling, and now he can jump up. A few jumps and I realize that I was starting the ninja far too low! The map was there all the time, but Tim's code kept spawning the ninja several screenfuls below the map and automatically centering the camera on the ninja instead of the map. Tweaking the spawn point puts the ninja inside the map instead, and it works!
Other than struggling a little bit with Perforce, the rest comes pretty easy. My hastily-drawn map turns out to be quite an obstacle course for Tim's default character-moving routines, which seem a little pokey for a ninja. So I double the acceleration, add a routine so that it quadruples dedeceleration, so the ninja can take off like a Ferrari but pivot on a dime. The map is still a challenge, but not frustratingly so.
Now my ninja has a world to run and jump in, but no way to die. Next step: Enemies.
Have you ever wanted to win eternal glory? Here's your chance.
Last year, the Evil Lord Mordemort was foiled by gtg ice skating lessons and was locked up in Android Detention Asteroid X-16. However, the Evil Prof. Mordemort has escaped!
Now, the Good Guys™ are looking for adventurous coders to join the fight against Mordemort. The Good Guys™ are offering one or more of the following:
New Units and Weapons
Free Food
6 Units of Credit
Cool t-shirts
Improving your programming and coding skills
More than $40,000 in prizes
Ability to impress corporate sponsors
Eternal Glory
Check out battlecode.mit.edu for more details. Registration for a chance to win eternal glory is now open.
The 6.370 BattleCode programming competition is a unique challenge that combines battle strategy, software engineering and artificial intelligence. In short, the objective is to write the best player program for the computer game BattleCode.
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.
Last week, as part of the Open Government Initiative, Agriculture Secretary Tom Vilsack announced the Department of Agriculture (USDA) would launch the Innovations for Healthy Kids Game Challenge, a national contest for the development of creative nutrition games that motivate kids to make healthy food choices. In the spirit of openness, we want to engage all of you in designing the Challenge for success.
The Innovations for Healthy Kids Challenge hopes to harness the creativity and ingenuity of the American people to promote the growth and healthy development of our youth. [snip] We know that this is just the tip of the iceberg when it comes to the power of digital games to help children learn and develop healthy eating habits.
Given the immense potential, we are looking to you to help us design the contest to elicit the very best nutrition games from developers across the country. In particular, there are four questions where we would greatly appreciate your feedback between now and January 6, 2010.
Jeremy Monken is one of the organizers for GP4CP, a local Boston-area fundraiser for the Penny Arcade-affiliated Child's Play charity, which sends games to children's hospitals all over the world.
He just sent me an email letting me know that GP4CP (the name is awesome!) be hosting it at Microsoft New England Research & Development Center, a.k.a. Microsoft Cambridge. They'll have games, food and drinks and a raffle of games donated from local studios, EA, and Warner Bros Games. The event details are online at www.gp4cp.org, so check it out and support a worthy cause!
When: Saturday, December 19th 6:00pm - 11:00pm
Where: Microsoft NERD Lounge, 11th floor.
One Memorial Drive
Cambridge, MA 02142
Why: To show the Boston area what a positive impact gamers can have and to welcome Penny Arcade Expo to the neighborhood before their first East Coast event in 2010.
Friday Games at GAMBIT 12/18: Super Splendid Sega Saturn
This week's Games at GAMBIT will be in celebration of Sega's unsung hero, the Saturn. While it may have been the PS3 of its day *dons flamesuit* the Saturn had many excellent -but forgotten - games. Come join us as we play titles such as:
Astal (good sprites never go bad)
Panzer Dragoon II Zwei (if you're going to go shoot things, it's better to take a dragon than the bus)
NiGHTS Into Dreams (Sonic Team was once capable of great things)
Marvel Super Heroes vs Street Fighter (2x Robot Zangeif vs 2x Robot Zangeif is a thing of beauty)
Virtua Fighter Remix (the killer app of its day)
Also featuring...
Whatever else we feel like!
Be there from 4:00pm to 6:00pm to join us in deep critical discussion of the Saturn's historic significance as the last console made for high quality 2D graphics. Plus cookies.
As a huge fan of Canabalt, the giant "F" that shows up at the beginning of the game repeatedly reminds me about the existence of Adam Saltsman's (a.k.a. "Adam Atomic") Flixel. Flixel is Saltsman's game engine that powers the spritely, blitty, pixelly goodness behind Adam Atomic and Danny B's masterpiece of one-button parkour. I'm using "game engine" loosely; Flixel is better described as a collection of ActionScript 3 classes. However, the combination of all those classes aims to give a game programmer the ability to create 2D games very quickly, with some long-standard features like volume control, framerate meter, and game pausing available by default. It's also optimized for a certain type of 2D game currently popular among the indie game scene... chunky pixels, lots of filmstripped sprites, rectangular collision boxes.
The Flixel download is just a zip file with an MIT license and uncompiled ActionScript 3 files. This suggests that if Saltsman's code does something you need done differently, you really could just go into the source and change it, which is comforting. I'm using Flex 3, Adobe's IDE and compiler for ActionScript projects, although you can apparently use FlashDevelop or mxmlc instead. I'm hoping to move my experiments to an automated build machine in the near future, so finding that the Flixel wiki features well-written tutorials on how to get started on all of these environments is a huge bonus.
One trick is that all the tutorials in the Wiki appear to be written by different people. This means that the tutorials all feature subtly different coding styles. Some aggressively choose to import all of Flixel's classes, fit the Actionscript files into a larger file structure, and override his methods by default. Saltsman's own step-by-step instructions takes a more conservative, change-only-what-needs-changing approach to Flixel, seemingly happy with many of the default behaviors in his base engine. It's nice to have different approaches to the same problem, but it takes a little effort to identify functional differences in the code examples that could produce different behavior, and purely stylistic deviations that work fine either way.
Figuring out how I should organize the Flixel files with respect to my own source files takes me the most time. Every tutorial has a different recommendation... some suggest creating a "com" directory for your source files and Flixel in an "org" directory inside "com". Some prefer to use the Flex Builder default of putting your project and Flixel as equal partners in your Documents folder. Knowing that I'm going to check everything into Perforce as soon as I get a clean build, I want it in my local Perforce workspace directory tree instead. I finally find a solution that I'm happy with: A HelloWorld project directory (created by Flex) next to a flixel directory, which holds the contents of the full Flixel download, complete with license text. (Note: This does create two nested directories called "flixel": e.g. [workspace tree]/flixel/org/flixel/data/FlxAnim.as) This should make it really easy for me to update Flixel when Adam releases new versions.
Two hours in and I'm switching game states, throwing text on the screen to tell me whether it's working. Part of my slow progress is due to the fact that I'm pretty much new to AS3; I had only worked with AS2 in the past, so I'm learning as I go. The Flixel wiki directs me to other sites that provide beginners' introductions to AS3, but I feel relatively confident in my ability to pick it up from the Flixel examples alone. (And what I can't figure out, I can ask Drew!) The other reason for the slowdown is that I'm insisting on typing everything in, without copying-and-pasting code from the tutorials. I feel I might miss a nuance or important step that I may have to repeat in the future.
I'm noticing that many of the Flixel tutorials (I should really just stick to one!) refer to older versions of Flixel. Screenshots of sample output look subtly different from mine, hinting that Flixel is actually a rather mature batch of code. It puts a little speedbump in reusing sample code, but it does boost my confidence in Flixel's robustness. Saltsman has tested, tweaked, and found better ways of doing things since its early days. For the record, I'm using version 1.45.
In fact, some tutorials describe getting the Flixel files by pulling it out of the file hierarchy of mode, the sample Flixel game that showcases many of Flixel's features and Saltsman's monochromatic pixel art stylings. It's a pretty ruthless game... like Bangai-O without the offensive capability. (Hmm, adding self-guided missiles or bouncing projectiles to mode seems like a decent weekend project.)
mode ate up quite a bit of time, though, so I'm wrapping up my initial exploration into Flixel after two hours and checking everything into Perforce. I've succeeded in making a Hello World that kills the player. Now to give the player a chance.
It is a great review of Jesper's equally great book. The review talks a bit about the Wii, and the development of the controller over the years. There is even a bit about the Contra Code.
Congratulations on the review Jesper, and we are looking forward to getting our crate of 1,000 free copies of A Casual Revolution in the mail for Christmas!
UPDATE: You can also now read some excerpts from the book, interviews specifically, on kotaku.
Western Otaku: Games Crossing Cultures by Mia Consalvo
If you missed Mia's fine lecture two weeks ago, the full video of it is now on TechTV. Gene compressed it as an m4v file for iPod and iPhone so you can take it with you!
From Nintendo's first Famicom system, Japanese consoles and videogames have played a central role in the development and expansion of the digital game industry. Players globally have consumed and enjoyed Japanese games for many reasons, and in a variety of contexts. This study examines one particular subset of videogame players, for whom the consumption of Japanese videogames in particular is of great value, in addition to their related activities consuming anime and manga from Japan. Through in-depth interviews with such players, this study investigates how transnational fandom operates in the realm of videogame culture, and how a particular group of videogame players interprets their gameplay experience in terms of a global, if hybrid, industry.
Mia Consalvo is visiting associate professor in the Comparative Media Studies program at MIT. She is the author of Cheating: Gaining Advantage in Videogames and is co-editor of the forthcoming Blackwell Handbook of Internet Studies.
1/8/10: MIT Admissions announces MIT: THE GAME(JAM)
Bored during IAP? Want to help create something awesome for MIT Admissions? Need a little practice for the Global Game Jam?
The MIT Office of Admissions will be hosting MIT: THE GAME(JAM) during the first weekend of IAP, Jan 8-10, 2010. Come join Admissions staff and other students for a fun and highly caffeinated weekend creating entertaining games for the Admissions Office. At the end of the session, we'll have a big awards ceremony, crown someone the king or queen (or team) GameJammer, and then feature everyone's creations on the MIT blogs and a soon-to-be-created MIT Facebook page. Additionally, the top team (as voted by peers) will win $100!
Learn about coding, have some fun, be creative, and help out the nice folks who let you in to this madhouse all at the same time!
Free food and drink and snacks will be provided to keep code monkeys munching throughout. Bring your laptops, get game design software installed by IS&T types, and we'll be ready to rumble!
1/1/2010: Vote for games for MIT's 150th anniversary!
MIT will be celebrating its 150th anniversary in 2011, so the MIT Museum is running a poll to select 150 objects to represent the institute's history. Students, faculty members, alums, staff and other interested parties may vote for up to 10 items that have been nominated for the exhibition until January 1, 2010.
MIT's role in the development of videogames (and the role of games in MIT) should not be forgotten! Here are some of the game-related "things" that were nominated.
If you agree they should be immortalized, vote for them! If searching for your favorite bit of MIT game history doesn't yield any results, you can make a new nomination. (I'm looking at you, Harmonix...)
2/5/2010: CFP: Research Topic Proposals for GAMBIT's Summer 2010 Game Development Program
Call for Proposals:
Research Topic Proposals for GAMBIT's Summer 2010 Game Development Program
The Singapore-MIT GAMBIT Game Lab is seeking research topic proposals for its Summer 2010 game prototype development program. The Lab seeks researchers who are interested in seeing their mature research put into practice as a game and who are able to devote a few hours a week towards this end at the MIT lab from June 7th through August 6th.
Interns from the Boston area and from Singapore collaborate on development teams each summer to create prototype games which demonstrate concepts based on accepted research topic proposals. Each team is required to create a 5-30 minute polished gameplay experience which demonstrates or explores a research topic. In addition, the game must target the production values of commercial casual games and be distributed online.
Depending on the research topic, the games created might apply some theoretical concept about design or development (e.g. new game design methods, new management methods), use a new technology that has not been used in games before, be an implementation of a specific set of innovative game mechanics (e.g. modeling a system that has not been implemented before), be an analytical tool to study players, or be an educational game to teach a topic.
Each development team will need an expert who can explain the core research and assess whether the game is effectively exploring it. Thus, research topic proposals will be required to select a researcher to participate in the Singapore-MIT GAMBIT Game Lab summer program for the entire duration of June to August. The selected researcher will be required to visit Boston for at least the first two weeks of the summer program at a minimum. Selected researchers are also expected to collaborate with GAMBIT towards publication of the finished product: be it in academic venues such as conference or journal submissions, or through the professional game industry via festival submissions, commercial development or licensing opportunities.
SUBMISSIONS
Interested researchers should fill out this questionnaire and send it to Sara Verrilli (akiru AT mit DOT edu). All researchers currently receiving funding from GAMBIT should apply in this way as well.
Priority will be given to researchers funded by GAMBIT, Singaporean researchers, and researchers at MIT.
Now Accepting Applications: The 2010 GAMBIT Summer Program!
Applications accepted until January 14th - Apply Now!
What is the Singapore-MIT GAMBIT Summer Program?
The Summer Program at GAMBIT brings together students from Singapore, MIT, and other New England institutions to work on video games used for research at the lab. The program runs for nine weeks, from June 7th to August 8th, at the Massachusetts Institute of Technology in Cambridge, Massachusetts.
Who should apply?
We need interns to serve as: Artists, Audio Designers, Game Designers, Producers, Programmers, and Quality Assurance (Testing) Leads. Students currently enrolled in a Singaporean institution are eligible, and those with relevant skills, experiences, and course backgrounds are encouraged to apply. Applicants must also be at least 18 years old by June 2010.
How to apply:
All applicants must fill out and return the General Application and a copy of their resume on or before January 14th, 2010. Download the application from this site, and email the completed form to gambitsummer AT gmail DOT com. Include a version of your resume in the same email. Applicants for positions as artists or audio designers must also include a portfolio (details below), and programmer applicants need to complete and return our initial code test.
Once the general applications are received and processed, secondary tests will be sent out, due on January 29th, 2010. Not all positions require a secondary test, so not all applicants will receive one. After the tests are received and graded, interviews will be scheduled individually, but will likely occur in the second half of February and early March, with offers for positions being sent out in March.
Click here to download the General Application.
(Includes portfolio requirements and resume advice.)
Artist and Audio Designer Portfolios:
As mentioned above, applicants for Artist and Audio Designer positions must submit an portfolio along with their General Application. Portfolio CDs or DVDs are also due by or on January 14th, and should be delivered to:
Artist Portfolio Submission Instructions
Your portfolio should consist of between 10 and 20 examples of any type of two- or three-dimensional work you have completed recently. We suggest that your work reflect your interests, experience and abilities in the arts to date. It may be in any media, may be finished or in sketch form, and may be self-directed or from an assigned class project.
Your portfolio must be reproduced on a CD or DVD. We will not accept work posted on a website as your portfolio submission.
Each image should be submitted as a separate file in .jpg format. Individual file sizes should not exceed 3MB. Please do not affix any adhesive labels to your CD/DVD.
Time-based work or performance pieces may be submitted in video format or as QuickTime files on a CD or DVD.
Include a work description sheet. Number the examples you are submitting and on your description page list the corresponding number, medium, size, date of completion and title for each work. You should also include a contact sheet/thumbnail page of the images on your disk.
Please note: it is very important that your full name and address are clearly noted on your CD/DVD and your description and thumbnail pages.
Please note that we cannot accept physical original artwork, as these materials will not be returned to you.
Audio Designer Portfolio Submission Instructions
Please send us a portfolio of your best work on either a CD or a DVD. Include a brief description of each asset, describing what you were trying to accomplish when you created it. While we will accept audio designed for any medium, keep in mind that this is part of an application for a video game audio position. Things that would be particularly relevant are
Different types of audio (e.g. looping music, sound effects, voice)
Interactive samples (any games or software that use your audio assets)
Breadth in style (e.g. whimsical kids game, epic fantasy RPG, and serious war game)
GAMBIT UROP Opportunities Open House, Friday, December 11th from 4-6pm
GAMBIT is now hiring current MIT students for a potential 16 positions for the MIT IAP session (Jan 5 through 31).
WHEN: Friday DECEMBER 11th, 4-6pm
WHERE: NE25, 3rd Floor.
I invite you all to attend a meet and greet with the researchers at the Singapore-MIT GAMBIT Game Lab on FRIDAY, DECEMBER 11th, from 4pm to 6pm.
Each semester of the school year, we bring in student research assistants via MIT's UROP program along with students from some of the other regional colleges to assist our researchers with their work. This can range from helping a researcher collect data or create a tool for data collection, creating a game based on existing research, enhancing a game we already have, or creating tools or middleware for use with future game development.
Here are brief descriptions of the projects we'll be working on and the number and type of positions available on each:
Physics Deformation Library
Creation of a wrapper in C# for Unity 3D for existing research, plus a tech demo/game to prove that it works.
2 Programmers. Skills: C#, Unity
Glove/Hand Tracking Library
Creation of a wrapper in C# for Unity 3D for existing research, plus a tech demo/game to prove that it works.
2 Programmers. Skills: C#, Unity
Dream Logic Modeling Game
Creation of digital prototypes based on research into game puzzle logic and existing paper prototypes created this past summer.
2-3 Programmer/Designers. Skills: One or more of Java/Processing/Flash/Unity, writing Interactive Fiction
PAX Booth Game
Creation of an analog or digital prototype of an ARG/location-based game that will be played at PAX East in Boston in March 2010.
1 Programmer/Designer, and 1 Designer. Skills: PHP/Ruby/C#, experience in iterative design of game prototypes
Windows Mobile Sensor-based Game
Creation of a tech demo/game for the Windows Mobile platform using an existing library for accelerometer-style sensors.
2 Programmers. Skills: programming for Windows Mobile
The Sophocles Project
Design for a web site and blog for an ongoing research project.
1 Artist, 1 Web Designer/Developer. Skills: HTML, PHP, Movable Type, Illustration, Web Design
Abandon 2.0
Creation of new art assets for levels we created this Fall, and integration of them into the game. The previous version of this game can be found at http://gambit.mit.edu/abandon
1 Artist, 1 Programmer. Skills: Python, Panda3D, Illustration
Molasses
Level creation for an existing game based on the Boston Molasses Disaster.
1 Programmer, 1 Level Designer. Skills: C#, TorqueX, Unity, level design
We pay the same rate as the UROP direct funding pay rate (about $9.35/hour) or credit, and are looking for people able to work 20-30 hours per week during the IAP period as well as work 10 hours/week in the Spring semester. Please still apply if you can only work during the IAP period - some of our projects will only last during this month.
PLEASE EMAIL Rik Eberhardt (gambit-request@mit.edu) with the type of position you are interested in, a brief statement of intent why you are able to fill this position, and your availability for both the IAP (Jan 5 through Jan 31) period and the Spring (Feb 1 through May 15) period.
More information about work for the Spring period will be sent later this month.
2010 Global Game Jam registration for the GAMBIT site is closed.
The Singapore-MIT GAMBIT Game Lab will be a host site in the Boston/Cambridge area for the 2nd Annual Global Game Jam, from January 29 through 31, 2010. Other sites around the world will run game jams with similar rules and limitations, with one unique constraint at each site.
Update: as of January 8th, we now are at our limit for registrations. We will re-open registrations later in the month if more space is available.
How it works
A game jam is a cooperative gathering of game developers to encourage experimentation and innovation. It starts at 5pm on Friday with friendly introductions, followed by a run-through of the rules, the theme, and the constraints. Participants then quickly come up with ideas and pitch them to everyone else. Once everyone has formed or joined a team, the groups split up for further brainstorming around the idea, and reconvene in a shared workspace with the other teams to start development.
Finished games are handed in at 3pm on Sunday, after which everyone plays all the other games and votes for their favorite. The winners get kudos, and bragging rights. All finished games will be uploaded to the Global Game Jam website.
Some constraints
Participants should go home for a shower and a good night sleep in the evenings. The workspace will be closed from midnight to 9am in time for the last subway train. Breakfast will be provided on both mornings. Participants may choose to pool their funds for lunch or dinner delivery or may opt to eat at nearby establishments.
The rules of the game jam prohibit the use pre-made content (this includes program code, audio, graphics, models, etc.) unless it was publicly available at least a month prior to the game jam. Contact reberhar AT mit DOT edu if there are any questions.
Registration
Registrants must be over at least 18 years old to participate. The jam is largely targeted at game development professionals and college students with game development experience. Participants should not plan to register as teams. The jam is limited to 30 participants, with last-minute priority for professionals. There is no fee for registration.
If space is available, participants should receive an email confirmation within a week.
Location and Timing
The game jam will be held at the Singapore-MIT GAMBIT Game Lab on the third floor of 5 Cambridge Center, Cambridge, MA. Participants should plan to arrive well before 5pm on Friday, January 29, 2010 and to participate for the full duration of the event, which should conclude by 6pm Sunday, January 31, 2010.
Despite their soul-crushing difficulty, we can't stop playing 'em... This Friday, we'll bring out a couple of games renowned, even appreciated, for their well-designed and considerable difficulty. We'll start at 4pm, and Matt Weise will present a short talk about Demon's Souls at 5pm. Other games include Mega Man 9, Battletoads, and Ninja Gaiden Black.
At a recent open playtesting session I had the latest build of Pierre: Insanity Inspired running, hoping to get an idea of just how hard the game is and whether anything should be done about that (with only six levels your difficulty curve can easily become a wall). During the course of the night I had a rather interesting encounter with one tester in particular.
For those of you unfamiliar with the game, Pierre follows the adventures of an eccentric artist cat who may or may not be insane. The gameplay takes place on a rotating disc. The titular character, Pierre, is moving around on the outer edge of the disc, which is being bombarded by various falling objects. Some of the objects must always be avoided, and others must be collected at certain times. The game's research goal is to investigate how different types of failure communication can affect player performance. In other words, does the way we tell you that you screwed up matter?
To emphasize the failure feedback, we created a secondary character who pops onto the screen to yell at the player when he or she is hit by a hostile object, or collects an object at the wrong time. The aforementioned tester asked me what the relationship between the two characters was, and I answered honestly: I really do not know. Said tester informed me that my lack of knowledge was "inexcusable," which I found to be a rather intriguing - if slightly hostile - response.
The question is an interesting one, though I had only considered it in terms of authorship and intentionality. Playing the game, it seems to me that the unnamed character does have a relationship with Pierre: in some instances it would seem he wants Pierre to succeed, otherwise he would not get so angry when the player does something wrong. At the same time, when the player fails a level, the character is seen in the background, laughing at and taunting Pierre and the player. Sometimes he is frustrated by Pierre's failure, sometimes he relishes it. So what is going on here? One might point to the title, noting that Pierre himself is probably what "insanity inspired" refers to, hence we cannot take any of his perceptions at face value. But the unnamed character is often addressing the player, not Pierre, and so cannot be a product of Pierre's mind.
During the design of the game our focus was on addressing the research question. Adding a secondary character was merely a way of emphasizing the feedback to the player. Given our intentions, are questions such as "what is the relationship between Pierre and the unnamed character?" even meaningful? A better question might be, "what do you think that relationship is?" Or more importantly, "why do people infer or desire a relationship?"
Although it was never stated outright, I always felt that we were relying on what Scott McCloud calls closure - letting the player fill in the gaps with his or her imagination. There is a lot of space in the game's plot and world, space that - I would hope - the player feels free to complete for his or herself.
To return to the aforementioned tester, then, I wonder what they think of other games with light characterization. Certainly Miyamoto had his characters in mind when designing Donkey Kong, but what are we to make of the relationship between Pac-Man and Blinky? Or Q*bert and those spring-like snakes? Did Mario and Luigi fight a lot growing up? Why are the Black and White kings trying to kill each other? And do these relationships even matter?
In analyzing any work - be it literature, film or games - we tend to think about who the characters are, why they made the choices they did and what might have happened differently. But characters are not people. They do not have agency and they do not make choices. Characters are just devices, like metaphor, irony, or game mechanics. Pierre's unnamed antagonistic cheerleader serves his function, and I am happy to leave his existence at that.
You are free to come up with your own interpretation.
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.
When we last left off, I had just introduced our nameless super market clerk, a poor boy stuck in a nightmarish world where customers speak in gibberish and the aisles sob with loneliness. We wanted to be able to implement some of the more abstract concepts into playable mechanics. One of the things we had discussed in length was the role of objects in dreams. Nouns often appear in place of complex ideas. Often, people have reoccurring nightmares about their teeth falling from their face. This is generally interpreted as a manifestation for anxiety or worries in the dreamer's mind.
BACKGROUND
To examine this idea, we came up with a fairly straightforward scenario. The set up: the customers have run into each other, spilling the contents of their bags every which way. You, the clerk, must return the proper items to each customer, but which items belong where? The player is cued to the customer's 'theme' by the objects that are still left in the bag (a horseshoe and a rabbit's foot, for example). Once the player determines the relationship between these items (they represent 'luck'), they can easily identify the final element that lies amongst distracter items on the floor (a four-leaf clover).
Here are some early combinations we proposed:
- Horse Shoe, Rabbit's Foot -> Are Lucky -> 4-Leaf clover
- Slugs, Butter -> Are Slippery -> Soap
- Pita bread, Pants -> Have pockets -> Kangaroo
- Donuts, Swiss Cheese -> Have holes -> A tire
- Balloons, Ice -> Do Float -> A rubber ducky
- Mentos + Coke, Baking Powder + Vinegar -> Do Explode -> Dynamite
- Donuts, Swiss Cheese -> Holy -> A cross
- Honey, Bubble gum -> Stick-y -> A stick
- A Door, A Can -> Things you open -> Your mind
- A Train, An Orchestra -> Things you conduct -> Electricity
It's important to mention a couple of things about the grouping here. I've mapped them here to 'Are', 'Have', 'Do', Wordplay, and Abstract Wordplay. Only the first category is truly representative of dream logic. Here, items are characterized as prototypically lucky or slippery. The second group is classified by properties- kangaroos, pants, and pita all have pockets. The third group is based on word play. Donuts are 'hole-y' and a cross is 'holy'. The final group is based on more abstract wordplay. You can open up a door, a can, or your mind. These groups are purposefully ordered by difficulty-level as prototypical traits are necessarily more readily identifiable than abstract associations.
IMPLEMENTATION
Each item was represented on a game board with two sides: one for items in the bag and one for items on the floor (See Figure 1). Each 'target' item on the floor was mixed in with two 'distracter' items. The player was only given one guess in order to avoid random guessing. Because of my impeccable artistic skills, players were allowed to ask about the identity of the objects. This became important particularly for some ambiguously drawn items. A bag of ice (what I drew) does not necessarily cue 'floating' as well as a single ice cube (what was intended). Figure 1. Implementation of the 'Objects-as-Metaphors' Mechanic. (Top) The player was given a pair of pants and a bag of pita on the left hand side. From this, the player was expected to deduce the relationship of 'has pockets' to items in the bag. The player could then apply this expectation to the right-hand side of the board to pick out the 'has pockets' object, the kangaroo. (Bottom) The player was given a bottle of honey and a piece of bubble gum. The player was expected to deduce a relationship of 'is sticky'. From this, the player could identify the stick as itself 'stick-y'. This argument required the use of word-play, which was not accepted by some players as consistent with dream logic.
RESULTS
Test players performed much better on characterization tasks involving 'is' or 'has' than 'does'. For instance, the 'has pockets' condition was immediately identified by all testers. Neither of the testers were able to identify the ice and balloon as 'do float'. There are a couple of potential reasons for this. I already discussed the first possibility, that I am not much of an artist. This was more or less compensated for by a re-drawing of the ice so that it was not contained in the bag (which confounded the first trial, wherein the player focused on the bag as a container for ice and the balloon as a container for air) and by allowing testers to ask questions. Interestingly, both testers also identified the objects in this trial as belonging to a 'set', wherein one object is similar to the other in some ways, but different in a particular other way and thus the third object should follow this pattern. For instance, one tester identified the balloon as containing a gas, the bag of ice as containing a solid, and guessed the distracter item, vinegar, as the item belonging to the bag because it contained a liquid. This was a valid guess (though not the one we were looking for) and should be considered for future design. This also raised the issue of object selection for the distracters. Our secondary tester grouped the balloon and ice with a top hat, because all three belonged at a party (also a valid conclusion). One tester also rejected the logic behind the word puzzles because he doesn't "dream in homonyms" (again, a valid point).
Regardless of logistical implementation issues, we determined this prototype was not necessarily the direction we wanted to proceed in with the dream-based game. The logic, while intriguing, did not lend itself to a story and did not directly involve the personality of the supermarket clerk. While the use of metaphor was acknowledged as relevant for future prototypes, it was determined that the mechanic could be put to better use in an adventure-game type setting than on its own. Furthermore, it was stressed that we should be taking a deeper look at the goals, desires, and motivations of the individual dreaming the dream, a notion to which this prototype did not lend itself.
How would a person's profession, interests, and hobbies manifest themselves within dreams? How does this work with dream logic?
This is the idea behind the prototype I'm working on for Clara. I wanted to think of something that a person working at a supermarket could possibly experience that would give them nightmares. How about terrifying shopping carts that act suspiciously similar to the friendly creatures in Alfred Hitchcock's The Birds? The prototype itself is laid out so that the player can see the entire parking lot, free spaces, and obstacles as well as the carts. The core verbs for this will be "run" and "throw" since your only defense against the carts will be taffy (my highly researched guess as to what shopping carts fear).
Initially, I imagined the carts moving similar to birds in real time. Not necessarily in a "v" formation, but in some kind of grouping where the carts can break off and "dive-bomb" the player, all while remaining on the ground. If the cart gets within range, the player will have to retaliate at the proper time or receive damage. To keep the game interesting, the carts would eventually encircle the player and they would have to break through the formation by attacking more than one shopping cart.
However, after thinking about this set-up for a while, I decided to go with something slightly different for the actual prototype. Instead, the shopping carts will only move or change position if the character turns around. I imagined the character having an irresistible urge to look back as they walk. Every time that happens, the carts rearrange themselves so that they are within attacking range of the player. I tested this with Clara in the very early stages of this and many problems were brought up. For one it was too easy to just use the taffy to get rid of the carts. I didn't think of creating grids on the board, so player movement was not clearly defined. Also, the game seemed to deviate from what Clara originally requested. The idea seemed interesting, but execution gets a 3/10.
Now I am back to the drawing board and am trying to a new approach. Clara suggested looking at this through the mind of the character and trying to inject their personality/interests/etc. into the actual game. Maybe the character arranges carts at the supermarket constantly and suffers from OCD as well. How can I communicate that through not just a narrative, but also through the game mechanics? What would be the best way to combine the character's personality, mostly their OCD, with pattern recognition? Hopefully I can find a concrete, interesting way to implement all of this for the next prototype.
Dream logic is a distinct entity from the rational thinking we encounter in everyday life. For our most recent project, the prototyping team has begun exploring the prototypical dream experience in order to exploit this unique thinking for a dream-based game.
A brainstorm session revealed some key highlights about dream thinking:
- Concepts can be at once more clear and more obscure
• Certain ideas can only be fully realized in dreams, like the structure of benzene ring represented to Kekulé as a snake eating its own tail. The metaphor of the snake is an obfuscation of an idea, yet is also a clearly defined message to the dreamer.
- Commonplace actions become extraordinarily difficult, while extraordinary actions become trivial
• Riding a horse may be intuitive to the dreamer, though they have never seen one in real life. Brushing one's teeth, however, may become impossible.
- Space and time are easily obscured in dreams
• This was compared to the forest maze found in many RPG's, or the cave maze in Monkey Island, where only one pattern will correspond to a feasible mapping of space
From here, we began to construct individuals who may generate interesting scapes for our dream logic to be applied. A stressed student might dream about a code that comes alive, where literal bugs crawl out of the screen. A shy child might dream about a forest of legs, where the only escape lies in tapping each knee with a lollipop to see through the thicket. A pizza delivery boy/ quarterback might dream of a row of angry houses, each one attempting to gobble him up. Only by throwing the toppings into the house's mouths can the boy hope to survive.
We settled initially on the idea of the supermarket clerk who dreads every day of work. Everyday tasks become impossible for the boy as he moves his way though the aisles. While restocking, the items move around behind his back. Customers speak gibberish and run into each other, scattering their items across the floor. Without a common language, he must decipher the commonalities between the items in the customer's bag and the items on the floor in order to return the items to the proper owners. But in the bags, he finds absurd objects-- 2-day old shrimp, tires, sticks, and turtles. The aisles all whine about their problems. One is lonely, another is on fire. How can he help them? The greeting cards begin to shout at him as he rushes down the aisles. Only if he puts them in order will they cease to chatter. Finally, outside, he believes he's reached an escape. Alas, the shopping carts gather and stare at him, as if a pack of ravenous crows. He must return inside in order to survive.
Stay tuned for part II, where I'll talk about the implementation of some of these ideas into early paper prototypes.
Earlier this week (or possibly last week, depending on when this post goes up), Genevieve posted a blog entry about creating a word game for the Sophocles team. As she noted in her post, our group of 4 split into two teams of 2 to work on different concepts. I was in the group that did not contain Genevieve, so I thought perhaps I'd write a bit about the idea that our half of the team came up with.
Our prototype, like that of Genevieve's group, required the player to use words to form a bridge in order to cross a gap. It's not a coincidence that both groups prototyped games involving bridges; the idea of building a bridge out of words or parts of words was discussed in the brainstorming that we did before splitting into two groups. However, as with the dog-and-girl prototyping at the beginning of the semester, the two prototypes managed to be quite different while still adhering to the same basic concepts of words and bridges.
The thought process that resulted in our group's game went something like this: "What is unique about words; what are their defining characteristics? ...Well, words are made up of a limited set of smaller individual components (letters), which can be arranged to form larger entities. But the other group is already exploring that aspect of words... But words also have meanings associated with them and enable people to communicate. Could you make a game that explores words and meaning?"
...and I think that's how we ended up with a game where you have to translate a stream of gibberish from a guy standing on the other side of a ravine and wearing a weird hat (he wears a weird hat because we needed a way to differentiate the player from the crazy gibberish-speaker in sketches of possible game layouts, and giving the crazy guy a crazy hat was an easy way to do that).
Specifically, our team created a game where you (or rather, your avatar) and an NPC are standing on opposite sides of a ravine, and he starts telling you a story, sentence by sentence. However, some of the words he chooses to use are unfamiliar, and you must translate them. For example, he might say, "The other day I was walking down the sidewalk and I found a baby bird that had fallen out of its gleeble." In this case, context would hopefully lead the player to conclude that 'gleeble' means 'nest'. Then the man might say, "The gleeble was at the very top of a tall bloggin," and the player would have to deduce that 'bloggin' means tree.
The man would then continue to tell you his story, and every sentence would contain a higher proportion of nonsense words. The trick is that all but one or two of the nonsense words in each sentence would be ones that you'd encountered in previous sentences. So maybe he'd say, "And then a bloggin furpled on my klonker, so now I have to vob in a swippy in the glopp," and the player would remember from previous sentences that bloggin = tree, klonker = house, vob = live, swippy = hole, and glopp = ground, and so would be able to guess that "furpled" means "fell", and what the man is actually saying is "And then a tree fell on my house, so now I have to live in a hole in the ground."
Then, once the man has finished telling you his story and you've learned all his weird words, objects start to appear in the ravine that separates you and the man, and as you speak the words for those objects, the words appear in the air and form a bridge to the other side.
One of the biggest obstacles we've encountered so far is agreeing on how to spend our time. Level of detail is a big issue. Since we are working for only a short time on a game, we'd like to stay more or less on the 'big picture' level. However, in order to really discuss a game idea, you have to look at some of the details or else you are ignoring what makes the game unique.
At one point, we began making a spreadsheet of all the unique objects in our prototype game. The point was to be able to deduce a general nomenclature or way of speaking about how the objects interacted on the player's goals. This seemed unnecessary in a lot of ways because it meant spending a lot of time sitting around talking about what the cat 'might' do in any given situation. Since we didn't have the cat in front of us, it was rather easy to neglect certain ways in which the cat could interact with the object (it could come from behind, it could approach it diagonally, etc.) Furthermore, when we did identify a tricky situation, our solutions were primarily artificial. They were created in vitro, if you will, away from the living creature. They would not necessarily make sense in game or to the player.
This gave way to an overall sense of urgency just to 'play' and figure out what would happen from there. Play-testing was a great way to identify the gaps in our thinking. From our play-throughs, we were able to better organize our thinking. On the other hand, play-testing meant we were much more likely to get hung up on details. If we wanted to make a functional prototype, we needed to have a very narrowly defined set of rules that were consistent across all play times. This meant sacrificing a good deal of creativity and invention. We had to allocate all of our time during this period to making one singular idea work. Even though we had many different ideas of how to approach the general concept, we were forced to focus on the details of this one idea. This led to a good deal of frustration and perhaps a more narrow mindset then was appropriate for such an early stage of design.
Obviously, this can be somewhat compensated for by splitting the group and working on multiple conceptual ideas at once. However, this does not totally address the issue, since the actual prototyping stage still limits the freedom of the designer. I think the main lesson learned is that there is an overall role for both of these processes (the creative, free-flow, no-limitation of verbal analysis and the more constrained, practical approach of play testing). The important thing for the team will be to balance creativity with practicality. Similarly, we will need to be able to problem solve any major flaws in our design, while avoiding getting too caught up in the details.
One nice thing about using mostly c# for development is that reading in input files is reeeeeaaally simple. It's just your basic file reader and parser.
Right now my main scene gives my Level_Importer a file name, and Level_Importer returns an ArrayList of the objects in the scene (only walls for right now, I don't think that the levels store enemy information).
So now my characters can run around real levels... if I could only get my main character to move. I'm using my old Lizardman guy right now to move until I can get some help with Maya.
Even now, when I'm more or less familiar with Unity, I occasionally make dumb little mistakes. For one thing, I keep forgetting that any settings that I change in Play mode will reset themselves when Play mode is turned off. Today, I've been reminded once again to be very careful when selecting a Unity object by clicking on the object directly.
I first discovered the problem when my avatar began bumping up against an invisible object. I thought at first it might be a wall I couldn't see from this angle, since planes in Unity are only visible from one side, but there didn't seem to be a wall anywhere nearby.
I moved the avatar around some more and discovered another spot where it behaved oddly, this time climbing on top of a phantom object. About then, I remembered that there had previously been an object on that spot which the avatar had climbed on top of when I moved it there. Was my scene being haunted by the ghosts of objects past?
A little investigation turned up the problem. Earlier, I had indicated some objects I wanted to move by clicking on them directly, rather than selecting them in the hierarchy. As a result, in each case I had actually moved one of the children of the object, not the object itself. The part I moved contained the mesh renderer and all the visual components, so it looked as if I had moved the whole thing, but I had actually left the collider and all the physics components behind--hence the phantom barrier my avatar had encountered.
Here's a picture of my avatar with the phantom bathtub:
The silver lining is that this incident led me indirectly to the solution to a different problem: it explained why the chasers hadn't been turning black when the script told them to. Because the visual components were in the child object, I should have told the child to turn the object black, rather than adding a renderer to the parent. Now if I can just make that work in a script...
Currently I am trying to import the maya assets from Abandon into Visual3D. This doesn't seem to be a complicated process at all, except for the fact that I have no idea what I am doing. Any artist would be able to figure this out, but I'm completely lost trying to navigate around Maya. I think that I need to export the mesh with the animations into Orge format, but I can't seem to get the animations to go with the mesh and skeleton.
I need the animations so that my character will move (it doesn't move without an animation for some reason).
If I got that working, the game would actually look pretty similar to abandon. The only things I would need to add would be enemy behavior (which may be complicated) and a way to import levels with text files (which should be pretty easy). After that, it's just a few tweaks until the level looks pretty close to the original game.
-thumb-175x218-1852.jpg)
