Blogs - PsySal

Today I am working on the final denoument cutscenes in The Real Texas.

Coincidentally I have been watching the amazing fan-made documentaries on the original Star Wars trilogy (Star Wars Begins, Building Empire and Returning to Jedi by Jambe Davdar.)

The Original Triogy, Ebert Was Right

Seeing how the Original Trilogy was put together in more detail has given me a lot more appreciation of film techniques. Last year Ebert said that games are not art, and the gist of his argument is that games cannot manipulate scenes as finely as films can.

Suicide-inducingly boring debate aside, the second part of this seems true to me. Each scene in A New Hope is absolutely filled with detail, carefully scripted. In film, the camera never wanders beyond very tightly proscribed bounds.

The Trash Compactor Scene

Consider the large metal bar in the trash compactor scene. Han picks this up and attempts to use it to brace the walls from closing in. It is very effective to see the bar bending: it shows us how powerful the compator really is, outlines their desperation, and creates a sense of panic as we can relate to it in a physical sense (we can imagine ourselves trying something similar, and understand how hard it might be to properly position it.)

In a game, the requirements for this simple prop are much deeper. If that bar braces the trash compactor, it should brace other things. We will need a physics engine that can somehow handle malleability and ductility. We have the ugly choice of letting the player carry it with them if they choose, and then making sure it can't break gameplay or cause strange glitches in other scenes, or of forcing them to leave it behind.

But it's actually worse than this: even if we implement such a prop, we can't force the player to use it, anyhow!

Restraint and Creativity

When I watch these documentaries, it creates in me a burning desire to imitate. This is by now a familiar feeling for me, maybe it is for you too. What I have come to believe is that this particular burning desire is the harbinger of creative suicide.

To create, we need to take ourselves out of this particular kind of inspiration to imitate, no matter how strong it is. In the case of making games, we need to take a deep breath when we watch great movies.

If we attempt for the same kind of tightly-controlled and yet varied effects that film makers have at their disposal, we will find ourselves creating a badly-scripted, weakly-interactive non-movie non-games.

Simplicity

Instead of trying to co-opt this power of tightly-framed scenes, let's examine our own constraints.

First, the player is not an actor. In fact, the player is the only element we explicitly do not direct. This is a difficult constraint to stick to when we are trying to imitate film effects. It's very tempting to have the player character stop and walk to a certain place, or perform a certain action at an opportune time, but we should stop and look for another solution.

Second, in place of varied effects put interesting rules. Rather than constructing elaborate scenes requiring a certain set of actions, build several flexible props and then experiment.

