Category Archives: Quick Reads

LoLCG public preview


It’s been six months since the LoLCG project kicked off, a pretty intense six months at that. We’ve gone through several major incarnations since then and it’s time to show the working a bit. I’m releasing the first playable preview of the game today as a celebration of six months for us, the World Championships and the end of Season 3 for all. Looking for something to do while LCS is off the air and you await the upcoming preseason changes with anticipation? Look no further- you can try the LoLCG today!

Right here, right now! 

I admit I’m a little scared to put this thing out. It’s been a lot of work and what you see here is only a tiny part of it. It’s also fresh off the presses- we haven’t tested this little preview set at all, so in a sense it’s a bit of a test in itself. Will it be understandable? Will it be cool? Most of all, will it be fun? Those are questions only you can answer, so be our guest and try it out.

I’d like to thank both the LoLCG testing group and Riot themselves for their incredible assistance in keeping this thing trucking along- almost any other company I know would probably have C&D’ed this project, but as far as I can tell Riot actively altered their policies to allow it- and other fan projects like it- to happen. They are, in the most genuine of senses, champions.

As always, I welcome your feedback in whatever form it comes- the best way is through the project email at There’s a lot of work still to do, there probably won’t be a real release until sometime next year, but I hope this whets the collective appetite.


The Prototyper’s Dilemma

I’ve been rather quiet of late, mostly because I’ve had quite a bit of design stuff going on. Not only is the LoLCG project now worthy of the title- a project of more than one- but the prototypes for Wild Abyss arrived and getting both sleeved, sorted and played has been taking up pretty much all of my time.

There are other things in the works, too, but I’ll leave those for later. I have the next part of the ERI framework series about half done as well as a bit of writing on bioshock: infinite, but I think the latter has been done to death so it probably won’t see the light of day.

In the meantime, I’d like to talk about a particular issue I run into as a developer, that might be interesting for other people interested in taking their design a bit more seriously. It has to do with that most terrifying of processes, playtesting. I’m also going to use the opportunity to show off some of the goodies I’ve been working on that have been keeping me quiet.



In any game design, it’s important that you go beyond the people you are familiar with for testing purposes. Whether that’s your inhouse studio folks for an indie developer or a regular gaming group, these people will be familiar with you, your style and idiosyncrasies. They’re good for providing people against whom the most basic of tests can be performed, but beyond that any data you get from testing with them is likely to be inaccurate compared to how the game may perform in the market.

So you need to go about finding independent playtesters. If, like me, creating a commercial NDA and paid testing environment is impossible, that means finding volunteers from outside your normal circles.

This is where the prototyper’s dilemma strikes. In a perfect world, you could post your paper-slip prototypes and nascent ideas on the internet and get a bunch of enthusiastic, capable playtesters interested in a moment. In reality things are a little more difficult. Back when I was 14, I spent around 3 years prototyping and developing a warhammer army book. I wanted to make sure this thing was balanced and interesting, so I tried to organise playtesting. That experience taught me more about game development than all my university education put together. If you want to get tests done, you need to present your testers with a product that isn’t entirely dissimilar to the quality of commercial product they are used to… or at least one that looks like it. You need to get them to buy into what you’re doing through giving them a clear indication of just how serious you’re taking this. Hand scrawled notes on notepad paper do not do this.

One of the reasons the LoLCG looks so spectacular is because of those lessons I learned. You cannot get good, unbiased testing happening without that level of production pre-invested in your designs. Enthusiasm will fizzle, tests will be delayed, people will drift away and you will lose momentum or end up getting frustrated and making decisions based on insufficient data. To keep people attached to the project, you have to give them something that, even if it doesn’t play that well, looks and feels like it should.

The dilemma, however, is that a playtester coming in from the cold, especially one with little experience of the development process, will look at yourdesigns and assume that’s the best you can do, that your first prototypes are the equivalent of a videogame public beta, when in reality the guts of the game are about as polished as a rotten stick in a peatbog. This in itself creates expectations and dissappointments- I’ve found people tend to overlook the visual design of the LoLCG cards in order to focus on the text because they feel the text is more important.

