Pick it up, and let us know what you think!

Update: Visit the official Pax Britannica website.

Pax Britannica is No Fun Games’ newest work, a one-button real-time strategy game. It was programmed and designed by Renaud Bédard, Matthew Gallant and myself, with visuals by Daniel Burton and audio by Ben Abraham. It was written for Kokoromi’s gamma 4, a showcase for one-button games. Once we found out that it hadn’t been selected, we posted it to the TIGForums for feedback. We weren’t really planning on treating this as an official release, but it’s gotten enough attention that it’s about time I wrote something about it ^_^.

In Pax Britannica, you control one of up to four motherships taking part in an underwater skirmish. Each player uses one button (A, F, H, or L if you don’t have gamepads plugged in) to control ship production, with the ships themselves being AI-controlled.

To check it out, download the Windows pre-release. Mac OSX and Linux versions are on the way, along with the official release.

These simple mechanics lead to a surprising amount of depth, and we’ve gotten praise to that effect. Pax Britannica was shown on Bytejacker, my favourite video podcast ever, where it’s currently a contender for Free Indie of the Week. It’s been featured on IndieGames.com, Play This Thing!, Gamasutra, and GayGamer.net among others (thanks guys!). Also, an adorable little kid said it was good! (Thanks @CymonsGames!)

For a quick peek, check out Darius Kazemi’s video review (much appreciated!), embedded below.

Several new textual genres have emerged with digital computing and automation. Computer programs, complex lists of formal instructions written in specially designed, artificial languages, can be seen as a new type of the rhetorical figure apostrophe, the addressing of inanimate or abstract objects, with the magical difference that it actually provokes a response. Short, simple programs are often linear, but longer programs generally consist of collections of interdependent fragments, with repeating loops, cross-references, and discontinuous “jumps” back and forth between sections. [...]

Programs are normally written with two kinds of receivers in mind: the machines and other programers. This gives rise to a double standard of aesthetics, often in conflict: efficiency and clarity. Since speed is a major quality in computer aesthetics, an unreadable program might perform much faster than a comprehensible one. The poetics of computer program writing is constantly evolving, and through paradigms such as object orientation it inspires practical philosophies and provides hermeneutic models for organizing and understanding the world, both directly (through programed systems) and indirectly (through the worldviews of computer engineers).

From Cybertext: Perspectives on Ergodic Literature, Espen J. Aarseth (p11). Emphasis mine.

Sounds great, how do we do that?

If a game gives the player agency, then the act of playing the game becomes more directed and enjoyable. But, how does a game make this happen? Mateas answers this by first bringing up two concepts from Aristotle’s theory of drama: material cause and formal cause.

Aristotelian what now?

Material cause and formal cause have opaque names, but they’re actually pretty simple concepts. Material cause means the components that make up something. In drama, this means things like the acting and dialog that you see when you watch it. By finding patterns in these elements, you can infer things about how the characters are feeling, and what direction the plot as a whole is going to go. This leads to the formal cause, which is the overall goal, or plan. In drama, this refers to the plot, or the theme. The author is the only one who knows the exact formal cause, but the viewer infers it from the material cause.

But wait, we were talking about games

Mateas takes adds player interaction to these concepts to map these concepts to video games. He redefines formal cause as being not only the game’s end goal, but also incorporating the goals of the player. The player forms new intentions as they’re playing, and those intentions shape what they do in the game. They become the “plot” of the gameplay experience. He also reevaluates the role of formal causation:

In noninteractive drama, understanding the formal chain of causation allows the audience to appreciate how all the action of the play stems from the dramatic necessity of the plot and theme. In interactive drama, the understanding of the formal causation from the level of plot to character additionally helps the player to have an understanding of what to do, that is, why they should take action within the story world at all.

That is, the context of the game which makes up the formal causation actually indicate to the player what actions they should expect to be able to take.

However, affordances given to the player given by the material cause also suggest actions to take. This just means that if you see something in a game, you expect to be able to interact with it and use it for something. This ties in with the concept of affordance from user interface design. For example, when a weapon drops in Super Smash Bros., not only do you expect to be able to interact with it, but its very presence suggests to you that you should do so.

What does this have to do with agency?

Mateas uses the concepts of formal and material cause to indicate how a game can give the player a sense of agency:

A player will experience agency when there is a balance between the material and formal constraints. When the actions motivated by the formal constraints (affordances) via dramatic probability in the plot are commensurate with the material constraints (affordances) made available from the levels of spectacle, pattern, language, and thought, then the player will experience agency.

The player will feel agency when the goals coming from the game’s plot or context match up with the things that the game mechanics allow and encourage the player to do. This is because the player’s long-term goals cause them to decide to take certain actions (to form intentions), and the material causes (mechanics, items) allow them to take these actions in a way that produces results. Not only that, but these results are then meaningful because they are relevant to the game’s plot or the game’s intentions (usually because the results were expected by the player). This means that the player is constantly driven to make meaningful decisions and getting meaningful results.

Control

Games are systems which react to the actions of the player. The player gives the game certain input, and the game responds to it by behaving in a certain way. As the player figures out how the actions and reactions relate to each other, they are able to control the game state, to make it do what they want it to. For example, when you play Super Mario Bros. you learn where to jump and how to move to beat the enemies and get to the end of the level quickly. In Tetris you learn to place blocks so that you can destroy them well and get a high score. As players master a game, they start to feel control over it. The player feels control over the game’s micro-world much more than they would normally feel in real life.

Fun games can take advantage of this by leading the player to learn how they work, while continuously providing new obstacles to overcome. This way the player is always increasing their mastery of the system, while never running out of things to learn.

Deep concentration, or Flow

Sherry also describes an altered state of mind involving deep concentration. Though the chapter never actually uses the word, this altered state matches very well with Csíkszentmihályi’s notion of “flow.” There’s a good deal to read on flow (notably Csíkszentmihályi’s own “Flow: The Psychology of Optimal Experience”, which is a very interesting book), but the gist of it is that the entirety of your self is focused towards one activity, and everything else is pushed out of your mind. In this state, outside worries disappear, you lose self consciousness, and the flow of time moves at an unusual pace. Strangely, the state of flow can also make your mind feel “free”, as it’s not limited by its normal thought processes.

To begin this state of flow, the activity needs to be hard enough that it’s not too easy, but not so hard that it becomes frustrating. Video games have a unique advantage in this since, as they are backed by a computer, they can adapt to the player to offer them the ideal level of difficulty. In fact, many of the games mentioned, such as Space Invaders, Pac-Man, and Asteroids, are written to get harder and harder forever, so that in theory there’s no end to the challenge (actually, Pac-Man wasn’t quite infinite, there was a bug on the 256th level where the entire right side of the screen had corrupted graphics, making it pretty unplayable).

Since games usually give you a measure of how well you played, they make it easy to track your improvement. “The games require total concentration [...] at the same time as they provide a stage for excellence.” The combination of the two can be really addictive!

Even if it worked well, it didn’t go perfectly. I kept up the habit of working continuously, but I didn’t keep a great sense of direction. Last semester at school, I started the habit of keeping a todo list, and mapping out when I would do what at the beginning of each week. I had so many different things to work on that I needed to do this to reduce pressure and get everything done.

This summer, though, I’m usually focusing on one project at a time, so I unconsciously dropped the habit. As a result, even though I’m productive a day at a time, I often don’t have a good sense of where I’ll be at the end of the week, and small tasks that aren’t part of my main project (like cleaning up -_-) often get put off too long.

In June I’m going to continue what I was doing in May, working 6 hours a day five times a week, but I’ll also work on longer-term task management. One way I’ll do this is to keep a scheduled todo list which I map out at the beginning of each week. The other way is something I’ve been experimenting with recently.

For whatever project I’m working on, I’ll put each task on a single index card, along with any notes I decide to write about it. I can lay these out on my desk, easily sort them by priority, and keep whichever one I’m working on in front of me so that I can’t forget what I’m supposed to be doing =). If I find myself working on something with no card, then it’s probably not important, and if it is then I can make a card for it on the spot. I found this to be a really satisfying way to manage tasks, especially when you can take a card and write DONE in big letters, while putting it into your success pile ^_^. It also helps to maintain focus since you know exactly what you should be doing at all times.

Specifically, I’ll be doing indie game development. Why? Because it’s what I’m passionate about. I’m going to start out with short prototyping projects, probably about one week each, to try out different ideas. This summer I should have fun, come up with good ideas, and learn lots, improving my technical and creative skills.

