Water it down and burn it

Wow, I'm posting a lot more often than normal! I guess you can thank my new job at Linden Lab for that. :) We'll see how long this keeps up...

As far as I can tell, there are two types of games that people play for a long time: games that water down content and stretch it out through RPG grinding or FarmVille-style appointment systems, and games where you create. Okay, I guess there's a third - games with evergreen content complexity, like Triple Town, but these are very rare and I don't know of any very successful online games based on that principle.

World of Warcraft is the obvious example for games with lots of content, and even when it's watered down there is still a ton of it and it's very expensive to develop. FarmVille is an example that combines a thin layer of grinding with a thin layer of creativity. Minecraft is an example that combines a layer of grinding (harvesting resources) with a much deeper system of creation.

In all of these examples there is a social element as well, which is essential (even in Minecraft, minimal as it is), but even non-games have it (chat clients, forums, social networking sites) so I won't dwell on it here. Just keep in mind that the longest-lasting games tend to be social in some way.

In games with a creative element, like FarmVille and Minecraft, the grinding gameplay serves to give structure and ease the player into the creative play. As the player begins to tire of the grinding gameplay, the creative part is there to take up the slack. But the initial gameplay structure is essential to provide that hook and that ramp into the later experience.

In games where the creation experience is separate from the gameplay experience, there will be some players who only do creation and many more who only do gameplay. In this case you could set it up so the creators are providing gameplay content to the players. However, without watering the content down (with grinding), it is likely that the players will burn through content much faster than creators can create it. And because playing is separate from creation, most players who burn through gameplay will not transition to creation - they'll just leave.

I've imagined making a game where you create platformer levels like in N or Super Meat Boy, and earn points when other people play these levels and rate them highly. I still think that would be a cool idea, but I'm realizing that it would not work very well as an ongoing community experience. I doubt that anyone would spend months playing Super Meat Boy, as good as it is, while millions of people play games like FarmVille or World of Warcraft for a very long time. There's just not enough gameplay in a platformer to keep people going on level design alone.

But you could imagine a game where people create watery RPG content for other people, and where the creation and gameplay aspects are connected enough that there is a steady flow of players becoming creators. If you connect the creation and gameplay in a sloppy way, the two could collapse into each other, with people exploiting creation to farm gameplay progression (creating easy dungeons with gold everywhere and no monsters, for example). There could also be problems with finding appropriate content for players at various levels. But it should be possible to tune everything so it works as a self-sustaining ecosystem of playing and creating and moving between the two.

What would that look like?

Revising Flydrill

After a year and a half, I finally updated my game Flydrill. Yay.

You just added achievements!

Ever since releasing Flydrill in March of 2010, I've been dissatisfied with the game, and embarrassed to show it to people. It wasn't a bad game - in fact it has been my best so far, but there were just so many problems I saw in it, so many things I wanted to change.

In particular, I thought that they key ingredient the game lacked was logistical gameplay. Later on, I realized that this was just one of many shortcomings, and that the core of the game and the overall structure of it could stand to be improved as well.

So what I've done this past week is improve the core gameplay.

First of all, the arbitrary dream-logic rule that you could only drill to the right is gone, and now you can drill in all four directions. This opens up a lot more possibilities for burrowing and evading through tiles, slipping out of danger through narrow gaps which you can widen into caverns as in the screen shot above. It's also a lot less confusing for new players. Why can I sometimes drill and sometimes not? That question doesn't come up anymore.

Next, I got rid of the extra lives. Now it's one hit and you're dead. Why so cruel, you ask? One answer is that this is inherently a very hardcore game, requiring the coordinated use of many skills and actions, under significant time pressure. I'd originally tried to make it more casual, and weakened the game as a result. Now, I embrace its hardcore nature. Having a single life sharpens the focus of the entire experience. You stop paying attention and you die.

Getting rid of the extra lives also means that you can no longer feel the despair of being down to your last life, with no hope of recovery. The complacency associated with having two extra lives safely tucked into your back pocket is no longer an option. No false sense of security.

And it's much less confusing. Before, I noticed that many people would lose a life and not realize it, never learning the lesson that running into a swarmer is hazardous to your health. Now, there's no question. When you touch a swarmer, you know something bad happened. And because you've learned something, you decide to try again, armed with your new knowledge. Clarity is more important than coddling.

Finally, having a single life makes it much easier for me to balance the game. I've increased the frequency of invincibility halos and decreased the frequency of portals, so that the experience alternates between frantically dashing through clouds of enemies long enough to find a halo and racing to get the most out of your halo while it lasts, maybe taking out an enemy or two just because you can. Halos are not rare experiences anymore. This alternating rhythm is now the core of the game. If you had more than one life, it wouldn't work as well because the game would drag on and on, and the extreme focus of the halo-less portions would be dulled by a false sense of security.

Along those lines, I've also greatly improved the pacing of the game. In Flydrill's very first release, the game started out very slow, and to many players, boring. In response, I crudely ramped up the pace, throwing everything at the player right away. This was not optimal. But I figured that overwhelming the player was at least better than boring them. Now, however, I think I've succeeded in making the game interesting from the very beginning, while also gradually introducing new enemies to the experience to keep it feeling fresh.

The first thing I did was increase the speed of the swarmers. Back when the game gave you multiple lives, the swarmers would start out really slow, and very gradually get faster as you progressed, slowing down whenever you lost a life. Like Pac-Man CE. However, with three lives, this meant that the swarmers started out so slow as to be totally harmless, and eventually got ridiculously fast, neither of which were fun situations.

So I made them speed up much more quickly. To compensate, I made them slow down every time a swarmer dies, whether by colliding with another enemy or with your halo of death. This creates a nice feedback loop - the swarmers get fast, but once they reach the point where they're so fast that they're running into each other, they slow down. And it means that if you can dodge the swarmers long enough, they'll slow down so you can escape safely. But as soon as you travel out of range, they'll have gotten fast enough to catch up with you again and the cycle repeats. This alternating cycle nests nicely with the larger cycle of halo having and not-having, and makes the core gameplay much more enjoyable.

