2010/12/05

My First Time

I killed Starshine. I slit her throat.

I held her a long time before that, feeling the pulse at her throat, the warmth of her body, the movement of her breathing. Chickens can sit very calm if you hold them the right way - crouching over her, hand around her neck gently, fingers in the soft feathers of her belly.

Then upside down by the feet, similarly calm. Tied her up on the pear tree right above where my last treefrog was buried. Bright red blood dripping down through the decaying leaf litter. Phil held her wings as she convulsed in death, like a person violently vomiting, blood from a gash in the neck. I hope that she did not suffer; I fear that she did. Three times, deepening the cut. How terrible, how incompetent...

I was barefoot. My toes were painfully cold, I realized once the blood had stopped dripping and her eyes had closed. Sitting on a beach towel on the bathroom floor, drying my feet, I cried to myself, partly in pain, partly from nausea, and partly out of guilt and horror over what I had done. Maybe not long enough, but it was something. I didn't skin the body, though I helped pull some feathers out. I watched Phil do it and held the pan for the organs and meat.

Crouching there, with my knife to her throat, feeling her pulse with my hand - it was like standing on the edge of a high-dive, looking down at the water far below. We're all waiting for you. How could I do this? How could I let anyone else do this instead? But oh, it was far too easy to take that plunge. I'm sorry. And thank you.

I don't want to write about this anymore.

Midnight, Starshine, and Princess Buttercup in their early adolescent years. Year.

2010/11/25

Origami Zergling and Hydralisk Tutorial Videos Complete

Earlier this year, I released three videos of me folding my origami hydralisk, hoping that this would help the people who got stuck trying to follow my step-by-step diagrams.

Sadly, it did not. Many people replied, asking for more clarification on the infamous Step 11.

YouTube is a great place to practice NVC...

So, being the generous and understanding origami teaching person that I am, I decided to try again, with a much slower video where I narrate each step of the way in detail, as if guiding a complete beginner.

And it seemed to work. Yay.

I love how you go so slow, other just go through things so fast.

Thnx for posting this, I menaged to fold one while watching! Good tempo and very instructive!!

Most of the time people go too fast and you miss a step, but there is NO possible way you can miss a step in this. Awesome! You must be a genius o.O

thank you u are one of da best origami narrator :D

And, the classic...

god thank u after 2 years i did step 11

Yeah, after seven years I finally have created some instructions that other people can follow. :p

It's very slow, so it's a long video. Slow but good. :) In eight parts on YouTube. Here's the first:



And the rest:

Also, I made a similarly slow, narrated tutorial video for my origami zergling as well. In ten parts. Here's the first:



And the rest:

And again, the acclaim:

Thanks that was the best series of explanation videos ever.

this is a very noob friendly vid. nice. you don't see origami videos this well made that often.

sir, you have my respect and the [SF] Official Seal of Approval

The best part is knowing that I have improved people's lives in real, tangible ways. I give people the power to fold origami aliens. Now that's what I call real value. :)

After 2 and a half hours of testing my persistence and determination I have completed this project. Thank you axcho, because of you, I am now the epitome of cool, the envy among my peers and I have a freakin' paper zergling.

Thank you, axcho, for these fantastic videos! I've finished my (hot pink) zergling! It can join the esteemed company of my origami hydralisks (also thanks to you)!

Thanks for the videos! I just finished my zergling, and I knew almost nothing about origami before. :D

Seriously, that's amazing. Several people who have never done origami before have commented saying that they were able to follow these instructions and make an origami zergling as their first model.

Okay, now you can start bugging me about an origami ultralisk. Maybe I'll actually make one in a few more years. ;)

2010/10/24

Why Avatar Is Important

I wrote this back in January, and somehow never got around to posting it until now. Well, here it is. Better late than never, right?


There was this other movie that everyone seems to be talking about. I saw that one, in IMAX 3D. I shamelessly add it to my list of favorite movies, along with The Matrix and Lilo & Stitch and other such gems of cinema. I may be excessively indie when it comes to games, but no one can accuse me of being a film snob.

Whatever people are saying about it, what I appreciated in that movie was that it clearly showed what people left behind when they took up agriculture and industrialization and the trend toward global corporate hegemony - I said "hegemony" haha! - that is, the fun. Not moral superiority, not environmental friendliness, not utopian peace and happiness, but a life that, despite the dangers, the high mortality rate, the lack of iPhones or toilet paper or whatever else you want to measure, a life that is richly fulfilling, challenging, rewarding, interesting, in a way that the human mind and body craves and thrives on - in a word, fun.

