More details to come soon.

For more information about the idea behind it, go here: http://www.godatplay.com/2011/07/a-meaningful-gameplay-game-jam/

The "goaterpillar" is about to eat blocky strawberries

Hunger is a game prototype created by Dusty Peterson and Ryan Hoffman in the span of about 16 hours. The idea of this project is to try and communicate the idea of hunger through gameplay, and do so without text or gauges. It’s not a political statement about starvation or world hunger, we just wanted to recreate that feeling that everyone gets a few times a day.

While the subject itself is very simple, it actually turns out to be pretty difficult pull off. Video games are great for sound and visuals, but we can’t really give people a physical sensation. We decided to work around this by attempting to recreate symptoms of hunger through an avatar which the player feels empathy towards.

Download Hunger Here (Windows only)

Gameplay

The original challenge we gave ourselves was to implement the idea of hunger with GAMEPLAY ONLY! Meaning we would implement the bare minimum of visuals and sound, and put most of our effort into the player’s interactions with the game. This turned out to be a little too restrictive, but we did manage to make some progress here.

In hunger you play as some kind of animal, it kind of resembles a goat and a caterpillar so I will refer to it as the goaterpillar from here on. The goaterpillar can walk around, it can run, and it can eat. Eating increases the goaterpillar’s fullness, but waiting around will make it hungry, and running will make it hungry even faster. Hunger indirectly affects how quickly the goaterpillar can run. Running speed is based on stamina, where moving decreases stamina and not moving recharges it. How quickly stamina recharges is based on how hungry the goaterpillar is, and hunger also affects the maximum amount of stamina the goaterpillar can have.

So to sum our gameplay up: physical performance can be pretty heavily influenced by how hungry you are.

Does this work to convey the feeling of hunger? Kind of. I think with some more balancing we could get the above system to feel pretty good, but physical performance is only one part of hunger. The gameplay doesn’t currently do much to communicate the mental or emotional drain of hunger.

An idea that I wish we had time to implement was the idea of adrenaline, or excitement. When you are hungry, the sight of food is exciting, and it can cause a rise in energy. In gameplay terms if the goaterpillar was hungry and it saw food, it would get a burst of energy and move faster towards the food. This would be the same kind of feedback that we already have, but might suggest an emotional reaction. It might also just be confusing, its hard to know without actually play testing.

Visuals

Feeling hungry yet?

The visuals of this prototype are simple on purpose, but our implementation was kind of interesting. Instead of drawing a single texture to the screen for our avatar, Dusty decided to create polygon art (similar to pixel art) where he would draw a character entirely with colored rectangle polygons. This turned out to be a pretty neat style and allows for some great flexibility in animations. We have since discussed taking this style further for a future project.

The background is procedurally generated, it consists of tiled blocks of mildly varying colors and will loop when you reach the edge of the world. The main focus on the background was color saturation, which was tied directly to how hungry the goaterpillar is. This was our attempt to simulate the fact that hunger takes hold of your attention. You start only thinking about food, noticing food, and everything else fades to background noise. The desaturated background suddenly makes food  really easy to notice. In addition to the background color, food starts to glow when the goaterpillar is hungry, which really exaggerates the effect.

Audio

There are three sound effects in the game, all of them recorded by me with a cheap computer mic. The sound effects are both funny and really help sell that the goaterpillar is eating something. We wanted eating to be satisfying, which can help reinforce the periods of hunger by giving the player more desire to eat. I think that chomping and chewing noises make eating a lot more satisfying than if the game were silent.

A sound effect that we really wanted but were unable to get to is stomach churning. When you get hungry your stomach can growl, and I think just hearing this noise really triggers the hunger association in any of us.

Another thing our game lacks is music. While technically music has nothing to do with feeling hungry, music is very good at evoking emotion. The game could play melodic happy music when full, then fade to sad and longing music when hungry. While the player is hungry and they see food the game could suddenly jump to an excited tune, and then of course back to happy music when they feel full.

Conclusion

We didn’t get a lot of time to spend with this prototype, but it was a great experience. While I don’t think we nailed the feeling of hunger, we definitely started to approach it, and given more time I think we could have players across the world running to their refrigerators.

Note: The art in the game is from StencylForge because I didn’t have enough time to add Daniel Xiao’s excellent art. His feedback throughout development helped make the prototypes better than they could have been.

Learning to Fly Prototype #1
Learning to Fly Prototype #2