The next pacing improvement I made was to space out the introduction of enemies. Now that the game was interesting just with swarmers, I could wait to introduce the other enemies, without fear of boring the player in the beginning of the game. Puffers come in shortly after swarmers, teaching you to watch where you're going as you dash madly away from danger, and then later the gunners, teaching you to use walls for cover instead of hanging around in the open, and then finally the diggers, teaching you that sometimes a cozy little burrow can be the worst possible place to hide.

Lastly, I made big solid walls appear every so often, to provide some milestones in your rightward journey, and throw in some opportunities for serious drilling. At first I'd assumed that these walls would be very dangerous places, where you are stuck frantically drilling as your enemies nip at your heels, so to speak. But as it turned out, with the four-way drilling now available, these walls became safe havens that I'd look forward to - places where I could burrow safely, feeling through the gaps in the tiles that my enemies could not fit into, where I could be pretty sure to find a halo or two in the safety of the solid wall. Unless a digger stopped by for a visit. But that made it all the more exciting. :)

And the portals, those bubble things that change the background color and clear all enemies from the screen, now have a more pronounced effect on what type of enemy you are likely to find. The colors have stronger associations - red for gunners, green for diggers, and blue for puffers - and the difficulty does not go down so much when you enter a portal. So it's not always something you want to go for, especially if you see a green portal in a nice, safe blue zone. You have to make a choice. And that makes it more interesting.

Also the portals now have big halos around them to make them easier to hit. New players often have trouble with the timing-sensitive flapping controls, and hitting a portal shouldn't be a challenge in itself. But the portals also don't appear as early to tempt these new players either, since the color changes and corresponding enemy distribution changes would totally throw off the gradual pacing I have set up.

The last change was to add a persistent high-score display, inspired by iPhone game Bit Pilot, to replace the now-useless extra lives in the upper-left corner. This game is entirely about pushing your score a bit further than last time, and I decided that I'd give this goal the attention it deserved by making your best score constantly visible as you play.

The other last change, the last last change, was to add achievement notifications.

"Achievements?" you gasp, "How crude!"

Yeah, that's what I thought at first too. But wait, there's more to this than you might at first think. I didn't go with the typical trophy-style achievements, where there is a list of things to achieve, and then you achieve them, and you are told that your achievements have been "unlocked" and now you can see them shining magnificently in your list. I mean, that would require a whole new interface to design and implement! No way!

Instead, I went with the second option.
From Chris Hecker's Achievements Considered Harmful?:

For interesting tasks,

1. Tangible, expected, contingent rewards reduce free-choice intrinsic motivation, and
2. Verbal, unexpected, informational feedback, increases free-choice and self-reported intrinsic motivation.

There's no list. When you do something cool, like travel 1000mm, or kill 10 enemies, or hold a halo for 20 seconds, the game tells you. When you do something even more cool, like travel 2000mm, or even 3000mm, or kill 20 enemies, or hold a halo for 40 seconds, the game tells you again. And that's it.

Short of adding coins everywhere, it's one of the few things I can do to make the player actually feel good about what they're doing in the game, instead of just making them frantic and terrified or temporarily relieved at having escaped with their single life for a few precious seconds of respite inside the safety of a wall.

The only shortcoming is that this feedback is not entirely unexpected, since the pattern is pretty easy to pick up on, and it tells you every time. I might experiment with the game only telling you the first time you do something, making its announcements much more rare and precious. But for now I think the system works pretty well.

And I didn't even have to design a new interface for it. That's the best part. ;)

The changes I'm considering next are more drastic, like adding baby fliers to guide for upgrade points and adding upgrades to spend those points on. Logistical gameplay. But I'm not sure how it will all turn out.

For the moment, I'm just glad that Flydrill is finally, at its core, a solid game. I'm not embarrassed to tell people about it anymore. :)

So try it out and tell me - what do you think?

How Artists Want to Make Games

On the notgames forum, Michaël Samyn posted this thread:

Programming in code is counter-productive for people with art-sided brains. The solution to this problem exists: graphical programming. But the people who need to implement this solution happen to be its worst enemies. Because to engineers, code-based programming beats everything.

Until somebody somewhere starts believing artists when they say they want to program in a visual language, or starts realizing that giving access to artists is the best way for a creative technology to continue evolving, I find myself settling with inferior designs. Because I cannot express myself adequately in code, I need to change my ideas, I need to talk about simpler things in a simple way.

It's like someone is forcing me to write poetry in French. French is a great language. And people who are familiar with it can write beautiful poetry. But I speak Dutch. My Dutch poems are subtle and sublime. In French, however, all I can write are nursery rhymes.

So I've been thinking about this a lot over the last several days. Actually I've been obsessively thinking about it non-stop and reading everything I can on related topics online.

I tend to do that for a different thing every week. This week, it's been this.

So there are a few pieces I've been focusing on, that seem most crucial to the success of a programming or game development tool for artists. There are probably others, but I thought I'd share what I've been thinking about so far.

One is readability through R-mode perception.

First of all, a disclaimer: When I say "R-mode" versus "L-mode", as in "Right brain" or "Relational" or "Rtistic" versus "Left brain" or "Logical" or "Linear", I don't mean to suggest that the brain is really divided into strict differences between its physical right and left halves. That is an outdated belief. But I find the terminology to be a useful shorthand.

Thinking on Michael's comments about visual flowcharts being easier for him to read than linguistic code, and looking back on my own experience, I think there really is something significant about how the code is presented and perceived, even when the underlying logic is the same.

When I am reading code (or a book!) I am usually using what I call "L-mode" perception - going through in a linear, linguistic way, and building up my mental model one step, one line of code at a time, following the logic that is expressed symbolically, in sequences like that.

However, sometimes my mind is in an "R-mode" of all-at-once, spatial perception like you'd use for looking at a painting or trying to find a certain LEGO piece in a big box of pieces. When I am in that state of mind, and I look at code (or to a lesser extent, written language) I see all the words at once and perceive the spatial relationships between them, and the underlying logic of the code is utterly incomprehensible to me. Obviously not the "right" way to read code.

But maybe it could be.

Ha, that would be a good tagline. "The right way to code." :P

The thing about R-mode perception is that it's a lot easier to be creative when you're in it. The other thing about R-mode perception is that artists are usually a lot more skilled at functioning in R-mode than they are in L-mode.

Therefore, if you had a tool that let you do programming while in R-mode rather than L-mode, it might be slightly easier to do creative things with it. At the least, there would be less inefficiency caused by switching between R-mode and L-mode whenever you think about what you want to change and then have to dive into the code to actually change it.

