Wednesday, 8 May 2013

Score Conditions

Something I've been thinking about with respect to 868-HACK (yes I'm still working on it, the new version has a new name, I don't know when it will be done) is how players can approach score in a game differently depending on their goals, even when the score system itself is fixed. Some of this comes from conversations with @rocketcatgames and @stiknork.

Zaga-33 had a very minimal score system. The main focus is on the win condition of killing the end-boss; the score essentially measures progress towards achieving that condition (by counting which dungeon level you've reached), with a bonus at the end for how efficiently you achieved it when you do (by counting items remaining in your inventory). I discussed this in a previous post (which also touched on some of the other things I'm writing about here).
Before you've completed the game, playing for score is quite effective: it helps you measure your progress towards the ultimate goal. But it turned out that once you can complete it, playing for score wasn't interesting for very long. Whether you could get a high score depended largely on random factors: whether items and level configurations were favourable. Then once you'd achieved the maximum possible score, there was nothing further to achieve. (This is why I didn't include an online scoreboard, see another post.)
But that wasn't the end of it. @Rocketcatgames found another way to play: trying to get a streak of as many wins as possible in a row. I'd tried to balance the game to almost always be completable, and he put that to the test. So I patched in a streak counter that shows up when you win the game, to keep track of this for him (and anyone else who wanted to try that challenge).
In one of the previous posts I talked about how taking a very coarse measurement for score helps to average out the effects of randomness; here we have the coarsest measurement of all - win or lose - added up over multiple plays, turning out to be the best way to display skill.
The interesting thing that came out of this for me was: playing to get the maximum score and playing to get the longest streak required subtly different priorities - similar skills, but applied differently. To maximise your score requires taking reckless risks and succeeding at them, while streaking requires minimising risk as much as possible. The conservative player uses an unidentified item under controlled conditions, where the consequences won't be too bad if it turns out not to be useful; the risky player gets into a situation where only one item will do and then guesses right - or dies, which is okay because they wouldn't have gotten the top score anyway.

Consider the sequence of scores (or wins/losses) across multiple games, instead of just a single number from one game. One way to interpret that sequence is to just keep the biggest one in it, the "high score", that's fine, but there are other possibilities.
Counting streaks (where there's no win condition, you could look at streaks of scores larger than N).
Average score - Drop7 tracks this, and it affects how it's played (although it's a bit broken because you can cancel a game before the end without it contributing to the average). This is potentially really deep because you have to work out to what extent the higher scores you may get by taking extreme risks balance out the lower scores you get when those chances don't work out. In a game with an exponential score system it might be worth getting nothing most of the time in exchange for the occasional zillion-point game - or it might not.
Also there are different types of average you could take: median, geometric mean, harmonic mean.. or you could look at average streaks, or something weirder - what if the ideal way to display your skill at a game is to lose every seventh time you play and win the rest, or to guarantee that each score is higher than the last - a streak of increasing (or decreasing!) scores?

Measuring streaks of wins is pretty similar to measuring your win percentage - a high proportion of wins implies long streaks; long streaks could come from playing badly but many many times, but are most likely to come from being able to win reliably. So win percentage might be a slightly more accurate way of expressing skill, but I prefer to look at streaks because they feel more exciting - there's a psychological difference. Tension builds as you win multiple games in a row, and you may change your style to be more conservative to try not to break the streak. "I won 30 times in a row" sounds more impressive than "I win 83% of the time". (Also the average becomes hard to change once you've played a lot - though this can be solved by averaging across a rolling window of the last N plays.)

A similar consideration comes up in multiplayer games: are you trying to maximise your chances of being in first place, or maximise your expected position among the players? Often you get situations where anyone could attack the player in the lead to bring them down, but it would cost them their own position and give the game to someone else (a form of kingmaking) - and sparks can fly when players have different implicit ideas about what they should be playing for. And when there's a score, if you're behind do you take risks to try to win or do you aim to maximise your score to lose "by less"? Does the absolute value of your score mean anything at all, or is it just about how it compares to other players? Tournament structures around the game can answer this one way or another - in an elimination tournament you might just want to be first (or to not be last), whereas in Poker you typically only care about your score.