“I wished to say to men, ‘If you desire to continue freely in your creative work, it will be necessary for you to enter the struggle and conquer the forces of darkness that are about to invade the world.’” –Jacques Lipchitz, on his sculpture Prometheus Strangling the Vulture II

“Learning to Fly” puts you in the role of a bird struggling to fly as high as possible. It’s also a game about how I’ve felt in my first year as a full-time indie game developer. My overall goals for the project were to convey the following ideas through game mechanics:

• that you should celebrate your accomplishments and progress
• that you should avoid comparing yourself to others
• that you should enjoy the journey instead of doing things for external rewards

Some Background

Since this game is about personal themes of struggle, it would help to provide some background information.

Ever since I was a child, I would spend a lot of my time exploring video games and their development. I’d consume books and articles on video game development and design. I’d play games with an eye on interesting choices the developers made. When I first learned how to program, I remember the first time I plotted pixels on a screen on my Apple II c+. I realized that making the computer draw images on the screen meant that I had the power to make video games.

I taught myself how to program, and I even made a few simple games. When I got a PC, I remember hacking out my own Pac-man clone in QBasic, complete with bouncing cherries.

When I got to college, I spent a lot less time coding on my own than I wish I had, and I didn’t spend too much time making games. There’s an unfinished Pong/Warlords clone in QBasic somewhere to show for my efforts outside of class and homework. Still, I had this idea that game development was what I ate and breathed.

After college, I participated in a few 48 hour game development competitions. I was able to finish a complete game for a few of them, too. Clearly I knew how to make games. I’ve done it before for years, after all.

Well, after years of struggling with my own projects part-time and saving money, I quit my day job in the summer of 2010 and went full-time indie. I figured by the end of a year I’d have at least a couple of games under my belt.

Well, it turned out that I was woefully unprepared. Making a complete, commercial-quality game is not anything like taking a 48-hour prototype and doing more of it. I underestimated the technical requirements for my project, especially since, as a GNU/Linux user, I had no good choices in 2D game engines or frameworks to leverage. My one month project has turned into a year-long learning experience. I kept missing self-imposed deadlines, I struggled with my lack of skills and experience, and all the while I was painfully aware that every day I didn’t ship meant more of my savings disappearing.

Maybe I Shouldn’t Be an Indie…

Occasionally throughout that year, I’d have feelings of despair. I felt like I had too much to do, yet I didn’t know what to focus on first. Whatever I did do, I’d almost always have a feeling that I’m wasting my time and should be doing something else. Since so much seemed to be going wrong, nothing ever seemed to be going right! Any plans I had kept becoming obsolete since it is hard to do any kind of marketing and sales projections if the game’s schedule keeps slipping. Since I’m the only one running my business, I’m the only one taking on all of the various roles, and it can get quite stressful since there’s no one to go to but me. There would even be days where I’d wonder if I quit my day job too early, especially as month after month passed with no way to make income.

I especially felt like a failure because in the time I have spent working on my first major project, many games have been developed and released by others. Some became critical and financial successes. I’d see these other developers and their games and think, “How can I compete with them if I can’t even get this project out the door in a timely manner?”

Then I realized that I didn’t really have any reason to feel so down. I was a full-time independent game developer! There are people who would love to be in my position. In fact, I was one of those people, and I took the big step to actually make it happen. My project might not be finished, but I’m always making progress on it. It’s much further along than it was weeks or months ago! And since I’ve been focusing my efforts on my project full-time, I’ve learned so much more this past year than in the past five or 10 years combined. Aside from my dwindling savings, what was there to actually despair about?

Dealing with Despair

I realized that there were a few disempowering thought and action patterns which led me to feel frustrated and depressed. Comparing myself to others was one such pattern. When you’re working on your first project, it’s good to know about the competition, but it’s not good to worry that your game is nowhere near the level of depth and complexity of Minecraft or Dwarf Fortress or Civilization. And yet I’d compare my first project to someone’s 10th or 20th, or a project with a much larger budget and team than mine. Imagine playing basketball and getting frustrated that you’re in the same universe as Michael Jordan, thinking that all of your practice and energy expended will, in the end, be for naught because, after all, how could you hope to compete? In a similar way, I’d feel like any progress I made was tiny and pointless compared to what other indie game developers were putting out.

Focusing on end results meant getting frustrated when those results didn’t happen. Getting frustrated by mistakes meant worrying about mistakes and feeling like I’m out of my depth. Worrying that I’m feeling too stressed resulted in me thinking that I’m not cut out for game development. Trying to be realistic made me wonder if I wasn’t capable of anything important. All of these patterns led to feelings of despair.

