Choosing Game Jam Themes

Every month at Cipher Prime, we hold a twelve-hour game jam, a contest in which people try to create a game based off a theme of our choosing. Along with stressing over hosting the event (and, of course, over our own jamming efforts), we stress over choosing game jam themes.

WHAT’S SO HARD ABOUT CHOOSING A THEME?

Picking a jam theme isn’t as easy as it might sound. As an organizer, you want to give jammers an interesting jumping-off point, while still letting them be creative. Oftentimes, too much freedom leaves teams paralyzed with indecision; having constraints can actually make teams think more creatively. When thinking about how much freedom a theme gives teams, it’s also important to realize that people will often self-impose restrictions subconsciously.

STICK TO TEXT

Both the Global Game Jam (GGJ) and the Philly Game Jam (PGJ) have used pictures as jam themes (below). The GGJ used a drawing of the ouroboros, and the PGJ used a photo of decrepit playground equipment.

When the games were submitted, the GGJ received lots of games containing snakes, and the PGJ received lots of games containing a playground wheel as a centerpiece. At this year’s GGJ, the theme was the sound of a heartbeat. As when the theme was a picture, many people interpreted the theme literally and submitted games that involved hearts, or love, or something else that connected very simply to the theme. While there are plenty of counter-examples to this phenomenon, anecdotally, photo- or audio-based themes lead to a higher number of literal interpretations (and fewer original games). Because these themes engage with a particular sense (sight, hearing) very strongly, people have a hard time moving beyond that strong initial engagement to something deeper. Text-based themes lack a defined visual or aural form, freeing people to think about themes abstractly, rather than concretely.

WHAT’S IN A NAME?

If we’re sticking with text, generally a single word will suffice for a theme. Abstract nouns tend to give jammers plenty of context to work from without allowing them to simply utilize the theme for a set piece. Concrete nouns, however, tend to pigeonhole participants by allowing them to latch on to something tangible in the same way that picture-based themes do. Verbs, similarly, limit thinking by spoon-feeding potential player actions to designers. Conversely, single-word adjectives tend to be way too broad–it would be far too easy for designers to make any game they felt like, and then make sure that at least one tertiary aspect of the game could be described by that adjective. This is probably why the GGJ organizers have never chosen a single-word theme that was either a verb or adjective.

CATCH THAT PHRASE

Not all good themes come from abstract nouns. Another common source of good themes is catchphrases (such as GGJ’s “As long as we have each other, we will never run out of problems”). While not frequently utilized, phrases as themes can be deployed to great effect. They force jammers to consider both the literal words of the phrase, which can lead to gameplay ideas, and also the emotion and the context of the phrase, which can add many more layers of depth to consider. For instance, in 2009 the PGJ used for its theme the Michener quote, “An age is called Dark not because the light fails to shine, but because people refuse to see it.” This quote produces lots of jumping-off points, from the light/dark dichotomy, to perception of the human condition, even potentially to Dark age history. Any of these avenues could be explored and still be thematically relevant.

THEMES SHOULDN’T BE CHOSEN DEMOCRATICALLY

Textual themes are popular with the granddaddy of organized game jams, Ludum Dare (LD). LD’s community self-selects a theme for each competition. But this can lead to internal conflict. When participants get to select their own theme, they’re likely to pick a favorite theme, or one that fits a design idea they’ve had. If that theme isn’t selected, all the time they’ve spent invested in the design seems wasted, discouraging the person from participating. Additionally, having participants vote can lead to very generic themes. For instance, in 2013, LD’s theme was “Minimalism”; in 2008, LD’s theme was “Minimalist”. Having a single entity, rather than an entire community, choose a theme can prevent similar or poor themes from being chosen.

THE GOLDEN RULE: INSPIRE CREATIVITY

The point of any game jam theme is, ultimately, to inspire and cultivate creativity. Because they’re made in such a limited period of time, the games made at jams are never going to be the same as a game made over the course of several months or years. Participants shouldn’t be trying to make a generic first-person shooter, RPG or platformer. Game jams are opportunities for game creators to make something new and interesting, and game jam themes should respect that.

Divining the Music of Splice