SpaceChem does something interesting with its scores, which the developer spoke about at GDC this year. It offers multiple criteria by which your solution is evaluated, so as well as completing levels you can try to improve your solution along each of these axes. But the criteria aren't independent: improving on one axis will cost you on the others. One really clever side-effect of this he pointed out: optimising for one type of score means you're likely to be below average on others, but all scores are added to all leaderboards regardless of which one the player was aiming at, which means everyone can get to be above average on one of them.

868-HACK, like Zaga-33, has both a score and a binary win condition. And, also like Zaga-33, it's possible to achieve the win condition almost every time with cautious skilled play. But unlike it, your score is not closely tied to the win condition at all. You might get 24 points and then die in the first sector, or get to the end with no points at all. There's often a choice between the two - getting points is risky and reduces your chances of survival; sometimes you can guarantee a higher score if you don't try to get out *ALIVE* as well.
The first thing I did, which is in the 7-day version, was to order the scoreboard so that any winning score - even 0 - is above any losing score. This kind of says that your score means nothing if you're dead. And this is interesting, it's a deeper challenge to figure out how exactly many points you can safely get to the exit with than to just grab the highest numbers you can find.
But over time it became clear that it suffered from a similar problem to Zaga-33: getting the highest scores was largely a matter of luck. I already knew a solution: streaking technology. But since this time scoring and winning are not coupled, the length of a streak alone wasn't enough: instead I'm tracking the cumulative score. It presents a difficult problem: how many points should you get in each game to maximise your score across a streak? This works really well.
The expected sequence of mastery is: trying to get to the end, trying to get a high score, trying to get a high streak score. Note that of course I don't expect all players to be interested in this - I'm perfectly happy if someone stops at an earlier tier. If you just get to the end and are satisfied with that that's completely fine, but if anyone wants to keep on playing then there's a greater challenge to measure themselves against.

When putting a score in a game, don't just say "try to get the biggest number" and be done with it. Consider whether it's a score that makes sense to compare against other people, or if it's (like Zaga-33's) better just as a measure of personal progress. Consider the context around the score, how different goals across the sequence of repeated plays can shape how players approach each individual play. And when you find the most interesting goal to aim for, consider how to present it to players. Show people a number and someone will care about it and try to make it bigger. Be open to players inventing their own approaches, a game can accommodate different styles of play driven by different goals.

Sunday, 5 May 2013

being good at glitch tank

WARNING: MOPEY

I find myself in possession of what is possibly the most pathetic skill: being really good at a competitive game that I made myself and that virtually nobody else plays.

Recently I've been struggling when I try to make multiplayer games. I get excited about ideas but lose motivation very quickly. This weighs heavy on me, even though I'm doing okay making singleplayer games; multiplayer is what I care more about. I try not to be too much influenced by people's responses, or by stupid numbers like download counts or page views or sales, but I've not been able to be unaffected by the difference in response I get to singleplayer games versus multiplayer ones. I've written before about the frustration of feeling that I've failed these multiplayer games (Glitch Tank in particular) by not being able to give them the audience I feel they deserve. I suspect at this point there is no chance of them ever finding that - this culture has a singleminded obsession with newness; if something is "old" (i.e. not released THIS WEEK) then it's not worth paying attention to; new opportunities arise only for things newly made. So I must accept failure.

Was trying to explain to someone recently why Glitch Tank is the best game I've made. I thought maybe writing something about what's good about it might help me to move on (it worked for my scarf).

