A quick thought about software usabililty
by Ben on Jul.31, 2011, under Uncategorized
I wanted to install an update to some of my music software today, on Windows XP. Here’s the story.
I found out about the update via email, because there is no single place to find out about updated software. Obviously Windows isn’t a closed ecosystem so a single update point might be an unreasonable thing to ask, but it’s a shame there is no obvious central place that notifies you of updates: just an RSS stream with app name, version number, and a download link would be enough, and one program could read that once every startup. Instead, all your software asks to run at startup just so that it can check for its own updates, slowing your boot times and sometimes leaving stuff taking up memory. Not great.
The update was not for the app itself but for the samples, and the sample pack update had a version number of 1.0.5: did I need it? I don’t know. The software doesn’t tell me what version the samples are. It’s not in the Help -> About menu, because that’s just the software itself. It’s not noted in the Start Menu either. Nor in the Add/Remove Progams dialogue. So I just have to install it and hope for the best. Why is there no standard way of finding version numbers, in 2011? Even if different vendors have different ideas of what a version number should mean, there should still be a single place you go to find them.
I read the readme file that came alongside the installer. It tells me I need to navigate to the right directory if I’ve moved the samples. I might have done, so I bear that in mind. I run the installer, and at no point does it offer me the option of navigating to the right directory. Instead, it finds the correct location of the samples and patches them. Except, it doesn’t really. It seems to have done everything 1 directory level up from where it should have, so now I have to work out whether I can just copy them over by hand. Grr. Did I mention that the installer proudly said 1.0.4 in the title bar, not 1.0.5?
I go to their website to search the forum to see if anybody has (a) any idea how to find the version of what is installed(not because I need that any more, but because I’m intrigued as to whether it’s even possible), and (b) whether everybody has a problem with the directory structure when upgrading, or if it’s just me. I get asked for a username and password. I don’t know my username and password. I hate passwords (as you can see in my previous post on the issue) but this is especially bad because I need to use one account and password to authenticate my software and another account (and potentially another password) to use the software’s forum. I click the ‘forgotten password’ option, and have a reset link sent to my email account. I click the link, and it emails a new random password to my email account in plain text. I spend 15 seconds getting angry that they’ll send me a forum password via plain text email but won’t store anything server-side that lets me actually retrieve my original password, 15 more seconds amused that the random password they generated for me was ‘dddd5ddd’, and plough on.
I get into the forum, and enter a search term with 2 keywords. I am given a list of all results that match either of the 2 keywords. I feel like we’re back in the days of Altavista vs. Yahoo when search engines thought it was better to give you more results rather than better results. Then, Google demonstrated that when people typed “A B”, they really wanted A and B, not A or B – has the rest of the world not noticed yet? I suppose it was only 11 years ago, after all. Anyway, none of the hundreds of results seemed at all relevant to my problem, so I gave up.
Now this was an extreme case, but it’s rare for me to not encounter at least one issue similar to one of the above during any installation or upgrade. As software developers, we should do better than this. Right?
Related Posts:
Passwords and authentication
by Ben on Jun.19, 2011, under Uncategorized
With the recent security problems leading to many passwords being exposed (eg.Hackers claim they stole a million Sony passwords, or the Gawker hack) there have been several security analysts – some professional, some self-appointed – doing analysis of the stolen data to pass judgement on what the general public chooses to use as account passwords. Examples include “LulzSec E-mail Hack Proves We’re Lousy at Picking Passwords” (PCWorld.com), “Statistics of 62K Passwords” (codelord.net), and “A brief Sony password analysis” (TroyHunt.com)
They all suggest that users are employing poor security practices, suggesting they should be creating better and more diverse passwords. Yet this is all ignoring the fact that not one of these accounts, as far as we know, was compromised by having a poor password. They were compromised by companies having poor data security. The guessability of your password or whether it appears in the dictionary becomes completely irrelevant when it gets posted up on a website. And before that point, it’s only vulnerable if it’s a common word – at codedump.net Troy Hunt’s analysis of the leaked login data shows that the top 25 most common passwords are used by only 2.5% of accounts. In other words, you have to try to log in to an account at least 25 times to just get a 1 in 40 chance of being able to log in – and few sites I know of will let you continue to attempt to log in that many times. You can take the reverse approach, of taking one or two of the most common passwords and trying a bunch of usernames, but if usernames aren’t exposed to the public then this is non-trivial, and again a site can limit the number of login attempts from one address to make these attacks much less practical. In practical terms the only people at risk with their bad passwords are the 5% or 6% who choose things like ’123456′ or ‘password’ – the rest, who might just choose a dictionary word, have nothing to fear if the site is coded with any attention to security. Programmers like to remind each other that “obscurity is not security”, so how come very similar programmers seem to think the use of more obscurity by users is the most important part of securing their accounts? Surely that is a double standard, best addressed by developers rather than by users, by ensuring repeated login attempts will not succeed.
What about the more reasonable issue of when people share 1 password across multiple sites? Again the data suggests that over 90% of people who had accounts both with Sony and Gawker used the same password for both. Sounds bad, in isolation. But consider the alternative. A password has to be remembered to be used. Either you remember it yourself, or a tool has to remember it on your behalf. In the former case, given how many different online accounts a person might have (I have about 30 that I use regularly, and about another 100 used occasionally), this is simply not practical. Adding so-called ‘best practices’ such as ‘using a mix of uppercase letters, numbers, and special characters’ into the mix start to make it even harder to remember them, since case-sensitivity is a particularly geeky perversion and most people don’t think of numbers and punctuation as part of a ‘word’. If they forget a password as a result, they have to ask for it to be reset, usually due to a website being unable to send the password back to you and unwilling to store a hint on your behalf. And if they find themselves doing this often, they’ll just switch to a simpler password that they won’t forget. The upshot of it is that a normal human is going to need to reuse passwords if they’re memorising them by hand.
This, of course, is why so many experts suggest the use of a password manager. Something like Lastpass, except, oops, seems like they’re not completely secure either. Imagine if you lost access to pretty much all of your online accounts because of a problem like this. Without wanting to criticise Lastpass – their security issue is trivial and has been handled much better compared to Gawker’s or Sony’s – it seems little short of madness to me for anybody to want to entrust all the keys to their digital kingdom to a 3rd party somewhere on the internet, because not only is that a single point of failure for your own authentication but it’s an incredibly attractive target for hackers, knowing the potential payoffs of getting in would be great.
What about an offline password manager? KeePass is one highly regarded option in this area, and their website says: “you should use different passwords for each account. Because if you use only one password everywhere and someone gets this password you have a problem… A serious problem.” True enough. It goes on to say, “You can put all your passwords in one database, which is locked with one master key or a key file. So you only have to remember one single master password or select the key file to unlock the whole database.” So… just one password for everything? Isn’t that still “a serious problem”? To be fair, there is an added layer of security here in that at least this stage is being carried out on your own computer rather than across the internet, but now you’ve lost the benefit of being able to authenticate wherever you go. The tech-savvy can perform a variety of contortions using some permutation of USB keys and portable apps, encrypted password files in a DropBox or cloud storage, apps on their smartphone, etc., but this is all no good for the average user.
Of course, I’m glossing over another point, and that is that most users already have a single point of failure for their authentication – their email account. I can have completely random 15-character-long passwords that are unique across all my accounts, but all that is for nothing if someone gets access to my email account. They can then go to pretty much any site and choose the ‘reset my password’ option and pick a new one to gain instant access. Perhaps the moral of the story there then is just to make sure that your email password is unique, complex, and unguessable. Then pick as many different passwords for the rest of your accounts as you can remember.
The lax attitude towards security of typical users isn’t the problem – passwords are the problem. In real life we try to limit the number of different types of authentication a person needs to be able to produce and we try and make them simple to use. But computer security experts try to get us to create more and more types of authentication, and ask us to make them complicated, which is impractical.
Similarly, passwords themselves wouldn’t be anywhere near of a big issue if they weren’t getting leaked onto the internet in their tens of thousands due to poor security on the part of the companies. If companies do need to store your identity data then they need to do this properly. Expecting every programmer to be fully competent in security issues is a pipe-dream but at the very least companies should be compelled, perhaps by local law, to take reasonable steps to protect the important stuff. No hacker should be able to get away with anything better than a salted hash which is impractical to crack.
So what’s the alternative? One would be to make more use of authentication systems like OAuth or OpenID, which allow you to use a small number of authentication methods across a large number of sites, a bit like how a national identity card or a driver’s licence can be presented to many different service providers to prove your identity. This allows users to employ a few strong passwords and still have many accounts. It also means there are no confidential authentication details on most of the sites you use, so they have no passwords to leak no matter how poor their security.
Of course, the downside is that the auth providers again become a single point of failure – how do you keep someone out of your Google/Twitter/Facebook when they themselves are just protected by a password? Perhaps the answer there is to make auth providers require more than a password – a date of birth, a secret question, maybe even biometrics. Some laptops come with fingerprint readers now – is that going to get more practical? Maybe some other hardware-based approach like the World of Warcraft authenticator would be a start, as it seems to create one-time hashes that would be hard to spoof without possessing the device. Whichever methods were chosen, it would arguably be worth taking a significant hit to convenience for this initial login to your authentication provider if you know you don’t have to perform it for every site you log in to.
On the whole though I can’t claim to have a good answer here because I’m sure a competent security professional can point out flaws in the previous two paragraphs. And who is to say that Google or any other major authentication provider will do a better job than LastPass at keeping your data hidden? But I will stick by my assertion that exhorting users to use a variety of complex passwords is – except in the case of their email account – a pointless and counterproductive measure.
Related Posts:
The importance of abstraction
by Ben on May.24, 2011, under design
(Long time, no post. I could start by explaining and making excuses, but no – let’s get down to business.)
From the late 90s to the present day, many commercial games have been focused on some sort of realism – graphical photorealism, real-world physics, etc. Certainly when you look at the man-hours spent on most game software you’ll see far more of it invested in features that further the simulation aspects: eg. the creation of life-like environments and characters, and life-like movement of the characters through that environment. The game is almost a token gesture on top, usually just a set of simple goals with a basic scoring system to provide some sort of obvious incentive to chase those goals.
Gamification is a common buzzword these days, typically referring to how businesses can benefit from making interactions with their products more game-like, and so they have looked to the games industry for pointers on this. The interesting thing is that the assumption has been that this would be about seeing how games are made and then extracting game-like properties from them, but in fact it might be more accurate to say that what we call games developers have really just been ‘gamifying’ themselves in the first place: rather than making games with simulation aspects, they are often in the business of writing simulations with a healthy dose of gamification.
We know that a ‘game’ does not have to involve simulation at all – there are plenty of definitions on Wikipedia, each differing, but none implying that a game intrinsically has to model the real or a fictitious world in any way. So why has the games industry adopted this position of writing playable simulations? I think there are a mixture of reasons for this, some good, some bad. I’ll return to the good reasons in a future blog entry, but for now I’m more interested in the bad reasons, which I feel have taken precedence and given us an entire industry of games that aren’t really games any more.
Firstly, many players – and, it would seem, game publishers and some developers – seem to feel that a game can’t be enjoyed unless it reaches some sort of contemporary presentational standard. To many people, good graphics makes a good game. To be fair, a lot of players do have trouble enjoying older games and some modern independent games because they find the graphics primitive and distracting. But I would argue this is mostly cultural: we’ve been sold the mantra of “better looking games are better games” because it helps sell new hardware and software, and I think in part we’ve bought that line because there is a truth to it – newer games do play better, for most people. But this is arguably because improvements in game design have run in parallel with improvements in game technology, and we mistake correlation for causation. The design improvements we’ve seen over the years can apply equally or more so to games that don’t look as realistic as many modern ones do, and thankfully some indie developers are showing us just that.
There’s also an argument regarding the interface, that worse graphics make a game’s visuals harder to understand, and to a degree that does hold true, but it’s hard to argue that even games 15 years old looked so bad that you couldn’t adequately work out what was going on. Children can enjoy blocky graphics and unrealistic iconic representations so I don’t find the interface argument compelling.
Secondly, I think many developers actively want to make things more real. Partly this is because game development is often driven by programmers who are interested primarily in technology and who like to push that technology in new ways. Perhaps the majority of coders I’ve known fall at one extreme or other of an interesting dichotomy – they either want to write interesting features themselves from the bottom up, or they want to play with 3rd party software and libraries to implement those features quickly. But either way they are playing their own ‘development game’ which is more about the technology’s intrinsic properties and not so much about what the technology is to be used for. Programmers get bogged down in optimising code that already runs fast enough or switching to a new and shinier 3D engine because those challenges are often more interesting to them than shipping a finished game. Perhaps that’s why they’re programmers and not managers!
However I think the other side of the coin is that most programmers – and, I would sadly argue, designers too – don’t really know how to improve the abstract thing that is ‘game play’. There are many who’d love to create better stories, emotions, AI, and so on, but don’t have the knowledge or skills to do so, which means they resort to making the improvements in areas they do understand. You can throw more polygons at a 3D mesh to make it look better, but you can’t just throw more materials at a rock/paper/scissors conflict model and expect to magically have a better game. You can make a game run more smoothly or make it more colourful-looking or write one of those amazing everything-is-brown-or-grey-so-it-must-be-a-gritty-game shaders because these are techniques we know about (and saw at SIGGRAPH 15 years ago), but there isn’t much resembling a science for designing the abstract game features, or at least not one that is well-known and accepted. Even some of the better-known designers such as Daniel Cook and Raph Koster seem to consider their work to be more about casting an enlightened eye over trial-and-error, relying on play-testers to tell them what is fun. While nobody would seriously argue that you don’t need some sort of play-testing – just like graphics programming requires the programmer to actually look at what is being rendered – it seems a bit defeatist to assume that it’s not theoretically possible for a knowledgeable enough designer to be able to create a compelling game experience without needing to have others try it first. In particular I can’t agree with the suggestion that emotions, experiences, and personality in games “cannot be systematically engineered no matter how many design articles anyone reads“. I can’t imagine making such a claim about film, or books. It seems even more invalid for games, where the player is a participant: so if we’re not there yet, we just have more work to do, more knowledge to acquire.
I think we can get back on the right path to that by returning to those older and purer games, the ones from decades ago that delivered interesting gameplay to us long before they could attempt to deliver a world that looked like our own, when all the graphics and sounds were necessarily iconic and symbolic. Rather than trying to look and act like real life, they attempted to capture the essence of what games had previously been – sets of abstract rules, represented somewhat arbitrarily, but in such a way that they could be played with. Chess, poker, soccer, Scrabble, all involve real humans in the real world but who are acting on artificial tokens and according to artificial rules. The contests may be played out physically or mentally, numerically, linguistically, or spatially, but essentially they’re all abstract.
This should immediately show us that moving away from simulation is not just about picking a different aesthetic for your game’s visuals as a replacement for photorealism, but about realising that a game does not have to attempt to directly model or simulate any aspect of real or imagined life to be an enjoyable activity. It should instead be sufficient to create some representation of it that lends itself readily to interesting play. Minecraft’s world of blocks is not just a graphical simplification, nor even just an aesthetic choice, but is an abstract representation of the world, simplified to make it easier to reason about and to build with.
We can go further, and say that this creative use of abstraction isn’t limited to symbolising the physics of the world (where physics in this context includes the visible and audible aspects), but can symbolise the interactions within it – the narratives, the emotions, the events. For example, look at combat in a game like Oblivion, where the game simulates a continuous 3D space in which fighting and exploring are seamlessly interwoven, just as in real life. Unfortunately, the limitations of the artificial intelligence means that most fights can be won simply by jumping onto a ledge and shooting your hapless assailant from above. Compare this with the approach taken in the Final Fantasy series (or, of course, any number of traditional CRPGs and JRPGs) which switch to an explicit combat mode, mostly isolated from the main world, with completely different actions and constraints to create a more compelling tactical experience. The part of me that loves exploring an open and consistent world much prefers the former, but there’s no denying that the gameplay is simply better in the latter. Oblivion prioritised the simulation over the game, meaning the simulation flaws become game flaws, revealing the ‘uncanny valley’ in interactive form. Final Fantasy tells you that combat in this world is resolved in a separate space, and once you accept that, you can enjoy the rest of the game undistracted. In such a way, the more abstract form can paradoxically be the more immersive one, because it immediately tells you to engage in suspension of disbelief. You enter the experience already accepting the unrealistic elements – a realism ‘sunk cost’ of sorts – and thus they don’t detract from the game.
Similarly, when a similar phenomenon to the Oblivion problem occurs in Minecraft, eg. a monster being stuck below you while you shoot it, the experience seems less jarring. Minecraft doesn’t try as hard to pretend that it’s a real world and so your immersion isn’t as readily broken by such a problem. Embracing abstraction buys you that extra suspension of disbelief. No-one minds that Chess queens are more powerful than history would suggest. And nobody complains that Monopoly is unrealistic because of the lack of cities built in a square ring.
Combat encounters are just one example. While Oblivion’s fighting attempts to be simulatory, its conversation mini-game is purely abstract and could have worked well had more effort been put into it. Research in RTS and 4X games is often handled with a very abstract interface, for reasons of necessity, but there is surely scope for interesting choices to be made at that level. And obviously some games are almost entirely based on abstract models, such as turn-based strategy games such as Civilization or management games like Transport Tycoon or Football Manager. On the surface they are still simulating something, but in simplified and discrete terms that can be easily reasoned about, both for the designer and for the player.
Other art forms, possibly because they have intrinsic limitations that can’t be solved with better hardware, have long since stopped worrying about trying to make the media more realistic. Painters and sculptors happily create works that are symbolic representations or even caricatures of what they are depicting, rather than just trying to be scale models. Writers commit entire stories to ink printed upon thin slices of wood without worrying that the reader can only possibly enjoy this story if they see it visually and audibly, because we know readers can see beyond the fact that they’re staring at text and allow their imaginations to create the world for them. Are game players not capable of that? Or perhaps we as game developers just don’t have as much respect for our players as other artists have for their audience?
For too long computer games have tried to be interactive films, acting as if we have to simulate some sort of realistic space in order for the game to be fun. I’d argue it’s time to get back in touch with the origins of games and embrace the make-believe and abstract aspects that embody what is unique to games, the ability to play with a set of rules and explore the interactions between them. By weaning players off the ‘playable Hollywood’ model and back onto a purer sense of ‘computerised games’ we can both broaden the appeal of games and garner more respect for the medium.
Related Posts:
by Ben on May.02, 2010, under Uncategorized
(Reposted from my other journal, with minor edits.)
I play a lot of Football Manager 2005. On this game I bought a lesser-known player from Norway whose position is marked as a “Defender/Forward Left/Centre/Right”. So he seemed adaptable, but I never got good results, no matter where I played him on the pitch, so I turned to Google to get more information – maybe other FM2005 players had an idea, or maybe I could find news reports telling me what position he plays in real life.
Instead, the first search result I get back is his Facebook profile. He has 679 friends, is single, and is a fan of Eric Cantona, the English Premier League, and, er, Tattoos and Piercings. What is the world coming to? Maybe Facebook is too important these days, with things such as these new ‘Like’ buttons popping up on completely unrelated sites, gathering your personal information and selling it to advertisers and so on. I’m not usually the kind of person to worry a lot about privacy concerns, but this could get a bit much.
This article by Raph Koster says it all really: ‘Facebook will become your ID card for reality’. “You will swipe your Credits card to buy your movie ticket using some credits you earned with the loyalty program in Farmville, and swipe it again to get into the theater. You watch the movie, which helpfully tells all your friends where you are and what you are doing.”
Whether all that comes to pass or not, with Facebook becoming so ubiquitous that everybody is on there (including lower league Norwegian footballers), could we be entering an age where Facebook games are what people think of when you mention computer games to them? Could we already be at that point? There are probably more people playing Facebook games than other computer games, but I don’t know if they would equate the two. Perhaps the age of specialised hardware for games is going to come to a gradual end, as web technologies start to close the gap on the standalone graphics APIs, with the benefit of a much larger audience waiting to play games in the browser.
Related Posts:
Understanding what facilitates meaningful strategy in games
by Ben on Mar.10, 2010, under Uncategorized
Often we invent games by taking an existing game that works and adding a twist to it, or changing some aspect of its behaviour or theme to something different. But how would we create a game from nothing, without using an existing game as a framework? In particular, how do we make the game complex enough that it’s not trivially ‘solved’? (Set aside any game where the physical skill aspect is a significant component, or games with few or no choices where strategy is typically not intended to be a factor such as Candyland or Snakes and Ladders.) I find this a very difficult problem, but to make a start on it requires some appreciation of what makes a game interestingly complex in the first place, and the tools we typically use to create this complexity.
Generally it would seem that most games we play can be described using the extensive form notation from game theory. It’s not as intuitive a representation for individual or simultaneous decisions as normal form notation is, but extensive form captures the important notion of each move opening up a new game state and new possibilities. For example, in Chess there is a single starting state, but that branches out to 20 possible successor states, and from there, the tree branches further to 400 states, and so on. I would suggest that the complexity of the game in terms of how easy it is to ‘solve’ it or to come up with the best strategy is closely correlated with a player’s ability to understand this abstract tree of game states. If “a game is a series of interesting choices” as Sid Meier has said, it’s the player’s ability to understand the ramifications of those choices that matter, which is to say that they need to be able to predict to a certain degree the effect that they will have on the tree of game states. If the choices are too easy to make, they’re not interesting, and if you can’t see that some choices are clearly better than others, again it is uninteresting.
With that in mind, it seems that we embody this essential complexity in our games in a small number of ways:
- A combinatorial explosion of discrete state spaces. As noted above, the game state tree for Chess has 400 possible positions on turn 2, and a branching factor of of about 35 on average for successive moves, making an exhaustive study of the possibilities impractical. Therefore you have to plan more generally, making an estimate of which moves are good and which ones are bad and deciding which part of the tree to look at and which ones not to. The high branching factor means that even Chess computers need to do this via something like alpha-beta pruning. A common way in which we can create this large number of possible states while keeping the game easy to understand is to use an abstract game board, as in Chess. A 2D grid gives you an easier way to describe and reason about the state changes while keeping the quantity of options high. Compare the rule “Rooks can move vertically or horizontally as many squares as you want without jumping over another piece” with “A rook at position 1 can move to positions 2, 3, 4, 5, 6, 7, 8, 9, 17, 25, 33, 41, 49, 57. However it cannot move to position 3 if position 2 is occupied, nor position 4 if positions 2 or 3 are occupied, nor… (etc)” Being able to bring prior knowledge of Cartesian coordinates and the notion of adjacency and straight lines helps simplify many possible state transitions into a much simpler rule.
- Hidden information. Typically this takes the form of a player’s hand of cards, or the fog-of-war in a real time strategy game, or even the act of forcing players to move simultaneously and thus having to estimate what the other person will do. This doesn’t make the state tree branch out any further, but it does make it much harder for a player to know which branches can be safely ignored. Compare the choice to leave your Queen under attack by a Pawn in Chess against advancing one of your middle-ranked pieces into enemy territory in Stratego. In Chess you will almost always benefit from taking a Queen with a pawn unless moving the pawn puts you at risk, which is quite easy to check for, so it’s reasonable to assume that is the move you should examine first and in most detail, making the decision quite easy. In Stratego however you simply don’t know whether it’s worth attacking that piece unless you have managed to build up some information about it, so you will need to consider all your other potential moves in roughly equal detail.
- Random factors. Randomness is like adding a 3rd player to the mix – whereas you can predict the actions of the 2nd player (your opponent) as he will always make the best move that he can given the limits of his capabilities, the 3rd player (luck) will play unpredictably, increasing the number of possibilities you must consider, in a similar way to the hidden information above. Indeed, randomness is really just a subset of hidden information, but it’s worth drawing a distinction between the two because hidden information can be potentially knowable whereas random factors cannot. (Though keep in mind the middle ground, eg. of a shuffled deck of cards – towards the end of the game it becomes more deterministic.) Some people disparage random factors as bringing ‘luck’ into the game but really it’s just about risk management. For example, Civilization would be a much less interesting game if you knew that your Phalanx unit would always defeat an attacking Militia unit. Instead you have to balance the probabilities out. You have 66% chance of beating one, 44% of beating two in a row, 30% of beating three, so how many Phalanxes do you need to defend against 3 or 4 Barbarians, given that it’s mathematically impossible to mount a perfect defence? This poses an interesting dilemma for players which again forces them to consider a wider range of options as there is no obvious solution. Greg Costikyan has a great presentation here which shows the different benefits a random factor can bring to a game and it’s well worth a read.
- Continuous state space. Games that utilise physics engines and real-world simulations exploit this to create a wide range of possible situations from a simple set of mechanics. Arguably this is the most popular method used by games today to introduce elements of strategy and tactics to what are otherwise computer-based sports relying on reflexes. It is similar to the Chess rule system in that people have an inherent basic knowledge of geographical space and direction and indeed the laws of physics which they can bring to the game to help them reason about it. Yet the continuous and almost infinite domain in which entities can move makes predicting the exact results a difficult endeavour requiring skill and expertise. You can point a gun in an FPS in an infinite number of different directions, and can stand in an almost infinite number of positions when you do it, and the best combination of these two factors at any one time depends on your opponents (and maybe your team mates) who are constantly moving within that continuous space, as well as your understanding of the implications of the relative positions and orientations. These considerations may not immediately seem relevant to the typical turn-based strategy game, but they are – the same positioning and aiming mechanics, albeit on a simpler scale, exist in games like Scorched Earth or Worms, for example. You obviously no longer have a simple tree of discrete game states here, but from the near-infinite set of possibilities you have to mentally build your own game tree, and select your tactics based on that. When you examine a continuous domain you can pick out discrete areas within it which you can reason about – for example, in FPS games you might mentally divide the area up into rooms, areas in cover vs. areas in the open, paths between weapons or power-ups, and so on. Then you plot a route from one point of interest to another and also use such points of interest when deciding how to maximise your ability to attack someone and minimise their ability to attack you.
The end result of all these approaches is that instead of calculating the whole game tree in your head and calculating the correct flow through it, you have to look for patterns and use those to guide your judgement. Your basic skill at the game is essentially your knowledge of the game’s patterns, and the depth of the game is proportional to how hard it makes it for you to understand the full game state tree.
But there’s an interesting meta-game here too, because since you know it’s impossible to know the whole game tree, you know that your opponent is in the same position, and must therefore also be formulating his own patterns to judge the game and formulate his move. This means it’s worth trying to guess your player’s patterns also, and often that is of more use than to attempt (usually in vain) to find the optimal approach – after all, in any one situation you only have to do enough to beat your opponent, not to beat all possible opponents that could exist. (“Remember, when you and a halfling are being chased by a hungry dragon, you don’t need to outrun the dragon…”)
Related Posts:
Crossover games and explaining them to the audience
by Ben on Dec.02, 2009, under Uncategorized
This post is long overdue, for which I apologise. I hope to resume a more regular service before the year is out!
There’s a post on Penny Arcade from a few weeks back which is complaining that a certain game Brütal Legend seems to masquerade as one type of game (ie. a Real Time Strategy game) while actually being something else (a third person action-RPG). The tone of the article is that games shouldn’t be mixing one type of gameplay with another, and the main complaint is that players have expectations of a game playing a certain way.
Personally, I feel this is a false problem caused by narrow-minded reviewers and fans. Games won’t get taken seriously until it’s accepted by both groups that they don’t exist merely to fit into pre-existing categories – although they certainly can choose to do so – but are individual creations and should be judged as such. There’s nothing wrong with genres as descriptive labels, as they carry a lot of useful semantics. What’s wrong is when they move from being descriptive to prescriptive.
Nobody complains that a film’s exact genre wasn’t explicitly specified before you watch it. Crossovers and variations are par for the course and often encouraged. Film reviewing and criticism moved past this single-genre categorisation long ago and a film’s entry on IMDB typically lists several genres for each individual film, reflecting the way in which different aspects are combined into each whole. Games should surely be seen in the same way.
Tycho at Penny Arcade should really know better and I am disappointed at his attitude, wanting to classify games as Either This Or That and not wanting people to experiment with crossover. Imagine if we’d thought that way 15 years ago. To paraphrase his quote towards the end of the article, “I love action games, but I don’t want to play an action game while I’m playing an strategy game”. Bye bye to the entire RTS genre then! Luckily, some people at the time noticed that although the strategy aspect did suffer a little, you gained something from the urgency of the action. And thus a new approach was born. Mixing a bit of this with a bit of that is how biology has improved species for millennia.
It’s arguable that in this case the tutorial doesn’t educate the player adequately and therefore gamers fall back to genre stereotypes, coming undone when they hit the boundaries of the metaphor. But it’s nobody’s job to explain a game in terms of other games or existing genres. If all games are to be presented and judged that way then we’re in for a boring future bereft of creativity where games can only borrow from within their genre to ‘innovate’ (if such a word could be said to apply). Cross-pollination between genres would seem to be frowned upon and God help those who might actually come up with a completely new game type. I don’t think that’s the future we want to see.
Related Posts:
Code archaeology
by Ben on Sep.23, 2009, under programming
Something interesting happened today. For a couple of years, myself and colleagues had mulled over a certain ‘killer feature’ that we wished our networking layer had, as it would have made our time implementing gameplay features much easier. Today, while doing some long awaited R+D work on said layer, I found that feature. The sheer size of the codebase meant that what we’d wanted for years had lain dormant and undiscovered all that time.
In actual fact, its only call site was commented out with a note saying that it was too slow to use in practice, but I have a feeling that it could have been easily optimised and saved us man-months of work.
Why hadn’t we found this before? Well, it’s a very large code-base and most of the people who originally developed it are long gone. Unfortunately there was obviously not much time for or interest in documentation back when it was written, and we’re too busy making actual games to be able to invest time in checking all these low level components which already work.
I see a couple of lessons in this:
- Enforce documentation as company/team policy. When the brains behind the code are no longer at the company, that’s when you need documentation to replace that lost knowledge. Unfortunately it’s too late to write it then. Designate a proportion of a coder’s time to documenting their code, so that an equal or greater proportion of some future coder’s time can be saved. (Failure to do this also results in scheduling problems, where some future coder is expected to perform a task as quickly as the original coder did, despite lacking the insight into the code that the first person benefited from.) I know it’s hard to sell documentation time to a publisher or whoever, but I’m sure that many projects lose more time from problems that arise when coders don’t fully understand the code that they’re working with.
- Write less code. Sometimes, documentation just isn’t going to happen, or is inadequate, or whatever. One way to mitigate this is to write fewer lines of code. The fewer lines of code you have, the less likely it is that there are large areas of the codebase that nobody looks at or understands. It also brings reliability benefits – if you halve the number of lines in your code base, it stands to reason that each file, function, and line gets read twice as often on average, and double the eyes means more of the bugs get spotted. Cutting the lines of code may not be easy to do, but most codebases have some duplication they can lose. In C++ templates and polymorphism can do a lot for you here if you think ahead rather than resorting to copy and paste. If you’re lucky enough to move to a higher level language then you get this benefit for free, since most are far more concise than the equivalent C or C++.
There are interesting implications for team size, too. To reduce the risk from lost code knowledge, you ideally want a lot of coders, and to rotate them round several subject areas. This way, knowledge is spread out redundantly and the loss of any one coder should not impact the general understanding of the system. On the other hand, large teams start to incur prohibitive communication costs, where documenting and explaining your modules can end up taking longer than creating them. And rotating people around areas of the code tends to reduce code quality, both through making people less concerned about defects in their code (since they may never have to touch it again), and through not being able to become an expert in a certain area.
You need enough programmers to be able to develop the required system in the timescale available, but too many and you’re going to have dark corners of your code base that few will understand and they can actually cost you time. It may be that there is an optimal number of programmers that can work on any given software project. Does it vary according to the programming language in use? Or maybe according to the type of software being developed?