This pressure gradient between the two societies, the fun and the unfun, is what drove the progression of this story. And this movie drove this difference home in the way no other medium could - except for games, of course - and for that reason, it is important. That's it.

And lots of people feel it. They feel this gradient pushing them away from their own lives and into the imaginary fun of the movie, which is no place to be if you are in fact a real person. But this fun place is real, it's just out of sight, in the past, or in those pockets of the world where the fun has yet to be sucked out and converted into GDP.

But no one's talking about it like that, because the usual sides to pick, the usual ways to debate these kinds of things are so readily available. Yes, kind of sad. But it gives me hope. If you show people what they're missing, they will feel it, and they will desperately seek it out, even if they believe it to be imaginary.

So, hope for the world. I must remember my mission. This is why I chose games. Light the fire, make the spark. Don't crack the whip. Whips don't work very well on rockets anyway.

2010/10/13

Teaching Flixel

A few weeks ago, I started teaching some kids how to make games with Flixel and other free tools. I'm offering my time up as a volunteer, at a progressive school I came across through this inspiring blog. Here is an email I just wrote to my students:

Hi class,

I'm really tired right now. I should be sleeping. But I'm writing these instructions to you now because of something that is more urgent to me than sleep. River sent me an email asking me again to explain how to finish the animation and change where the bullet shoots from. He apparently wanted to figure this out enough that he bothered to remind me about it. He didn't have to do that. I don't have to do anything for you guys. But he wanted to. And because he wanted to, I will do whatever it takes to help him get there, even though I'm really busy, even though I'm tired. Because this is the whole reason that I decided to try teaching a class at PSCS. I came here on the chance that I might be able to help someone get somewhere they really want to go but can't get to by themselves. I'm not an expert in most things, but this opportunity to share what I can with people who want it is very motivating for me.

And I've been waiting for this. And now I see the beginnings of it.

I'm not attached to you wanting to learn game programming, or game design, or whatever. You love playing games, and I think there is a chance that you may come to love creating games as well, once you get more of a taste of it. It is an acquired taste. It might not be your thing. Which is fine with me. I don't really care personally either way. But if it is, and if there is a chance that it might be, I will do whatever I can to catch that spark in you, and help you kindle it into a steady flame, if you so choose. Just let me know.

Yeah. So, those instructions...

You added some code in the beginning of update() that said this:

var moved:Boolean = false;

Then you added code to each if-statement for the arrow keys, to changed moved to true, if you press an arrow key during the update.

moved = true;

So you have a virtual bucket, sitting in your computer's memory, which you call moved, in which you can put either true or false. But it doesn't do anything by itself. It just sits there.

However, it is useful. Because you can look at it. If it has true inside it, you know that an arrow key was pressed, because you put true in it whenever an arrow key is pressed. Right? If it has false inside it, you know that no arrow key was pressed.

Say you wanted to do something only if an arrow key was pressed, and another thing if no arrow key was pressed. Like play a walk animation, or play an idle animation. If you wanted to do that, then it might be helpful to look into this moved bucket, and see what's inside.

You could say...

If moved has true inside of it, then play the walk animation.
Otherwise (if it is false), play the idle animation.


And you could translate that into actual AS3 code, like this:

if (moved)
{
    _box.play("walk");
}
else
{
    _box.play("idle");
}


And you would put that code in update(), after all the arrow keys and such have been checked.

Some notes:

if (moved) is the same as if (moved == true) - because what you put between the parentheses in an if-statement is checked to see if it is equal to true. If it is equal to true, the code in the curly braces is run. Otherwise, it runs the code for else.

Why does if (FlxG.keys.LEFT) work to see if the left arrow key is pressed? Because FlxG.keys.LEFT is a virtual bucket that holds true if the left arrow key is pressed and false otherwise. Get it?

Also, there is no way to just stop an animation. You must have another animation to replace it. For example, you could create an animation, with _box.addAnimation(), that is called "idle" and that has only one frame in its list of frames. Then when you play that animation, the _box would stay on that one frame forever, unless you play a different animation later on.