Many goals in game development are easy to understand, if not to implement. You know you need to create an enjoyable experience, that the UI needs to be readable, the menu needs to be useable, that it needs to interface with whatever distribution platform you’re putting it on, and so on — the implementation of a solid game design largely comes down to patience, practice, and coffee. But artistic goals are less obvious, especially when you go to write something like the soundtrack to Splice.


Now, if you’re writing a soundtrack for somebody else, they’re going to give you a set of rules to follow — for instance, “It needs to be western-themed,” or, “It should sound like an Ancient Chinese epic.” But when you’re the one creating the game, your only constraint is that it needs to sound good. And as most artists know, trying to create in the absence of constraints is damn near impossible. So what do we do?

We create our own constraints.

Choosing Constraints

With Splice, we chose a microbial theme. But its movements and general milieu are meant to feel somewhere between the macro- and microscopic. We wanted to play with the ideas that exist on the boundaries between Science and Religion; in short, we wanted to create the feeling that you are toying in God’s domain. But because we tend to focus on experience-based gameplay, and we don’t generally use things like “plots” and “characters,” we ended up creating this ambiance through our visual style and constant but subdued references to religious symbolism.1

To help establish this mood, I sought to create the music as a character: a singular companion to soothe you while you are messing around in this domain. To enhance this music-as-character aspect, I limited myself to a single instrument — the piano. I also wanted to give the player the sense that their companion was something a bit more than them — a guide and a guardian, something quite possibly angelic. And so, I settled on writing music for three pianos. The idea of using three pianos simultaneously was to create music for a piano to be played with six hands. In doing that, it sounds like a piece a person should be able to play — much like this piece in Gattaca that was composed for twelve fingers. I’ve heard of people trying to play Splice‘s songs by ear, saying, “Oh, I can play ‘Barachiel,’ but ‘Cassiel’ is too complicated to pick out,” even though it sounds like it should be something you can pick out. It sounds like a single person playing the piano, but with six hands — an “impossible” piano soundtrack alluding to its “divine” origins.

Practical Art

Composing for three pianos created a definitive aural landscape for the game, and it’s also a style that is relatively easy to compose for. Which means that, when deadlines come up and we suddenly need another four tracks, it’s not something that takes me weeks to compose the same way something heavily orchestrated like the Auditorium soundtrack did. So this was a good choice from both a practical and artistic perspective.

Now we add even more constraints. Every track starts in the same way — with an introductory ostinato punctuated with a heavy bass note. The time signatures and tempos change, but there is always a two-or-three note ostinato permeating the entire piece that the additional harmonies and melodies are built on top of. In this way, I created a complex soundtrack built from simple elements, echoing the gameplay that were creating. Finally, every piece is pitched one white key down from the previous, starting in Bmin with Barachiel and finishing in Cmaj with Cassiel. In the Epilogue, I do the same with the black keys, starting in A#min with Ariadne and finishing in D#maj with Daedalus.

In the end, I was extremely happy with the resulting soundtrack. Without the constraints, however, I’m sure I would have done what many artists do in these situations — wait for inspiration. And while inspiration is a wonderful gift, it isn’t something to be relied on. Some people complain that constraints weigh them down; I’d agree that constraints are weights, but how else would you exercise your creativity?

1 For example, the number seven recurs throughout the game: there are seven sequences in the Origin thread; there are seven strands in each Sequence; the Splice logo has seven nodes in it; the game shipped with 77 levels…

Super Hexagon: Six Sides of Awesome

After thousands of losses and months of play, I am just 17.87 seconds away from beating the final level of Super Hexagon. And when the clock ticks pasts 60:00, I will prize that moment as one of my greatest gaming achievements.

This is weird for me, because I’m a brain-games person, not a finger-games person. I like games that take forever to play and even longer to master. Games where you spend as much time learning how to play as you spend actually playing the damned thing.

Yet Super Hexagon, in which my all-time average round length is probably somewhere under ten seconds, is also one of my all-time favorite games. There’s a lot to learn from a game that can break my expectations of a genre, so I’ve spent a lot of time thinking about how Super Hexagon makes me feel and why I play it.

It Feels Good to Know I’m Improving