However, this may not even be possible.

All the visual programming editors I've seen, all the examples that have been posted here, require an uncomfortable mix of L-mode and R-mode perception in order to use. What I tend to see is a bunch of visually identical boxes connected by lines, and differentiated by text.

What you see in R-mode is the set of relationships between the boxes. But you can't tell what each of the boxes does. To do that, you must read the text and think symbolically, in L-mode. Really, very little information is conveyed through spatial relationships, through R-mode. Most of it is still sequential and symbolic.

For that reason, I find that pure written code, all L-mode, is much easier for me to deal with, since I don't need to switch around multiple times a second just to figure out what everything means. However, I suspect that there may be a way to create a pure R-mode method of programming too. But I'm not confident that it's actually possible. Just intrigued enough to try.

There are some programmers who hate the idea of visual programming, and say that it's a waste of time to use spatial relationships to convey the meaning of code. If you are one of those people and you use syntax coloring or indentation, you are a hypocrite.

So there's one aspect. Make sure your tool is R-mode accessible, if you want artists to be able to use it.

The second thing is building with functional pieces in real (or almost real) time.

Artists tend to appreciate tools where "what you see is what you get" - you're manipulating the end result, so you can immediately see the results of your actions. The process becomes more like sculpting.

Programmers tend to discount such tools as nice but unnecessary. They are used to typing in code for an hour, hitting a button, and waiting a minute for everything to compile and show up on the screen.

These are two fundamentally different mindsets, as different as a slideshow and an animation.

When you operate in the slow, "slideshow" approach, development and creativity tends to happen in an architected, "top-down" way. You have a plan, which is in your head, and then you put in a bunch of time and hard work to mold reality into the shape of that plan.

There is a fundamental shift that occurs as you decrease the time between action and result. It's as real as the shift that occurs when you hit 24 frames per second - from slideshow to animation. To your brain, it's alive, it's moving.

When you operate in the immediate, "animation" way, development tends to operate in a more exploratory, "bottom-up" process. You don't have to have an entire plan in your head. You see the results of your actions immediately, and if they are surprising or unexpected, you can adjust your plan. You can try random things and follow them if they prove to be interesting.

In the area of game design, innovation is much more likely to come out of an exploratory process than an architected one. As Jonathan Blow said earlier. It's hard to do things that haven't been done before if you have to plan it all out in your head first.

So we want a tool that allows us to sculpt the end result, with immediate feedback.

Part of this is that everything you can make should work. It may not work in the way you desire or expect, but it should still do something.

If you are painting with pixels in an art program, no matter how you put those pixels down on the screen, it will always be a functional, viewable image. It might not be pretty, but you can still see it. You are never going to run into a error message that says, "Invalid pixels at position 55, 46. Image cannot be displayed."

But if you are writing the code for a program, this sort of thing happens all the time. Most of the things you can type won't work at all. They won't turn into a program, even a broken one. There are right ways to write code, and wrong ways to write it.

I would say that this also makes a big difference. Perhaps the biggest difference is that writing code has a much higher barrier to entry, more learning how to do things at all before you can start learning how to do them well. But it also makes experimentation so much more difficult. You can't throw a bunch of random stuff together just to see what happens. Because what happens is nothing. It just won't do anything at all.

So if you can build only with pieces that work, and immediately see what changes, this would make truly artistic interactive art much easier to create.

The last thing is expressing general logic through specific examples.

This is probably the most impossible and most revolutionary but least important of the three. If you just had a tool that you'd use in R-mode, that let you shape the end results with immediate feedback, that could be awesome, and probably enough to make a huge difference.

But at the same time I am intrigued by this further vision I have of providing specific examples, which the system will extrapolate to create possible general rules for creating those examples, which you will then provide feedback on and refine in order to guide the system's hypotheses toward the end you have in mind.

Because I don't see how to actually avoid symbols when describing logic, or how to directly manipulate end results in a general way. Because games are systems, and the end results happen when you take the rules that you have set up and run them through their paces.

So maybe this is the only way to achieve those first two goals in their entirety.

What am I talking about?

You know how you draw diagrams and mockups for different things that happen in different situations in a game? Like this. It's a pretty common way to organize your thoughts when you're designing. The thing about those is they're all organized around specific examples, not general rules. So you might draw a diagram with a guy hitting a wall, showing how he bounces off or breaks through it or whatever. It's not completely specific, as you might have an abstract line standing in for any kind of wall, and a stick figure representing any kind of guy, but at the same time it's very concrete. And you can add general connotations by writing in little notes, to explain the rules behind the example more clearly.

The reason that we don't just stop there is that our game development tools require everything to be spelled out exactly - they cannot extrapolate from these examples, because there is so much ambiguity. It could mean this or it could mean that.

However, we run into a similar problem when trying to communicate our ideas to other people who are helping us make them into a reality. Especially if we are designers and we are telling programmers what to do. How do we solve this problem with other people?

Part of this is by clarifying with more examples when an area is unclear. Kind of starting at the highest level and breaking it down into more specific situations when necessary. Another part is through conversation, asking "It sounds like you're describing this... Is that right?" and responding "Yes, exactly!" or "No, I was thinking something more like this..."

Both of these could be accomplished with a special computer program instead of a human programmer. Maybe not as well, especially in terms of accuracy of translation, but in some ways better - particularly, in the time between your description of a design and seeing something on the screen. And this increase in speed could make up for the lack of accuracy, since you can adjust and correct much more quickly. And as a result, make use of exploratory design instead of architecture.

Break dynamics down into stories instead of rules. A playthrough of the entire game could be an example story, and you could create example stories of successively smaller and smaller pieces of the game until you have specified it completely. Or completely enough.

The tool generates possible rules that could create the situations you specify, and presents several for you to try out. Most likely none of them work the way you want. Pick the one that's closest, and let it generate more possibilities based on that. It's an evolutionary search. Like Biomorphs.

And stories don't always have to be specific stories about specific instances. They can be more or less abstract and universal. Like Raven, with a capital "R", who is both the character Raven and all ravens and all tricksters at once. Or the princess in the tower, or the wise old man, or the dragon in the cave. Or the stick figure on the crosswalk sign who represents all pedestrians who could ever walk this way. There is a continuum between the specific and the symbol.