You might also wonder whether telling the _box to play an animation, telling it again and again every frame, might make it start over from the beginning every frame and not get anywhere. There is a way to do that. But fortunately, Flixel will not restart the animation if it's already playing. So this works.

There you have it - the instructions for how to make an animation only play while moving. It will take a bit of work, a bit of thought, a bit of failure and frustration and trial-and-error in order to get it to work in your particular program. But this is the price we pay.

I do not demand success from you. But I do demand that you try, or I cannot help you. And I suggest that you try more than once, even if you fail at first. You have unlimited lives, when it comes to programming. Remember that.

Next.

Making bullets shoot from somewhere other than the top left corner of the box sprite.

This is easier.

Find the code where you first create the bullet. It looks something like this:

var bullet:FlxSprite = new FlxSprite(_box.x, _box.y);


Remember? That creates a new FlxSprite, and gives it the name bullet, and puts it at a certain spot on the screen. That certain spot on the screen happens to be the upper left corner of the _box sprite.

If the box sprite has its corner at the coordinates (5, 10) and it is 50 pixels wide and 50 pixels high, then where is its center?

I'll tell you the answer. Its center is at the coordinates (5 + 50 / 2, 10 + 50 / 2), which is the same as (5 + 25, 10 + 25), which is (30, 35).

To put it more generally, the box's center is at (_box.x + 25, _box.y + 25). Just add an offset of (25, 25) and you get the center. Right?

What if you wanted to put the bullet at the center of the box?

var bullet:FlxSprite = new FlxSprite(_box.x + 25, _box.y + 25);

Would that work? I suggest you try it out and see.

What if you want it to appear somewhere other than the center? Well, try using some other numbers, instead of 25.

Once you get that working (which I'm sure you will), try making an animation for the bullet. Can you do it?

Show me on Monday.

If you have any questions, let me know before the weekend.

Good luck.

2010/09/19

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.

2010/09/10

Walk or Die and other games that are notgames

I don't spend a lot of time playing games these days. Portal sits in my computer, unfinished. A borrowed copy of Psychonauts lies unopened by a dusty PS2. I have accumulated a list of more than a hundred web games yet to try, and I haven't even checked the Jay is Games archives in several months.


So, it may come as a surprise to you that today, in a bout of either procrastination or perhaps a newly strengthened determination to make a dent in my overwhelming backlog of unplayed games, I have, in fact, gone ahead and played a handful of games. Well, technically speaking, notgames.

Not sure if I've mentioned notgames yet on my blog. Officially, they do not exist. There are no notgames, nor is there a "notgames" movement. But there is a forum. :p And a blog.

One is called Hummingbird Mind. I found it very immersive, despite - or because of? - being mostly text. Immersive like a novel. Or like I Fell in Love with the Majesty of Colors, maybe.

Perhaps it helped that I found myself in a similar mental state to the protagonist. If only I could allow myself to take a nap as I did in that game. Or notgame?

Another is Looming. Same guy who made The Majesty of Colors. The black and white pixel art brought me back to my Mac SE and calculator days. I'd like to make a game in such a style sometime.

It's a good example of distributed or embedded narrative. In fact, that's all it is, really. You are an archaeologist. Piece together clues about the past in a ruined world. Like Where We Remain. I'd like to do something similar for my own game Flydrill, eventually.

And then there is Freedom Bridge, whose author even refers to it as a notgame. Not quite Passage, but I found it very effective, particularly considering how absolutely minimal it is. I do wonder whether making the graphics more detailed would improve or detract from the experience. I'm not sure, but I'd be curious to find out. I'll be thinking about what inspiration I might take from this.

And lastly, Walk or Die, by the same author. It was this notgame, perhaps the least impressive of the four, that inspired me to write this blog post and overcome many months of non-blogging inertia in doing so.

...or die

By the way, once you try these games, you should head over to the Game Trekking website for the chance to support the author of Freedom Bridge and Walk or Die in making more experimental notgames as he travels across Asia. Less than three weeks to go if we want to get this off the ground. I've pledged one hundred dollars.

Anyway.

Here's why I wanted to write this blog post in the first place. After playing Walk or Die, I wrote this post on the notgames forum, which I am now reposting here, on my blog:

Finally got around to playing your notgames. ;)

I played it for at least ten minutes, while walking on my treadmill. :) I liked it quite a bit.

Actually, I really like it. I stimulated my creativity almost like a real walk would... though it helped that my real legs were moving at the same time. :D