Almost from session to session, I know I’m getting better at the game. This improvement might be incremental, but it’s there and it’s gratifying.

Super Hexagon’s game design maximizes this feeling in a couple of ways: it has a focused objective (survival over time), and you are given many (many, many, many) trials in which to improve.

Moreover, the game is awesomely efficient at bringing you back to the action. After you lose, a single tap anywhere on the screen takes you right back into the fray. A game isn’t menus. It’s a game. For small arcade-style games, it’s especially important to keep your player playing the game as much as possible. Super Hexagon nails this.

In a single session, you will play dozens and dozens of seconds-long rounds. All that focused feedback makes you hypersensitive to small improvements. It feels like a big deal when you pick up the game and find yourself consistently reaching ten seconds past yesterday’s performance.

To win, you must move precisely, navigating and switching between particular wall patterns. The walls you get aren’t completely random, but a series of wall patterns, and you start mastering them each in turn. You end up improving in phases, and noticeably so, as sections that once seemed impossible become trivially easy. It’s far more gratifying to know that you can “beat” this or that pattern, because you often can’t tell that your reaction times are getting better–that sort of thing sneaks up on you.

Super Hexagon’s modular level design gives you more chances to feel better about your performance in every session.

It Feels Good to Have a Goal

Months after its release, I still play Super Hexagon, an arcade game that technically never ends, because I have a goal: beat all six levels by surviving for sixty seconds in each.

Now, sixty seconds is just an arbitrary stopping point set by the game’s designers. But reaching that final sixty seconds is no mean feat, so it’s a goal that seems both worthwhile and attainable. The game keeps on going after that, but once I break past sixty seconds on Hexagonest Hyper Mode, personally, I’m done. I’m retiring until the sequel comes out. And I will be exceedingly happy.

It Feels Good to Stop Losing

This is my favorite part of Super Hexagon. You spend most of your time losing, but you get pretty zen about it. Losing happens in Super Hexagon, and it happens a lot. You know it and you expect it. But starting again is so, so easy. Each new round is enticingly full of potential, and the amount of energy you need to invest to try again is ridiculously low.

But the best part of frequent losing is that once you’re on a roll, you are on a fucking roll.

You might be stalling at a 10- to 15-second plateau, and then suddenly find your time shooting up past 20 seconds–25, 26, 27… And when you realize it, you get this kick of adrenaline because you have no idea how far you can go. Your movements are so correct and so masterful that you can’t believe it’s you doing what you’re doing. It’s like you’re a runner breaking away from the pack and pulling mysterious speed out of nowhere to finish way ahead of your competitors. It’s thrilling, and it washes away the frustration of your numerous previous failures. And it makes you want to play more.

IT FEELS GOOD, MAN

Super Hexagon deserves the praise it’s getting because it does what few games, brain-games or finger-games, do well: it streamlines an experience down to its very essentials and makes that experience worth more than the sum of its parts.


Unity Networking for Fun and Profit

Getting Connected

Unity networking utilizes the Client-Server networking paradigm. This means that there needs to be a single server, which clients connect to. The server handles the routing of network messages to clients. A server can be a remote machine that only handles the messaging, but for a game like Duet, which is going to have a very small number of connected clients, it’s much more likely that one of the player’s devices will act as the server. Creating a server is a relatively simple affair, with the server instance calling Network.InitializeServer. Clients then just use Network.Connect to connect to that server. There is a bit of complexity regarding Network Address Translation (NAT), and accessing remote machines, but dealing with those issues is a bit beyond the scope of this document.

Connecting the server and client(s) initially does very little. In theory, connected servers and clients could be on completely different scenes, with totally different game states. This may seem strange initially, but allows for flexibility and performance that would be impossible if everything was kept in perfect sync across all peers (clients and server). For example, Project Gorgon (an in-development Unity-based MMORPG) uses several “headless” (without a graphical component) Unity applications to handle NPC interactions. Even though the client and the NPC driver are two completely different Unity applications, they are able to share information with each other. If we want to provide a completely synchronized experience with multiple identical clients, then we need to provide a structure that handles that. Fortunately, that isn’t terribly difficult.

Network Views