I found that there are better ways to think and act if I want to avoid feeling helpless. If I focus on the journey as opposed to the destination, I can feel good about progress being made instead of feeling bad about the progress I’m not making. As a result, I can be passionate about the work I’m doing. I can create my own reality instead of worrying about what everyone thinks my reality should be. I can trust myself to make decisions and learn from mistakes. I can deal with the things that are within my control and ignore those things that are not. I can take time to celebrate my victories instead of constantly looking ahead to what’s next and what’s unfinished.

Interestingly, as I worked on my jam prototypes, I found myself dealing with a lot of these issues as I worked. I was learning how to use Stencyl since I didn’t trust that my own code would let me make anything quickly enough. Even though Stencyl was fairly powerful and allowed me to quickly put together a game, it was still new to me, and I struggled at times to figure out how to make it do what I wanted. It didn’t help that I wasn’t sleeping or eating as well as I usually do. At various times throughout the jam I felt like I was wasting my time, that I should work on my own game project, that it would be OK to not finish, and that other participants were probably putting together some awesome games and my game would barely compare even if I could get it finished.

Maybe it was partly because my game’s themes were about pushing through such struggles, or maybe I internalized the better self-talk since I had practice with it throughout the last year, but I persevered.

Prototype #1 Analysis

“Learning to Fly” starts off with your bird on a tree branch, and there is a score at the top of the screen: 784 out of 6000. Soon other birds are flying up at various speeds from the bottom of the screen, giving you encouragement to follow.

If you press the Up Arrow key, you’ll move up a small amount, and gravity pulls you right back down. By pressing up repeatedly, you can move higher, although it is a struggle. Your arm literally gets tired as you press the key over and over again. Luckily, there are other branches to rest on as you proceed.

You’ll note that the other birds seem to fly up with ease, but it’s your option to pay attention to them or not. You can compete with them if you want to, but in the end, it doesn’t matter what they do. It only matters what you do. Some are slower than you, but some are way faster.

As you move higher, you see that the score at the top of the screen increases. It doesn’t decrease as you fall, but it gets closer and closer to 6000 as you fly higher and higher.

Eventually you’ll see the top of the tree, and the screen stops scrolling up. If you fly all the way to the top, you’ll find the score reaches 6001/6000. That extra point was originally a bug, but I liked how it felt to be rewarded with something extra for keeping with it and making it to the top.

But the game doesn’t end. There is no explicit victory or defeat for the game. It’s your choice to care about the arbitrary score. You can choose your own path. You can even fall down to the ground if you want.

I think I managed to convey the feeling of dealing with work struggles and imagined competition well enough in this prototype. It’s a chore to fly, and you can see other birds flying past you with ease. Some of them might be veteran flyers. Others are slow, and once you get the hang of things, you can catch up to them easily, but it is possible that the player never sees them. Of course, the player can choose to ignore all of the other birds since they have no way to impact how well the player does.

But I think I left too much up to the player in terms of focusing on progress and celebrating goals. Resting on branches might help relieve forearm tension, but without an explicit goal, the player might not feel that there is a reason to spend so much energy and effort on trying to fly. The extra point at the top might say something about completion, but there is very little conveyed about focusing on progress.

Prototype #2 Analysis

For the second prototype, I tried to address those issues. I set the starting position on the ground, and I placed a greater number of birds moving up at different speeds to make it even more clear that they are your peers. As you fly up, you’re guaranteed to catch up with at least some of them. Again, some are easy to pass while others are way too fast.

The biggest change I made is related to tracking progress. I removed the score at the top of the screen. Instead, every time you touched a branch, a marker would appear telling you how high you’ve flown, how much higher you’ve flown since the last marker, and how much higher you have to left. These markers become permanent fixtures within the scene.

When you reach the top this time, the game actually ends. You lose control of the bird, who lands on the tree branches, resulting in one last marker appearing which says you made it to the top. After a few seconds, the screen scrolls down throughout the level. You can review the markers you left behind and see where you’ve been. You’ll also see other birds still struggling to fly up to the top. The game fades to black when the ground comes into view, and the game resets.

