Designing for the Untestable
Originally written for #AltDevBlog
Sometimes you’re asked to design for the untestable scenario. For instance, design a system for 10,000 players to asynchrously interact in a persistent competitive world with progression mechanics that plays out over 3 months.
Disclaimer: The entire time you are reading this remember one basic truth or else everything else contained herein is useless.
Focus on second-to-second play first. Nail it. Move on to minute-to-minute, then session-to-session, then day-to-day, then month-to-month (and so on). If your second-to-second play doesn’t work, nothing else matters. Along these lines, if your day-to-day fails, no one will care about month-to-month, either.
- Brenda Brathwaite
Let’s Talk About Things We Can’t
Originally written for #AltDevBlogADay
The forbidden knowledge of the game industry is mostly acquired over a smoke or drink in the pub, parking lot and corridors of conferences. Though the personal scars slowly form our own tales over the years which are then shared in similar back alley fashion. I can safely say 80% of my knowledge about the industry, the stuff that matters, I should have never been told.
This is the absurd construct under which we work in the modern corporate creative world. The dark NDA, the culture of secrecy and the allergic reaction to inquiry or unionisation are complex a subject matter about which books could be written.
We are not an open industry by our nature, which I find absurd because most of the people I’ve met in the industry are open and friendly. When our skeletons are exposed they are outdated and mostly surrounded by such drama and media circus that little intelligent discussion and dissection occur. Often one or more parties say nothing by choice or court order, leading to wide speculation or mudslinging.
I’m convinced the reason we are seeing so much success among indies is because they make games free from our industries black cloud of secrets. Often the most valuable thing the veterans bring to the table is the knowledge of a secret war fought, and battles won which allow them to avoid old hidden pitfalls. Yet there are very few who would ever, or could ever share such knowledge in the open space for others to learn from.
Our crunch culture is not all top down for instance, many insane death marches are started by the team or some other factor. Though because we often don’t discuss or document these situations honestly our peers repeat the mistakes we have made.
I’ve heard several friends working on big titles bemoan the run-away visionary, or narrative designer who ship wrecked the projects in similar fashions. In my own short time in the industry I’ve seen one or two tropes repeat themselves on different projects.
I’m not advocating the spilling of company secrets on the newest hottest title, the kind of thing our consumers would lap up eagerly. I’m saying we need to push forward the tale from that project 4 years ago. The time where the entire company was moved continent for one coder, or a project was canned because of a personal war between two managers, or the tale of how enums were banned.
The last year has given me a lot to write about, and I have been recording it all. As the glitter and crunch clear I find myself looking at the year thinking about which of those stories I could share.
If you can do one thing in the coming new year, try find that one story or two that you can share. Not over a pint in the pub but in public for the greater discussion and improvement of our industry.
WebPad: Bring your Own Controller
Going to take a break from my Useless Designer series to talk about a personal project which has me very excited. While judging Dare I came across a good idea which could be brilliant: using a mobile device as the controller in a shared space. The idea was shown by Lucky Ghost using the iPhone and a native iOS app. However, Apple would never let it through the AppStore and not everyone likes Apple. The idea was good but limited, but then a solution hit me there and then and I excitedly shared it with them.
The game hosts a web-service providing HTML5 WebApp with WebSockets transforming any modern mobile device into the controller.
Stop being the Useless Designer: Programming
A bit to the left, No a bit to the right. Mmmm maybe if we make it blue?
Let’s face it, there is nothing more annoying than being bossed about by someone who is useless.?
So here are three simple rules.
- Work with them in the trenches.
- Everyone in the trenches has to be useful.
- Supplement don’t Replace?
So acquire some “Hard Skills” fast and be useful. This is a multi-part post for some places to start developing those “Hard Skills”.?
Judging Daring Doers
This year was the first time I was involved in Dare to be Digital. Now I’ll admit that due to time commitments and unfamiliarity, I sent others from my team to mentor but agreed to judge. Now I’m kicking myself, why did I pass up the opportunity to mentor such amazing and brilliant students. In a few weeks these students have produced high quality vertical slices and complete products which in some cases surpass the level of quality I’ve seen in many studio incubations, RnD or pitch teams.
Every game, bar one, blew me away in quality and the teams were talented, engaged individuals who clearly have a future in our industry if they continue at this level. A wide range of platforms and ubiquitous brilliant tools really pushed quality and innovation to an all time high. This year was apparently a watermark year according to the other judges and I’m glad to have been there. In fact my only WTF moment was, where were Microsoft? Some brilliant Kinect work on the floor, almost all of which hit the mark.
So onto the teams themselves...
Stop being the Useless Designer
Part 1: Excel & Formulas
A bit to the left, No a bit to the right. Mmmm maybe if we make it blue?
Let’s face it, there is nothing more annoying than being bossed about by someone who is useless.?
So here are three simple rules.
- Work with them in the trenches.
- Everyone in the trenches has to be useful.
- Supplement don’t Replace?
So acquire some “Hard Skills” fast and be useful. This is a multi-part post for some places to start developing those “Hard Skills”.?
Though I encourage you to jump into your own tunnels of exploration. I hope this is the first of a multi-part post focusing on various tools or hard skills for designers. Introducing a tool or skill, then getting you interested.
THE BEST PLACE TO START IS YOUR IN-HOUSE TOOLS!!!
The Mechanics of Convention
Our profession develops, we form conventions and a toolbox of useful solutions. These tools make us faster, and more efficient. Conventions are not only developer driven but player driven as we define the language of games. The real question is when to break convention?
Originally written for AltDevBlogaDay
Before you know the answer, you must know the Question
Define the problem clearly with all parties, locate the true source problem and eliminate symptoms. Do you want a sticky goo gun which sticks to walls; or do you want an indirect weapon?
The most common mistake with a convention is to blindly apply it, without knowing the problems its designed to solve. You need to delve past the symptoms into the root causes and motivations. For example what may seem like an issue with your jumping dynamics may actually be a visual feedback issue.
Study not only the present state but the history of a Convention
Every day more people more intelligent than you are pouring collective hours into solving the problem you have just started thinking about. The convention you so readily reach for, or dismiss, did not pop into existence fully formed but instead grew through the years of gaming history from title to title.
Seeing the path of development allows you to better understand the components that build the convention, and the parts which were thrown away. Often choices were made, limitations imposed or situation demanded and the path of development was altered. Sometimes a convention might not be the best fit for your game, or even a good starting point but an earlier version of the convention could be ideal building block or tool to use.
Invention is Expensive
The key benefit of a convention is its a known element, with known quantities. In many cases with known relationships to other conventions. The development time is predictable and many of the edge cases are known.
Implementing a convention in an environment will introduce some new edge cases and relationships but they will be tiny in scope when compared to a new invention.
A new invention or variation must be explored for all edge cases, establish relationships with all other elements of your project, and be iterated upon to reach a stable state.
If you do not have the budget to invent a new convention, don’t start. Find an existing convention that roughly fits and use that instead. A loose fitting convention will be ten times better than a half baked idea.
A little invention goes a long way, but too much will Alienate
While some conventions are entirely developer facing, such as coding conventions, many design conventions are outwards facing to the customer. If a player buys your game which has been marketed as a first person action shooter, there are certain conventions they expect.
Altering convention or surprising your player will often pleasantly and enhance their experience, but only if your solution is clearly superior. Though too many surprises will frustrate or alienate your player, even if your conventions are better than those previously established.
When to break Convention?
Every artistic endeavour must seek to achieve something new, or improve upon the old. The question of when to break convention is simple.
You should always break at least one established convention, though the less you break the more likely you are to succeed. Break too many and failure is assured, break none and success will never be yours.
The Hidden Evil of the Micro Transaction
The Hidden Evil of the Micro Transaction
Over the last year a lot of time has been spent thinking, writing and developing my thoughts on social gaming and by extension micro transactions. The last few months of my professional life have involved some fairly complex and sometimes scary monetisation designs and discussions. Moving from consoles to social web games has been an interesting path to walk, with many lessons to be learned.
Micro-transactions are not Evil!
I prefer the Yummies
The classic line from Hamlet, “for there is nothing either good or bad, but thinking makes it so” is the one which applies here. MTX is a valid business model which, when used correctly, can enhance a game experience and bring a product to a wider audience.
A key barrier to entry for so many people is breaking open their wallet. For this reason I love Facebook games, but also XBLA games. The trial mode enforced by Microsoft does not get enough credit for upholding really good accessibility and up-sell standards. It enforces the “try before you buy” on developers and does some really intelligent things.
That being said poor monetisation design or a mismatched business model can destroy a product. Some quick examples:
- ESports != Game Affecting Micro transactions
- Experimental MMO != Upfront Cost + High Sub Cost
- Awareness Raising Serious Game != Fixed Cost Model
Greed is NOT Good
Many, not all, business and marketing characters I’ve met are so focused on the bottom line they cannot see the product. Now in some cases, this is just greed but more often they are not gamers, they do not partake in the craft nor enjoy its fruits.
Some quick numbers and explanations for you.
| ARPPU | Average Revenue Per Paying User is measured on a per month basis. | It varies a lot and is one of the less visible numbers in the industry. |
| LTV | Lifetime Value of a User | Varies MASSIVELY |
| Engagement | DAU / MAU | 20% Average |
| DAU | Daily Active Users | Top 40 all above 7 million |
| MAU | Monthly Active Users | Top 40 all above 1 million |
| Conversion Ratio | Monthly Conversion rate of Players to Payers | 2% Average |
| Organic Traffic | Amount of Traffic you get that isn’t due to Ads, Purchased Traffic or Partnerships. | Hard number to pin down and the real value is often hidden behind marketing dollars. |
First thing that your money people are going to focus on are those numbers, especially the ARPPU. As a game designer your key metric should be the Engagement, Lifetime value and some of the softer metrics.
Instead of gobbling the raw ingredients like a lazy fat child, put in some work to cook up a feast. Take some risks, aspire to improve the game so people want to play it rather than feel compelled to play it. Drive up the engagement, word of mouth buzz and reduce the churn (loss of players). In short, take the long view.
Grey Areas are Green-lit by Greed
The problem with all this is this it is an ambiguous, grey area. The real kicker is that grey areas are always green-lit by greed. In the interest of a “little more”, so much wrong has been done. So many ideas ruined, communities broken, and teams overstretched by wanting that little bit more. The old sustainable farming arguments come into play here.
The massive problem is that you as the Games Designer or other development members do not always have the final say, but you can still fight your corner. You can build your arguments and try to provide some strong research and data to help your money people see the long term view.
The problem is this Green lighting of Grey areas doesn’t only hit the money people can filter into your team. Money is a great excuse to put your toe over the line.
Strong Vision Holder
The saving grace is if your company founder, CEO or similar authority is a strong vision holder. Failing that, you can have a hard-headed idiotic bitch of a lead designer in heels with a baseball bat and a South African sized chip on her shoulder or your local equivalent, who is willing to fight your corner.
The design and vision has to remain consistent, lines must be drawn and values upheld. From this position you can try to innovate and develop. It’s scary and frightening and there is no guarantee you will get it right. Trust, Integrity and Values can be sold if you’re starving. They can never be bought if you’re fat and wealthy.
Girl’s gotta Eat
So all this being said we aren’t making games for free and we need to eat. I’ve never met anyone in the trenches of game development who wasn’t filled with passion for their craft. I’ve got a whole other blog post to write about: compromise, tips on winning people over and facing the harsh realities.
At this point, however, I will just recommend this brilliant, fiery rant of awesome.
GDC 2011: No Freakin’ Respect! Social Game Developers Rant Back by Brenda Brathwaite
Along with this counter point argument
Redesigning Wild Ones into Playdom's Top Game: A Social Game Design Reboot by Joshua Dallman
We do it because we love our games, not the money… but a girl’s gotta eat.
Respecting Design
Originally written for #AltDevBlogADay
I’ve got a question: “Do you respect your designers?”
Growing up I always wanted to make games, and gravitated to programming as the means to achieve this. I entered the industry as a programmer and had a blast, though I found myself more and more attracted to this strange thing called, “Games Design”. Eventually I made the very tough personal decision to switch from a programming role to a design role.
So often hopeful “designers” choose it as a path because they can’t be a programmer or artist, and not because they respect or understand the profession.
Now I still code, and try to stay current as a programmer because I haven’t ruled out the possibility of switching back. The hardest thing for me to deal with was the lack of respect design has as a profession. Truly proving to your non-design peers your profession requires study, diligence and commitment is a tough nut to crack. So where is the source of the problem?
Given enough time and resource a bad designer can make a good design
Accidental design, or advancing a design through experimentation, requires very little design skill but a lot of resource. Most people can tell if A feels better than B once implemented, so given the ability to try both options they can compare and then make a choice.
Now this is horribly in-optimal but is the root of the problem in many ways. In most respected professions a vast amount of research, basis of knowledge or method of thinking is required to advance in professional grade problems.
As a designer I respect once put it, your job description is to “Achieve the most with the least”.
No one will ever tell a programmer how to code, but everyone will tell you how to design
Once a design is implemented and tangible, most people can see if A is better than B. Now because of the above factor and the fact most design problems can be explained easily to a laymen because communication is a key design skill, well it means everyone can stick their nose in. Including senior members of the company who should know better.
Honestly, the biggest problem the lack of respect causes is this high level of interference from every Tom, Dick and Harry.
In most high skill professions the execution is the simple part, it’s the diagnosis and formulation of a solution which is the hard part. Now most people could inject medicine with a syringe, finding a vein is not that hard, but knowing when or what to inject is tough. Likewise, the result of a complex design problem seems trivial, and once explained obvious to all involved.
It should be pointed out that artists have this problem to a lesser extent as well. The advantage is that an artist executes the idea without needing to communicate, while most times a designer needs to communicate the solution. So the execution is removed from the diagnosis and formulation, meaning that it can be separated easily and appears trivial.
Proving a good design premise is like trying to convince someone a song is good only with sheet music
That being said, trying to convince someone without design knowledge of a complex problem and solution without implementation is tough. Though the onerous to convince people is on us as designers. Sadly many bad designers, instead of solving this, use this as camouflage to hide their incompetence.
Now I don’t know the perfect solution, but I would suggest as an industry we need to learn sheet music and conventions by which we can discuss problems. A process that is already happening but slowly. The problem is many poor designers keep rallying against these conventions or building of hard theory basis.
They keep rallying against conventions and theory, expressing their “individuality” or “creativity” or some other fluffy concept as a defense. It’s because “bad” designers, “lazy” designers who are not willing to put in the work, find it easier to have things fluffy. This fog and lack of clarity is the shield they use to hide behind and we need to rally behind the hard theory and science to gain respect as a profession.
I’ve met more bad designers than I would care to admit, and I’ve only ever once worked with a designer I strongly respected.
Do you respect your designers?
It all comes back to this question. As a programmer I could see my development, and my peers could see it. I could advance my career and have a clear skill progression path. As a designer I often feel lost, and fear most my “value” is from the trust I’ve earned from colleagues and is non-transferable to a new company. I study hard, work hard and know I’m a better designer today than I was yesterday but I struggle to communicate or measure this development.
Finally my question for my fellow designers, “How do we build up design as a profession?”
A Kiss is always harder than a Kill
Originally written for #AltDevBlog: Link to Original Post
Games let us craft interactive systems in which we can play and explore. We play with limited rule-sets, physics, combat, squad based AI, and a million other complex systems which give us a world to explore. Why then is one of the core human experiences, our social nature, all but missing from games?
[Delete several paragraphs explaining where we are and why – assume audience knowledge]
Jump to Nuts & Bolts discussion.
It all boils down to the fact in many ways the dialogue tree system we are so comfortable with is a local maxima in evolution of social interactions and needs to be discarded to make progress.
Let’s take a brutal approach to a social interaction with a game agent. Now if we look at the three stages we can separate them nicely. Currently Inputs are stupidly simple, the game-pad offers the emotional range Morse code, no wonder the agent has trouble interacting. I’m less concerned here because of Kinetic and the brilliant academic research being conducted in this field.
Our outputs however are extremely high quality with amazing voice acting, great visuals and delivery in our high end products. Though the methods we use aren’t scalable, and impractical for dynamic systems. Again there is great research in text-to-speech, automated lip syncing and similar technologies. So great strides being made in this area, but it will be the most painful transition to make as early version of this technology just can’t compete with the pre-baked polished deliveries we have at our disposal.
While challenging I think both of those areas are moving forward at a good pace and will be solved in the near future.
Then we get down to the gritty problem of the agent itself and the formulation of a response. Something we are getting very good at for say tactical combat simulation, where the inputs are better and the outputs rule governed. The dialogue tree however is at the end of the day a static graph (path manipulation through skill rolls or simple scripting doesn’t count) which creates a dumb but effective reflex agent.
How can we grow this agent into a more intelligent system which allows for play and exploration? Can we make an agent who processes and develops an opinion of our actions rather than simply reacting to them by a cast iron static reflex system?
Now while research is going on in this area its super fluffy and long range and does not get as much funding, mostly due to past developments in academia (see AI Winter). One of the trickiest areas with an intelligent response is it requires some degree of knowledge, and knowledge representation is a damn tricky problem in the AI world.
Nuts & Bolts
The key point to the entire problem is that the agent in a game-world, unlike an agent trying to exist in “reality”, lives in a world where we know everything. Using this we can seed them with knowledge they require and a basic relationship network. Through this they can perceive and understand any event which is within the scope of the game world as we have provided them with a working knowledge base from which to understand it.
This will allow us to make advances faster than our “reality” counter parts with quicker results as we have limited the scope of the problem space. Game developers like to cheat 
. It would also help if for the short term if we allow ourselves to use clunky or unappealing input or output systems which would not be acceptable in a commercial product 
Now I know this all sounds very fluffy and I sound like a crazy newbie who has discovered neural nets for the first time and has a naïve grin ear to ear. Though I do acknowledge the scope of this problem and I know the way forward is solving a lot of smaller problems to construct the tools to solve the larger. My dissertation which focussed on building a query/response framework along with the concept of 2nd degree authorship was the umpteenth step for me but the 1st solid piece of results.
2nd Degree authorship had to be proven because I know that at the end of the day we do still want to write and construct narratives, rather than pure random simulation situations. I proved this with a fairly simple rule-based modifier system, one possible solution to procedural authorship of social interactions.
Another requirement is data model which was generic enough to be expanded without being reworked. Again I manage to propose a fairly simple atomic model which would work for several game systems.
Finally I looked at building a query response model which could hold context and remain fairly generic. My research mostly hit dead ends until I considered representing a conversation as a tree, which provides context and a query as a path through that tree with null nodes. Response then could be sub-trees. XPath nicely fitted to this concept and I’m quite happy with the flexibility of the resulting system.
The full details up to this point can be read in my dissertation here.
The next step is build a system in which agents can observe a self-contained play session, discuss it with a player entity or another agent and have a personality persists over multiple sessions. I had two possible planned prototypes to explore this concept. This is the thing I was struggling over for the last week.
The detective prototype was appealing due to its lack of what we will call secondary work (not directly pertaining to the research). In this scenario we would use 2nd degree authorship aided by some procedural systems to generate a crime scenario. The player would then interrogate several agents to try build a picture of the truth. The agents would of course have a personal partial vision of the situation and be manipulating their responses to remove the appearance of guilt.
This is an appealing prototype firmly built on my previous work with little need for secondary work. The two key concerns however were that it strongly depended on the strength of my generation algorithm and would therefore possible reach a dead-end or be handicapped if that system were inferior. It also caters to a fairly narrow spectrum of games, not having many traditional games systems interaction with the social model.
So the second prototype is a tactical turn based shooter. A game I’ve been throwing around for the last year or so, in which the world is persistent but the missions are throw-away and players build reputation. The idea is that the agents (in this case infiltrating squad members, or defence agents) can debrief their controller after the mission about the events. These agents would be persistent over the game world getting hired, fired and killed.
The main point here is the social information is mostly being scraped from a “live” game session in which one side (the defender) is not actually present. The downtime between missions however can be used to de-brief and casually talk about items. This means the game itself is not reliant on the social system, making it easier to have multiple versions, swap out or rewrite the social component without altering the game itself.
Also the persistent nature of the agents mean if I leave a server running long enough distinct social ecosystems should hopefully evolve.
Well that’s the plan; I’ll discuss more details in future posts and as the project advances. If you have any interest in this field or my research please do contact me I’m always looking for people to bounce ideas off and just share my crazy dream to cut-down the dialogue tree and burn its pitiful remains in the fires of progress.
Further ramblings on the matter are on my site, FlammablePenguins.com