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

"force map (mission impossible?)" by Yish

1st Rule: Be as Flexible as possible

Your toolchain and setup should allow for the quickest possible editing as possible as well as bulk editing. I highly recommend integrating a Python or Lua console which allows live editing of data and constants. If you can get sliders for editing or fast visualisation HUDS then all the better.

Ensure that everything possible is loaded from data, the simple stuff like magic numbers to basic behaviours and conditions.

Everything should be in data explicitly. For instance if your original design states that the Weapon Strength is proportional to the phase of the moon and character level which can be expressed in a mathematical equation then DO NOT put the equation in code. Instead your data should contain the equation. There are several reasons for this the most common is when you discover a level is off balance. Then you can adjust level 22 without altering a complex equation which was used as the base-line.

Ensure that your data is robust enough to migrate between versions and survive minor alterations to the structure of the data. Sometimes you may need to throw away some data because it can’t be migrated but this should always be a last resort.

2nd Rule: Model It

Okay I lied, everything is testable but you need to be clever about it.

Mathematical modelling is a process by which we take massively complex systems like population growth or oxygenation in the human blood stream. By monitoring the inputs, outputs and some control variables we can build an understanding of a system.

I know this all sounds like really heady stuff and it is a complex field but even a limited understanding can reap massive rewards. For example take a weapon in an action MMO. Given a weapon that has 100 different stats we can express a rating out of 10 in two areas, Speed and Damage, and our measurement is Kill / Death ratio. We could start by building regression fit by some data we have gathered, thank you WolframAlpha. Though with a bit more effort we could model a 2D plane with K/D as the height which provides even more information. The richer the model the more you can learn.

Always remember the Lab is NOT the real world however.

I cannot strongly enough express the power of models in large scale designs for the broad strokes. Even better if you have a complex model you can create a simple representation of it using Python or similar to create a model which you can adjust in realtime. With simple visuals you can quickly see the potency of an action, such as rewarding a sum of gold in an early quest, can inject into the system.

I highly recommend all designers pick up a book on the subject and if lost ask your programming or financial department. I know that sounds strange but there are likely a few people there with the background to help you build a few basic models.

3rd Rule: Measure Everything

Of course all the above is useless without measurement. Everything is a datapoint. You must have the analytical muscle to get detailed data out of the system fast or else everything will always work from theory and feeling. Poor data will lead to instant failure.

Which leads to a sub-rule which is never trust your intuition when dealing with large scale systems. Your common sense is built on very primitive immediate feedback. It’s great for telling you if a tiger is about to eat you or a date is going well but when it comes to massive mathematical systems more often than not it will lead you down dead ends and false leads.

Even if you’re certain about something, measure it and confirm it. That way you know with confidence that the simple stuff is true. Then when a complex system throws a wobbly you won’t waste countless hours because a basic assumption was false.

4th Rule: Speed and Automata

The ability to time-jump or accelerate the game-time can be immensely useful in complex systems.

Ensure you can decouple rendering or else this is impossible. This is a basic, “Are your shoelaces tied?” question but it bears repeating.

Try making your time jump or acceleration as low level as possible. It should be as stupid and unaware of the game systems of possible.

Consider a delta of a month. I know it sounds crazy but try it. If your floating point math breaks, a number overflows, something clamps, or some code clamps or assumes a delta then that’s bad. Sometimes it can be helped, but then algorithmically (if possible) calculate the maximum time step and ensure you can’t overstep it. It’s also a good idea to pad this estimate to be safe.

Talk to your AI programmer; get an estimate for coding up in order: a random bot, a non-suicidal bot, a stupid bot, a reasonable bot, a perfect solution bot. The last one may not be possible but it usually is. Often a thousand random bots, while computationally expensive, are the best place to start. They will quickly identify edge cases or dead end scenarios. Bearing in mind that the smarter bots will be more prone to breaking when the game changes.

As the game becomes more stable it becomes more and more useful to have these bots around, even post launch. They will quickly let you thrash at a release candidate before letting it out in case you introduced an unstable equilibrium or exploding problem, bad designer no cookie!

5th Rule: Accept your Failure

After all this work you must accept you’re guaranteed to fail. What’s important is the size of the failure and how quickly and confidently you can adjust your system once it’s gone live.

First step is build a bunch of predicated milestones and thresholds for your game. Setup alerts so the moment the live game is drifting outside those thresholds warning bells go off. The sooner you can address them the less likely the model is to explode.

NEVER EVER ADJUST A VALUE WITHOUT UNDERSTANDING IT!!!