(Is it the best game I've made? Possible cognitive biases at play here: 868-HACK may be better but it's still too close for me to view objectively - its compromises are too fresh; Vertex Dispenser took a lot out of me and I don't much like to think about it now; O's vulnerability to violence bothers me; solved puzzles aren't interesting.)

I suspect maybe in my being-bad-at-marketing I've failed to communicate what kind of game Glitch Tank actually is. Or more importantly, what it isn't: it's not a casual party game. I think maybe people are sometimes disappointed with it because they expect this is what it should be? It's an "indie" game, it's on the ipad, and that's what most of the other local multiplayer games on there are. Glitch Tank has humour, but it's not something that plays well without giving it your full attention. It's a deep competitive game, and it's most interesting at a high level of skill. It's an "e-sport", if that's your preferred language. It's good for getting good at, it's good for playing a lot of, we still play it. This fits well with how I like to play games: picking a few to master rather than trying to keep up with everything that gets released. It's maybe not so appealing if you prefer to dip into lots of different things. It's a high-skill game; this means it doesn't work terribly well between players of widely different skill levels. The best way to enjoy it is with a group of people getting good at it together. It's not so interesting if you just get good at it and then beat people up; you want to be challenged.

You have to make decisions in a short space of time. It's hard to quickly calculate the consequences of an action; the relevant information is spread across the map and it takes time to process it. It presents a wide range of possible situations, and subtle variations can lead to very different outcomes. The heart of the game is the duplicate action, creating a copy of your tank which responds to the same input in parallel. The same instructions produce different outcomes for tanks in different positions and orientations, and all of these outcomes matter. Attacking from an unexpected direction with one of your clones expresses quick thinking, cleverness, simultaneously paying attention to disparate things, creative problem solving.

Eventually you develop an awareness of how long it will take to absorb this information and work out the consequences, and you start to take this time into account. You enter a state of "metacognition", thinking about your thought processes, making decisions based on acute self-awareness. Weighing the advantage gained from acting quickly against the advantage gained from considering your move.

Meanwhile you are of course considering your opponent's thought processes, how long they will take to think about things. You've seen that they have an opportunity to attack you but they're thinking about something else - do you act quickly to evade the attack but risk hurting your position because you haven't taken time to fully evaluate your evasive move, or do you wait to be more certain of your move but risk them becoming certain of theirs?

A key factor that makes this work is that every action carries a risk of negative side-effects. The laser and mine actions allow for friendly fire, you can damage yourself; mine especially since you place it right next to you. This makes the duplicate action risky; because your clones start near you they're more likely to harm you than your opponent (this too is why spamming actions quickly is unwise - you'll kill yourself more often than not; the "overheating" effect was not added for balance but to signal that this is a bad idea). Just moving becomes risky when you might step on a mine or into your opponent's line of fire, and even turning can ruin you if you end up stuck facing a wall or danger. So a poorly evaluated action doesn't just fail to improve your position, it can actively hurt you.

SPOILERS:
The rare invisibility action is the fullest expression of this; it's clearly advantageous to be hidden from your opponent, but unless you act very carefully (which costs attention, slows you down) you can lose track of your own position at which point you're acting blind - unless you do a action with a visible effect, which reveals you to your opponent also.

In some ways these thought processes are a lot like other high-level competitive games (which is what I was aiming for; the Kompendium project was an attempt to make the mental states of high-level RTS play more accessible). But I feel it's different enough (at least from ones I'm aware of) to be notable. The way randomness is fundamentally incorporated into your actions means your plans must be flexible, you have to manage risks and possibilities, and there are strategic considerations that aren't possible in a low-randomness game (holding onto opportunities until they're useful, trying to cycle through actions that aren't useful without endangering yourself, ensuring your hand doesn't get cluttered with problems). But the way this happens in real-time distinguishes it from the board/card games that present similar considerations; you have to think about these things quickly and manage time.

Monday, 8 April 2013

how to do a game jam

1) Start with a concept. Anything will do, it's not really going to matter. The standard form of "just like X except with Y" is perfectly fine.

2) Believe that it's a real game. It already exists, in a sense; games are mathematical objects, they have independent existence in the Platonic world of forms. Or something. Whatever it takes to convince you that it will work.

3) Start with the smallest thing that the player does regularly in the game. If they're mostly moving a character around, then that. The core interaction. Code it.

4) Spend lots of time on graphics, and on getting the feel of the controls right. These are really important for being able to trick yourself that this could plausibly be an Actual Game.

5) Play with it. Lots. Pretend the rest of the game is there. Yay, you made a game! (Now you just need to finish it.)

6) Drop your original concept. There's not enough time to implement it, and it's probably stupid anyway, what were you thinking? Just forget it. What you've done already can work without it.

7) Okay that's probably left some threads hanging: tie all of them together. You had this big idea but now that you don't have time for it there's a gap there, something else needs to fill its role. Just join everything up, it'll work out somehow. If there are two characters that aren't properly fleshed out - just make them the same person. If you've dropped your elaborate crafting system but the player still needs to acquire items somehow, and you've dropped your complex AI controller but you still need to introduce enemies somehow - just make the items be the enemies. Does that even make sense? It doesn't matter.