I am particularly inspired by the concept of the Dreamtime. The translation of this name is misleading, as it does not refer to a time in history. It is like a parallel slice of the world running alongside and underneath the specific, physical world, where the gods and heroes walk, creating and personifying the dynamics and processes that underlie everything we see in reality.

I want a tool where I can not only shape the world as a level designer, but also shift into the Dreamtime and shape the dynamics of that world as concretely I would shape the placement of coins and mushrooms.

When this happens, we will get our interactive art.

Flydrill and Logistical Gameplay

Want to know why I haven't written a blog post in two months?

I've been making a game.

It's called Flydrill.

Explore an infinite dream world. Survive an endless nightmare. How far can you fly?

On the 23rd of October, in 2008, I had a dream where I was this little abstract flying thing like the flier from Flywrench. I was in a maze of square tiles, and I could drill to the right. Little swarming dots chased after me. When I woke up, I decided to turn it into a real game.

And so, more than a year later, I did - with a bit of help from some helpful people, an exceedingly helpful game engine, and some "inspiration" from Canabalt, Left 4 Dead, and Pac-Man Championship Edition. Though I've only ever played one of those games. I'll let you guess which one.

But I'm not here to go on and on about how I made this game. I've already done that, in this thread on the Flixel forums. And I'll probably be posting another blog post, soon, about how to get Flixel and Mochi Live Updates and the Newgrounds API all working nicely together. But this isn't it.

Every time I release a game, I discover new blind spots in my understanding of game design. This latest game is no exception. The feedback I've gotten on Newgrounds and Kongregate has led me to some interesting new hypotheses about the basic principles of Flash game design.

Here they are.

...but first, a screen shot!

I've become convinced that Logistical gameplay is the single most important factor in predicting a Flash game's eventual success or failure. Of secondary importance is the Tactical gameplay. Flydrill is the first game I've made where the Tactical gameplay is really solid - in fact, I think it's better than most Flash games in this regard - but it has no Logistical gameplay to speak of. And the player response shows it - great reviews, but a mediocre overall rating.

If my hypothesis is correct, then adding Logistical gameplay to Flydrill should make it a very successful game in terms of portal ratings and popularity.

So, what is "Logistical gameplay" anyway?

I first came across this term in the book 21st Century Game Design by Chris Bateman. Corresponding to the four personality types in the Keirsey Temperament Sorter, he identifies four categories of gameplay skills: Strategic, Diplomatic, Logistical, and Tactical. My own analysis is based on the research in the book. Read it if you want to learn more.

According to Wikipedia, "Logistics is the management of the flow of goods, information and other resources, including energy and people, between the point of origin and the point of consumption in order to meet the requirements of consumers."

What does this mean for games? When it comes to Flash games, at least, Logistical gameplay often means lots of upgrades and items and achievements to serve as the requirements for in-game resources, and various ways to convert player time and skill into these in-game resources, whether experience points or virtual cash.

But logistics isn't just about grinding for an achievement. All gameplay revolves around choices.

Logistical gameplay (read more) revolves around choosing how to allocate your resources - which upgrades to invest in, how much to spend, how much to save, and how to manage your time and effort effectively for the greatest payoff. The pleasure of Logistical gameplay is not in simply doing something, but in doing it well - optimizing it to perfection. This is why achievements are so important. They give the player a reason to excel, which creates Logistical gameplay.

There are many Flash games that focus on Logistical gameplay. But the best example that I've found is a little game called Toss the Turtle. Actually, it's not little at all, it's big - packed with items and upgrades to buy, achievements to earn, and tons of variables to tweak and improve on the way to the perfect turtle toss. You can see this formula repeated in many top-rated games, from Learn to Fly to Infectonator : World Dominator. Why? Logistics. Each of these games is heavily Logistical, with a bit of Tactics thrown in.

But what is Tactics?

Tactical gameplay (read more) is about the choices you make from moment to moment in the midst of action. This can be anything from dodging bullets to matching gems - in general, reading the situation of the moment and responding in the most appropriate way.

In Toss the Turtle, the Tactical gameplay consists of choosing when to shoot your turtle for extra height, and using the arrow keys to slightly adjust the turtle's trajectory. It's not much, but it gives players some non-Logistical skills to work on between trips to the upgrade shop.

But the purest example of Tactical gameplay that I've seen so far is the ingeniously simple Particles. All you do is avoid the bouncing balls for as long as you can - no upgrades, no story, no fancy graphics. But the gameplay it creates is very effective, and very Tactical - reading and responding to constantly shifting patterns of safety and danger.

There are other types of gameplay that tend to be less critical for success in the Flash game market - namely, Strategy and Diplomacy. But these can be very important for long-term success, because these are the deeper skills valued by hardcore players.

Strategic gameplay (read more) is about imagining solutions to complex problems, and this skill is most often catered to in Flash by puzzle games. Fantastic Contraption is the perfect example of this. Its commercial success may have something to do with the fact that it is based on Strategic rather than Logistical or Tactical gameplay - as I mentioned earlier, Strategic gameplay tends to be favored by more dedicated players, who are perhaps more willing to pay for the experience.

But also important to mention is that Fantastic Contraption also supports Logistical gameplay, because each puzzle is predefined, and the solution can be discovered by trial and error - in other words, Logistical optimization - if no ingenious Strategic insights come to mind. This means that all the players who prefer Logistical gameplay will still get some enjoyment of the game, rating it highly and sharing it with their friends, even if they don't like it enough to pay for it.

Diplomatic gameplay (read more) is about understanding and reconciling differences while preserving individuality, a skill that is rarely catered to by Flash games. We just don't know how to make Diplomatic games - not yet, at least. But there is one genre that begins to approach Diplomatic gameplay - in a very rough and rudimentary way, but still, it's Diplomatic more than anything else. Can you guess what it is?

No? I'm talking about spot-the-difference games. The gameplay in these games is not Strategic, Logistical, or Tactical. It's about finding the discrepancies between two different points of view, and resolving these differences. Diplomacy, abstracted. Difference games often support interesting artwork or involved storylines - see Dream or 4 Differences for example - which can provide players with a sort of imagined Diplomacy of conflicts to resolve and different characters to empathize with, even if it has nothing to do with the actual gameplay.