This is fine in the lab or experimentation phrase but once things are live and you’re working on a live game you need to understand every nuance of that value. Your models will help here along with clear documentation. It’s helpful to have a rough graph or visual for how the value will propagate out into the system.

Without this knowledge you could just be making things worse. Honestly this is where the true value of your understanding of the systems and numbers behind your impossible system come into play.

Conclusion

Well I hope this helps anyone who has been asked to design the untestable. I know I now have a notebook full of footnotes on the topic. It’s a complex and tricky thing todo. Remember though the first thing to consider is the second to second but then maybe you can look at the year to year.

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.

The game hosts a web-service providing HTML5 WebApp with WebSockets transforming any modern mobile device into the controller.

WiiU vs Everyone

This is of course intended to take place over a WiFi or LAN connection. The concept of a controller which is mutable, touch-screen joy, and capable of delivering privileged information to the player is exciting and could break new genres. Just look up your nearest designer.

Playing a game in a shared space using the power of a computer (or console) to show pretty graphics and using a common space, while at the same time having the ability to display privileged information is really interesting. Consider card games, inventory management or the popular party game Werewolf. The simplest concept is pure conversions of mechanics from board games and similar, but the more advanced ideas are truly exciting.

Something the Wii-U touches on with its single controller, but fails to take far enough, is the brilliance of privileged information. Not to mention the cost barrier that the Wii-U introduces, perhaps if they allowed the DS with download-play to function as a Wii-U style controller it would be cool but I digress... the real point is that people already own phones, tablets and netbooks, removing the cost barrier specific hardware introduces.

Pros & Cons of a Web App with WebSockets

This idea fizzed over and my brain immediately started suggesting ideas. I mentioned it to some dev friends and they had ideas of their own. It was clear there was a demand for this and it dawned on me to write a library which supplies the framework to quickly develop games with WebPad controllers.

With Unity, which is one of my favourite environments to roll home projects in while being popular with indies, I set out to make a Library for the Asset Store. After some fun with Unity & threads along with the joys of working with an in development spec, thank you WebSockets. Working with a moving spec is a joy I could write another post about. Still, the person who wrote the hybi-00 handshake /response spec should be shot! But I digress...

I just wanted to share this concept that has me so excited. So after getting a rough prototype together I fired an email off to Unity Asset store guys looking for advice on how to distro code securely on the store but still haven’t got a response. So now I’m considering just making it an open source project and throwing it up on GitHub.

Would love to hear thoughts on this and I’ll post again when the project is ready for general use.

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”.?

Part 2: Programming Skills

A designer does not need to be a programmer but understanding programming is key.

One of the most valuable but more expensive skills for a designer to acquire is programming. Brenda Brathwaite succinctly makes the point in her post, "Built on a Foundation of Code – Game Edu Rant".

Where to start? While I would suggest Codecademy or GameMaker, because if, as a designer, you can get to the point of making digital games solo, it will exponentially increase the potential of your learning curve.

While researching this post I discovered Codecademy, a brilliant introduction to programming with interactive. My tweet of my discovery (this was prior to it’s press coverage) spread like wildfire, I can easily say it was my most popular tweet out of the 3000+. This supports my belief that programming is fast becoming a life skill and I expect the basics should be included in schools in the near future. So I shall move past this point to less well covered ground.

Designers should be interested in Logic & Behaviours, not Code

At the end of the day the reason you need to understand code is because it’s the brick and mortar your game is built with. Though you want to continue to interact with it at the Logic and Behaviour level, you’re interested in how your game functions. Don’t get lost in performance or implementation, that is the job of the programmers and you should work with them to achieve the desired effect but not attempt to do their job.

Negotiate Policy with Programmers

Just as Designers don’t want unqualified doodles on their design specs, programmers don’t want the mad ramblings of a half trained programmer clogging up their code-base. You should work with your programmers and find a safe, efficient way of exposing as much game behaviour to the design team as possible in a safe manner which won’t damage the code productivity or quality.

You are part of the team, not an End-User

These solutions don’t need to be over-engineered, sometimes simple policy helps. For example, one of the easiest lo-tech ways to expose a bunch of balance numbers to designers is to have a game_numbers.h. This contains all the game constants in native code which the designer can edit, without fear of damaging everything or polluting the code base.

A similar approach can be taken with game logic. Exposing a function list to designers, and having all the game behaviours in a single code file, means that with a fairly basic programming knowledge the designers can craft complex behaviour systems or logical systems without the need for code support or complex tools.

The important thing is that it is an agreement, a policy and common sense which control these. As a member of the team you are trusted. Yes, under this system a designer could go into the code base and turn it all to goo but they won’t. You are not an end-user, you can be restricted by soft systems (policy).