I really like the day/night transition. I've been wanting to make a game with a five-minute day with the changing light and sounds and creatures - I've even commissioned a song for it, with morning, day, evening, and night, and I love the song but I haven't made the game for it yet. :p

One suggestion to try which might go against what you were originally exploring is requiring a steady relaxing pattern to be maintained at about the pace of an average slow walk, rather than holding the space bar.

I was thinking the same thing! Press to step, control speed, and all that. Maybe even more interesting terrain to walk on, as opposed to a completely flat surface. And I could see that being interesting, focusing on the feeling of accidentally stumbling and the fear of death.

And also I wanted to see more elaboration on the "death" part of the experience, because you can still observe, and maybe see the one spot grow and change over time though you are not going anywhere, you are transforming.

"Oh, this looks like a nice place to die. I will stop here." I thought.

And maybe combined with something like We the Giants, leaving traces for other people, seeing other people's traces. Reminds me of an idea I had about a game where you walk along a pebble beach, and you can arrange pebbles and driftwood in configurations that other people can see, or you could entropy-ishly knock over a tower someone made. And close to the waves, structures are knocked over and smoothed over naturally by the water and wind, while further, toward the cliffs, footprints and structures last longer.

Not sure how that would apply here, exactly, but it's got me thinking... :)

This is like the notgame equivalent of the game Linear RPG! :D

Now I really want to take this concept and have brontosaurus make some really nice pixel art for it! And nice sounds... No music, just high quality environmental recordings.

Procedural. I've been reading about how Left 4 Dead's AI Director works (fascinating stuff!) and I wonder now about applying it to other ends. Specifically, instead of measuring "emotional intensity" and modulating stress levels, how about modulating "boredom" or "joy" or "confusion" or "interest"? The system is really not that complex. I'm reading about it because I'm trying to do something similar for my game Flydrill.

I've wanted to make a game that feels like walking in a forest. So far The Path is the closest thing I've found. And now this.

Mind if I elaborate on this concept with a real (not)game? :)

Hum. By the way, I finished two new narrated video tutorials for my origami zergling and hydralisk. They are slow, and for the first time people are actually getting all the way through to the end! I'll post about them soon...

2010/07/28

Origami Hydralisk Tutorial Video and StarCraft II Released!

Update:
I just posted two slow, narrated tutorial videos for origami beginners - one for the zergling, and another for the hydralisk. Check them out. ;)


In case you haven't heard, StarCraft II is finally out! :D

Conveniently, Blizzard has been kind enough to time their release to coincide with the even more exciting release of my own epic, three-part TUTORIAL VIDEO for my original origami hydralisk design! ;)

A long-awaited release, most assuredly.

Rather than try to describe it to you, I'll just embed the videos right here on this blog and you can experience their amazing splendor firsthand. Just try not to let your head explode.


FOR THE SWARM! :D







It's been three years since people first started bugging me with incessant demands for a tutorial video. But now I can rest in peace, because the tutorial video is complete! :D Or not, because now they're asking when I'll be posting the instructions for my origami zergling. Oops. :p

If you want to be the first to know when I post my zergling tutorial video, go ahead and subscribe to my YouTube channel. :)

instructions coming 'soon'...

2010/06/10

Game Idea Giveaway - City Basher

Last year, I wrote up this game idea giveaway for Emanuele Feronato to post on his popular Flash game development blog. But after waiting for many months without a reply from him, I decided to post it here so I can finally share it with all of you!

Be warned, this giveaway is epically long. My longest yet.

...continued from The Game Idea Giveaway Thread

Request by triqui:
  • what sort of game idea you're looking for
    intriguing but difficult-to-implement ideas will do
  • what your goals are in making this game
    I would like to make a post about gameplay ideas

The idea: City Basher


In short, City Basher is a physics-based multiplayer artillery game combined with a trading card game (like Magic: The Gathering). It's a competitive game where you try to knock over your opponent's buildings, and it is designed to work very well with microtransactions.

This game is founded on the wide appeal of vanquishing strangers over the Internet and the primal joy of toppling carefully built towers of blocks, without the bother of having to actually build them in the first place. For that reason, the game is primarily a quick deathmatch experience, like most online multiplayer games aimed at bloodthirsty teenage males. Though there is also the option for team play and casual matches between friends.