So that's some interesting background information. But why would I say that Logistical gameplay is the single most important factor in predicting a Flash game's eventual success or failure?

On page 91 of 21st Century Game Design, I came across a table citing this study on the distribution of the Myers-Briggs personality types across the general US population.

Here's what I found:

• 50% of the US population prefers Logistical skills (SJ)
• 25% of the US population prefers Tactical skills (SP)
• 15% of the US population prefers Diplomatic skills (NF)
• 10% of the US population prefers Strategic skills (NT)

No wonder Logistics is so essential!

If you make a game that focuses exclusively on Logistical and Tactical gameplay, you will automatically capture 75% of your potential market. If you focus exclusively on Tactical gameplay, as I did with Flydrill, you will capture only 25% of players. Oops.

Hmm, that explains a lot.

Tower defense games effectively combine Logistics and Tactics into a single package, which helps explain their popularity and continued success. Puzzle games combine Logistics and Strategy. And the only reason we don't see more Diplomatic games is that no one knows how to make them. Difference games are the closest we've come.

So there you have it. If you want to make a Flash game that appeals to the majority of players, you must be sure to include some excellent Logistical gameplay. How to do that, of course, is the subject for another blog post. ;)

Until next time...

awesome score yay! :D

Playtesting the Enemy

You've probably heard that it's a good idea to playtest your game. If you haven't heard, well, I'm telling you now. It's a good idea.

But how about playtesting other people's games?

I was reading a book called Don't Make Me Think, a classic in web design and usability. At one point, the author suggested doing a usability test of a competitor's website before you start designing your own.

Why not apply it to game development?

If you're thinking of making a particular type of game, find an existing game that may have some relevant similarities, and do a playtest of it.

Find a random person, sit them down in front of the game, and observe. Watch for what they enjoy, what confuses them and where they get frustrated.

Then repeat with other random people and other games. Do it with both good games and poorly designed games. You will learn more by testing both than by only looking at one or the other. See where the bad games fail and what the good games do differently.

And then when you go to design your own game, you will know what mistakes to avoid.

Art Museum Notes

The following is a fairly faithful transcription of the notes I made in my sketchbook at three art exhibits, several years ago. I hope you find them as interesting as I did.

The links were added after the fact, of course.

An-My Lê: Small Wars


(rehearsal)

these military tents, vehicles, etc.
just staked out in a featureless desert

• really gives a feeling of makeshift,
  arbitrary imposed structure
  
  • culture, human actions and thoughts
  
  
• would be a good setting for a game
  
  • reminds me of IvoryDrive's Black

one of those soldiers there lying in the shade of the camouflage
reminds me of my dad when he was younger

setting up facades, models, in the desert
for simulated training environments

• physical, not digital
  
  • in the desert

The camouflage really does make them blend in.
It would be hard to see while driving through
the desert, eyes getting bored, skipping over things

• hiding in the gaps of attention

(reenactment)

I like those bamboo and forest photos

Snipers - a lot of pictures of those
It's an interestingly different role
and way of approaching gun combat

• hidden, but not really that much
  
  • gaps of attention?
  • desert vs. jungle

the Distant Flare photo is interesting


Kim Jones: A Retrospective


books and covers - paths, portals, symbols in the mind

• living, organic, growing, moving book covers?
  how does that change things?
  
  
  • showing an instance of dynamics of the system
    that is described within

playing wargames on maps - Tufte
"work on it, get tired of it, work on it more"

• long-term devotion to a creative construction,
  a miniature garden - viki
  
  
  • similar to Civ2 micromanagement and slow pace
    keeping higher levels of organization in mind,
    but individually controlling the smallest parts
    

I like those weird stick/clutter/adhesive costumes

• good for ragdoll?
• MMO customization?
  
  • Katamari

"indeterminate form" "biomorphic forms" "hybrid creatures"

• one must map out Jones' particular symbolic language,
  his "personal idiom of figures, animals, and forms"
  to understand possible or intended meanings
  
  
  • connection to "homeless, camouflaged soldiers, peasants,
    or any number of mystic figures found in religions worldwide"
    
    
  • Raven?
    

Installation art is a good source for miniature garden,
anthropomorphic, symbolically rich, minimal constructions

stick interweavings similar to jungle/forest

• Bug aesthetic

war games become abstract, mathematical structures
when you zoom out, like cellular automata

particle trails connecting the elements of this installation,
depicting dynamics of their relationships,
and also in their individual operation

• Dust in The Amber Spyglass

putting books, meaning-rich pictures
into crevices and hidden surfaces
in ordinary physical objects and landscapes

• the objects without secret books all point to the special one
  somehow, in their arrangement or orientation
  

Having to lie down, or crouch, or whatever
to engage with whatever material is hidden there,
can bring or force a particular physical context to the situation,
which is usually seen as uncontrollable
in the design of digital content


Shu: Reinventing Books in Contemporary Chinese Art


Gutters - in comics, in books - rooms in architecture

Books used to have a lot more different forms, before perhaps
economic processes pushed it to a local maximum?

• When a new medium is invented, many forms emerge,
  each as guesses of what might work
  
  
• scroll (continuous) - no gutters?
• pleated (accordion) - gutters partly there
• pages (normal book) - gutters permanent between pages

Ink can make letters visible, or cover them up and distort them

distortion of discrete signals vs. continuous?

• what happens when the interpreting rules, the context, changes?

What feelings are contained in the flow
and halting and reversing of line in written characters?

• alternative to interpreting visually, it's kinesthetic.

Sketch books are another sort of book

Paper cutting (like with an X-acto blade)
could be a way to do Northwest Coast art

using the stacked pages of books as a blank substrate
on which the results of a process could be recorded

• like burning patterns

letting ink build up beyond its use within the context of books,
and let it take on a life of its own

• like the magic books in Discworld

putting the reading of an image in an explicitly sequential form
by putting parts of it on each page

Where does ink get its power?
Partly in the materials and processes used to manufacture it.

• similarly with paper

"encyclopedic"

Different languages, different writing systems,
different cultural approaches to books, text

Silk worms, living letters

The book, "transmits knowledge but does not
guarantee its authenticity."

• what would a book be like that does
  guarantee its authenticity?