8) Keep playing the game. This is important, way more important than programming it. You need to get a feel for what it wants to be.

9) Realise it's not going to work, and throw it all away to start again. It's stupid, it's not interesting at all, and even at its newly reduced scope there's no way you're going to finish it, you were just deceiving yourself all along. You've probably still got time to make something really small... goto 1. (NOTE: skip this step in the event that your game is actually any good.)

10) Uh if you reached this then you have something interesting, keep working on it until it's done I guess? Don't worry too much about the deadline, it's better to make something good than force it into some arbitrary constraint. Neat.

Sunday, 17 March 2013

7drl success: 86856527

edit: please bear in mind that this was a prototype made in a week. the commercial game i have now released based on it has the same basic idea but is considerably more advanced and more clearly explained. this prototype is not intended as a demo version.



Successfully completed this seven-day roguelike. It's a CYBERPUNK HACKING GAME with COMPLICATED RESOURCE MANAGEMENT and LONG-TERM DECISIONS.

There are some issues that I don't have had time to fix yet, due to the whole seven-day thing:
- It's quite complex and I skimped on explanations so expect confusion.
- The mac version doesn't work on older versions of the operating system (this is part of Apple's planned obsolescence hellhole; the latest version of xcode won't build for older systems but I'm forced to update to it because the older ones won't build for newer systems and I've been forced to update the operating system on my ipad so UGH; basically I have to have multiple xcode versions installed and I really can't be bothered untangling this mess right now so).
- It might crash on completion. Or other times, who knows?
- It doesn't save.
- It might not be that well balanced, there's lots of costs to get right and I haven't played enough yet.

I intend to spend more time on this and release a more finished version in a few weeks.

download:
latest version: windows mac
7-day version for the record: windows mac

Some explanation if you're finding it too confusing:
- Arrow keys move, moving towards an enemy attacks it.
- You pick up resources from tiles by using DATA SIPHON, which are the smiley faces you collect.
- Siphoning floor tiles gives credits or energy, which are spent to activate programs.
- Siphoning wall tiles gives programs or points.
- The red number on a wall is how many enemies will appear when you siphon it.
- Mouse-over walls/programs to see what they do.
- Click programs (on the right sidebar) to activate them.


edit: hahahah I said "a few weeks". anyway it's released on ios now and I'm still working on an updated PC version.. it's way way better now though!
edit: now also available on steam.

Tuesday, 12 March 2013

7drl: day 2

I enjoyed seeing Terry's posts about his progress on his 7-day roguelike so I'm writing one too. No promises about keeping this up consistently.

The classic roguelikes I've most played are Nethack and ADOM, so any critical generalisations I make are mostly about these. (The Angband family seems to suffer from most of the same problems without the redeeming features though.)

My 7drl last year was a curated selection of some common elements of roguelikes - tactical combat (focusing on evasion rather than slogs), inventory management (limited to single-use powerups), the identification game. This worked out pretty well, so I started thinking about trying to do something similar but with a different subset of roguelike components. Specifically, it would be nice to include richer character growth. Gaining items in Zaga-33 is a form of growth, but because they're consumed when used their effect is quite short-term (gaining identification knowledge is long-term growth, but very limited).

I'd classify the common forms character growth takes in roguelikes as follows: either intrinsic (innate abilities of the character, usually permanent or close to it) or extrinsic (granted by items which can be lost or replaced), and either interesting (granting new abilities and changing the rules) or boring (making numbers go up).

Advancement in roguelikes often ends up being quite dull because there's not much choice involved. Intrinsic growth often lacks any choice at all (you killed some things and went up a level and now you are stronger). Extrinsic growth often offers obvious choices where one alternative clearly dominates another - particularly when the choices are boring (it's very easy to determine which of two numbers is bigger; take the sword with the most plusses on it). Decisions often come down to either being obvious or a pure gamble once you understand them: either you know fire damage is going to be better because the strongest enemies are made of ice, or it's unknown whether you'll turn out to need one or the other. Worse, most of the time the correct choice is "carry both of them and switch between them as appropriate"; i.e. not a choice at all and just tedious micromanagement. (Apparently Brogue has treasure rooms which only let you take one item; this is good because it removes the "all of the above" option.)