Like other multiplayer artillery games, most notably Worms, each play session is short, measured in minutes, and involves only a handful of players. But as a game supported by microtransactions, players maintain a persistent identity across play sessions, retaining their avatar, items, resources, and statistics. This is the approach taken by Gunbound, a multiplayer artillery game that was one of the earliest successful microtransaction-based games to establish itself with Western audiences. Gunbound made its money by selling avatar decorations. City Basher will do that, and more. Much more. [cue dramatic music]

Each play session takes place in a 2D arena, seen from the side. The arena is full of buildings, structures of physically-modeled blocks, some solidly stacked, some precarious. At first, the arena is a neutral territory, dominated by a huge monolith in the center. Players take their places in the arena, each one piloting a vehicle with a mounted cannon or two. The game begins, and players open fire on the buildings to convert them to their own color. When one player topples an enemy building, a new building rises up in its place, owned by the player who placed the final shot and color-coded accordingly. The session ends when the neutral monolith in the center is toppled, and players are awarded their final scores.

The play format is very flexible. The game is not zero-sum. Players play for points, not simply to defeat their opponents. If you destroy one of my buildings, you are rewarded and I am penalized, but your success does not depend on my failure. It merely happens to coincide with it. Players are never eliminated from the game, though they are free to leave at any time - their buildings are simply replaced by neutral ones. And most arenas would support a varying number of players depending on how many people are available. If there are slots open, new players can join an existing game. This is very important for a casual multiplayer game like City Basher.

Since this is a game supported by microtransactions, we want to make everything into an item that can be bought and used up. Not that players would necessarily have to pay real money for everything in the game, but it's nice to have that option. What this does is set up the expectation that things can be bought. If players get used to paying for items with virtual currency earned in the game, they'll be more open to paying real money for the really valuable items they might want later on. In City Basher, these items consist of vehicles, weapons, buildings, arenas, avatar decorations, and general enhancements.

Gameplay

An important part of most any game is the movement, how a player gets around in the world. In City Basher, vehicles encapsulate this piece of the gameplay. Every player starts with a basic vehicle that is like a slow-moving tank. But other vehicles could be bought. They might move faster, they might be smaller or larger or shaped differently, and some might even fly or hover or jump. However, movement isn't the focus of this game, so it should be kept fairly simple. As a result, each vehicle is controlled in more or less the same way - that is, with the arrow keys or with the mouse, following the mouse cursor. Also for simplicity and to minimize the effect of lag, vehicles would not be able to collide with other vehicles or knock over buildings. Instead, they would pass through other vehicles harmlessly and treat building blocks as immovable terrain.

The real fun of the game starts with the weapons. This is the part that puts the artillery in artillery games. As is typical in the genre, the basic weapon is a slow-firing cannon, which the player must aim by setting the angle and power of the shot with the mouse or keyboard. There are a lot of ways to set up the specific controls for this action, so I won't go into too much detail here. The easiest way I can imagine is just to click the mouse to set up an attack, move the cursor to set the angle and power, and click again to fire. This way, you could fire off a quick shot by double-clicking. Since attacking is a focus of the game, different weapons could even have different methods of control, as long as they support both the keyboard and the mouse.

For a game like this, there would be dozens, if not hundreds, of different weapons to buy. Some might be variations on the basic cannonball, maybe with extremely high mass for extra power on stable buildings, or a small but extremely bouncy ball that can ricochet off multiple blocks and quickly take out more delicate structures. Some weapons might shoot several balls at a time, or an explosive shell, or several balls chained together. Others might be a different kind of weapon altogether, like a rocket launcher or a block-melting death ray. There are a ton of possibilties here - just look at a game like Worms for example. Each weapon would have a certain reload rate, a waiting period of anything from a half a second to several minutes before they can fire again. This would help to give the game a more strategic, turn-based flavor, without the turns. For this reason, there could also be weapons that are weak but useful because of their rapid firing rate. Another part of the strategy would be in selecting your arsenal, since you can only bring a limited number of different weapons into each game.

The other focus of the game is on buildings. Weapons are what you use, and buildings are what you use them on. So naturally, you'd be paying a lot of attention to them. Just like there are different types of weapons, there are also different types of buildings, each one a particular configuration of blocks of various size, shapes, and masses. Some have special side effects too, that are active while the building is in play. For example, one building might increase the mass of all your other buildings while it is in play, making them harder to knock over. There could even be a building that increases the strength of gravity over the entire arena, or doubles your score from every hit. It's a lot like the way that different cards have rule-changing effects in games like Magic: The Gathering or Pokemon.