Tools, instruments, for writing and printing

• specialness, valuableness, preciousness of objects
• containing stories within? worlds? hints of them?
  

a chunk of stone forming interesting spaces and patterns,
held by a stand

• stands, frames = important

Early Chinese characters were very rounded, lacking tension.
The modern characters are angular and hold much more discretely
understandable tension and flow, like traditional formline art

Sleeping books

• as architectural ruins
• active cultural objects, carriers of social messages,
  eventually become dead relics
• "vulnerability of memory and history"

How would this look anthropomorphized,
like in Discworld's Unseen University library?

What does it describe?

• pathways in the universal possibility space,
  ant trails formed but fading away

Communicating with Prototypes

For the last month, as I've detailed on this blog, I've been working on a project with the artist brontosaurus.

Both of us are very new at this whole indie game development thing, and we have made plenty of mistakes. And we will make plenty more. But we are learning.

I thought I'd share some of our latest mistakes, and what we've learned from them.

First of all, we've switched game ideas almost every week for the past several weeks. This in itself is not the problem. We change direction because we find problems with our old ideas that prompt us to start anew.

Here's a quick overview of the journey our ideas have taken:

We started with a game based on this picture.

Then we switched over to procedural aliens.

But we couldn't turn it into a game.
We tried to find a game here.

Then we decided to simplify.
We thought climbing would be easier.

But we couldn't make it fun.
So we switched over to suburbia.

And now, we're still in suburbia, but reconsidering.

Why have we had to switch ideas so frequently? What mistakes made it so difficult for us to just stick to one idea and finish it?

It has been a progression of mistakes. We started off trying to randomly doodle a game into a existence. Then we realized that we need to start with actions and gameplay before we start doodling interesting worlds and characters.

Now I'm beginning to see that our process for coming up with gameplay has been flawed.

My specialty is in game design, and programming. I choose to work with brontosaurus because his skills complement mine - his specialty is in world design, and art.

The way it usually works is that someone like me comes up with an idea for a game, and then finds an artist who is interested in making the art for that game idea. But we did it differently. Since I didn't have a particular idea in mind, and I like talking with brontosaurus about game design, we thought we'd just come up with an idea together.

This was not our mistake. The problem started because we were both communicating our ideas in words.

When I try to explain a game idea to brontosaurus, he has trouble understanding how it would look or feel. But the ideas I come up with usually have interesting game mechanics that I could prototype.

When brontosaurus explains a game idea to me, it's always very evocative and visually interesting, and he's ready to create all sorts of cool concept art for it. But I have no idea how to start prototyping it, since the mechanics are too vague.

Because I've been impatient to agree on an idea and get going, I always go with the ideas that brontosaurus comes up with, even though I don't know what the gameplay will look like. But sooner or later the vagueness of the design catches up to us, and we reluctantly decide to come up with a new, more feasible game idea. This is how the cycle continues.

Brainstorming may be fine in text. But when it comes to choosing ideas to work on, it's not really fair to evaluate our ideas until we have experienced them in either a visual or procedural form. I will express my ideas through prototypes, and brontosaurus will express his ideas through concept art.

If my prototypes inspire brontosaurus to come up with a world and an art style, then we can make them into full games. If brontosaurus' concept art inspires me to invent mechanics and gameplay, then we can turn those into games, too. But our starting point must be tangible. Words are not enough.

Let the game designers come up with gameplay, in the form of prototypes. Let the world designers come up with worlds, in the form of concept art. Don't force one to do the other's job.

It may take longer at first, but it's the only way we'll make something that we're both satisfied with.

Let's hope it will work in time for the contest. ;)

Update:
In other words, Less Talk More Rock.

Thoughts on the EXPLORE Contest

I'm working on a project with brontosaurus.

We have seven days to submit a game for the EXPLORE contest at Jay is Games. I like our current idea, and I think we should keep going with it. But even if we can put it together in seven days, I'd want to take at least another seven days to playtest and polish it. In other words, I don't want to rush this for the contest.

We could take a break and make a short, quick game for the contest just for fun, not expecting to win anything. I had a few ideas for that. One is to use our conversation history as the game content, since we have plenty of it, and it's interesting. There are a number of ways we could use it, but one very simple way to do it would be combine it with the Linear RPG. Or the typography could be a physical space to traverse, like Silent Conversation, with emoticons as powerups or something.

I was thinking about the Stick Figures story in Tales from Outer Suburbia, and where the story is, or where you might find a game there. It seems to just describe a scene, a place, without turning it into a particular story. It's hard to identify the protagonist, antagonist, and conflict. Maybe the antagonist is actually the confusion felt by the townspeople, rather than an actual character. Who knows? But you can more easily see little stories inside of it, like a kid smashing a stick figure with a baseball bat and getting frustrated, and uncertainty turning to fear and anger.

I was thinking about games, and how you could have a persistent world that is experienced through short, repeated game sessions. Little stories inside a world. Imagine Canabalt if instead of starting over when you die, you start again in the same world, at the place where you left off, or on the ground where you landed, or as another character somewhere else. It is similar to Calamity Annie, the way the narrative progresses even as you play again, where the gameplay repeats, but the world is fleshed out as you continually revisit it.

I'm also thinking about Zero Punctuation. Our conversation history could take the role of the monologue that narrates the images in a Zero Punctuation review. The only difference is that it is a dialogue, in text and not in speech. But the communication is similar. It does not tell a story, it discusses and explains. However, if we were to do this, we'd need a way to automatically come up with the images based on the text since it is not feasible to generate so much content by hand.

Freedom of movement across an image, linear movement along a text. Text forms the goals, while images are the medium of action? One action per line of text, one visual change. How do you create images from text? How do you combine text and action to get an image? The image and text give rise to the feedback. And the text leads the progression.

I was thinking about Spirited Away, my favorite animated movie. If Canabalt is like The Matrix, what would be the equivalent for Spirited Away? For Canabalt, you take the decisions that are implied and make them explicit. Or rather, you make it explicit, since there is only one decision. What equivalent can be found in Spirited Away? What decision can be made with the press of a single button?

But Canabalt is a linear game. You decide nothing. You act, in order to experience. Can exploration be about anything other than freedom of movement? When does exploration feel linear? A map does not dictate a path. When does it feel linear? A maze might have only one path, though it looks like a map. A labyrinth, even more so. Look at the feet. They never change their rhythm, yet the landscape around them changes. Is that exploration? What if they do change their rhythm?