When peers are connected, only game objects that have Network Views attached to them can transmit information across the network. Network Views are built-in Unity components, and have a few different operation modes that allow for situation-specific performance tuning. There are three pieces of information that are crucial to utilizing Network Views: the owner GUID, the State Synchronization Mode, and the Observed Component.

The owner GUID is the least visible of the three properties discussed above, primarily because it is initialized by Unity, and cannot easily be changed. Whichever peer creates the Network View is set as the owner. This is important because only the owner can write changes to the state synchronization stream. Other peers can perform local changes, but Unity won’t send those changes to other connected peers.

For example, Client A owns their player object, and can send position changes to the other peers. Client B owns their player object which punches Client A, sending them backwards. The change in position seen on Client B’s instance won’t be seen by any of the other peers. For the force to actually take effect, Client B needs to communicate to Client A that its player was punched, and have Client A react to that change. This doesn’t sound ideal, but it actually allows a technique called Dead Reckoning, where Client B show’s Client A’s reaction to B’s action before A has actually sent a reaction message. For more information, the Valve wiki has an excellent article on interpolation, prediction, and compensation.

State Synchronization

Each Network View (there can be multiple Network Views attached to a single GameObject) has an Observed Component and a Synchronization Mode. The Observed Component is the component whose data will be automatically sent through the network by Unity’s networking. Transforms are commonly used, but any type component can be observed. Since only one component can be observed per Network View, if you want to observe multiple components of an object, you’ll need to utilize multiple Network Views. It may be possible to create a single Component that is an aggregate of all of the components you’d like to sync, but I haven’t investigated that possibility.

The Network View’s Synchronization Mode can be either “Off”, “ReliableDeltaCompressed”, or “Unreliable”. Turning the Synchronization Mode Off means that the Observed Component will not be sent over the network, and can be left null. This can seem like a wasted option, but it is the way of using the game object solely as an endpoint for Remote Procedure Calls (RPCs) without sending useless information over the network. Surprisingly, both ReliableDeltaCompressed and Unreliable Synchronization Modes utilize the UDP protocol, which is inherently unreliable. Unity Networking has it’s own network layer that utilizes ACKS and NACKS to make sure that anything marked as ReliableDeltaCompressed is, in fact, reliably streamed. ReliableDeltaCompressed is much slower than the Unreliable Synchronization, but it is guaranteed to have all updates seen by all peers, and that all of the updates are seen in the correct order.

The Unreliable setting, unsurprisingly, makes none of these promises. When using Unreliable Synchronization, messages can be lost or arrive out of order. This isn’t as useless as it sounds. When the component being synchronized is something that is constantly changing, such as a player’s position, there are going to be lots of updates being pushed through the network. If a small percentage of them are lost in the cold void of the internet, it isn’t a very big problem. Any lost messages are likely to be rapidly made outdated by newer ones that do make it through to the peers. Unreliable Synchronization is much faster than ReliableDeltaCompressed, which makes it ideal for data that will be constantly changing.

It’s worth noting again that with all types of Synchronization, only the changes made by the owner peer will be reflected across the network. Even if the server wishes to make changes, if it doesn’t own the object, it cannot. Therefore, if you want the server to be the authority on game state (which is a fairly standard requirement), the server needs to be the owner of all important objects, and have the players that “control” them send requests for state changes.

Observing a Script

Along with observing basic unity Components like Transforms and RigidBodies, a NetworkView can be given a custom MonoBehavior as its Observed Component. When a message comes in (or a request to send is made), the MonoBehavior’s OnSerializeNetworkView method is called. The BitStream parameter can have data pushed to or received by it using the stream’s Serialize function. Determining whether or not the Component is an owner is a simple matter of reading the stream’s isWriting property. When setting up the functions that read and write serialized data, it is important that the order data is serialized and deserialized is identical, otherwise the right data will end up in the wrong place. Only basic types (int, float, etc) can be serialized, along with Quaternions, Vector3s, and two types relating to NetworkPlayers. Custom objects, even if they are serializable, can’t be send through this function, nor can variable-size objects like arrays. In theory, this limitation could be circumvented by sending the length of the array, and then the contents.
Like the built-in synchronization for unity Components, the order and reliability of OnSerializeNetworkView calls depends on the Synchronization Mode of the Network View. In Unreliable mode, the data is sent/received approximately 15 times per second, though that can be changed by changing the Network.sendRate parameter. Rather than send a certain number of times per second, when Synchronization is in ReliableDataCompressed mode, changes are only sent/received when unity detects that a the component has changed in a way that warrants a data update. Since there is more overhead in this mode, it makes sense that the updates should strive to contain more data, but keep the number of transmissions lower.

