Monday 27 February 2012

Jam and Kart

I've made thirteen games in the last eleven days.

For TIGJamUK6:
- Cube Gallery
- Number Quality
- a physical card game.

For Pirate Kart V:
- Game Title
- Game Title: Lost Levels
- i heard you like videogames
- Ludoname
- Ytilauq Rebnum
- Reverse Passage
- Grand Vampire Chase
- Reverse Passage 2: Mother's Edition
- Gardens of Time: Design Problem Solving
- Multicolour Alien Olympic (two-player)

Obviously some of these will be less interesting than others. Game Title is probably the best place to start if you want to try one of them.
I highly recommend doing game jams. There's really nothing else like sitting down for a couple of hours and having a new game at the end of it.

Note that this isn't even that many. SophieH made 16 this weekend.

(All downloads are Windows only at this point, I'll try to do mac builds of some of them this week.)

Thursday 9 February 2012

a dead end

Still making two-player games. There's a particular dead end I've run into repeatedly. It seems quite natural, at least to the way I think - lots of designs have ended up in the same place for completely different reasons.

(Definitions: I'm just talking about real-time competitive videogames here.)
(Disclaimer: Somewhat tired and unwell. Thoughts may be fragmented or incoherent.)

So, I'm not interested in making games where being quicker than your opponent guarantees a win. Just a matter of taste. I'm happy for speed (and chance) to play a part, but in general I prefer the outcome to be determined by decisions made by the players.
Part of the reason for this is that I play games with my wife, and usually if speed is very dominant in a game then I'll just win in a kind of boring way. My reflexes are better trained by more years of playing videogames, big deal. In a battle of wits, we're usually evenly matched (although don't ask about Chess). Having relatively even chances of winning is more interesting.

So the problem is: how to make a real-time game where quick action doesn't dominate?
A too-obvious solution is to have some kind of resource that accumulates over time and constrains how fast you can act. This leads to the dead end of which I spoke: having resource constraints on all actions. I've made at least four different games on this model, and although they had interesting decisions to make, they weren't interesting to play. Build something, wait to recharge, build something, wait to recharge. Games where you spend most of your time waiting for something to happen are boring. BORING. There's a lack of engagement. No matter how short the delay is, eventually you've made your decision and are just waiting. (Make the delay short enough and the quicker player wins and still spends most of the game waiting impatiently.)

I'm working on a very short timescale. Games that are over within five minutes. I've seen this type of thing done on a much larger time scale, games like Neptunes Pride with actions that take hours to execute. Circumvents the boredom by letting you achieve something else while waiting. But I don't like these either, they tend to advantage logging in frequently and at inappropriate times; they take over your life.

I've done games with some continuous actions with no time constraint, and some discrete actions constrained by a resource dependent on time. e.g. Exuberant Struggle. This works. I'm working with very restricted controls so it becomes quite limiting, but it's led to nice designs. The continuous actions often give false decisions - "do you want to dodge the incoming bomb? y/n" - but still give something to do and make the game more engaging. Speed is still an advantage, but I've been able to constrain how much of an advantage it is enough so that a player with slower reflexes can still win.

Glitch Tank's a curious example. It has a built-in disadvantage to haste. Spamming actions will let you build up lots of tanks and mines quickly, but friendly fire means this isn't a strict advantage. Acting quickly is an advantage, but only if you do so safely. It just barely works.

There are other ways out. I'm interested if anyone has examples that solve this. But I recommend avoiding it because it's been a dead end for me. Certainly if you throw away my constraints there isn't a problem - if you're happy for speed to be a big advantage, or if you make a turn-based game (which can end up playing faster as you master it). Or if a game is intentionally boring (?).