You could make a game where you press a button to turn and change direction. This could be freedom of movement. Is it linear? If your actions have bigger consequences later on, maybe it is not really linear. If you turn here, you got to the desert. If you turn here, you go to the ocean. In Canabalt, your actions now have their consequence now - they do not change your route for the future. Can you explore without changing your route?

I've been thinking about tension before it solidifies into an emotion. I've been able to notice this tension already several times today, and let it fade away without latching onto anything external and feeding off the imbalance that results. I imagine there could be something similar for positive emotions. It all reminds me very much of Daniel Cook's Constructing Artificial Emotions, and I am intrigued by the idea of incorporating this into a game.

Where will this take us? I don't know. We'll see.

Active Sketch 02 - Ledges

Another sketch.

This time, a prototype. I made it to test out the movement controls for a climbing game.


In our effort to make a cool intriguing game, the artist brontosaurus and I have been coming up with concept art and procedural sketches that we could combine into something interesting. But we've realized that our approach is in need of a slight course correction.

Procedural trees and space invaders may be cool to look at, but that's not the same as a game that's fun to play. If you create a bunch of cool things, you don't automatically end up with an interesting interaction when you put them all together. But if you start by creating cool actions, things to do, then you're more likely to end up with something that's fun to play.

Daniel Cook put it this way, when asked for advice:

Typically what I'd suggest is working on a core mechanic and seeing if you can 'find the fun'. I see you focusing more on artwork...which is pretty, but doesn't find the fun.

Given this suggestion, I realized it might be more appropriate to spend less time creating procedural art and more time prototyping gameplay.

This doesn't mean that I shouldn't spend any time creating procedural art. It just means that before I come up with things, I need to come up with the actions first. If I have the gameplay down, the stuff you do, then I'll know what sort of things would go well with those actions, what would make them more fun or meaningful or interesting.

So this is our new doctrine: design the verbs first, then the nouns. Not the other way around.

Thus, this climbing prototype.

Active Sketch 02 - Ledges

It's simple. Use the arrow keys to move the climber around. You can press up to jump, or down to drop from a ledge. The interesting bit is that you can hang on ledges. Maybe not quite as interesting as jumping off walls, but hey, it's an experiment. :p

I used the Flixel engine to make it. Flixel is awesome. It's perfect for little games like this, especially if you like pixel-y graphics. I wholeheartedly recommend it. I'll write a blog post about it sometime.

However, brontosaurus and I probably won't be taking this climbing concept any further. We had thought it might be a good idea to start with a simple action like climbing, and build up from there. And we started creating some concept art for such a game, which you can see here.

But after trying out some movement controls in this prototype we decided that the gameplay wasn't strong enough to carry an entire game. And that's the whole point of a prototype - to tell you whether the game is worth making or not.

So we're back to the drawing board.

And with some inspiration from Shaun Tan and The Little Prince, hopefully we'll come up with something even better. I'll let you know how it goes. :)

The Invader Ecosystem

Humans, invaders, and trees.

For my first project since going indie, I've been working with the artist brontosaurus on a little game. The specifics of this project change around a lot, since we're taking a loose, spontaneous sort of approach to developing it. Lately we've been heading in a space invaders-ish direction, and we've been trying to think of how we might extract some actual gameplay from the procedurally generated toys we've been playing with.

In order to focus in on something simple, we've decided to base the entire game off the feel of the concept art above, I Have You Now.

We thought that might mean creating a little ecosystem of invaders that the player, a human, could observe and mess around with. Like, the invaders eat each other, maybe reproduce a little bit, and maybe you can help some invaders fight off some other ones, maybe do a bit of genetic engineering, and it would be all cool and stuff.

But I'm realizing that it would not really be all cool, or stuff.

So...

In general, the full artificial life approach with procedural terrain, trees, and invaders is both too big and too bland. It's too big for us to finish quickly. And it doesn't have enough human interest. We've got to put the feeling in it, the fantasy, the thing that makes it worthwhile to participate in the experience.

It's too big in a lot of ways, but the main problem is artificial intelligence - how the invaders behave. Adopt an Invader is an elegant design because the core behavior of all the invaders is the same - a simple flying, shooting ship. Additional behaviors and personality, like dropping goodies or flying in a certain pattern, are manually added by the players. Computers do what they're good at, and the players do what they're good at. Everyone's happy.

The problem with this approach is technology. We can't make Adopt an Invader right now, since we don't have time or resources to set up a database-driven web site. But we could incorporate the core idea into a single player game. That is, take generic invaders and manually add personality to them through playing the game.

It's like Pokemon. But instead of collecting the creatures so you can fight better, you collect them so you can start building onto them. Not physically, but mentally, in terms of behavior. Each invader is like a base for your LEGO pieces.

Now you have a goal - find and acquire invaders to build on, as well as the raw materials with which to build. And now we can start turning this into an addictive loop. And so now we're getting somewhere, with this game design.

We'll see where this idea takes us. Both brontosaurus and I like creating things, so hopefully we can turn the process of creating itself into a game. Creating, as well as collecting things with which to create, that is. It's a lot like what we're doing right now - collecting inspiration art, trying to build on that to create a game. We'll see. :)

Any thoughts?

walking along...

Notes on 21st Century Game Design

I thought I'd post a quick summary of the player model presented in the book 21st Century Game Design, by Chris Bateman. He has since come out with a new player model, but the old one is still interesting to think about.

If you want to learn more about the book, you can read the review on Lost Garden.

In this model, the audience is grouped into four types of players:

• Conquerors care about Challenge
• Managers care about Mechanics
• Wanderers care about Worlds
• Participants care about People

The system is based on the Myers-Briggs personality types:

• Purpose- where you get your energy
  Introverted (I) - long sessions
  Extroverted (E) - short sessions
  
  
• Learning - how you process information
  Intuitive (N) - hardcore
  Sensate (S) - casual
  
  
• Motivation - how you make decisions
  Thinking (T) - competition
  Feeling (F) - simulation
  
  
• Structure - how you manage your time
  Judging (J) - goals
  Perceiving (P) - process
  

The four player types are defined in these terms:

• Conqueror (TJ) - competition (T) and goals (J)
  
• Manager (TP) - competition (T) and process (P)
  
• Wanderer (FP) - simulation (F) and process (P)
  
• Participant (FJ) - simulation (F) and goals (J)
  

There are also four types of skills:

• Strategic (NT) - think ahead, invent, coordinate others
• Diplomatic (NF) - resolve conflicts, find similarities
• Logistical (SJ) - meet needs, organize, optimize
• Tactical (SP) - read the situation, take action

The four player types prefer using certain skills:

• Conqueror (TJ) - strategic (NT) and logistical (SJ)
  
• Manager (TP) - strategic (NT) and tactical (SP)
  
• Wanderer (FP) - diplomatic (NF) and tactical (SP)
  
• Participant (FJ) - diplomatic (NF) and logistical (SJ)
  

Hardcore and casual players also prefer certain skills:

• Hardcore (N) - strategic (NT) and diplomatic (NF)
• Casual (S) - tactical (SP) and logistical (SJ)

I've been finding it interesting to analyze my own game ideas in terms of what play styles and skills they support.

For example, I came up with a way for Adopt an Invader to cater to all four player types in this model - conquerors, managers, wanderers, and participants. And in doing so, I realized that trying to appeal to all four types would make the design much too big and ambitious to actually create. So I decided to focus on the conquerors and participants, and make the experience as enjoyable as possible for those two types.

In case you're wondering, my favorite style of play is probably that of the Wanderer, which makes sense, given that I also tend to prefer Explorer and Seeker play. I tend to care more about the overall experience and fun than about competition and challenge, and I like to focus on the process instead of worrying too much about goals. But in real life, I am extremely goal-oriented. Which is interesting. :)

However, these player types are not clear-cut boundaries. They are fuzzy generalizations about the average behavior of large groups of people. As the book says, "The four play types are not mutually exclusive; one or more can be enjoyed by each individual player."

Just keep that in mind and you'll be fine. ;) I hope you have as much fun as I have digesting this new player model! :)

Zero Punctuation Interactive

I've been watching Zero Punctuation reviews. What are those? "A short experimental film in which I attempt to make a video using only recorded speech and static images." Like this.

I saw that a Zero Punctuation contest has been announced, with really poor terms - basically, they own everything you submit, and you get nothing, except maybe some publicity, if you happen to be the one winner.

However, I am inexplicably intrigued by Zero Punctuation, and would really like to come up with a way to combine its "static images" and "recorded speech" in an interactive format. Like a game. Recorded speech wouldn't make sense directly in a game, but the still images, as conceptual, pictographic communication kind of like comics, could have a lot of interesting potential.

I just don't know how. A game where you compose images for a review? A game where you are a character inside a review? How do you translate the experience from the linear format into something interactive? Magic crayons? Miniature gardens?

The recorded speech is what you create in your head, your train of thought, while interacting with the static images. Static images are to animation as what is to games? Animation is essentially many still images strung together in sequence, but Zero Punctuation slows it way down, down to the bare minimum. Hmm.

You put those images together in space, rather than time, and you have comics. Instead of recorded speech, you have text. But you also have the reader's mind filling in the gaps. You have the viewer filling in the gaps in Zero Punctuation, too. And the way the images play off the speech, and the way the mind bounces between them gives it a certain flavor that is very interesting. How do you describe that dynamic? How do you recreate it in a game?

Back to animation and static images. What are games made of, if animations are made of static images? Choices? "A series of interesting choices." But what happens if you slow those down - are we back to text adventures here? Whatever happened to information density?

But in Zero Punctuation, it's all about the timing. Comedy is about timing, animation is about timing, and Zero Punctuation is about comedy. The images in Zero Punctuation aren't slower versions of normal animations - in fact, they feel faster. They cut out the slow stuff, the stuff that makes things feel detailed and coherent, and it still feels good. It feels unique, it has its own style.

It suggests, connotes, implies detail like digital speedpainting. It does not elaborate. What is the equivalent for games? In terms of pace I'm thinking WarioWare or any number of Flash clones. But what would it look like to have these compressed choices, only the important or amusing stuff, maybe random and incoherent, but always contributing to the pace and feel if not the plot or the main goal?

What would it look like? How could you make a game like that?

Yet More Intriguing Ideas

These will probably be the last new ideas I post for a while. Hope you enjoy them:

2009/07/14
A game where all magic is created by playing music. You have a flute that creates different magical effects depending on what note is playing as a drone in the background. Flutes in different keys would interact differently with the same drone. You can supply your own drone, but more powerful would be to use a drone that is already sounding in the background, like the electric hum of a generator, or the rushing sound of a waterfall. In a mechanical or steampunk world, droning sounds would be easy to find.

2009/03/30
A game about visual hierarchy, where you can create, modify, and arrange graphic elements in order to achieve certain goals about the way a viewer would look at the composition. Different elements might draw attention more strongly, or hold attention longer, or direct the flow of attention in different ways. It could make a good puzzle game. People could play it to learn graphic design.

2009/03/07
A game about software development, but abstracted, so you are building a system of interacting parts to accomplish some goal. You may add pieces to it, and you may factor out identical or similar components. These pieces would most likely be physical shapes that link together rather than actual code. You may also reorganize or refactor the system to make it possible to factor out more pieces. There is a tension between adding more, for short-term benefit, and refactoring, which is better in the long run.

2009/03/03
A game where you can snake around as if controlling one end of Noby Noby Boy. But you also want to come back to your center, your foundation, so that you can move your center instead of just getting caught up in your head and hands. There is a tension there between continuing to snake around and collect stuff and deal with stuff, and taking the time to come back to your center and move from there, to reset.

2009/03/01
A game where you are a small aquatic creature dwelling near the surface of a small pond, perhaps an artificial pond or pool in a garden.You spend your time close to the edges of the pond, as the open water in the center is more dangerous to you. The water is dark, but full not empty, and its depths are warm and reassuring. Sometimes it rains, rippling the surface and bringing colder water to the pond. It is always overcast. The surface colors are black and shiny gray, turning to orange and brown below and at the edges, the color of the soil and water. On land are the muted grays, browns, and greens of winter plants and stone.

Yay. Let me know if you have any thoughts to share about these ideas. :)