The downsides to not working as an employee are that there’s no structured work environment, no outside pressure to excel, and no salary. Nevertheless I think it’s going to be a net win, since 100% of the effort I put in goes to stuff of my choice, the effort I put in directly benefits myself instead of some big corporation, and I can make the work fun!

The biggest worry I have is that since there’s no outside pressure, motivation will fade to laziness. To avoid this it’s very important to keep the work fun and cultivate my motivation.

My monthly goal for May will be to put a substantial effort into the projects I’m working on. Specifically, I’ll put in six hours of work, five times a week. This is similar to January’s goal of timeboxing 3 hours of time every day, but this time I’m going to aim to devote the entire 6 hours in a given day to a single project, which should let me focus and really get in the zone. I’ll have the option of changing what I’m working on from day to day, so I’ll still have the freedom to mix things up if I get worn out on something. This six hours is a minimum, not a fixed amount, so some days I’ll likely put in more. It’s a bit less than a full-time job, but I plan to use that extra space to allow my schedule some flexibility, not to slack off.

I have big ideas for May and the rest of the summer, so I need to start building momentum right now. To start off, I’m going to spend the rest of April getting back to waking up early. The near-sleepless CS Games and end-of-semester rush knocked me out of any regular schedule I’d managed to build up, so my first goal is to straighten it out.

Download it for:

• Windows
• Linux (32-bit)
• Source .love file (run it with LÖVE or rename it to .zip to extract)
• Alternate .love file for OS X users, which uses [shift] to shoot instead of [control], which is often reserved.

The game was written for Ludum Dare, a game development competition. The idea is to write a complete (but small) game, mostly from scratch, over a 48-hour period. It’s free to participate, there are no prizes (except for your game!), and all of the post-competition judging is done by the competitors. Our theme was “advancing wall of doom,” which I think I kept to pretty well. I’m happier with Extinguish than I was with either of my previous two Ludum Dare games, but there’s still definitely room for improvement.

With my previous Ludum Dare games, the main problem was that I was driving my game design with technical ideas. This was especially true with Mininode, where I had awesome (or so I thought) ideas about how I could hook different components together into graphs and have them interact in strange ways. The problem was that once I’d implemented the technical side, I ended up having no good ideas for interesting gameplay. Needless to say, it didn’t turn out very fun.

This time, I started thinking about the actual gameplay from the beginning. With a lot of work I was eventually able to turn it into a game. This time, I had a different weakness: direction. Although I had a general idea of where I was going with the development, I didn’t take the time to break the task into milestones. The most important part of being productive is knowing what you’re doing at any moment, and what you’ll be doing next. You need to have concrete goals, or mini-deadlines. I didn’t know where I was aiming to be by the end of Saturday, so I ended up not doing as much as I could have. This made Sunday all the more frantic, and although I finished the game, I would have liked to have time to add more features, such as sound and better graphics.

I learnt a lot this weekend, and it will help me to do a better job during the next competition. If you can code and want to compete in either the next mini-competition (in May) or the next main one (in August), check out the Ludum Dare website or check out the IRC channel.

Finally, a timelapse of the development of Extinguish!

A typical deathmatch game has you living for at least maybe 30 seconds on average (longer in many, like Counter-Strike). In Cel Damage, you’re lucky to live longer than 10, and it’s not uncommon to die while spawning! Dying can be especially frustrating for a few reasons:

• many of the weapons in the game are one-hit-kills
• some of the weapons can kill you from halfway across the map
• whether or not someone succeeds in killing you is dependent on how good the other player is, not on how good you are at defending

Basically, you can die through no fault of your own, often with no warning!

The trick to enjoying Cel Damage is realizing that it’s normal to die! What matters is who else you’re able to take out before it happens. In Cel Damage, death is not something you can reliably avoid, and that doesn’t matter.

The issue is that most games are based on survival, where dying either gives a substantial penalty or means game over. Neither of these are the case in Cel Damage, but the attitude of dying is bad is carried over when you start to play it. The game’s failure is not in how liberally it deals out death, but in not communicating to the player that dying is normal. When you’re breaking an established game design rule, you have to make it clear, otherwise the player will assume that either the game is broken or they’re doing something wrong.