Work struggles and imagined competition were still conveyed well in this prototype. This time, however, I think the markers did a great job of giving the player a sense of progress while still allowing it to be optional. You can land on every branch, leaving a trail of markers behind you, celebrating every few feet of height attained, or you can fly all the way to the top without stopping. I like to think of the latter as being focused on your end goal, while the former is more about focusing on your progress. You can backtrack without penalty as in the first prototype, but it does allow you to revisit earlier markers to see how you did.

With the score at the top of the screen, the external goal was hard to ignore. Changing to markers gave the player more freedom to decide what to focus on while still emphasizing celebration of progress and goals. The player can acknowledge accomplishments or ignore them. The player can try to create many small pieces of progress or cram everything into one big celebration.

When you see the other birds still flying at the end of the game, it’s a good way to acknowledge your improved skills and abilities. You were there once, and look how far you’ve come. Even if other birds made it before you, you’re here now, and other birds are still trying to get to where you are. While you can acknowledge competition, in the end, it’s only what you do that matters, so who cares who is faster?

Conclusion

There were other mechanics and dynamics I wanted to explore but ran out of time. Improved flying controls based on strength and experience might have made the game less physically challenging while still conveying the idea of struggle. Resting on branches would help the bird recover strength to continue flying up. Another option was to make the bird fly higher based on how far it fell, meaning that true flight could only be attained when falling from the highest branches. Perhaps it would help convey the idea that failure and success go hand in hand.

I thought about providing different kinds of rewards for the player. Eating worms for happiness might have worked, but I didn’t want the player to specifically aim to get to worms. I wanted flight to be the main goal. Perhaps making attempts at flight be official events in the game would make it easier to track the player’s progress. I thought about creating treadmill areas in the game. If the player doesn’t acknowledge progress often enough, the game could replicate the current area on the screen, and the player would continue to fly up without noticing that he/she hasn’t gone any higher. I think it would do a good job of conveying the feeling of unending work, but it wouldn’t reward the player for persistence. I could add a timer to give the player an incentive to fly as quickly as possible. I could even make the timer as inconsequential as the other birds, allowing the player to choose to pay attention or go at his/her own pace. Similarly, displaying scores for the other birds could give a better sense of competition. Going backward is a benign action, but it could be rewarded as a way of acknowledging the player’s history, or it could be punished as a way of representing setbacks.

The biggest thing I would have liked to do was to find a way to make the journey more enjoyable considering how much work it is to fly up.

Making this game was actually a therapeutic experience. In 48 hours, I experienced a lot of the feelings and stress I had during the last year in rapid sequence, and this time I knew how to deal with all of those feelings. In that sense the jam was a microcosm of what I’ve been dealing with. I’m very pleased with how I pushed through the struggle and with the results.

“To change with change is to remain in the changeless state.” ~ Bruce Lee

———————————————————————————————-

Download the Prototype(Windows Only) : Here

Requires : OpenAL & DirectX 9

In the zip file is a 3rd party folder. This contains Visual Studio 10 run time files. If you don’t have VS 10 on your system, you will need to install either the 32 bit or 64 bit depending upon your os.

It doesn’t have sound but the engine requires OpenAL.

———————————————————————————————-
When looking at ideas for what to explore at this jam. I kept coming back to things like commitment, drive, tenacity. As I thought more on it, I began asking myself what do these things have in common? To me the big thing is that they are all components to achieve something, specifically for me, these things relate to my goals as a game developer of being able to operate my own studio. But why are these things important and why is there such an urgency from these things? The answer, impermanence. Impermanence could be looked at simply as change. We are all impermanent, we will live for any undermentioned amount of time, and we will die, at least at this point, all of us. Now what death is and what actually happens there is another topic entirely. But what can be said is that for any of us, dealing with impermanence is something that we must all endure.

In my life, I’ve recently had some people pass away that were seemingly young, in good health, and then suddenly, they were gone. That can happen to any of us, and while we shouldn’t waste time waiting for death to come, we should let death serve us as a reminder to make the best of our daily lives and help us have a sense of urgency in accomplishing the things that we set out to do. It should also serve to allow us to enjoy the now and to be present in the company of others and to really share who we are with one another.

Impermanence is not something to dread or be feared, but rather accepted, and used as motivation for each of us to reach our potential.

So, It Begins

Putting the idea of impermanence into overall gameplay could be handled in many ways. During our initial brainstorming session for the jam we came up with many good ideas. We had to settle for something that was small enough in scope to attempt to tackle over the weekend. We decided to take a hero character and have them seek out an item that was causing fluctuation in the land. The item, or relic as we ended up calling it, was the source of said chaos and was responsible for releasing wraiths into the game world as well. These wraiths (in design/theory) were wreaking havoc in the land. The relic itself was causing the world to flip upside down and rearrange itself causing mass confusion.