So here I'm trying to create a character advancement system based on choosing between interesting alternatives, in such a way that there's no obvious best choice but without it being a matter of blindly gambling, and committing to them rather than micromanaging.

So far I have four enemy types with different abilities, and they're super-easy to kill because the player has a ranged attack which stuns them. No advancement yet, but that's totally the goal. (Zaga-33's goal was a system of politics based on making and breaking deals with different enemy factions so uh I guess we'll see.)


(You can only see three enemies in this picture. Like I said: abilities!)

Tuesday, 26 February 2013

two-player games

A two-player game is a tool for paying attention to someone and expressing yourself to them. With more players, group dynamics creep in; there's more to pay attention to and it's harder to give your focused attention to an individual. On the other hand with a larger audience self-expression is amplified - games that ask you to act, make jokes, and generally be extroverted work much better with larger groups. I value the focused attention-giving of one-on-one games over larger group interactions (though I do value both); similarly to how I perform better one-on-one conversations than in group discussions.

Good two-player games present many opportunities to impress and admire your adversary. What can these opportunities look like? When you're figuring out a game, learning together, you can show off by figuring out how to do something before your opponent does. Strategy games like Chess let you spot moves your opponent hadn't, or think ahead to come up with a cunning plan, and then surprise them with it. These surprises don't feel strictly delightful in the context of the game - they hurt your position - but there's an intellectual delight in being shown something you weren't expecting, and in being presented with a new challenge to think about. Chess also lets you demonstrate your memory and experience by learning openings and endgames, though personally I'm less interested in this.

Many different skills can be expressed through games - creativity, reasoning, reading your opponent ("yomi"), attention, humour, strength, and so on. It is unfortunately difficult to express moral virtues like generosity, selflessness, courage, love, honesty, faithfulness in many games, because either these actively cost you through inefficiency, or they're actively rewarded and feel less meaningful because they don't cost you; perhaps this sense that morality should cost something excludes it from being fully expressed in games because all in-game costs are imaginary.

Expressing your virtues in a game is not about trying to be the smartest kid in the room, to figure out who's smartest, to lift yourself up by putting your opponent down. These are attitudes of insecurity. Let's try to help each other feel more secure, to lift each other up by appreciating each other's abilities - whether it's the grudging respect of nemeses as portrayed by Holmes and Moriarty, or more likely in the context of a friendly relationship. Maybe one of us is smarter, though this is impossible to measure absolutely, but even if so we can still admire each other.

When designing a two-player game, ask these questions:
* What virtues does it allow the players to display to each other?
* How can I direct the players' attention onto each other rather than just onto the game?
* How can I avoid the feeling of "multiplayer solitaire", playing together alone?
* How can the game continually present new opportunities for players to express themselves to each other?
* How can it give scope for moves that are particularly notable in their cleverness or idiosyncrasy?
* Can it provide high-pressure moments requesting quick/clever thinking followed by low-pressure moments to reflect on the previous?
* Are there hidden depths that players can impress each other by revealing and share the joy of exploring?
* Are there unexpected combinations requiring creativity to uncover?
* Does the mastery curve exclude players low on it from having anything interesting to say to those higher?
* Are one player's clever actions sufficiently clear for their opponent to see why they're clever?
* How will actions in the game provoke admiration?

Monday, 18 February 2013

acknowledgement of privilege

I'm ridiculously lucky to have been supported in making games full-time for a couple of years, and before that to have had a flexible enough occupation to spend a lot of time dabbling, and before that to have had a childhood with plenty of leisure and access to technology.

I consider that I've made some things that are worthwhile. But if not for these opportunities, I wouldn't have. If I'm any good at what I'm doing now, it's only through having had the chance to devote an incredible amount of time to it. I'm fortunate. Being able to put years of unpaid full-time work into something before seeing anything back from it is an incredible privilege.

It's still very unclear whether I'll be able to make a living from this. I hope I can. But now that I've gotten over a certain hurdle in terms of recognition, more opportunities are appearing - the IGF, interviews, people writing about my work. Opportunities that wouldn't have happened if I hadn't been able to work on this for an extended period. Just being part of a community of mutually-respecting artists; that's incredibly valuable and it's a place I've had to earn. I've been lucky to have lived in the UK for a while, where there's a thriving community of game developers, and where I've been able to meet many successful and interesting ones. I wish that everybody could have such opportunities.