Programmers like to Provide Solutions

Try to make it easy for your programmers. It’s easier for them to knock-up a basic text interface than a full contextual GUI. That being said good tools are the key and so often quoted in post-mortem. If you ever find yourself doing a repetitive design task, are frustrated with a process or are unable to “get at” the parts of the game you want then talk to your team.

Programmers like to solve problems and provide software solutions. If they have time and can see a way they will provide you with a solution.

Learn the Tools

If your studio has a scripting language, or a toolset which is used in developing content, learn it! It is your job to understand and learn that tool from start to finish. Find the manuals, if they are out of date, you should have them updated, if they don’t exist, get them written. If they have bugs, faults, or areas which need improvement, report them.

Someone has made the effort to build that tool, if you do not learn it and use it then you are wasting their time.

Get your hands dirty and own the tools. If your lucky enough to have sufficient programming skills you might even do a little minor tool maintenance, but ask permission first. The muddier and dirtier you get in the trenches, the more hands on your are with your systems the better you will understand them.

So here is to getting your hands dirty, your systems tuned and your game built.

Post Series for #AltDevBlogADay

Footnotes

#Please note: I’m not dismissing high-level design or the need to get an overview on the project but too often useless people use these as shields to hide incompetence.

#You have a team of specialists who will always have more time and expertise than you in many things. Look to understand their work, support them, and refine the design with your increased knowledge but never try do their job.

#Hard in terms of based on solid fact, brick and mortar stuff, as opposed to soft skills like communication and developing a feel for a product which can often be more difficult to master.

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...

Update

Just found out the winners were Joust!, Tick Tock and Dreamweaver. (^_^)

Joust!

Honestly there is no feedback I can give that would improve this game.
Yes, it is that good. It’s a fun Kinect title which has cleverly avoided all the technical limitations of the Kinect at the design phase. It’s fun, energetic, well-scoped and polished to a pretty shine. The audience loved playing this game, and were it on my XBox today it would make a great party game, though it is probably too small scale to be a stand alone product.

A choice of different characters do as the title says and joust. The player jumps and slaps themselves too giddy up and go faster while trying to precisely align their arm as their jousting pole. It’s a brilliant combination of energy and precision which avoids all the pitfalls of Kinect. The single player is nicely couched in a training narrative which effectively adds a game mode while training the player for the two player experience.

The only negative comment I would have is towards Microsoft: with all the great Kinect titles at Dare, where are you? Seriously, this gem needs to be delivered in some form to your console. Mini-game collection, XBLA or just in the FunLabs project. Parents were asking the team where they could purchase it, thinking it was a complete game, and I agree with them.

Tick Tock Tows

The most polished product and a lovely team with a good idea of how to move this to the market. A brilliant use of Unity3D and in fact my only negative point on this game, why isn’t it on the market already? With all the publicity and foot traffic from the general public they would have already garnered hundreds of sales and, within the week, possibly thousands.

So the game is a puzzle affair, a fixed camera looking into a lovely toy box filled with life and animation. The art style delivers stunning, appropriate visuals, all the while reinforcing the narrative. It’s one of those games that just make you smile at the iPad and go, preeeeetty iPad. The game is intuitive, the flow of puzzles is steady and never frustrating while never getting monotonous. They have several themes with plans for more and a nice collection of puzzle mechanics.

There isn’t much in the way of innovation but a solid fun puzzle game. Why innovate when what you have feels fun and fresh?

Lucky Ghost

Okay, I fully admit they have my mind buzzing with possibilities. Some explanation is needed (_) So I’m going to wax on about tech for a bit then return to the game.

The game is a brawler multiplayer game hosted on a PC but then a range of iOS devices serve as the controllers for the game. So think WiiU but with any amount of devices, up to whatever the network traffic can support. The problem with this is that Apple would never let it through the app store. The team talked about possibly using the iPad as a hosting device to make Apple happy but sod them I say. This is an awesome idea I want to see more of.

The solution I came up with on the spot has me giddy and I want to explore it, so I shared it with the team. HTML5 web app! Seriously, the control interface is a touch screen joystick and a few buttons in one mode and a few buttons in the other mode. HTML5 web app using websockets would serve that function. That would mean that any smartphone or tablet could run it. No need to go through the app store, no install, and no device lock-in. This opens up a massive range of TV gaming options to my mind. Sadly, Microsoft policy is that XNA is not allowed web connections on 360, Sony has no equivalent indie dev solution, but a PC or Wii solution is available.