While in the long run, that is true, the text of cards and the precise wordings are the last thing that needs polishing during the card design process. First the parameters under which those wordings must be constructed must be established- how much space do we have, what symbols are available, how many can we use before the cognitive burden becomes to high. There needs to be text there for the testing to actually be valid, but the balance of these texts is by nature rough and ready until it can be established what the restrictions under which a polished version must be constructed are.

Unfortunately, the sort of people likely to volunteer for playtesting are the sort likely to fixate on these sorts of discrepancies and thus you end up distracting your testers from simply playing the game in a relaxed, open state where you can get good information on how the areas you want to isolate are working out. Add on the natural focuses of the various kinds of players, whether you use Bartle’s suits metaphor or Mark Rosewater’s timmy, johnny and spike etc, and life is hard.

So this is the Prototyper’s Dilemma: Without achieving superficial similarity to a finished product, you will not be able to attract and retain testers. The more effort you spend in that regard, however, the more your testers will have unnatural reactions to the parts of the material that most need testing.


I’ve discovered that it’s not as simple as simply getting your game to the tabletop or screen as soon as possible, nor is it about polishing like a madman before doing any testing. Like many things in game design, there is an elegant balance to be struck between conveying the identity and overall mechanisms of your game effectively and not jarring your testers into over-analyzing things.

I should note that the impact of this is largely dependent on just how hardcore you take your design. For games like LoLCG and Wild Abyss, everything matters- colour choices, fonts, layouts, grammar, amount of cards, visibility, even the size of a playset.

This might not seem important, but it IS. If I want people to be able to realistically play a game, having a set of cards that will fit neatly into a schoolbag or a hoodie pocket or similar is the sort of thing I take into account
very early in the process. Isolating and testing these kind of dynamics is really important to getting the desired experience for a player. Tweaking and perfecting mechanics are the last priority, not the first.

So, how to resolve this? Unfortunately, the point of a dilemma- in fact the very meaning of the word- is that there is no simple solution. Luckily, unlike the famous Prisoner’s Dilemma, this one isn’t exactly binary in its solution space. For Wild Abyss, I’ve taken what I learned from earlier games and attempted to create a prototype which strikes that balance. The visual designs are colorful at a distance but minimalistic and simply executed.


The result is a game that looks impressive but only took me around 30 hours to prototype from start to finish- less than a week’s work in the evenings. This whole game went from initial concept to first prototype in 16 days

While polished, this is clearly a first prototype- not least because it’s written all over the thing. The ship designs are just too far on the clumsy side to be finalized, the resource card designs are clean and generic etc. I’ve had a good reaction from my playtesters for this game- they’re happy to just play it, and aren’t overly inclined to focus on technicalities. The result is after only a few games I’m getting a lot of good information on where I need to make changes, and after the twenty or thirty more I want to get done with this first prototype set I should be able to make some really significant choices that will benefit the game based on solid, unbiased information.


LoLCG begins

So, I finally got enough proofing and polishing done to print my test set for the LolCG. The very first cards, hot off the presses.

After about six hours of sitting at a table that looked like this:



The LoLCG finally went on her maiden voyage!

Courtesy of Master Summoners Pachi and Mike





This is one of the most joyous culminations in the cycle of design and development, seeing your baby hit the table or the screen in a serious game for the first time. Pachi tried a strong jungle deck, but forgot to draft any good jungling champs, while Mike played my more conservative summoner spell heavy engagement deck.  At the end, Mike came out on top, but it was a close run thing. The game MVP was Warwick, healing himself through Singed’s poison clouds to build a solid lead and a strong point from which Mike could leverage his offensive.

All in all it was a promising start. Note that we’re still recruiting stage 1 testers for another few days, so if you want to get your hands on these early and are willing and able to do glados proud, sign on up!



LoLCG is ready for testing!




If you’re interested and you find this post, please share it through twitter/FB/tumblr/forums, however you like. The more interest we get, the better the game will be! Autosharing links are available if you click on the post title.




Introducing Wild Abyss