The similarities don't end there. City Basher handles buildings just like cards in a trading card game. You don't build buildings, you collect them. Each player has a bunch of building cards in their collection. Each of these cards represents a particular building type, though a player might own several copies of the same card. When you join a game, you choose a set of cards from your collection that will be available to you during the match, in the form of a deck of cards. Like any trading card game, there is a limit to the number of cards that you can include in a single deck, and a limit to the number of duplicates you can use of the same building card. This means that you have to put some thought into which ones you choose. Some players might even spend more time just designing their decks than they do in playing the actual game!

When you choose which deck you want to use for a play session, this determines the type of buildings you can get in the game. Whenever you are due to have one of your own buildings pop up in the arena - say, when you topple an opponent's building - a random card is taken from your deck, and placed in the arena as a new building. When that building is toppled, the corresponding card is returned to your deck. That means that if you have three copies of the Citadel of Awesomeness card in your deck, you can have up to three Citadel of Awesomeness buildings in play at any time. And if you have no more cards in your deck when you destroy an enemy building, that building is replaced by a neutral one instead. The most powerful buildings are designated as Legendary buildings, and can only sprout up in special Legendary building slots, of which there might only be one or two in any given arena. Legendary building cards are ignored when drawing for normal building slots. This helps keep the game balanced.

Finally, there are the arenas, where the games take place. These are not items owned by individual players, but the effect is similar, since players may have to spend points or money to access certain arenas. At its core, an arena is a 2D map of indestructible terrain with a bunch of building slots scattered around - areas on the ground where a building may sit. One of these areas is reserved for the monolith, the giant neutral building that ends that game when it is toppled. The arena defines what this monolith looks like, as well as the deck of possible neutral buildings that may pop up. Each arena also specifies how many players are allowed at a time and where they appear at the start of the game. Lastly, each arena defines its own physical properties like gravity, air resistance, and wind, as well as the background graphics and sounds that make up the feel of the place.

Monetization

In a typical microtransaction-based game, there are two types of virtual currency involved in the in-game economy. One is earned through playing the game, like experience points. The other is bought for real money, which is how the developers make a profit. City Basher is no exception. Players can exchange their real money for a virtual currency we'll call Coins, and they can also earn another virtual currency, Points, through gameplay. The names used here are just for convenience, by the way - in the actual game you'd probably want something a bit more glamorous.

Players can earn Points in a number of ways. The most common way to earn Points is to knock down an opponent's building. You don't have to knock it down completely to get points - you only have to reduce its height with your shot. Each type of building is worth a certain number of Points to topple, and you get a fraction of that for every fraction of the building's original height that you knock over. However, you only get to replace it with a building of your own if you deliver the final blow, one that topples the building completely. The advantage to having lots of your own buildings in the arena is that at the end of the game, when the monolith falls, you receive Points for each of your buildings according to their remaining height and Point value.

This results in a system where new players can join in the middle of an existing game without having any unfair advantages or disadvantages relative to the other players. It also encourages players to stick around for the whole session in order to earn bonus points at the end for their remaining buildings. At the same time, no one is bothered if they leave, since their buildings are replaced by neutral ones which yield Points just as readily as player buildings. And it works just as well for team games, since players on the same team simply share a single color, and don't earn any Points from toppling their teammates' buildings. On the whole, it is a scoring system designed to reward good players, without punishing the players who aren't as skilled. This keeps the game accessible to casual audiences. And that means more money for you.

So, let's talk a little more about money. Specifically, let's talk about what players spend it on, and why. First of all, let me emphasize that the game itself is free to play. Players are not spending money just to play the game, they are spending it to buy virtual items inside the game. This is what it means to have a game based on microtransactions. Second, it is important to understand why players would want to buy these imaginary items at all. Players will spend money not so much as an exchange but as an investment. It's not about exchanging value. Why would a player give you real money for nothing? It's about investment. A player gets some significant value through playing the game for free, and then they think that they could enjoy even greater value in the long run if they invest a little bit of their own money right now. They should feel like they're getting a great deal every time they spend money in your game. If you can keep this one principle in mind, all the rest of your monetization decisions should follow naturally.