Back to the game: several characters run around a flat arena with smash style play and power-ups. On death you gain access to GM style powers which affect the game state. Honestly, the game itself was highly polished and the audience was loving it, but the game design was nothing thrilling. The concept of the bring your own controller, with touch, is the Wii-U done right and it excites me greatly. So much so I’m tempted to knock up a quick library for Unity.

Dreamweaver

I really loved this little game, it's a wonderful narrative driven platformer aimed at kids with a whimsical graphical style that is delivered through strong graphics programming and strong camera work.

You’re greeted with beautiful 3D menus which feel natural and flow elegantly as part of the game, rather than a front end on it. The material and presentation of the product was particular strong. The game presents the setting of a childhood dream which oscillates between sunny dreams and fiery nightmares. Complete with brilliant puzzles, a fluffy companion, chase sequences and a well scoped vertical slice of a very solid children’s game.

The saddest thing is while this game would have been brilliant in the 90s, these days it would die on the vine. It really needs Walmart sales and those are hard to get without an established license or IP. This is the biggest weakness of the project and it is more a market symptom than a product fault. As once in the hands of children they would love it, just reaching that market requires getting attention and parent purchases.

A few areas of the game could have used improvement. The animations were poor and the transitions sloppy. The jumping animations lacked weight and the double jump needed some added feedback on the mid-air jump. The sliding animations in the chase sequences would have been nicely grounded with a few particle effects or similar. Also, the ending is a bit sudden from a narrative point of view and the fail logic in the chase sequence during a two-tiered section was frustrating. Overall these are nit-picking and I’ve seen shipped games with worse that did well.

I hope they release Dreamweaver for free as its a gem with no market potential sadly. The team however has a strong demonstration of their skills and I hope to see them in the industry soon.

Carne Carne

Meatballs with tongues, Tacos, Multiplayer Griefing and flying carrots garner this brilliant dish of 2D humour. A great game which started as a single player project but really found its feet in the multiplayer mode.

It was developed in Java, which was impressive as most entries used Unity, XNA, UDK or similar. Again the team and game both blew me away with their awesomeness. Given a rework to bring in online multiplayer and a more polished single player experience I feel confident that they could deliver a strong candidate for Steam.

It needs a design pass and just to be made more approachable. The controller mapping was infuriatingly frustrating on the game pad but is simply sorted with re-mapping. Though the game would work, and does according to the team, brilliantly with a keyboard and mouse setup.

Overall it was a slightly unfinished product which could go to market with some more work, polish and a bit of biz sense. The team was brilliant to chat to though and a lovely talented bunch of devs.

Conclusion

I’ll try write up more when I have time, I have reams of notes and honestly there were so many games I enjoyed. PaperQuest deserves a write-up and the artwork and theme of English Fusion from Tea and Techno had a brilliant colourful art style with accompanying quirky theme which just lit me up.

Overall it was an amazing experience I greatly enjoyed and I’m looking forward to hear the winners. Never before have I seen so much young talent in one place nor have I ever seen such a high quality output from an incubation or prototype project.

This bodes extremely well for our industry and speak volumes on the quality of these students. One thing I think it highlights even more strongly is the maturity of the tools available to craft games. Never before has our craft had such a low barrier to entry with such high quality potential.

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!!!

Part 1: Excel & Formulas

Excel is the brick and mortar tool for the designer. Through really any decent spreadsheet software will do and have most the features I list, so pardon the Excel centric explanations.

With Excel you can build entire complex systems and mimic game systems. Allowing you to not only prototype systems but also balance and analyze them.

Formula Introduction

Equations are the bread and butter for Excel. So here is a crash course introduction.

=10 + 5 + C2 - SUM($A$1:D10)+Sheet2!A2

=	must be the first character to indicate it’s a formula.
10	You can use “magic numbers” ? in your formulas, but DON’T! Unless it’s super obvious you’re better off using a cell reference to expose your logic.
+ 5	Most basic math can be exceled in excel formulas. We will leave calculus and statistical stuff aside for now
+ C2	This references cell C2, pulling the value from that cell. This is better than using constants or magic numbers. When you copy and paste a formula the program automatically adjusts all the cell references to their relative position. So if you copy this formula into the cell on its right C2 becomes D2. More help here
SUM()	This function returns the sum of one or more numbers. Excel has a whole range functions for use. Remember to use F1 and Google, also the auto-complete is pretty awesome.
$A$1:D10	This is a range including all cells from A1 to D10 that's a 4x10 block of numbers. The $ indicates an ANCHOR. So if you copy and paste this formula it won’t change $A or $1.
Sheet2!A2	This refers to a cell on a different worksheet.

Okay that’s a fast crash course introduction into formulas.
Need more help? Head over to Excel Introduction