I’ve had to pause the development of LoLCG for a little while so I can work out any remaining niggles with Riot (don’t worry, things are going fine there), so I’ve had a few weeks between when I hit what I felt was the most I could do safely on that project and now. In the intervening time, I’ve had a shot a whole new game, this time entirely of my own design and style. I’m using a lot of what I learned doing the LoLCG project both in terms of gameplay mechanics and technical development skills.

The result is looking pretty swell for a first prototype. Not as swell as the LoLCG, but I’m drawing all my own art here (well, the non background stuff anyway)

Wild Abyss

I’ve loved and adored civilization and epic strategy type games, ‘4x’ especially, since I played civ 1 when I was very young. Risk was the only real boardgame of that kind of scope back then, and while fun it wasn’t that great. Since then there’s been a determined attempt to bring 4x to the tabletop, from the sprawling Twilight Imperium to the sleek 7 wonders. Unfortunately, the pendulum swings one way or the other too much. From intense complexity, endless rules and hundreds of pieces, to elegant simplicity that loses much of the depth an narrative that the 4x is so good at conveying.

Wild Abyss is a space-based 4x game with an emphasis on resource allocation and combat rather than territory control, negotiations and maneuver. It’s almost entirely card based, with no star map or persistent board, meaning it doesn’t need a lot of space. Turns are largely simultaneous, so games with loads of players don’t take much longer than ones with only a few. It has a combat system that’s not much more complex than games like eclipse or TI, but offers a lot more in terms of both tactical and cinematic depth.

I’m looking forward to talking about it more in the coming weeks. I’ve kept a kind of stream of consciousness diary of the process which I’ll put up once I can edit into something that makes vague sense.


On toxicity

The word ‘toxic’ appears to have gone viral, at least in the competitive games community. It’s unsurprising, really, as it provides a lovely, pithy way of describing a certain kind of player or even person, to their backs at any rate.

As far as I can tell, Riot coined the term for PR purposes, as a way of defining the typical player who is not… socially considerate when talking to their community. In that role, it’s a fantastic tool, highly expressive and intuitive as to what it means. Of course, so are the words ‘fun’ and ‘game’ and don’t we all know the trouble that’s got us into, eh?

As much as I love Riot, this is one thing I can find serious issue with in their MO. It appears the company has collectively drunk the koolaid of believing that this PR jargon they made up is an actual thing, not just a neat way of describing a stupidly complex phenomenon. What’s made worse is that every definition of toxicity I’ve seen from them is different but for one fact: they all have a negative impact on consumer retention. We can fluff that up and call it damaging game experience and so on, but when it boils down to it, this is not about game design any more. It’s about audience selection and making wads of cash money. This isn’t inherently evil, of course, but it’s certainly not unambiguously good either.


So let’s get this straight. There is no such thing as a ‘toxic player’, at least not in the sense of actual flesh and blood players. It’s alright to use the term in pure hypotheticals and label a certain kind of action group toxic and consequently a hypothetical player who embodies that group a toxic player, but that’s not how the real world works, folks.

The worst outcome of this misuse is that people, actual people, are diagnosing themselves as toxic in fits of hypochondriac glee. Unsurprising given the peculiarly western tendency to syndromise any kind of problem, but distressing none the less. Personally, I am terrified of this development. There is no kind of psychological treatment in which repressing and punishing antisocial urges has anything but a styming effect on personal development and enjoyment for the individual being targeted.

Now I hear toxic being bandied around on unrelated podcasts, in design articles, interviews with devs, even potential research briefs. It’s a catchy, catchall meme. It’s also a delicious label to stick to someone you don’t like, a perfect tool to brand ‘the other’. It’s one of those inconspicuous little words that can worm its way into the consciousness of a populace and create divisions, excuses for unethical behavior and justifications for the unjustifiable. The sort of word that is one of many engraved in each paving stone on the road to hell.

Toxic, put simply, is toxic.


I stress that I’m certainly not saying that there’s no such thing as a player whose play is detrimental to the fun of other players, nor that a developer shouldn’t talk about this or even design things to prevent or mitigate that. Riot, for the most part, is doing the right thing- implementing systems in their game which gently encourage players to play in a way that is tolerable to other players. The problem is mostly in the discussion and the misappropriation of the term.