The game would have a relic, a player, wraiths, other obstacles. The players goal would be to find the relic before it drained enough energy from the land to cause another surge of fluctuation. If the player failed to do so, the world would be turned upside down and everything would be thrown around again. This would continue until the player would find the relic, destroying it and restoring balance to the world.

The Outcome

At the jam I had some technical issues that I’ve blogged about and talk about a little in the presentation video. The important part being, I kinda missed a complete day of dev time. This resulted in a more then unfinished prototype. I have sense then gone back and put about 7 hours into it to get it to a complete prototype state.

Gameplay

The game is close to our initial concept. Originally obstacles where supposed to generate in such a way as to make navigation through the game world more difficult. I could have spent more time after the jam working to create a system to group these items together and put collision checks on them, but I didn’t want to spend more time on it then I thought we would have, had my computer been working the entire time of the jam.

The gameplay itself does deliver a message of change, there is the impermanence of the gameworld the relic resets it every 7 minutes if the player does not find it. Then there is the drive of the player to want to restore the game world to it’s normal state. This is a change to be made to the world by the player. While the prototype ends after this point, the normal state of the world is restored.  I think I would have liked to have made a variation of the timer being random so the player didn’t know when to expect the world to change.

It could be suggested that there is a conflict in the intended design as the player is trying to stop change from happening.. That statement is false in the sense that the player is instead driven to change the rapid changing of the gameworld, so through impermanence the player restores order to the world which at the beginning of the game is in persistent flux.

Visual and Audio Components

There is no sound in the game at all. Music would have helped set the exploratory mood of the game more. And sound effects would have made it more interesting when finding the relic and struggling against the hordes of wraiths. We simply didn’t have time to create or even find music or sound effects to put into the game.

The graphics were a combination of custom sprites created by Nick and some random textures that I grabbed off the net. Nick did a good job on the sprites he did. The wall graphic which was supposed to be used make wall segments that would have been obstacles look out of place in the game. Also the playing field stops at certain points and no terrain is drawn so you just see the end of the grid layout and blue space. This does not serve well to enthrall the player in the game. Overall the graphics are pretty bland, but they serve the purpose of the prototype. I would have liked to have seen Nick have enough time to do custom graphics for the entire game. I really enjoyed the relic sprite that he created and would have really like to have seen him tackle the terrain texture(s).

Fun?

It has been argued that fun should not be a deciding design factor for meaningful games. I tend to lean towards the other side on this one. While I think that it isn’t necessary and is some cases could even take away from the design, I am a one designer who will probably always have the player want to have an experience they enjoy, so fun will probably always be a goal in some form for me.

This game I find somewhat fun in trying to avoid the wraiths, but this becomes somewhat tedious and as intended causes a feeling of frustration at times. (it’s the struggle to reach ones goal in the face of impermanence) I think having solid controls and being able to not get frustrated with interfaces can have a player enjoy the experience and to me that also qualifies as fun.

A Quick Note on The Jam

A general challenge that I see that comes from a jam like this is that meaningful gameplay is a challenge to really design. If you come to a jam like this without a solid design already, one becomes hard pressed to design and implement things. This is why I believe that events like this should either have people bring solid concepts and designs with them, or that it would work best as a week long event. Multiple iterations of prototypes was an overall goal that was proposed for the jam and only one participant, Gianfranco of GBGames met that goal. In order for successful designs and analysis to be reached, I would simply propose more time in either preparation, or actual implementation to be given to participants.

Molinism’s Middle Knowledge is a puzzle/god game prototype that is intended as a small part of a larger game about the debate regarding whether free will or predestination is a true description of humanity’s relationship with the Judeo-Christian God. This prototype explores the concept of “middle knowledge” defended by a philosophical & theological concept referred to as Molinism that attempts to support both sides at once.

Analysis after the jump…SPOILER ALERT

Overall Premise

Everyone I talked to about the premise seemed very interested, while expressing very justified concern over the ambitiousness of exploring free will vs. predestination in a game. So I think the idea is good, but a lot of people have no concept at all of how that would play out. Therefore, my use of concrete imagery here was a good choice in order to give people a grounding to think about the subject. Finally, focusing on middle knowledge was a good choice because it is about counterfactual statements, which are like if-then situations. That seems pretty ideally suited to a videogame.