Here's how it works in City Basher. All items are bought with either Points, Coins, or some combination of both. Some items are permanent, some get used up, and some last for a limited amount of time. Building cards and avatar decorations are permanent, as in a typical microtransaction-based game. But weapons and vehicles get used up - weapons are sold in the form of ammo, and vehicles can be used for a limited number of play sessions before they must be refueled. Only the starting weapon and vehicle last forever. This is like the rental approach to monetization. Lastly, membership cards to access special arenas and unlock special game enhancements are effective for a limited number of days before they expire, much like a subscription. Each of these items represents a different approach to microtransactions, in the hopes of appealing to as many different buying habits as possible and maximizing the revenue of the game.

Outside of the artillery game itself, there would be a sort of store interface where players could browse and shop for items. Building cards would be bought in random packs, from different editions, much like in an actual trading card game. Some editions could be bought only with Points, but the sets containing the more powerful cards must be bought with Coins. The idea is that players who really get into collecting cards are going to be the type to spend real money on the game. Avatar decorations are bought individually, mostly for Coins, though there might be some basic clothes and such that could be bought with Points instead.

Weapons are bought in bulk - that is, packs of ammunition - and for the most part can be bought with Points. For reasons of fairness, you want to be careful about charging real money for items that provide significant in-game advantages - like weapons - though it could be appropriate to charge Coins for some particularly strange or specialized types of weapons. Vehicles are similar, but since they have less of an effect on the fairness of the game, it is more appropriate to charge Coins for some of the vehicles, especially if their advantage is purely cosmetic or a matter of personal preference in the movement controls. Vehicles themselves do not get damaged or expire, but they do have a limited amount of fuel. Every time you enter a play session, you use up one unit of fuel in your chosen vehicle. The more powerful or expensive a vehicle, the more it costs to refuel it, though fuel should cost only Points since it is a recurring expense.

Arena access must be bought with Coins. Players buy membership cards, each of which provides access to several exclusive arenas for a certain amount of time. It might also be possible to include an arena editor that can be accessed in a similar way. This could be a nice place to incorporate player-created content, if you are so inclined. Other game enhancements can be bought individually with Coins, also for a limited amount of time. These may include advantages such as a larger maximum deck size, or extra weapon slots in each game. Most importantly, these enhancements would be the type of features that very dedicated players would appreciate and pay for, but that the average player would not find useful. This makes it acceptable to charge real money for such enhancements.

Permanent items - that is, building cards and avatar decorations as well as Coins and Points - can be traded freely between players. Temporary items like weapons and vehicles, however, may not. This is partly for simplicity, and partly because you want to use weapons and vehicles as a currency sink, a place where Coins and Points are removed from the game economy. And this role is undermined if players can just buy weapons from each other. In a real-world economy, this is not as important, but in a game where you can bring currency into circulation just by knocking over a few buildings, it's essential to drain that currency out of the system just as fast as it comes in, to avoid inflation. Since weapons and vehicles get used up over time, players must continually buy new ones, removing currency from circulation at a more or less constant rate. To keep the system running smoothly, you must continually balance item prices with the amount of Points that players can earn from each building type. Keep those Points flowing in and out at the same rate. No one said this would be easy!

Implementation

To actually make City Basher, you'd need a good rigid-body physics engine, like motor2 or Glaze, or even Box2D. This could also be a great project for use with the PushButton Engine, since it has built-in Box2D support and an optional networking component for making multiplayer games.

However, making any multiplayer game on this scale is always going to be a massive undertaking. Make sure that you know what you are doing before you start. If you've never made a physics-based game before, start by making a single-player prototype of the basic building-destroying gameplay. Then, if you're new to network programming, make a simple match-based multiplayer version of the game, without the special items or persistent avatars.

If you can do that, and make it fun, then you can think about taking the next step and making it massive. When you do succeed in making a massively multiplayer game, don't add in all the special items all at once. Start with the basic free game, and add items gradually, careful not to upset the balance of the game. Incremental development is the way to go.

Good luck.

References

Required reading for anyone who wants to make a game like this:

Since Emanuele Feronato never showed up to receive his idea, City Basher is open to anyone to use for free! Even you. ;)

Let me know if you decide to try making it. I'd be glad to help however I can. Post a comment!

Want an idea? Make a request on The Game Idea Giveaway Thread!

2010/03/10

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