The most dangerous result of this is the idea that a certain kind of play is inherently ‘wrong’. This is… it’s just plain disturbing. Play, at its core, is a process of experimentation and discovery. Play exists to push boundaries and explore what is normally not acceptable in ‘real life’. It also serves to train and develop, to instill contentment or joy and create wonder. Fundamentally, though, human beings, in fact all animals which play, play in order to do what would otherwise not be possible. To enforce a moral rhetoric upon this is almost always damaging to the player, because that concept is antithetical to the core purpose of play.

I’m not talking about something that’s nice and fluffy here. As much as the activity of play can be about exploring love and trust it is also about exploring betrayal and anger. It’s a careful balancing act, but one that is fundamentally necessary for human mental health and self development. In the end all those people calling you a noob faggot have a largely positive outcome on you as a human being, hard to believe as that may be at the time. What it doesn’t help is the developer’s profits, because you’ll probably drop the first few games where you’re exposed to that sort of antagonistic play. When these two collide we arrive at the problematic concept of toxicity. The utopian idea that all players can live in harmony and sing around the campfire at night. Like all utopian concepts it is enticing, dangerous and utterly wrong.


If I hold this to be true, I also have to hold that it is reasonable to create exclusive communities of play, where entry requires certain rules to be accepted and adhered to by all players, that is after all the essence of a game. The important distinction between a ‘toxic’ player and one who infiltrates such a community and then breaks the rules is that the latter is simply a rulebreaker, and can be expelled as such. A toxic player, on the other hand, implies someone whose play, while acceptable within the rules, is filthy and unclean. There is a double standard there- you’re welcome to come and play however you like, but good players only play like this. If you don’t, you’re a bad player and everyone is allowed to judge you.

That’s a far cry from a simple, professional: These are the rules, to maintain the game as it is intended to be played, the rules must be adhered to. If you don’t, you’ll be removed from the game. No hard feelings, that’s just how it has to work. If it’s in the rules, the players are free to exploit it however they so choose. The responsible party for toxic outcomes is not the player, it is the designer.

So I simply ask that we should be careful with the word. It’s not entirely without merit, but it’s powerful and dangerous. It shouldn’t be thrown around to label everyone and their kid brother. Nor should it be used in formal discussion unless clearly and meticulously defined and justified.


As a kind of postscript, I will say that Riot seems these days to have shifted their attention from toxic players to toxic environments. Unfortunately, the earlier discussions have created the implicit assumption that the former creates the latter, where Lyte’s recent analysis at the GDC shows that is clearly not the case. I applaud them for bringing that salient little fact to our collective notice. Notice it.


Design Theory: Deconstructing Iteration

Iteration is one of the most fundamental practices in the videogame industry. It’s the core around which every major company and almost all the minor ones structure their development. It’s a powerful, reliable tool. It’s also a problem. Like many methodologies that arise in industry, developers adopt the model without critical analysis of where it is best used and where its flaws are. The result is that the universal adoption of iterative process has perhaps done harm as well as good.

For new readers, I adopt a somewhat… adversarial style. I think that the more valuable and awesome something is, the harder you should try and identify the problems with it. So take the pithy negativity with a grain of salt, I’m trying to make you look at something harder than you otherwise might



Iteration is the process of developing a product through incremental adjustment. A product is developed and then tested. Based upon feedback and impressions of the tested product, it is adjusted towards a more desirable state, tested again and so on. The operative words here are adjustment, feedback, impressions and desirable.

Adjustment: Iteration has difficulty changing or reversing directions sharply and nimbly. Once locked into iteration, it’s hard to change broad strokes.

Feedback: Iteration depends upon testing, which means that the more iterative a process, the more bumpy the flow of asset development must be.

Impressions: A given iteration rarely has the luxury of undergoing deep analysis. Adjustments are more often made based upon shallow impressions due to limited time.

Desirable: to iterate towards a desired state, that desired state must be known. The more detail about the desired state is known, the more powerfully and effectively iteration can be directed.