The biggest problem with choosing to focus on middle knowledge is that the prototype lacks context. Almost no one knows what Molinism is and how it fits into the free will vs. predestination debate. So to provide a solid context, all three concepts would have to be explained at least a little to move on to the details of what middle knowledge is in order for people to understand how it could work. That just wasn’t realistic to do during a game jam, so I think it’ll just have to be an unavoidable fault of the game and the context will have to be established by reading the Wikipedia article for now.

Gameplay

The gameplay is both the best and worst part about the game. Let’s start with the bad news. It’s biggest fault is that it’s obviously incomplete. It’s not clear at all that some objects can be interacted with and others can’t. Even a simple glow or some kind of outline to delineate those kinds of objects would be better than nothing. Another big problem is the slider. Dragging from left to right walks the character across the screen and causes a bird to fly out of a tree, but as soon as the slider is let go, the bird disappears. This is a bug, but due to the nature of the game, it seems to suggest some kind of meaning.

Another thing is that the character seems to just walk right off the screen and nothing else happens, which is very confusing. The intention was that the tree needs to be placed at just the right spot, causing a bird to get scared and fly out of the tree at just the right time, causing the character to trip over the log, causing a serene moment with a bright yellow butterfly perched on a flower, causing the character’s lifelong love of butterflies. But of course, none of that is in there, so instead the focus seems to be more on the bird and the now arbitrary placement of the tree. The tree placement causes what is presumed to be the same character to think about some kind of confusing math equation (probability of choice) that very few people would probably understand, followed by some arm-waving at two objects.

Now for the good news. In terms of translating the concepts into gameplay, I think I settled on a good direction for how the gameplay would work. As I mentioned before, counterfactual statements are very videogame-like, and a puzzle/god game seems to fit that well. In fact, the golden nugget of the entire experience is the real-time feedback of moving the tree and seeing all the agent’s arms combining into one. That experience lights up my brain in a way that no other medium could. Reading about and even watching a video of that happening didn’t and wouldn’t have the same effect on me compared to the feeling of moving the tree and watching that arm. So I definitely need to find more things like that and give the player a better understanding of exactly what that part of the game means.

Furthermore, I think my attempt at moving objects in the environment in a sort of puzzle format was a good idea, despite being incomplete. Theologically, from what I understand of Molinism, God doesn’t directly control free-will agents. So it makes sense that the game involves controlling non-free-will agents in order to change the agent’s probability of free choice to 1.

As was made clear when I demoed the game, if the prototype was properly fleshed out, I think it would show the potential for an interesting, full-fledged game experience. The general reaction to the gameplay was “Oh, this really can be explored through a game” followed by “It would be cool if the game could do __,” which seemed to be a good sign.

Graphics

Overall, the graphics seem to work fine; not incredibly inspiring, but still pleasing. The colored silhouette style seems to suggest archetypal figures, which works well for this type of game. The character is clearly a human, but it could be any human. The tree is clearly a deciduous tree, but it could be any tree. And so on.

Visually, the biggest problem seems to be depicting choice on the left side. One jammer stated that it was unclear whether the objects the agent was pointing at were two choices or one. I think having multiple options there would make it much more clear that the character is choosing from multiple things. The depiction of the pictogram itself is a little unclear as well.

Sound

There are no sound effects unfortunately. But I think the music works pretty well to set a mood (found at incompetech.com). It’s maybe just a little too unsettling, but I was going for a mysterious vibe. Something that makes the player question if what they’re doing is right (in multiple senses of the word). It seems to work for that. It should not just play once and end, though.

Meaningful Gameplay Game Jam #1 Games

Giga Wife
Ryan Green & Keith Riddle

A “virtual pet”-style simulation game that explores how Ryan isn’t the romantic husband he thought he was.

Learning to Fly
GBGames