Recently I added a certain weapon to The Real Texas with a long reload. The player always has control over whether they want to reload, but they can't change that it takes a lot of time to get ready for another shot. It's a simple prop that in no way violates these rules, but it creates a lot of dramatic tension. Observing this, I put in another constraint (again, on the prop, not the player) which would highlight this tension (a minor spoiler, so I won't tell.)

Some Wind Waker Critique

I've also been playing through Wind Waker. I enjoy this game very much, but I have some funny criticisms. Basically, I think the game relies on too many different props that ultimately don't have very many uses. Most items can be used as a weapon in addition to one other effect. There is even significant overlap-- for instance the grappling hook ought to make the hookshot a nonentity.

I would have rather played a game with sword, shield, grappling hook, and maybe one other weapon, but which all interacted strongly with all props (e.g., grapple anything). Instead, it feels a bit scripted at times, because I know in many situations that I must use item X (say, the hookshot) because no other item will work.

Damn what a great game. However... why do we need both Grappling Hook and Hookshot?

Finally, It's Easier

Last thought before I wrap this up. It's easier to design games this way, because they are more natural constraints for our medium. It's fundamentally easier to work with just a few props and make them play with each other in interesting ways, than to relentlessly draw lines arond what the player can and cannot do.

When I find it hard to adhere to this, I take a deep breath. It just isn't film.

Let's break it down mathematically for just a second here, ok?

For our purposes, a Discrete Point Set is a collection of objects which can be differentiated from each other somehow. We call each element in the set a Point.

Points themselves are unordered; the set may be infinite or it may be finite. An infinite DPS would be for instance the set of all 2-dimensional (x, y) coordinates within the unit circle on the real plane. A finite DPS could be the list of letters { A, B, C, D, E, F }.

DPS's in Your Game World

Often in the course of developing a game, you need to perform an action on or find something relating to an object or a group of objects. An explosion needs to know all the enemies in it's area-of-effect, or the player object needs to know if it's next to a treasure chest.

Because game objects are always discrete (i.e., they are a separatable thing) the game world can be thought of as a DPS. Note that this does not mean it only contains what you think of as your game objects; think for a second and you will realize there are lots of "non-object" things in your game world, too. If it's a 3D game, it contains for instance all faces on all 3D models, all velocity trajectories of all particles, and so forth.

Note also that when we say "Point" we don't mean just an N-dimensional point such as you may be used to thinking of; in fact we could even mean something that doesn't exist spatially at all, such as an AI routine or a store item price.

DPS Query

Let's grant that your game world is always an infinite DPS (we can argue this in the comments, if you like.) We will define a DPS Query as a function Q:

Where W is your game world (an infinite DPS), R is the result set, and FDPS is the set of all finite DPS's. So, a DPS Query takes as input some number of arguments and returns a finite set of things. The arguments could be a 3-dimensional point (X, Y, Z), along with a radius R, and the finite set of things could be all objects that are near enough to (X, Y, Z). You could name your query function something like:

set< object* > find_all_objects_near_to_point (double X, double Y, double Z, double R);

Now let's get rigorous: why W for the domain? Suppose some parameter xn being passed to Q were not part of your game world DPS. In this case, it's hard to imagine how this parameter would relate to anything in that same domain at all. To wit, if the point (X, Y, Z) does not exist in your game world, how are you finding things that are close to it? This is an interesting detail to ponder.

This is useful HOW?

Very likely, you already have a world class or module or something to that effect. I'm just encouraging you to think a bit mathematically when it comes to what kinds of functions you might put on it. In short, it gives you this rule:

For instance, you might well want a function like:

vector< object* > get_all_enemy_objects ();

In fact, this is a DPS Query. Once you see that fact, you realize that other query functions might be useful, such as:

vector< object* > get_all_enemy_objects_with_hp_less_than (double Value);

or:

vector< object* > get_all_enemy_objects_in_state (string State);

Now you know: these are all perfectly valid functions to have on your World class, because they are all DPS Queries.

Takin' it TOO FAR

You can extend the rule:

Let's say you've got a function like:

void damage_all_enemies_in_radius (double X, double Y, double Z, double R, double DamageAmount, string DamageType);

That seems well and good. A Fireball spell might call it with damage type "fire" when it explodes. But by the above rule, we should perhaps rethink whether this belongs as a member function on World. True, it's handy. Also true: it's pretty specific!

In fact, we might give our head a check and think about whether it's really the World's business to hurt things in itself, or whether that action is better thought of as being done by the spell entity. Isn't the interaction between (burning hot plasmic air) and (orc flesh) better thought of as being direct, rather than being intermediated by the World class?

Advanced DPS Queries

We shouldn't stop with game objects. For instance, suppose that you've got an arrow that needs to fly through the air, and stick into the first wall it finds. If you've coded 3D before, you know that at some point you will probably be doing ray-triangle intersection.

We can imagine a DPS Query that does this, like:

vector< world_face* > get_ray_collision_faces (double X, double Y, double Z, double DX, double DY, double DZ);

The necessary intelligence to perform these collisions will live inside our World class. This is probably a good thing, and here's why:

We might find a world_face on terrain, buildings, or an object. World is going to be a collection of these things, understanding how they are laid out and interacting. The arrow we shoot need not be concerned that lava has now also been implemented, at least not directly. So the entity that needs to "know" about such things in terms of detecting arrow-collisions is also the entity that is responsible for managing these things in the first place, which is good design.

Final Notes: Finiteness, Ordering

A couple of things: remember that we are always returning a finite set of things, even though the game world is (uncountably) infinite. This limitation means we are going to package our query results into a vector<> or set<>, or we could create something special for iterating through as with a database engine. Not all DPS Queries would need to return their results packaged the same way, of course.

Now a note on ordering. We can of course order our results in any way we want, but sometimes we won't be able to, so it's important not to be part of the definition of DPS. An ordering is a linearizing operation, i.e., it takes things and puts them on a one dimensional line. Games are usually spatial and so many times, ordering does not really make sense. So some queries are going to have a natural ordering to their results, and some will not.

There is a common idea with artistic development that you will go through a period of experimentation and immitation, finally settling into a style of your own.

I'm not going to pretend that I have settled into my own "style" but certainly my technique has become fairly standard. It's just based on what appeals to me:

The Human Touch.

Awwww...

Tartan Blanket

Right now, I'm going through The Real Texas and basically leaving nothing unfixed or unimplemented. Some items or textures were drawn very hastily, or very early on in the project. I've developed since, and so I am reworking and redrawing things.

Luckily, when it comes to 3D models, I made everything a square, and so very little (if anything) needs to be re-modeled (there are a few trees and other objects that have been fleshed out, though.)

Just now I took this tartan texture, and redrew it. Some people might find it less refined, but that's OK! It's one of those times you have to just say as a designer, "I'm right about this one, sorry!"

In-Game Tartan Blanket

Here is what it looks like in-game.

Overall Progress and the IGF

Things are coming together really well. I won't waste time talking about it, this phase in game development is about millions of things like the above tartan texture redraw. I am pretty confident that Texas is going to amaze and amuse people.

I entered Texas into IGF and it wasn't selected. I won't lie, I was very disappointed even though all the nominated games were amazing. Truthfully the biggest benefit to being nominated would have been personal validation! Well, not even personal validation, but maybe something nice to tell family members who have supported me (and keep supporting me.) I am lucky to have people that support me! Not just people in my life, but also other game devs, and people who send me encouraging words online! Thank you!

WARNING THIS POST IS ABOUT THE QUALITY OF A FACEBOOK "NOTE".

I did it because I felt obligated.

HIGHLIGHTS:

The Real Texas Almost done. Almost!

• This is my main project; just a few days ago I finished working on the final boss battle and so in some sense it is "feature complete". I am polishing, and it will still need lots of work before it's ready to be released. But wow.


• I entered this game into Penny Arcade Expo early this year, where it was not selected.


• I also entered it into the IGF, and we'll see.


• I've just been playing it. I'm really happy with it, and wow-- it's already very polished!

New Bike

• I built myself a Surly Long Haul Trucker this year. The frame was not too expensive and wow was it worth every penny to finally have a bike that fits me well. I love it to pieces but unfortunately can't ride it in the winter. I took it out for quite a few +100KM trips this summer.

Victoria/Seattle

• My partner and me went to visit friends in Victoria, which was a blast. We then took the ferry to Seattle. Lots of fun, what a great town.

GAMES FINISHED in 2010:

Most of these are on the Games Page.

Demonic Farmer Gabo Finished, but unreleased.

• A farming sim with a twist. Finished, but unreleased. I'd like to rework it for keyboard-only input.

Whales of Aelia Finished, but unreleased.

• A sci-fi story game that I entered into LD early this year. I revised it and submitted to Asimov's Science Fiction magazine, but it was rejected just a couple days ago. C'est la vie.

Life, Death and a Day at the Beach Released.

• Three silly games for PIRATE KART II.

Paradise Perfect Boat Rescue Released.

• A cool little 3D game I made in a mad blitz where you are rescuing little villagers. I'd like to get this ready for android tablets when they are available later in 2011 (I guess?)
• It's not selling very well on the Intel AppUp store.
• Screenshots are here.

The Legend of Elkanah Released.

• An experimental bible story game. I played this over again last night and found I was actually really satisfied with it.

Waterwheel Released.

• A sort-of toy based on a book called CHAOS. Based on the lorenz attractor.

GUN Released, but only on the Winnitron 1000.

• I am really happy with this game. If you are near the Winnitron 1000, please give it a shot. As it is completely designed around a 2 player, arcade experience, I haven't figured out how to release it more widely yet. I hear there is a Torontotron and maybe a Winnitron coming to Sao Paulo, and to Calgary...

IN PROGRESS in 2010, not yet finished.

Diver after Coral. 30% Done.

• There are screenshots on pekuja's excellent #screenshotsaturday.


• This is a story-based game, inspired by Gregory Weir's games. I will reuse the platforming engine for other games.

Asha's Belt. 10% Done.

• There are screenshots and more in the Flashpunk Forums Thread.


• This is a large experimental project that I'm not sure I will finish. It's an advanced RTS story-based RPG in flash. Although I'm calling it 10% done, actually there is a lot in there. If I can get a few more features in I might be able to turn it into a game fairly quickly.

Today, after maybe 4 years of solid development, I reached the first "finish line" for The Real Texas.

December 7 I started work on the final boss mechanics. Today, 20 days later, it's basically complete. I will still need to do some major tweaking and add a few minor-ish things, but there you have it. And oh, dear friends, have I been slogging.

What's a Boss Battle?

I try to generalize the idea of "Boss Battle" into what is really just a climactic gameplay event.

These kind of climactic battles take a lot out of me, because I try to avoid formulas. As a result I do not work very efficiently and they take forever. In fact, when faced with a boss battle I end up wasting a lot of time browsing the internet or just sitting around the apartment and thinking. For me these are the hallmarks of having run out of creative energy.

Once an encounter picks up some momentum, however, it's more possible to focus. Like a puzzle that comes together, once you see certain things in action you can see more easily what is required to complete them. But reaching that critical mass is a long and painful process.

Each "boss" encounter in The Real Texas is somehow unique. I'm not suggesting they will blow your mind, but none of them are "memorize the pattern and hack away until it dies." And by unique what I mean is that they represent situations you should not have really encountered in games before or would not expect, exactly. Not that I claim 100% originality, either.

What's Left

There is now nothing major left for me to do to finish the game.

My list is roughly:

• One area for the epilogue.
• Some drawings for the "THE END" section and maybe to redo the intro drawings.
• Fill in a few areas with foliage/etc.
• Maybe a few small mini-dungeons/puzzles for reward items.
• A number of end-of-game cutscenes.
• Rework some quest sequences.
• Figure out one major-ish subquest's resolution.
• Fill in more object/enemy interactions, particularly with respect to the later-game weapons.

After this comes the truly end-game stuff of final play-testing and of marketing, which I will do in parallel. I need to try and get the attention of Steam and other distribution services. At the same time I will need to work with a number of people to play the game through and find out where the sticking points are, and resolve them.

Fortunately I have a great list of volunteers who have played the game in the past and/or are eager to give it a try! If you've asked me before, you are likely on this list. If not, you can post a comment here or email me at psysal@gmail.com and I will add you to it. I can't guarantee that I will get to you but the list isn't that long so the chances are good.

ONWARD!

A Present

In commemoration of this momentous day in my life I have drawn a picture of Gannon for you. He looks oddly at peace with things:

Game Dev Trix - Arguments

Today I have some things to tell you that are technical mumbo-jumbo-ey. This one is really juicy and I promise I'm giving away all my secrets, so ignore at your own peril!

Seeing the Small Picture

As programmers, we are used to dealing with nitty gritty details. For instance, if you show "openFile" and "OpenFile" to many programmers they will interpret "openFile" as a verb (i.e., "open the file") and "OpenFile" as a noun (i.e., "the open file"). A silly and sort-of wrong example, but it shows how tiny details change meaning for a programmer.

My programmer brain spends a lot of time wrapping itself around such minutae that it starts to seem normal, which of course it isn't. The danger is that I will lose perspective and see only tiny details.

This is why programmers sometimes do not finish making games. We spend all our time on bump mapping, when we should just have everything flat-shaded!

Parameters vs. Variables

One thing I didn't appreciate until recently is the difference between a parameter and a variable. We often think of functions in terms of arguments. Naeively, to draw an alien to the screen we could do:

$bitmapData = readBitmap ("alien.png");
drawBitmap ($bitmapData, 5, 10);

It probably makes sense, however, to have a Sprite class that captures some of the details:

$bitmapData = readBitmap ("alien.png");
$alien = new Sprite ($bitmapData);
$alien->draw (5, 10);

Let's loosely define a parameter as something which we do not change that often, and a variable as somthing that does. In this example, we have parameterized our bitmap data; the alien's (x, y) position might change every frame, but his graphic does not.

Grey Areas

As programmers, we tend to see everything in terms of arguments. Ha, ha! That is actually a pretty good pun! Anyways.

What I mean is that as seers-of-detail we take the above and realize that "all we've done" is reorganize things. $bitmapData is still being passed as an argument to $alien->draw (5, 10), it's just implicit:

$bitmapData = readBitmap ("alien.png");
$alien = new Sprite ($bitmapData);
Sprite::draw ($alien, 5, 10);
// or if you prefer, we could just call drawSprite ($alien->bitmapData, 5, 10)

It's important for a programmer to understand the above code, but we lose the big picture if we think it means that there is no difference between parameters and variables. Worse, I don't think we can draw a line exactly between them-- something else that programmers relish.

My point is there is a degree of variable-ness and parameter-ness to the inputs or context of a program, class, or function. Programming, in part, is carving up the parameter space cleverly into smaller and smaller chunks until we have a model that does what we want. In the broadest possible sense, the most "parametery" parameters are like the laws of physics (and aren'tprogrammers more willing than most to accept that these are somehow "reset" at the big bang/big crunch?)

Particle Systems

As every game programmer knows, particles make things awesome (just ask Rob Fearson). Writing a particle system is normally an issue of setting certain parameters: the rate of particle generation, the size, the rate that their size changes, the initial velocity, the acceleration due to gravity, the rate of "spread", controls on the initial position or size when they are first emitted, their color, the rate of change of their color, the rate of change of their alpha, and so on. A heckuvalot.

All of these we normally think of as parameters. We might have a few that are realtime adjustable, for instance the "origin" might be a variable so that the particles can track a moving object, or perhaps even the overall rate of emission-- then a spaceship can emit more fire as it moves faster.

As a real-world example, the particle system in The Real Texas has 28 (or, if you count a vector as 3 parameters instead of 1) 46 parameters. Only the "origin" that the particles are emitted from is a variable.

But the trouble with particle systems is tuning. With so many possibilities, it can take forever to get them looking proper! Most combinations of arguments are useless. But many combinations of arguments give great and varied effects, too! You can create very nice effects if you can get the arguments just so.

We could put all these into an interactive simulation with sliders and so on to adjust, and that would give us some artistic control. I think this is a good solution if you can afford it (or use a game development environment that already has such a thing for you.) But maybe you can not/do not have such creature comforts!

Parameter Wrapping

At run-time, these parameters do not change and so are truly parameters. But at tuning-time, they do change, and a lot. So when we are adding a frost effect for the Cloak of Ice, we should think of these parameters as variables. Tuning is hard because there are so many variables!

This is important: when viewed at from run-time, they are all parameters because none change. But viewed at from tuning-time, they are all variables because they all change. It's an important conceptual leap to see the development process as part of the program.

Anyhow, let's reduce them.

Trix 1 - Coupling

One strategy is coupling. To couple two variables, we recognize a relationship between them. Suppose we have two variables, emitAreaRadius which describes how large of an area to emit from and emitRate which describes how many particles-per-second to emit. We can rearrange these to be emitAreaRadius and emitDensity, and then just calculate:

emitRate = emitAreaRadius * emitDensity.

At first glance, it may not appear that we have the number of variables. In practice, however, we did, because at tuning-time we are going to fix one, for example size, and adjust the other. We have made one of these variables more parameter-like at tuning-time.

Trix 2 - Grouping

Another strategy is grouping. Suppose we have three tuning-time variables that control the color. One might be alpha fade rate, another one initial color, and another one describing a rate of desaturation (so that a bright orange flame particle turns into grey ash.) What we can do is group these together into a single tuning-time variable, colorType. When we set colorType, we are going to automatically set all of these tuning-time variables accordingly. This is helpful because we might want to make larger or smaller fires.

Trix 3 - Naming

This is really just a variation on Trix 2. When adding a particle effect to a jet engine, we might specify all 46 tuning-time variables as part of that object. But a better solution would be to create a super group containing all these tuning-time variables together, and call it for instance "jetEngineFire". Then we just create a jet engine and set it to "jetEngineFire", and can re-use this for other objects.

Not Just For Particle Systems

I use this same approach everywhere in designing assets in my games. For instance, a 3D model can be thought of as having a thousand design-time variables (every vertex, together with texture and color coordinates) or just a few (thickness, texture type, height). Clearly, at design-time the second is preferable. If you are into that kind of thing, this is really just another way of looking at procedural generation.

Hope this helps you! As a final bit of advice, I'd suggest to not over-design or look for a perfect parameterization of some function with many variables, but just cut things down to managable complexity and then run with it. Part of throwing out detail is that there is no holy grail, no perfect way to make the cut. At the same time, as you create more and more managable models you are going to see better ways to describe things.

Good luck!

No insights lately, sorry!

But here is what I'm up to:

Texas Submitted to the IGF

View The Trailer Here (sorry-- not uploaded to moddb yet!)

I think the IGF is a fabulous event. There is a certain noise surrounding whether the judging is fair, whether "indie" is really indie, and so on but overall if I look at the winners and nominees from last year I think it's pretty reasonable. People can never feel satisfied with judging, this is simply normal.

I am glad to be part of it. The field looks very, very good this year so it will be interesting to see what cream rises to the top. Here's hoping! If Texas doesn't really get noticed I won't be too surprised because there are many other fantastic games. Still, I can't help but feel proud of what I hav emade.

The trailer above was posted on The IndieGames.com Blog which is exciting for me.

Texas Is Almost Done

Since the big push for the IGF, I haven't felt much like working on The Real Texas. Life has been busy in other (fun) ways. Doubtless that will soon change, and I feel like one more big push will get 'er through to the end.

Then I will do user testing like mad to find out where people are getting stuck. I also scored an older Mac Mini that I will use for the Mac port. I'm of course not sure exactly if the HW will handle it properly but it should at least let me build and see that it runs.

I went to see this movie with friends yesterday, and really enjoyed it. I hadn't read the books but maybe I enjoyed it even more for not knowing anything.

Some weird feelings are settling out for me today, so I'd like to write about them now, while they are fresh.

Games' Symbolism is Formative

Zelda: Link to the Past came out around 1991, so I was about 12 years old when I first played it. When I was a bit younger, I played Zelda I and II, and it was a lovely, social thing. We would head to lunch at my friend's house to methodically burn bushes, or to write down long Gambling Cave sequences in a futile effort to crack the RNG.

Perhaps I'm on the cusp of the possible age to where playing videogames could be a formative experience. There are older videogames than Zelda I but they were under a certain threshold for complexity with respect to their symbolism, I think.

Religion

The human brain does weird things. Just like we used to find all sorts of nonexistent patterns in Zelda's Gambling Caves (something every slot addict must surely do) so too we find all sorts of unlikely analogies or explanations for other natural acts.

To pick a hopefully not-too-incendiary example, think about the US constitution. Certainly it's very important to the US, but what's so strange to an outsider like me is that people are so affixed to it, even to a religious extent.

In fact President Obama recently referred to it as the "Founder's Writ", which sounds a lot like "Holy Writ" to me, and Old Timey term for the Bible. Americans friends in earshot get this: it doesn't work like this in other countries. In Canada at least we really don't take our constitution that seriously, though it is of course important. Does this blow your mind? =)

Humans tend to get our brains wrapped tightly around certain ideas or symbols, extracting ever more meaning from them, and coming to ever more totally strange conclusions about the natural world because of it.

Scott Pilgrim

The imagery in Scott Pilgrim helped me to understand videogames in a different way. Symbols in games have the same kind of mythology that powers religious beliefs. They are, kooky though they might seem, a way to understand the real world.

There are some obvious examples from the movie, but I won't spoil anything here. Instead, let's pick an interesting example from games in general.

Warp Gates

Warp gates to a game designer are a handy way to refashion the game space to help the player get around. They reshape space in a way which really isn't in accord with the natural world, but which is useful.

If you grew up playing games with warp gates, maybe these are part of your mythology. The idea of a door might have a religious significance to you, as something that can somehow reshape space.

I'm not suggesting our generation are somehow confused as to the laws of nature, but interacting with gateways in games maybe has changed our perception of what a door can be. Even if that understanding never causes one to doubt the real purpose or structure of a door, it has become a powerful symbol for changing place, for shortcutting.

My Warp Gate

Actually, I just remembered something amazing. When I was about 10, between two houses one day, I saw a "cut through" or pedestrian walkway. I had passed by hundreds of times, but never noticed it. Naturally, I went through. What I found I called The Lost City of Paved Alleys. This was a paradise to me as a kid, because you could ride your bike very fast without worrying about cars so much.

So there was a real warp gate for me. I even still use it sometimes! Here it is.

Baptism and Eucharist

The most powerful symbols in a religion are interactive. I grew up in a church where certain things were very important: Baptism (where you are dunked under water as a sort of dedication to God) and Communion (which is where you eat bread and grape juice that symbolizes your belief in Jesus' Resurrection, past and future.) There were other interactive parts of a church service, like singing songs or saying special prayers, which are really pretty compelling especially when you do them in sync, as a group.

Psychologists will proscribe sometimes physical actions for you to take in helping to grow past some difficulty you are having. Maybe this sounds crazy to some people but it makes sense to me.

I once knew somebody who believed that screaming at the top of your lungs was really therapeutic. I'm sure he was right. He had some other weird habits.

Abstraction

We have to a large extent already abstracted the world we live in. Cars are real-life warp gates, bending and shaping space. You will understand this if you walk or bike somewhere that you would normally drive (but walking is best for this, as bikes are warp-gates, too.)

We rarely think of cities as a wild space, but I think that's how animals see them; forests with lots of people. For us they are an abstraction of place-nodes, and lines linking them. These are meaningless to animals, though they doubtless have their own strange way of understanding it (maybe in terms of danger, food, noise, and water.)

The day I went to see Scott Pilgrim we saw a Magpie (a local variant of crow) bathing in a fountain, inside a jewlery store. Somehow he got into the mall. After his bath he went next door for some candy. I'm not making this up.

Nature

The risk for us is that this abstraction will one day come tumbling down, for instance if oil becomes scarce, or we nuke ourselves into oblivion, or our system of money loses meaning through massive fraud or mismanagement. These apocalypses sit themselves behind all our symbols, because we do at some level recognize our abstractions for what they are.

I'm not sure the role that videogame-mythology might have in a world without all the modern abstractions, but it interests me.

Most games have what's called an "update cycle". One way or another, there are a bunch of entities/objects with an update () function, which is called periodically (usually every frame.) These might control enemy logic, particle positions, animations, etc.

Here is something that I have found to be incredibly helpful in reducing bugs.

Holy Means "Set Apart"

Consider that your entire update cycle is "holy"; that is, your objects are ONLY allowed to change their state meaningfully within it. For example:

• Suppose you have an Enemy class, with an update () method and a hit (damage) method.
• The hit (damage) method will typically have some logic to decide if the damage should destroy the object, and make it explode if necessary.
• Then, there is a Bullet class, which within it's update () cycle checks to see if it's colliding with any Enemy objects, and if so, calls hit (5) for 5 damage.

How Something Gets Hit by a Bullet

Here's how I will structure this:

• The hit (damage) method is outside the Enemy object's update method, so it's not allowed to meaningfully change the state of Enemy. In OO-terms, any changes it makes must be strictly private, and not change the public appearance of the object.
• This means that the hit (damage) method is NOT allowed to explicitly kill the object; as well, its not even allowed to affect the outcome of a function such as isDead () (which might check if the hit points <= 0).
• So, what you do is you have a request variable, such as "damage_accumulator" which accumulates the damage over a frame. the hit (damage) function just adds damage to the internal damage_accumulator.
• Then, in the object's update () cycle, you perform hit_points -= damage_accumulator; damage_accumulator = 0; and a check like if (hit_points < 0) { explode (); };

Reasoning Why It's Better

I don't know exactly why this saves me so many headaches, but it does. For sure, it's something "like" a transactional system; changes are being collected (e.g., in the damage_accumulator variable, above) and then being applied later on, all at once. The update cycle for an object knows e.g., that the object will explode before it heals, or vice versa.

But I think it's actually more to do with unexpected side-effects where an object's external state changes more than once per frame. For instance, suppose object A had update () called, then object B's update () determined it needed to call A.changeSomething (). At this point, A has looked three different ways in the game's update cycle: before A.update (), after A.update () and after B.update ().

It definitely seems to be working for me-- maybe it'll help you, too!

I recently finished a game, The Legend of Elkanah. It's a simple side project that is supposed to play something like a storybook, based on the Bible story 1 Samuel 1, with a bit of a feminist bent.

I have to say it's not very good, but it's interesting to look at why:

Pacing

As soon as this game was done, I knew I had created a snore-fest. There are a few reasons that it feels so slow:

Subject matter. Let's face it, this isn't a really exciting story-- although I do think it's interesting from a feminist perspective. I don't regret the choice of story.

Inactivity Triggers. There are a few key events that only happen after you have done NOTHING for a certain number of seconds (usually 2.) Players can't anticipate this and will want to progress the story forward, to do so they will intuitively try acting. This stymies them, of course.

I don't know yet if this latter is an absolutely terrible device, but to work properly this problem has to be solved. I like it, because it has the effect of the game interrupting YOU. I.e., there is one part where Peninnah says, "Sister," to interrupt whatever you are doing, and I think it's an effective device; or could be if we weren't frustrating the player.

Immersion

The game could do a better job of bringing you in, as a player. A few things break immersion:

Sound. Close to the end I realized this game would be overall fairly bad and as I hadn't invested any time in sound effects, I didn't make much of an effort. However, nighttime sound effects, wind, etc. would add a lot to creating a storybook setting for this type of game.

Interactivity. There aren't any objects you can interact with, or places you can go on your own. You are more or less trapped on every screen, and moving left or right is purely cosmetic; it doesn't affect the gameplay whatsoever where you are on the screen. Interactivity, even very simple, can help a player's imagination to enter into the world.

Replayability

This is the most interesting lesson learned, for me. We have in essence a branching path like this:

There are some major choices, and some minor variations.

The trouble is that you've got to go through that first branch three times, at least, to see all endings. That's really not too fun! Worse, whatever variations you see are fairly random and it's certainly not worth replaying the whole game over again to see them.

A Better Story Stream

A better stream would be something like this:

The blue arrows mean we are given the option, after reaching that ending, of rewinding back to the previous point.

There's a small "common" section at the very start, after which you make a choice. The story follows similar but not identical lines for awhile, then branches further off. If we hit a dead-end in the story we are given the choice to go back.

Onward!

I think the next side project I work on is going to be for the kids; i.e. just a regular game without much originality. Maybe an exploration-RTS in space or something, there's not many of those in flash and it wouldn't be hard to do...

This is not admitting defeat, just a break! =) I have at least 2 weird art-game projects and 1 plain weird thing sitting in the back of my mind that I will almost definitely make, too.