So iteration is fundamentally a polishing tool. It doesn’t reliably create great gameplay from nothing- it just takes what you have and smooths things out. It’s interestingly similar to genetic development* where occasionally some tweak that comes out of the iterative process proves so wildly successful it becomes a genre defining mechanic. Over a whole group of such projects, each adopting the iterative discoveries of their neighbors, you arrive at a kind of progress that is fundamentally quite random, but in practice slowly pushes towards the desired state.

The complications of this model are again similar to those with genetic development. It can’t really make any revolutionary changes, because it must develop in incremental steps from existing templates. A fundamentally flawed template will remain fundamentally flawed no matter how much it is iterated upon and any serious change in direction will require some messy improvisation based upon the existing template. It’s inefficient, since even with a developer directing ‘mutations’, the very premise of iteration acknowledges a lack of surety. The less certain of how to get the desirable outcome it is, the more inefficient iteration will be.

This creates a sort of paradox: the more you understand where you want to end up the less you’re inclined to iterate, but the more powerful iteration will be if you do use it because you can more efficiently make use of the feedback that iteration generates. The less you understand how to get to where you want to be, the more you’re inclined to use iteration but the less efficient and powerful that iteration will be.

This can be condensed into the following: the more solid design and potential in a product before iteration begins, the more it will benefit from the process. The less focus, direction and careful design in a product, the less it will benefit from iteration. It’s a multiplicative thing. To condense it even further, into the realms of profanity: No matter how much you polish a turd, it’s still a turd.



This is the main problem with the iterative model upon which the industry runs. Iteration is viewed as a catch-all method of fixing things up and ensuring a product is marketable. Problems with a basic concept are just assumed to get ironed out in iteration. While this may be the case, the amount of iteration that has to occur to get the product to the same level that a bit of forethought and analysis could achieve is massive. That means money and time wasted, game budgets expanding and general doom and gloom. Not only that, but solutions will more rarely be truly innovative and elegant, hacked together from re-purposed or rushed assets as they must be. The pressure to not go back to the drawing board is immense, particularly for studios working to publisher milestones or with announced release dates.

For all the flaws listed, iteration is supremely reliable. If you put a product through significant iteration it’s going to come out looking better than it did when it went in. This is great, but it can also be deceptive. Without a comparison, that improvement can deceive a developer as to the actual quality of their product. I often see playtest groups start with something utterly awful, get it to a point where it’s barely playable and hear things like ‘we feel like this is in a good spot right now’.

The promise of iteration to refine a game distracts from the need to set goals before development even begins. Specifying certain desired outcomes such as ‘we want players to spend no more than X time and no less than Y time completing this area’ or ‘we want 90% of our playtest group to report a 9 or 10 out of 10 satisfaction with this level’ give iteration something tangible to push towards and, importantly, something set in stone which performance can be measured against. I’m sure that this sort of practice does exist widely in more experienced studios to benchmark specific areas of the game, but I’m not sure that even the industry leaders establish these sorts of design-centered performance benchmarks from the get-go. I certainly know I don’t. To do so requires a significant amount of research and preparation, but on the whole I’ve found that every hour put into such work means ten less in the actual development cycle.


So what’s the alternative? Well, for the most part right now there isn’t one, and that in itself is a problem. This article is more about pointing out that iteration has very definite weaknesses and that it’s worth putting effort into figuring out other development methodologies which might avoid some of these. Iteration will always have a place, but it’s worth considering just where and when that is in the overall process. Too early and you cede your ability to refocus drastically in order to hit your goals. Too late and everything is already too rigid to benefit greatly from the feedback based tweaking iteration provides.

So have a look at your process. Do you really need to begin testing on day one? if so, what does that say about your understanding of what you’re making. Might your time be better invested in research, so you can figure out what you need to test more precisely? This is just one of the questions I ask myself before I begin iteration.

I hope y’all find this useful, or at least thought provoking.


*some will no doubt contest that genetic evolution is truly random and that design iteration is guided by conscious… well, design. This is true, but I’d contend that the goal to which we guide game design at the moment is so vague (Eg. ‘fun’ or ‘rewarding’) that this really only serves to limit truly awful mutations rather than creating significantly more powerful positive ones than random variation would.