Global Game Jam VIII, January 29-31, 2016

Another year, another Global Game Jam!  One of my favorite events of the year.  This time was different in that I came to this one with a team already prepared.  We had met a few weeks prior in preparation of the Cartoon Network Game Jam (much more about that later!), and we were looking at the GGJ as a practice run for how well our group would work together.

This year's theme was "ritual", which is an awesome word to build around since it can be interpreted many ways.  We opted to go with a more traditional interpretation, where the player would perform a series of small rituals/tasks.  From the set of diversifiers, we focused on not using any dialog or cutscenes within the game, and creating a non-violent game.

What resulted is Life of Lumby, where you guide the titular character through various stages of his life, performing a set of rituals to aid his community and gain favor with deities.  

Download and play the game here!

On the positive side, the game looks and sounds great.  It was an interesting challenge to have created a kind of game that's more of an "interactive experience"/story-based game than anything technically complicated.  As such, we didn't really have much experience telling a story through game, so our design was a bit disjointed and required us to take some time during lunch on Saturday to flesh out some of the specifics.  Additionally, while we managed to get all of our minimum design requirements in and (mostly) working by the end of the jam, our cohesive story and overall vision didn't quite make it through.  For example, one idea we focused on was to have Lumby ascend and reincarnate once he's completed his rituals (and his life)...that's only hinted at with the white-out at the end of the game.  We realized we could have done more to incorporate additional ideas - such as more NPCs - even if they would have been programmer art.  

Overall, I'm pleased with how everything turned out.  I'm particularly glad how well our team has gelled over the last few weeks - be on the lookout for more great stuff from us soon!

Global Game Jam VII, January 23-25, 2015

There have been some changes in my life recently, the chief one being my move to the greater Portland, Oregon area.  But that doesn't mean I was going to miss out on another Global Game Jam.  It was through GGJ that I was able to find the local Portland indie game community PIGSquad.

There were a couple major changes to how PIGSquad runs their game jams over how I'm used to them being run in Boston.  First of all, our jamming space at the Art Institute of Portland was open for the full 48 hours, whereas in Boston we were encouraged (and required) to leave at night for sleep.  Thankfully, I live fairly close to Portland, so I had no problem commuting back and forth.  The last couple jams in Boston required me to venture back and forth for an hour's drive each night.

When we used to form groups, we would get the jam theme, come up with ideas, and then pitch them to the entire group.  We would then form groups based on who wanted to work on certain projects, making sure each group had an appropriate spread of disciplines.  This was great for starting off with a relatively clear vision and being passionate about the project you're working on.  The tradeoff here was group members, with varying degrees of experience, sometimes struggled in finding a common technology to work with.  In Portland, we started off forming groups first, and the theme was presented to us afterwards for each group to then come up with their own idea.  I can see how this can be an advantage to some people, who already know who they like to work with (if they like to work with anyone at all), and you can form groups around the technology being used.

It was this group forming first that I think my group hit a bit of a snag.  The diversifiers (optional constraints to use on your project) for this year's jam were released early, and one that interested me the most was "Chimera", to make a combination digital and non-digital game.  It was relatively easy to start rounding up the people who expressed an interest in creating a board/card game, but since the computer component, and the design of how the pieces were to interact, was so up in the air, we recruited quite a few more people for the computer part than was ultimately necessary.  It's not that everyone didn't contribute in some way; I just personally felt we could have been more efficient as a group.

Our game -  Space Goats: Galaxy to Galaxy

The board game half of the group ended up designing most of the game, and the name must have sprung up as a kind of joke and ended up driving a lot of the aesthetics.  The game is presented as a card game for 2-6 players.  You draw Resource cards to boost your defenses, and Action cards which help you earn more Resources or redistribute what you already have.  Starting with the last player, at the end of your turn you then use the computer component (we designed it as an app, so a mobile device could be easily passed around between the players), where you set off a bomb with a timer to explode after a certain number of turns.  The bombs can either destroy a certain type of resource, or destroy half of your total resources.  There are also options to delay the timers of the bombs already in the queue.  If you don't have a particular resource available to destroy, you can substitute 2 of any other resource to make up the difference.  If you don't have any resources you are out of the game; the last player remaining is the winner. This results in a very fast paced game, as the longer it goes the more likely it is multiple bombs will explode on a given turn.