Two prototypes (#1 here, #2 here) of a flying game that explores Gianfranco’s frustration with taking so long to finish his first game as a full-time indie game developer.

Free Will vs. Predestination
God at play

A puzzle/god game prototype that explores the concept of “middle knowledge” defended by Molinism in the debate regarding free will vs. predestination.

Hunger
Ryan Hoffman & Dusty Peterson

A hunting prototype that explores what hunger feels like.

Relic
Will Canada & Nick Silhacek

An exploration prototype that explores how impermanence affects gameplay.

Post-Mortem after the jump…

Post-Mortem

While there were some failures, overall the game jam was a success. The jam definitely succeeded in what are probably the two most important criteria for success: the participants enjoyed themselves and were able to learn & grow as developers.

Intimacy

I’ve been a part of roughly 10 jams now, and I found it really interesting how this one was probably the most intimate I’ve been to due to the personal nature of several of the games and their accompanying presentations. Those who participated on-site were also squeezed together into tables right next to each other, instead of scattered throughout the space.

Technology

In terms of connecting with remote participants, that seemed to go well, too. We broadcasted a webcam feed of the entire jam through UStream, along with using it for the Opening Ceremony and the Show & Tell. For talking personally with remote jammers, we used Google Hangout. I hooked my laptop up to an HDTV displaying the UStream chat and Hangout windows. Hangout was very stable and performed well. There were a couple quirks that were a little annoying. First, there isn’t a nice public link to share; the link that you have to manually copy from the browser’s address bar seemed to keep expiring on people. Plus trying to keep that link alive means always having the Hangout up. Second, there’s a “sleep” function that disconnects you if you don’t keep confirming you’re there (that makes the first problem worse), and it seemed to just disconnect-from-sleep on its own sometimes. In the end, Hangout isn’t the friendliest thing for a 2-day event, but it did work like a champ.

Format

The biggest failure was probably the attempted format for the jam, namely that developers create several prototypes that explore a game element from multiple perspectives. Gianfranco of GBGames was the only developer who was actually able to accomplish this with his Learning to Fly prototype #1 and prototype #2. And it was really exciting to see that the idea for the format really worked when he presented the prototypes. Ryan & Keith’s Giga Wife is actually a small, but complete game. Considering how interesting the result is, it’s hard to imagine telling them “you shouldn’t have done that, you should have narrowed your scope and done multiple prototypes.” My Free Will vs. Predestination was too ambitious for my lack of programming skills and obligatory hosting duties, resulting in an unfinished prototype. Ryan & Dusty’s Hunger was a good scope for this format, but again only 1 prototype. And Will & Nick’s Relic didn’t quite get to a prototype due to Will’s computer troubles.

People also slept in pretty late on Sunday, so that combined with generally not quite being ready to present axed the on-site analysis planned before the Show & Tell.

During the opening talk, I should have either been more intentional explaining the limited scope, or we should have picked 2 specific ideas and had the teams each make 1 prototype of an idea. I’m sure leading by example would have helped, too. Doh…

Opening Ceremony

We went a little long, but overall it was good. I was able to set up UStream to screencast my presentation, which was a quick summary of Jon Blow’s Conflicts in Game Design talk and Alec Holowka’s Holistic Game Design talk (or rather, the part of his talk after he openly makes fun of other indie game developers). But again, most of it should have been more specifically about the scope and idea behind the format.

After my presentation was Paul explaining a few of the meanings we see in many of today’s games. It was pretty interesting to see them written plainly up on the board. It was a pretty good transition into thinking about our own meanings.

Show & Tell

This was awesome. It was fascinating to hear the developers talk about their intentions behind the games. Sadly, due to my inexperience with UStream production, I missed recording most of Ryan’s Giga Wife statement. But thankfully he has a good chunk of it written out below the game. Otherwise the entire game jam show & tell is up on UStream.

We’ll be posting our games and their analyses next! So check back over the next couple days.

BitMethod
418 6th Ave, Ste 1210
Des Moines, IA 50309

BitMethod is on the 12th floor of the Liberty Building, accessed through a door facing East that’s between a Hyatt Place and Gym F/X at the corner. Go in the door, take the elevator up to the 12th floor, and walk away from the glass doors to the NW corner. The doors to the building lock after 6pm on Friday, so there will be a phone number(s) printed on a sheet of paper on the door that you can call to be let in. So bring your cell phone or leave a comment to arrange getting in.

Online Location

UStream: http://ustream.tv/channel/meaningful-gameplay

The UStream channel will act as a live feed of the event.

Google Hangout (requires a Google Plus account): https://talkgadget.google.com/hangouts/690ab51fdc1b4b661c515f6c4228999fce4f0caa#

The Hangout will act as a group video chat. NOTE: This link is subject to change once we actually get it up! Check back in on this site tomorrow afternoon to make sure this is the correct URL.

The Schedule

Friday, 5:30pm – 8:30pm

Mingling, team forming, food runs

Friday, 8:30pm – 9:00pm

“Opening ceremony”

Friday, 9:00pm – Sunday, 10:00am

Game jam

Sunday, 10:00am – Sunday, 2:00pm

Analysis, writing, blogging – game critics welcome!

Sunday, 2:00pm – Sunday, 5:00pm

Show & tell – general public welcome!

What is a Game Jam

A game jam is an event where game developers get together to hang out and make games. This usually takes place over the course of a weekend, starting Friday evening and ending Sunday evening. A game jam is usually centered around a single theme or concept that participants should make their games about – in our case “gameplay that is significant for or provides purpose for how one lives life.”

A jam usually starts with a sort of social hour, followed by brainstorming game ideas and breaking off into teams to make the games. Recently, we’ve been trying to end a jam Sunday afternoon with a show & tell so everyone can see what was created.

The Vibe

The word “jam” here is appropriate, because the event is in some ways similar to musicians getting together to jam by just playing music with each other. So the overall vibe is pretty informal, composed of one-part coworking at desks and one-part social with developers catching up with each other and checking out what everyone else is up to.

One of the most unique things about a game jam is the creative energy present. For many developers, that leads to a kind of productivity that is hard to replicate anywhere outside of a game jam. Because of this, some people have attended who don’t even intend to work on games at all, but are simply there to feed off that energy. And some full-time indies will work on their own projects instead of participating in the jam, so that they can take advantage of that productivity. While not the ideal situation, those people are welcome at most game jams. Remote attendees are almost always welcome – that is certainly true for the  Meaningful Gameplay Game Jam!

Game jams also vary in their competitiveness. Historically, Ludum Dare has been an online “game making competition,” although recently a jam component has been added that is not competitive. Our game jams haven’t been competitive at all. The Global Game Jam seems to be somewhere in the middle due to featuring specific games, but not explicitly recognizing winners. The GGJ is technically a collection of many jams happening at different locations all over the world.

How to Prepare

Preparing for a game jam is mostly straightforward, except for a couple things that can be easy to forget. The #1 thing a participant can do to prepare for a game jam is:

Prepare your development environment.

This point is most important for those intending to work on a videogame. At many game jams, some teams will fail because a large part of the jam is spent just getting a game engine to compile, or upgrading software, or preparing an art pipeline. Therefore, prior to the jam, videogame developers should make sure their software is up to date and tested (including OS updates, middleware, libraries, etc) and that any custom tools to be used compile successfully, including developer tools that would be installed on a new computer – like a potential teammate’s computer.

Other important things to do to prepare is to get some good sleep before the jam – since jams tend to involve staying up late – and brush up on any rusty dev skills so that you can be as productive as possible.

What to Bring

Put simply, participants should bring whatever needed to get their work done. That could include the following:

• A computer with all needed components
• A power strip
• A video out adaptor for your computer (if showing something, a safe bet is VGA)
• Brainstorming/creative supplies
• A board/card game testing kit
• Food (usually not provided by the jam host)
• Clothes/toiletries (if the jam is out of town)
• A wireless router (this can come in handy for larger jams where wireless connections get maxed out)
• Folding table/chairs (usually not needed for most jams, but sometimes for less organized ones)

Where to Stay

If you’re coming from out of town, you’ll be looking for a place to stay. The arrangements for this seem to vary widely from jam to jam. Some jams – including the ones hosted by our IGDF club – allow people to sleep on-site. In the past, we’ve set aside dedicated “quiet rooms” for this very purpose.

Many times people who live in-town will host out-of-town jammers, too.

Participating Remotely

Developers who participate remotely usually stay connected at a game jam through a variety of different communication software, which could include IM/IRC chat, audio chat through Skype or Ventrilo, or video chat through Skype, Google Hangout, Facebook, etc.

In addition, jam locations will sometimes have a UStream channel where the public can watch the progress and chat in a sidebar.

What Makes the Meaningful Gameplay Game Jam Different

I’ve written a post on my own blog detailing how a Meaningful Gameplay Game Jam is different from normal game jams. Check it out if you’re interested.

[P.S. Let me know if I missed anything!]

The first game jam has been organized for August 12-14, thanks to the openness of a club called Iowa Game-Dev Friendship. The goal of this game jam is to explore meaningful gameplay through developing several prototypes of a mechanic or other game element and then critically analyze the prototypes and share the result.

In addition to being hosted on-site at BitMethod in Des Moines, Iowa, USA; it will also be hosted online. I’m still working out the details, but it will most likely involve setting up a UStream and/or video conference. Will Canada has a post about the game jam on his site, too. Spread the word!