Named Cells

Things without a name or context are extremely frustrating. Often a design workbook can become massive. So if a cell is used in many places or referenced on different sheets then NAME IT! It goes without saying your sheets should be named as well. This is the most common tip I give for Excel.

Naming a Sheet: Double click on the sheet name - Further Guidance
Naming a Cell: Click the cell name to the left of the formula bar.  - Further Guidance
Naming a Range: Same as cell but selects a range.

Random Numbers

Random numbers are always needed.

=Rand()

Generates a random float between [0:1] from which all your calculations can flow.

Gotcha / Quick Tip: The random number changes every time Excel does an evaluation pass which you can force by pressing F9.

VLOOKUP is your friend

VLOOKUP allows you to find data matching your request in a range of data. It’s the backbone of many of my formulas. The most common use case for this I found is when I have data from a separate source and I want to perform a bunch of lookups to bring data together on another sheet to add meaning.

VLOOKUP(lookup_value, table_array, col_index_num, [range_lookup])

Using the lookup_value it finds the row in the table array then returns the Nth item in that row relative to the start of the table, based on col_index_num. range_loopup  which allows you to have fuzzy matches.

One Gotcha is that the look_up value must be in the first column of the data, so sometimes you need to rejig you data a bit.

Further Guidance

The Power of Pivot Tables

Ah, the best kept secret of excel. You can either select a bunch of data already in Excel and go Insert -> Pivot Table or you can just import from a Data Source like SQL.

Then you can group and reformat your data in ways which are so useful. Now I grabbed some sample data from contextures.com. It’s a bunch of sales data for multiple stores. Here is a sample cut out.

OrderDate	Region	Rep	Item	Units	Unit Cost	Total
1/6/10	Quebec	Jones	Pencil	95	1.99	189.05
1/23/10	Ontario	Kivell	Binder	50	19.99	999.50

I can then take this data and with Pivot Tables see the following in a few seconds.

You can quickly pull out summaries and analysis on data with this tool. I strongly encourage you explore it further as entire books have been written on the topic. Feel the power of pivot

Further Guidance

Cell Formatting

Humans like colour, seeing a page of number means very little to us. So wherever possible get things into graphs or charts. Though sometimes that’s not appropriate. In these cases conditional cell formatting is your friend. It can quickly highlight highs / lows, relative values or just point out the bottom or top 10% for example.
This kind of quick visual reference point will often highlight problem areas in your game systems.

Quick Tip: Setting your numbers to the same colour as the background preserves the data but brings forward the formatting icons, letting you shrink the cells.

Further Guidance

Bins and Frequency

Using data bins is a common trick in data analysis. By breaking things into discrete chunks for analysis you can speed up calculations and perform analyses which otherwise would be difficult or impossible. For instance, say you are looking at a bunch of kill data for players which has the exact position and time of death. By breaking the timeline into chunks (or bins) and turning the map into a grid (breaking x & y into bins) you have group the data into manageable chunks.

First thing you will need to do is define your bin size and range. I recommend making a named cell for size (or step), minimum and maximum, then using relative formulas to make a range of bins. Lastly, select the cells which will have the result and use this formula.

=FREQUENCY(data_array,bins_array)

Gotcha: This is an ARRAY formula so be sure to press CTRL + SHIFT + ENTER when finishing the formula. If you’ve done it right your numbers will appear and { } will surround it to indicate an array formula.

Further Guidance

Conclusion

I hope your palate is whetted by this sample of the power of Excel. With a bit of thought you should be able to model prototypes, mode balance systems, analyze your systems, process information and help out in the trenches.

A last word of warning, do not try build your game in excel. Such way leads to madness and wasted time, instead model individual systems. When looking to plug those systems together often a data sample export / import is your friend.

At the end of the day all your game mechanics boil down to numbers. Getting those numbers right, improving your systems and optimising is one of the best things you can do for your game and Excel is one of the most fundamental tools in that arsenal.

Post Series for #AltDevBlogADay

Footnotes

#Please note: I’m not dismissing high-level design or the need to get an overview on the project but too often useless people use these as shields to hide incompetence.

#You have a team of specialists who will always have more time and expertise than you in many things. Look to understand their work, support them, and refine the design with your increased knowledge but never try do their job.

#Hard in terms of based on solid fact, brick and mortar stuff, as opposed to soft skills like communication and developing a feel for a product which can often be more difficult to master.

#Magic Number is a constant number used in line in a formula or code. Referred to as such because it has no context or reference. So anyone else looking at your work is immediate lost as to its source or context.

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.

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.

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.

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?”

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