What we did right: I'm glad we ended up with a overall simple game. It's quick and has a goofy charm, with Space Goats and Rocket Chickens and such.  While there can be a bit of strategy involved, particularly with small number of starting players, the real joy is bombs exploding and reacting to the consequences.  While modern game design eschews eliminating players from participating, the game is fast enough that the next game is never too far away.

Looking back, it's probably for the best that our digital component is as simple as it is.  When I first heard about the diversifier, I was trying to brainstorm ideas on how to incorporate a board game into a complex digital game (like an FPS).  We talked to some people present during our recruiting phase about the possibility of augmented reality or code readers.  Even early in our design phase, we discussed ideas about two simultaneous games, and how the digital players could interact with the board game players and vice versa.

What could go better: As I mentioned before, we didn't start with any kind of pitch or vision, so we overbuilt the team.  I'm happy to include first-time jammers, and certainly you're going to get varying levels of experience.  I guess I was just a little disappointed that the digital component could easily have been completed by one competent person in an hour or two.  I think I was expecting more from the digital side, but that might have jeopardized the project as a whole.  It's a learning experience, and good to remember when team-building for next time, if anyone wants to do a hybrid game.

I also would have liked a bit more wider coverage of the distribution of the digital component.  we designed it and worked around a 1080p resolution Android device.  I would have liked to have seen it on an iPhone (I didn't realize you needed an actual Mac to get that far; something I probably should have learned long ago), and the screen gets funky when trying to run the stand-alone version.

Check it out for yourself here!

Global Game Jam VI, January 24-26, 2014

Once again it was back to MIT for my sixth year participating in the Global Game Jam.

This year, the theme went back to phrases with "We don't see things as they are, we see them as we are."  I can see how such a vague phrase opens up creativity, as opposed to the last couple of years (an ouroboros and a heartbeat).

The logistics worked slightly differently as well.  We were back in the same old familiar classrooms in building 26, though the big change this year was that not all meals were provided.  This makes some sense, as there's usually a lot of leftover food anyway and I'm sure they're trying to save money.  Still, walking back to Kenmore Square to find lunch in the bitter cold was something I would have preferred not to do.

I ended up on a team where the pitched idea had to do with two players navigating a maze, where one player could see objects the other player couldn't, and vice versa.  We spent quite some time talking over the design, figuring out what there was to do in the maze.  For example, one idea early on was to have a player-monster chase the other player, but the cameras were attached to the opposite character.  (Luckily that idea was dropped...thinking about it, that probably would have been a horrible experience to play.)

The idea coalesced into what we named A-Maze-ing Co-Op (brilliant, I know).  The artistic theme we were aiming for was this kind of temple exploration, one player was a human and one was a robot - we ended up with only the floating robot due to time constraints - the human could be hurt by traps he couldn't see but was the only one that could disarm them due to his opposeable thumbs.  The robot's job is to seek out and mark the traps so the human knows which areas to be cautious around...and the robot can't see the trap keys, for whatever reason. The traps and keys take the form of pedestals with certain shaped holes, of which there is a matching key elsewhere in the maze.  The idea is to disarm all of the traps and then both players need to exit the maze together.

What went right: The scope of the actual gameplay was kept fairly small, so we were able to get a functionally-complete game done by the end of the weekend which was moderately fun to play.
Our original plan was to have each player on their own client, with the games connected over the network.  I was trying to get a very simple server-client model set up in Unity, but by lunchtime on Saturday, whether it was faulty code or the inexplicably slow MIT network, it just wasn't in the cards.  Thankfully the gameplay did not require separate machines, and I'm glad we made the decision to alter the game into a single-machine split-screen game with each player using their own set of controls on the same keyboard, that we could focus on the game and not trying to get network code to work.

What could go better:  Source control was a huge headache for us.  We opted to use GitHub, since free is good, but we only had a small amount of experience using it between us.  Git doesn't provide a lot of useful intuitive information when it's performing its actions.  We wound up with 3 repositories, 2 of which were false starts just trying to get a mostly empty project established for us to share.  I believe in source control, and I know how it works fundamentally, but I'm going to need to work with Git some more to get comfortable with it.

What to do different: Perhaps another half-day would have been nice to give the game some polish, and had some other people playtest it.  We had one of the audio designers ask us if we wanted sound for our game - that would have been nice to have, given some better planning or a dedicated sound person on our team.  One of the projects I'd like to work on coming away from this is to develop a procedurally-generated maze in Unity, since this and last year's project would have benefited from that from a replayability perspective.

Links:
The project page on the GGJ site
Play the game here!

Global Game Jam V, Jan 25-27, 2013

Once again, it was Global Game Jam this weekend!

I was again jamming at MIT, though now that the MIT Game Lab has dropped the GAMBIT part and moved onto the main campus, the logistics were a bit different this year.  The presentations were held in one of the auditorium-classrooms, and everyone jammed in some of the classrooms in building 26.  They were pretty lax about the food, which was nice, compared to the Boston FIG Jam which was held in the same rooms.  The funny thing is, I've only been to MIT a handful of times, but every time has been in these same classrooms - despite the large campus, I'd think these were the only classrooms available in the entire school.

The theme this year was another simple one - a heartbeat.

I had brainstormed a bit with one of the sound guys there, and ended up with a game pitch where sound factored heavily into gameplay, because of course.  However, he decided to go with another project, and I ended almost by myself, though awesome sound designer Dan Perry opted to join the project.  I had worked with him a couple years ago on the Punk is Dead project.

Sound Maze

Yes, a rather uncreative working title.  The game is a first-person maze/labyrinth navigation game.  It takes place in two parts - the first half where you maneuver around normally, as you might expect with any videogame.  When you grab the icon in the center, the game shifts to the second phase, where you have to find your way back out in near-total darkness, using your sense of hearing to guide you.

There are two mazes here, so finding your way back out is not as simple as retracing your steps.  The original pitch included the idea that the "visual" maze remained visible while you had to navigate the "audio" maze - open passageways might be blocked, and you could walk though some walls on the screen.  Luckily, the overall game design was simple enough that the prototype was finished fairly early on Saturday, and we were able to playtest it.  We had found that our progress in teaching the player to navigate by sight was negated by literally changing the rules midway through, and it was very frustrating and confusing trying to push in certain directions fruitlessly.  So, we changed it to darkness, where your sense of sight was instantly disabled.  The goal object in this half emanates a heartbeat, which gets louder as you approach - this came from a thought I had about not approaching a sound, but rather you hearing your own heart beating in your chest as you approach the end.

A lot of the tweaks from there on involved adding hand-holding for players.  None of the feedback systems (player movement, sounds when approaching walls, sounds when hitting walls) are terribly robust, so a player can get lost or frustrated quickly.  So, the "sky" was set to a very dark gray rather than black, so there is a little bit of light available.  We also added lantern flashes, crudely added as the walls lighting up, to give the player a brief glimpse of where they are.  We also found, with the mazes I had slapped together, that reaching the goal in the dark half required the unintuitive task of moving away from the heartbeat (where the goal was) before rounding a corner and heading back.  This was fixed by altering the hidden maze a bit to avoid backtracking.

What Went Right: Thankfully the design was simple enough that I felt the game was adequately complete early on, allowing for time for tweaking rather than trying to get it to run at all.  Since I decided upon a 3D first-person perspective, I felt Unity was a good engine to develop in.  While I don't have a lot of experience developing in Unity, I know the basics, and I felt this was a great opportunity ti dive in and have a "trial by fire".  And because I was the only developer, source control wasn't a great concern as everything was saved on my machine.

What Could Go Better: That being said, ideally I would've liked at least one other person, familiar with Unity, to have been on the team.  A lot of really basic things probably could have been solved early on (and special thanks to Michael Carriere and Alex Schwartz for helping me with such issues) that could have left time for more feature development.  An artist of some type would have helped too, whether it was by making the game not look so ugly, or perhaps helped with the lighting to aid gameplay and provided a better sense of atmosphere.   One of my stretch goals was to include randomly generated mazes, which might've happened if someone else was there to share the burden of development.

I'm really pleased how the game turned out, though, despite the prolific "programmer art".  Further tweaks that could be made are cleaning up the movement and audio feedback, sound optimization, and the aforementioned random mazes.

Another nice thing about programming the game in Unity - not only does it run on PC and Mac, but you can export a web build!  So you can play the game right here - like I said, the sound needs optimization, so it'll take a while to load...please be patient.

Global Game Jam, January 27-29th 2012

This was the fourth annual Global Game Jam, and I've been lucky enough to attend every year - it's an event I look forward to.  Aside from the usual "achievements" (optional restrictions to help focus your game designs), this year's theme was pretty simple: an ouroboros.

This year's theme. This exact thing.

Luckily, an image such as this can be interpreted several ways, and the game pitches reflected that.  The team I ended up on took the theme a bit more literally, borrowing a concept from American folklore: the hoopsnake.

What Went Right

Our goals for this project were to build on what has been successful in previous years: keep the game simple, and keep the humor high.  In that regard, we did quite well.

Hoopsnake! is a side-scrolling platformer, utilizing only one button as the game mechanic.  The hoopsnake constantly grows larger; grow too large and he'll fall apart, Game Over.  Press the space bar for him to take a bite of himself to get smaller; go too far and he eats himself out of existence.  You want to be small to fit through narrow passages, and you want to be large to be able to catch yourself on ledges after being propelled up by spring-coil copperhead snakes.  Eat all the doughnuts on the level to continue.

The humor is best exemplified by the soundtrack.  When you hit a spring-snake and are propelled upward, the game goes into a bullet-time state, and a bit of The Ballad of the Hoopsnake plays (also available as a separate track).  The overall goofiness of it earned us a standing ovation during our presentation.

What Went Wrong

Our team of programmers (myself included) didn't feel particularly strongly about a game engine, so we tried to pick something that we could all share.  Ultimately we settled on Java, using MarteEngine.  We made it work, although it's not the best engine for the design we had.  Most notably, MarteEngine is a tile-based platformer engine, where something like Hoopsnake! may have better benefited from something smoother or vector-based, like Flash.  As such, we had to get around this weird problem of the hoopsnake effectively falling down stairs, instead of rolling down a hill.

I felt the art could have been crisper, as well.  MarteEngine uses sprites, and one of the issues I worked on was making the animation of the hoopsnake work.  There was a lot of futzing with sprite animations and scale percentages, and ultimately we couldn't get it to look the way we wanted - but it doesn't matter so much because the hoopsnake rotates so fast that you'd barely notice the animation anyway.

As is usually the case with these projects, it would have been nice to have a bit more time at the end to polish what we had and focus a bit more on level design.  I feel it looks a bit clunky and rushed, but then again, it was only built in a weekend!

What to Improve

I think the successes of Hoopsnake! outweigh its shortcomings.  I only wish I had the time and money to learn several game engines to be better prepared for working with other programmers, or to invest into a single game engine, take the lead on the project, and be able to teach others.  But, that's more of a personal problem, and I enjoy tackling this problem with more game jams.

Download the Hoopsnake! project at this page.

Global Game Jam 2010 Postmortem

I participated in the 2010 Global Game Jam, held (among many locations) at the Singapore-MIT GAMBIT Game Lab in Cambridge. I did it last year, and it was so much fun I opted to do it again, despite the fact that I haven't had a free weekend yet in 2010. (We've been in something of a crunch mode at Quick Hit.)