Since the custom Component is still being Synchronized via the NetworkView, it holds to the restriction that only the owner can transmit data, and all non-owner peers can merely read the stream. Fortunately, there is a way for peers to send messages to each other

RPC Calls

Remote Procedure Calls, or RPCs, follow a convention that should feel very familiar to a Unity Developer. The if a GameObject has a NetworkView attached, it can call the RPC function, and provide a function name, a broadcast type, and a list of parameters. Then, all synchronized Network Views will receive a function call with that same name and list of parameters. The receiver’s function does need to be marked with an RPC attribute (“@RPC” for Javascript, “[RPC]” for C#), so the unity compiler knows that it is a network-exposed function. RPC function names must be unique throughout the scene’s scripts, so Unity knows which types of GameObjects can receive the RPC. In this way, it is very similar to using Messages, except instead of sending up or down the hierarchy, the messages are sent across the network. Similar to State Synchronization, RPCs can only take basic types, Quaternions, Vector3s, and NetworkedPlayer data. However, RPCs are at a disadvantage, since they can’t make use of the array workaround discussed above. The benefit to RPCs is that these functions are called on all peers that meet the qualifications of the broadcast type specified in the RPC call. Generally, and RPC will only be sent to a single other peer (such as a client messaging the server), or to all connected peers (broadcasting a change). Also, RPCs can be buffered, which means that they are stored at the server level. When a new client connects, all buffered RPCs are sent to that new client, which makes them useful for storing persistent state information.

Unfortunately, the Unity documentation is relatively light when it comes to discussing the performance of RPCs in real-time games. A note is made that the number of parameters of an RPC shouldn’t be overwhelming, which seems to imply that they are expected to be used for fast, frequent updates. However, RPC calls are guaranteed to be received in the same order that they are sent, which can introduce latency if a particular message is misplaced. Since they can, in theory, be called at any time by any component attached to a NetworkView, it would seem that they fill a space between the slower and reliable ReliableDataCompressed and Unreliable modes of State Synchronization. Their ability to affect other peer’s game objects, though, makes them invaluable. This doesn’t expose any additional risk of hijacked peers, though, since the owners of those objects receive the RPC, and can decide if it is, in fact, a message worth listening to.

My Final Argument for Games as Art

So I’ve been having an alarming number of nightmares recently. My nightmares don’t tend to be of the obvious pain-of-death variety; more of the slow, horrifying realization type. Last night’s was particularly crushing, and I would like to share it with you:

A different place, a different time. I lived in a house, with my wife, in a world overrun with vicious predators, who sought nothing more than to rend us limb from limb. For reasons not known to me, our house was not safe at night. So every night was spent running through the wilderness, not staying in one place for very long, leaving our scent with small groups of prey so the predators would consume them and not us. Every day was spent resting in the house; each day one of us would say to the other, “When we rest, we rest together,” and she would make a bottle for the baby. Every night, we’d run.

After a few nights, I realized there were no other humans.

And one day, weeks later, she was making the bottle, quietly sobbing, saying to me, “When we rest, we rest together,” and I realized there was no baby either.

 

Not exactly how I wanted to wake up, and it certainly kept me from sleeping for about the rest of the night. So I lay in bed, thinking about the dream, thinking about how I could communicate to someone just how crushing that realization was. There are obviously many ways that story could be communicated; I could write it, as I just did. I could turn it into a proper short story, with characters; I could illustrate it as a comic; I could do a short film. But all of these are viewing forms — even with a first person perspective, if you came to the realization, it wouldn’t be yours — you would be watching someone else come to the realization. You may feel for them, you may empathize, but it still isn’t your realization.

I realized the only way to fully communicate my experience to someone else would be to turn it into a game.

The reason, of course, is that there is a very specific set of criteria and stimuli you need to experience in order to grasp the full weight of the situation:

  • You need to be you, but as someone else. This strange dissociation isn’t a particularly difficult concept; we do it all the time in dreams, and we do it all the time in games.
  • You need to not know everything about yourself, but know enough to function in your new world. This strange not-amnesia isn’t really that weird; again, we do it all the time in dreams, and we do it all the time in games.
  • You need to be able to take in information at your own pace, information needs to be available to you at only the moments you look for them, and gaps need to be present to allow you draw your own conclusions. Movies try to do this, but they can only show you information; as clever as a director may be, he can’t truly allow you to discover information. But we do it all the time in dreams, and we certainly do it in games.

The realization that there was no baby, and hadn’t been for some time, only came at the moment I saw her crying, because every instance before that, after she made the bottle, we would sleep, and when we ran, she ran behind me. This allowed the assumption that she carried and cared for the baby. But when I had that realization, the rest of the dream came into the focus — I had never seen the baby, I had never heard the baby. The only evidence that the baby had ever existed was in my wife’s actions.

These sort of cognitions, realizations, and epiphanies are only possible in a medium where you are given a certain amount of author-provided information and a certain amount of autonomy of discovery. And so I discovered this truth about games:

Games can cause the participant to have author-guided realizations.

and even more importantly…

Games can cause the participant to have author-guided realizations that the participant owns.

I humbly submit that no other art form could as effectively communicate my dream, as I experienced it. And before you tell me it wouldn’t be a game because there are no goals, the goals are obvious: avoid getting killed by predators, for as many days as possible.

A game can be the strongest medium with which to express a dream. If that doesn’t qualify it as art, then you clearly don’t know how to dream.

Point and Click, Perfected

I play a ton of games. I’m also really fickle. In fact, one of the main reasons why I make games is my frustration with finding games that satiate my specific moods. I’m your worst game design nightmare. I get easily irritated, therefore, I HATE making games for me.

For a few years now, I’ve been hearing about this point-and-click adventure game called Trauma. I believe we’ve even had the immense honor of being nominated for awards next to this title. In my head, I’m not a huge point-and-click fan, despite playing every damn Cyan game from Myst onwards. Somewhere, I think I might be lying to myself. But, the truth is… a genre doesn’t have to define a game. Sometimes, a game can be so completely amazing, it just busts “awesome” at the seams.

I can’t really explain why I’ve put off playing Trauma for so long. At the end of the day, I was just being a jerk. I judged the book by its cover (which honestly looks fantastic). It wasn’t for me. It was for some other artsy, geeky, game-design nerd. Yep. I was wrong.

Trauma is INCREDIBLE. The story draws you in even when you hate story games (I DO, maybe). The aesthetics are phenomenal. A REAL designer was on this project. Almost every game I play these days lacks a good designer; that was not the case here. Someone took the time to really pay attention to the experience they were creating. There are no handholding tutorials. In fact, the basic tutorials are built into every stage of the game and even hidden as a part of the experience itself. The whole damn thing is just bathed in style. The music sets a perfect tone. The photographic imagery is impressive. The animations are smooth without being corny.

One of my favorite parts of the game is its control interface. By nature it is point and click. However, other actions can be performed by drawing lights in the air. Those actions are scattered around this playground-style-world for Gestures through Point and Clickyou to find. The only complaint I have about the game is that the 3 ‘execute’ actions are the same for each ‘dream’. I would have loved to explore a bit more and interact in a more conductive (think music) way.

The play time is rather short. We’re talking 3 hours to completely find everything and all the alternate endings. While some people may find this terrible, I cannot help but LOVE the game for this. The whole experience was fleeting. I have been treated to this amazing experience. I’ll never be in that state of mind again at that moment and pick that game to play. You’ve given me a lasting memory. Thank you Krystian Majewski.

Games like this make me self-reflect. I love being touched by an experience. For me, it’s rare and when it happens I cannot help but be thankful. Thankful that there are people out there making such great experiences and thankful that I’ve just got to get out there and discover them.