The theme for this year was "deception" and "abstraction", as well as the local constraints of "rain, plain and/or Spain". The project I worked on was called Define Yourself. The original pitch was that you started out as some abstract avatar, and your actions at the beginning of the game determined how the character was defined until you were much more fully realized. We were throwing back and forth ideas as we discussed game design on Friday night, when we developed the core concepts of an exploration space. Eventually concepts crept in borrowed from fellow programmer/developer Darren Torpey about an idea he had about a Facebook college simulation game. The game, as it stands now, is more that as a freshman entering college, you are very loosely defined as a person (abstract, if you will), and the choices you make in college - which classes you attend, how often you socialize, etc - define who you are by the time you graduate.

I think I'll move onto a list to outline what went right and what went wrong in typical postmortem fashion, but it's not to say it wasn't fun, that it's not a bad game, and that these aren't in any particular order or importance. I am not placing any blame on anyone for any perceived failures; I'm just mentioned who worked on what on the team.

What Went Wrong

• The initial design. Of course, with a game jam game, with the time constraints and the limited options you're given, either you come up with something simple and you do it and that's it, or you come up with something vague, and the design can go in multiple directions. Ours was the latter. One of my ideas early on involved nurturing a creature Pokémon-style in order to solve puzzles (hell, I still may make that game). Honestly, the Friday night design session is one of my favorite parts of the Game Jam, and game development in general. I would have loved to spend all night taking several ideas and molding them into basic game designs. But, unfortunately we only have two days to make a game, and we can't afford to "kill our babies" and run through several prototypes.
  
• Over-designing. Once we came up with our idea and we started hunkering down on the technical parts of it, our original pitchman Dan Roy and consultant Ravi Purushotma continued to make further designs. It's great that they nailed down the details of some of the things we planned to build, but they also added some features that weren't discussed during the initial design. So it got to a point where we were like, "oh, okay...guess we'll have to build that as well".
• Technical difficulties. For some reason, Darren had a hard time getting Visual Studio working for him on the MIT computers. I wasn't familiar with the repository system Darren set up for us (not that it was difficult, it just took a while to set it up, plus I'm prone to making mistakes. I'm still not used to working with repository systems :P). All told we were really kind of spinning our wheels until Saturday afternoon, so we had a lot of ground to make up. Additionally, some of the things I was working on were really simple things that I shouldn't have had problems with, and are really probably quite easy to fix, but with the deadline looming there just wasn't enough time to worry about it. Specifically, I'm thinking about the sound system. I don't know what kind of crazy format XNA expects its WAV files to be in, but apparently we couldn't figure out which magical settings it needed in time.
• Didn't meet all the constraints. This is a minor issue. We can make up arguments/excuses as to exactly where it is in our game that shows "deception" (and I think there were some good ideas thrown around in the design session), but the rain/plain/Spain kinda got left off to the side. Plus there were additional optional achievements, such as using all organic sound effects or using only 16 colors. But, we felt that these were more guidelines than rules, and there really more to spark creativity than to hold us to some arbitrary game conditions.
  

What Went Right

• Choice of platform. We chose to develop the game in C# under the XNA format, and specifically AngelXNA, which is an open-source port of the Angel prototyping engine developed by Darren and Jeff Ward. Now, I haven't programmed in a while (and never really in C#), so it took me a short while to get reacclimated. And since I was learning a new system, I was bound to make some rookie mistakes. For example, Darren questioned why I bothered to communicate within the game using AngelXNA's messaging system when I could have much more easily done a method call. And the answer to that was, well, I was mentally stuck using the messaging system since that was how it was reading keyboard input, and the sparse documentation didn't help to break me of that mental lock. However, it's still in its infancy, but the system made it much easier to build systems that would have taken us hours to build ourselves in XNA...which, of course, is the whole point of AngelXNA.
• Art and Music. Our artist Dan Salsberg came up with some great art with a nice visual style. And I have to both thank and apologize to our musician Alex Liberatore. I really do admire the Berklee students that attend these Game Jams, and game audio designers/engineers in general - it's really an under-appreciated aspect of games. He wrote some nice music and sound effects, and he and Dan Roy designed some really cool ways to implement the music as a function of the gameplay...but unfortunately you won't hear them because I couldn't get the sound system to work (see above).
• Complete prototype. It may not have sound, and the controls are a little sticky (for Darren, for some reason - they were working fine for me), some features were dropped, and it might not be terribly fun, but we accomplished the core concepts of the design, and it works. And for something that was only built in 48 hours, that about all I can ask for. Plus it looks good.
• It was fun! It was great meeting old friends and making new ones, and it's wonderful to go through the whole creative process of making a game.

What I'd Do Different

• Simplify. Maybe it'll take a bit more practice, but I'm slowly learning what kinds of things make for successful Game Jam games. First, come up with a simple yet specific "elevator pitch". Make sure the design is locked down by the time we leave Friday.
• Prototype, playtest, iterate, repeat. Make sure we've gotten a prototype done by Saturday afternoon, and a first playable by Saturday night. Sunday should be for polishing and fun-making, not "oh yeah, we should probably put all of the pieces of the game together and make sure they work before we need to upload our final game to the website in an hour".
• Get the sounds working in the game early. It's one thing if I'm using clunky sound effects I've borrowed from the Internet, but I don't want to waste another audio engineer's time again if I can help it.
• Don't forget the small stuff. If I were producing, for the first-playable I'd dedicate at least one hour to make sure we have a title screen, end screen, credits, and all other the other little things that tend to get forgotten that end up being slapped together.

That being said, it was a wonderful weekend and I can't wait to do it again next year.
We had a lot of other great games made at MIT:
RunRunRunJump: a platformer with text cues. Looks great in 3D Unity (even if it is mostly text in blocks).
Quest for Stick: a platformer where you can alter the platforms. Great visual style.
Jumble is Trademarked: a word jumble where the solution is not what it seems. My second choice when we were organizing.
The Hunt Alone: first-person shooter where you're a visually-impaired hunter caveman. Had they gone with their original idea of "blind caveman", I can't help but think, with some tweaks and more innovation, it'd make an interesting Daredevil(tm) game.
The Last Bullfight: first-person perspective where you're the bull. I think given a little more polish time, this would have had a real emotional impact.
Press X to Not Die: Flash game that's all quick-time events.
Pigmalion: action-stealth game. Worth playing if only for the opening cutscene.

Postmortem postmortem...er, wrapup

Had a fairly good time at the Boston Postmortem tonight. Quite a few WPI students there, which was commented on by a couple people I had talked to. It seems everyone here in IMGD suggests going to the Postmortem as a way of meeting industry people and getting jobs, so I get the feeling it might get to the point that there's going to be a grand migration from Worcester to Waltham every month and there will be more WPI students in attendance than anyone else.

I was happy to recognize a lot of faces from the Global Game Jam, which was the topic of tonight's presentation. It made me feel good to "know" people at the Postmortem, which is my goal right now...to meet at lease one new person each month and see them on consecutive visits. It feels a little weird to me that I was able to talk to so many people tonight, especially considering my past, as I was a lot shyer in my youth.

Our presentation went pretty well, except our game was the only one that experienced any technical difficulties (I think it was just an issue with the laptop talking with the projector). There were some upgrades made to the game the other day, so we're up to version 5. Another person in our group, Trey, ended up being our designated speaker, so I didn't actually say anything to the crowd, but I stood up front and tried to be helpful with my laser pointer.

I suppose I shouldn't get down on myself about our game. On the one hand, I think it's a strong premise and the name "Porcupine and Balloon are Friends" is just quirky and fun. Although, I don't think it's quite as strong as some of the other games made that weekend. But then again, it's a game jam game, it's supposed to be bad. But, everyone seemed really impressed with it.

So, all in all I'd say it was a successful night, and I'm looking forward to next month!

Global Game Jam 2009

This weekend I participated in the Boston chapter of the Global Game Jam. Overall I think it was a great experience and provided me with an opportunity to do something I've been meaning to do...make games for the hell of it! Plus, networking is always good.

My original intent was to blog about the Jam every day, make it a three part series. But, a lack of computer and limited sleep time didn't help that. Then I thought I'd write everything at the end and backdate the entries, but looking back at it now, nothing terribly excited happened during each day. So, you're getting a post-game wrap up.

Friday, January 30th

I arrived at the Singapore-GAMBIT Game Lab at MIT in Cambridge, MA about 4:40pm or so. Later than I had planned, but still plenty early (perhaps it was a good thing that I hit a tiny bit of traffic on my commute in). Some light chatting with the others, and then we got down to business. A brief overview of what to expect for the weekend...schedule, important information, all that fun stuff. We had several constraints/themes to work with. Our total gameplay had to be no more than 5 minutes. We could choose one of three words: illusionary, persistant or pointed. We had a quote, "As long as we have each other, we will never run out of problems." And finally, we were challenged with making a game around 120 beats per minute. How that got implemented, was up to us. The idea was that at the end, we could play all of the games at once and everything be synched up.

Let me say that the GAMBIT lab is a very nice facility. Although first walking in, it seems easy to get lost, but it's really kind of a square-A shape (or, a figure 8 if you count the hallyway with the elevators). The most striking thing is that the rooms all have some section of translucent wall, a kind of plexiglass surface, and everyone uses them as whiteboards. It's neat, as you can sort-of make out the images from the other side of the wall, but they're usually set up in the corner, so there are tables or something else in the way which doesn't make them that effective of whiteboards, in my opinion. It's more of the cool factor, than anything. Also, they call their kitchenette the "Respawn Point".

So, we had 20 minutes or so to brainstorm game ideas, and afterwards we pitched them to the group. [Now, personally, this is where I would've liked a lot more time. Maybe because I'm just not that good, er, experienced, in coming up with original ideas that fast, but my favorite part of game design is taking an idea and rolling it around in the brain, fleshing it out a bit, analyzing it against basic game design principles.] We then took these ideas, written on index cards, and pinned them up on the wall. Everyone then pinned their name and "job" (art and code, mostly...though we had a few sound and music guys there that ended up working a bit on all the projects) up next to the project they wanted to work on. In this way, the ideas got sifted down and people shifted around until we had about 6 total projects. And with that, we were on our way.

Dinner was Thai take out. My first time trying Thai food, actually.

Most of the rest of the evening was brainstorming with our group, figuring out the details of gameplay and all that fun stuff, which I really like. Our project ended up being a combination of two project pitches, as there weren't enough people in either group, so we joined up, and our ideas ended up working together. One idea was a Pac-Man sort of game, where the player controls two entities at once, but one entity moves at right angles to the other. And the directions each entity can move changes when it hits certain obstacles. The idea was to collect pulsating "pellets" (this is where the 120 bpm comes in), and you could only actually gather the pellet on its "upswing". The other idea played more on the "together, we never run out of problems" quote, and it wasn't much besides the title and a sketch, "Porcupine and Balloon are Friends". So, we kept that title, and the entities became the titular characters. We then filled in the gameplay with plenty of ideas, about altering speed, the size of the characters, various obstacles, special powers, and tying the gameplay together with some music.

The last decision was about development environment. One idea was to use a kind of IDE that Popcap Games has released (I'll have to investigate that further - Popcap rules!), but it would have taken too long to set up. Somehow we ended up deciding to use Yoyo Games' Game Maker. And the weirdest part was, I was more of an expert on the program than anyone else in the group!

A word of caution. Sure, Game Maker might catch a lot of flack. But, it does do good in that you can create a game prototype fairly quickly. However, MULTIPLE PEOPLE WORKING ON THE SAME GAME FILE IS A PAIN IN THE BUTT. It's just not multi-developer friendly, and in the end, I think that's why were weren't able to get as much done in the end as we would have liked. The "solution" we came up of trying to merge game files together is just much more of a hassle than it really ought to be.

Saturday, January 31

Really, not a lot happened on Saturday besides spending just about all day developing. We spent a good chunk of the day just hammering out more effective movement code. The original idea was easy to implement: when the player pressed a button, move one thing in that direction, and move the other in a perpendicular direction. But, when one collided, the other moved forward a step (usually because it could), which was something we didn't wanted. So there's all sorts of crazy checks, including ghost objects which handle the collision detection (and if they can both move freely, then the character sprites moved).

Lunch was Chinese food, and dinner was Middle Eastern. Again, Middle Eastern was a new one for me. Weird, I know...I'm just not that big into exotic food.

Sunday, Februrary 1

We really went down to the wire, trying to get as many of our features implemented as we could before our 3pm deadline. We had something fairly workable, but once again, thanks to our Game Maker problem, our final integration resulted in a lot of bug that would have taken too long to really sort out. I mean, it works, but it's very finicky and very liable to break on you. Unfortunately, that also mean that our sounds and music were a casualty, since they got put off for so long in the project. Heck, we almost didn't have a game start or win conditions. Still never got around to lose conditions, come to think of it.

We eventually got our stuff uploaded to the main database, and we gathered together in one of the rooms for brief presentations, and a chance to play each other's games. Plus, an informal vote for best game. I would recommend you look them up yourself on the Global Game Jam page and play them...look for "The Beat" and "Move mouse for your destiny". The Beat is a two-player cooperative puzzle game, with a sort of "The Blob" 50's B-movie style theme, but it really takes the 120 bpm idea to heart. Everything is in time to the music, including trap doors which you must cross, and the actions you take must fall on the beat of a measure. The "Move Mouse" game is extremely simple, it's almost abstract, but very poignant and aesthetically satisfying. You run through life, starting as a young kid working your way up through adulthood, and you move between tending a farm, building a house, and entertaining guests. It starts off slowly, the idea being that it seems like time passes slowly when you're a kid, but it ramps up quickly and you're spazzing out trying to take care of everything. It's more complicated than it sounds; really, you have to deliberately not do anything to really "lose" the game.

Again, these two were voted the best among our group, but the other games are worth a look as well.

While "Porcupine and Balloon are Friends" at this point doesn't seem to be that successful, I think it holds a lot of potential. There's still plenty of things to accomplish and a lot of challenge can be designed into it. Maybe it'll get converted to the Popcap thing and it'll work out better...I'll let you know if it does.

Keep an eye on the website for the game. Or, go to the Global Game Jam site now and download it yourself.

And thanks to everyone who worked with me on the project, and everyone else who participated in the jam...it really was a great experience!