A video recently cycled through my friends’ social circles which I wanted to share. John Cleese talks about Creativity and Open and Closed thinking modes.

The TL;DR of John Cleese’s talk

Closed Mode

Purposeful Highly Productive, but not creative. Good for getting things done. Default Mode at Work.

Open Mode

Playful, Curious, Fun, Humorous, Relaxed, Contemplative without goals.

I had a lot of takeaways from that but my biggest takeaway was what could I do to be more open and enable openness around me. In the past I’ve drawn mostly from my dramatic background and improv lessons, always saying yes. See Lisa Brown’s brilliant article on that topic.

Humour and Time are key to being in the Open Mode. Also Goals, Hierarchy and Authority are not conducive to the Open Mode. An interesting thought for those of you who read the Valve Employee Handbook floating around the net at the moment. The key thought this lead me to is simple...

You Can’t Play by Proxy

Too often I espouse the brilliance of the programming designer. The real magic is simple, you cannot play by proxy. A designer who can’t play (and change) with gameplay is like a chef who gets someone else to taste the food and describe it. An artist who cannot change the appearance of something in-game without someone else is like painting on canvas by instructing a monkey holding a paintbrush. A programmer who cannot go outside the spec is like a dancer in a straight jacket.

You need to hold the ball in your hand and feel it bounce. Always ensure your source control, build server and other tools do not stop someone’s experimentation.

The Open Mode is Unachievable in Crunch Time

A common example of the open mode in game development: someone has just implemented a system which due to an amusing bug is glitching out or not behaving in the designed fashion. In a crunch time, i.e. closed environment, a bug is filed, profanities are hurled and the bug is squashed. In an open mode and a lighter environment, possible earlier in the project, the group plays with the bug and says something like, “Isn’t that interesting...”

Now to be clear, most times nothing immediately comes from that comment though at times a brilliant idea or mechanic emerges. Often these moments lend themselves to interesting gameplay moments. For a prime example of game development project by open mode style thinking, look at Minecraft. Many gameplay features started as bugs or unintended behaviour which in a traditional environment would have been eradicated but the players enjoyed it and Notch left it in.

In order to achieve things we need to be in a closed mode. Though it’s easy to get stuck in that mode and with tunnel vision run down our path missing all the brilliant opportunities that are being thrown up during game development.

Playful Tools

When designing or creating a tool or pipeline think about how your tools enable playfulness, experiment and toy around with your tools. A willingness to create without fear. Observe how playful we are with pens, for many of us our primary tool.

Two Developers, one creating a scene in notepad with fragile .xml, the other drawing a blueprint in photoshop. The drawing based solution is more fluid and open to play. The developer can draw a “humorous shape” and see it in game without fuss. Leading to greater comfort and competence, discovering creative uses of the tools.

Nothing can frustrate and break playfulness more than a deep pipeline or frustrating tools. A buggy or frustrating tool ensures you're in the Closed Mode. As in the Closed Mode we are less likely to make mistakes and can follow rigid guidelines.

While being Creative Nothing is Wrong

We live in a digital world of hacks and cheats, we care for results not method. The thing which appears on screen is a beautiful lie. So if your engine is refresh sensitive and those silly European televisions are giving you trouble, well, just turn up the earth’s gravity*. Remember the product is the experience, not the game.

Too often a professional artist, designer, programmer or otherwise will dismiss or stamp on a comment because it’s patently silly. They insist on saying it’s too complex or saying it’s daft. Now please, respect the professional skill for which the individual was hired. Though at no point should someone be crushed or demotivated by the HAMMER of authority.

Jam, Jive and Jiggle

Encourage people to take time out to play in fixed time periods to jam, jive and jiggle. I write this after having just finished a weekend of Ludum Dare fun. The result of the Jam is less important than the time to play. The time to ponder and play with an idea. If you have a sprint structure try to take some time out after a sprint or a whole sprint, WITHOUT GOALS! Just play. See what comes from it.

People need to feel free to play with ideas, in order to have great ideas.

* A real humorous example of an engine hack seen in the wild.

Take a moment, think back, past the nostalgia and sepia dreams so we can consider old, forgotten mechanics. The thing we love about games is that they are complex and detailed but primarily, they are games. Systems of interaction and exploration within a created framework. All creative works evolve, compete, succeed and in some cases die out.

Though within these sepia dreams and old memories live viable mechanics which when re-examined and explored anew provide exciting areas of creativity.

Among the games of my youth three digital games stand tall, in order played: Hero’s Quest: So You Want to be a Hero^[1], X-Com: Terror from the Deep and Shadowrun on Sega Megadrive. Now some of these games have seen reboots or attempts at reboots which quite frankly angered fans and often missed the point. Thankfully through Kickstarter for Shadowrun and Firaxis for X-Com these two titles are getting a modern, caring treatment and re-examination.

X-Com Squad Turns

Many people passed over the unique quality of team-based turns. There have been many other games in the tactical genre but few have explored this idea of "I move all my units, then you move all your units". This concept of moving multiple units simultaneously thus requiring a session of planning which manifests as a massive investment.

As control is taken away from the player, breaking a golden rule to strengthen this mechanic, a high point of tension is created as the plan unfolds.

Of interest to modern designers is that this investment, planning and then tension as you take away control from the player. For a modern interpretation with a different angle I suggest looking at Frozen Synapse. The turns are simultaneous and you plan 5 seconds increments but once again, control is taken away from the player as they watch the consequences of their plans.

Golden Rule Broken: Taking Control Away from the Player

Shadowrun Hacking

Almost a fully fledged game within the game but with deep seated roots in the core gameplay. So often “hacking” or another core ability is thrown in as a tangential mini-game. With limited or no interaction with the core-gameplay other than a binary outcome of success or failure. This follows the premise of not creating a game mode shift for the player and avoiding a development investment in what is essentially a “second game”.

Older games were much bolder in this. In Shadowrun hacking you hunted down better hacking decks with a whole subset of stats which could be upgraded. The camera shifted from isometric to third person over the shoulder with new UI and controls. You built contacts and went on missions to acquire that “better piece of software” or that “underground deck”. Your decker’s point of access, which related to hacking difficulty, is determined by their physical entry point into the system. Individual nodes on the hacking map relate to camera systems or subsystems of the physical security system. Triggering the alert system or disabling it, affect the real world alarm systems.

That massive investment in an alternate game mode layered on top of the primary mode added massive levels of depth to the world and further fleshed out the game. Looking for modern alternatives I was unable to find a good modern execution of this concept.

Golden Rule Broken: Avoid Gameplay Mode Shifts
Alternate Expression: Focus on a consistent experience.

Time Based Gameplay

In Quest for Glory many moments of interaction were determined by time of day or the day of the week. This occasionally meant as a player you were running around waiting for an event to happen or cleaning out the stables to earn some coins and some time. While some modern games have integrated NPCs timetables much more complex than their predecessors, they have been made insignificant by removing their game altering potential and turning them into minor points of flavour.

The depth of gameplay this added to the world was significant. You had to work around a real world. As a side note the fact the game required you to grind some monsters or chores like stable sweeping to earn your coin allowed you to effectively use your downtime. In Skyrim I can wake up a town blacksmith and purchase armour, removing all gameplay impact of the town schedule. This mechanic lives on in many modern games but in our fear of inconveniencing the player it has been neutered. I encourage designers to look at the gameplay affecting elements this play style offers.

Golden Rule Broken: Never Inconvenience the Player
Alternate Expression: Never waste the players time

Mixing it Up

Quest for Glory additionally mixed combat, role playing, adventure elements while providing multiple solution paths gto many problems. Environmental storytelling, usage based levelling and many other elements which have survived into modern design lexicons.

X-Com famously mixed the tactical and geoscape layer in a very complex interwoven gameplay. Though as Brendon Chung's GDC talk into his trouble with Atom Zombie Smashers highlighted this is not a simple task. I’ve also already talked about the Shadowrun hacking element as another example. For modern designers still bravely exploring mixing of genre and mechanics you do have to look outside mainstream metric focused development. Though I worry that their lack of polish and budget in many cases restricts their ability to smooth out the seams and truly integrate genres.

Golden Rule Broken: Keep It Simple Stupid (KISS)

Conclusion

As many of these older mechanics show, breaking what we consider a golden rule today can sometimes be key to development of an interesting mechanic. These are just a few picked examples from these games. Many other elements exist in these older games which have been gathering dust.

Many of these older mechanics first came about due to technical limitation and were discarded with the limitation. Our Golden Rules were not forged by the gaming gods but discovered through trial,error and exploration. Some of them may lead to an evolutionary dead end in design, an appendix when no longer needed. I encourage you to mine old games. Not for the IP, nostalgia, or history but for the game. Uncovering the hidden machinery of the past, broken paths and discarded branches of game evolution for old and interesting ideas that can be made new again.

[1] Later renamed to Quest for Glory: So you want to be a Hero to avoid confusion with another game, Hero Quest.

A year ago ago I signed up to this service, TimeHop, which emails me my tweets and status updates from a year ago, and it has been strangely motivating. To see my growth, challenges and remind me of my goals, my dreams, my successes and my failures.

So this week a year ago I was...

• Listening to this classic song (http://www.youtube.com/watch?v=fzMhh8zhTiY ) while improving my Starcraft 2 Laddering position of course.
• Working Hard: Quote “Stress + Overtime = Weight gain -> More Stress -> Stress + Overtime... (T_T)”
• Learning to use Blender: http://yfrog.com/h413067151p
• Bitching about it’s lack of ngons, which it now has in dev branch (^_^) Great job guys!
• Which led to this game asset: http://yfrog.com/h0oiyp, http://yfrog.com/h2zxzvfzj, http://yfrog.com/h2og8sbj

I was going to write another designer skill-up post regards art tools but then I wanted to  follow up the brilliant, “You Should be Drawing” post by Mike Jungbluth, with a piece on the Flour Sack doodle. How everyone should doodle old school animation at least once to get a feel for motion and weight in animation... which led to me just wanting to shout from the roof tops.

BE ASPIRATIONAL!

If you're reading AltDev, or better yet contributing, you have at least made the first steps. I encourage you to draw up a bucket list or a dream list of stuff you want to do! Try Schemer!

Start your list with some traditional gamedev skills.

• Code
• Make “Hello World”
• Make Pong
• Make Particle Fountain
• Art
• Draw Flour Sack Animation
• Draw Human Hand
• Model Something on Your Desk
• Design
• Invent a Card Game using a normal playing deck
• Make a Boardgame
• Write a Roleplaying Module

Nothing is stopping you extending that list to include:

• Cook a Quiche
• Crochet a Scarf
• Model something out of clay
• Learn to Cat Yodel

There is no such thing as a useless skill! Aspire to be more, learn more, do more! Also being reminded about last year via timehop and making plans in schemer are not bad places to start.

Everyone I’ve ever met worth anything wanted to me worth more.

P.S. Sorry about the fluffy post but I got super fired up and needed to shout!
P.P.S Also there are similiar services to TimeHop & Schemer. They just happen to be the ones I’m using.
P.P.P.S Should I think things through more and be less impulsive... maybe
P.P.P.P.S I really will do a more technical, solid post next time I promise.
P.P.P.P.P.S: Can you make a recursive Post Script? I wonder...

In some cases the most destructive action one can perform on the creative psyche is to give it absolute freedom. The blank page, blue sky, and empty word document are among the most terrifying monsters in the creative world.

1. Apply artificial Constraint
2. Design within Constraint
3. Remove Contraint
4. Analyze

That sums up a little bit of advice I’m going impart as to how I defeat these monsters. I’ve used this model in various ways and below I’ll give some examples of this simple piece of advice.

One Button

The modern gamepad (or keyboard/mouse) provides a massive subset of control options. Too many in most cases. As a programmer I often just find myself going “bind” crazy because its easy to bind to a key. This leads to terrible interfaces; original Blender UI anyone

As a designer I often force myself to only have one button and one stick on a gamepad, or maybe just mouse interaction. I force myself to use less buttons than I think I need. Then I will often find ways to contextualize or simplify a mechanic or control. Leading to a more elegant control solution.

This also means I can often later in a project arbitrarily say something like, “Okay we will map that Global button to Shoulder button, they aren’t used anywhere”. Which is great when in crunch or a great feature occurs late in development.

Box It

Often when doodling an idea I will just draw a box on the page. Then draw only inside that box. This only really works for visual designs but I find it works really well to focus once I have a set boundary.

Coin Toss

Have two options?

Do a blind coin toss, and then before revealing the coin if you find yourself wishing for heads or tails you know your answer.

Three Point System

When constructing a narrative it’s easy to lose sight of the overall structure or lose detail. One trick I use is what I call the Bullet Point System. The system that forces groups of three means your always forced to find that third thing but also that you often self prune. Some of my best ideas come while reaching for that third point to fit. I also find that often something sounds great but then I can’t flesh it out to three points so I discard it.

Rules

• Write 3 lines
• No line can go onto the next line
• Always write 3 lines
• You can expand a point with exactly 3 sub lines

Story of Lost Boy

• Boy Gets Lost
  • Follows Butterfly
  • Goes into Cave
  • Can’t See Butterfly
• Boy Wanders
• Boy Finds Way Home
  • Mother Asks where he has been
  • Boy Gives Silly Answer
    • Don’t Retell Story
    • Child’s Vision
    • Doubt the Experience
  • Butterfly Lands on Boy

Pick It

Alternatively called the F it system this is for when often I’m uncertain or given too many options. If there are 6 different ways we can go and we can’t be sure which to go well then just throw hands in the air, F-it, and pick one.

Most importantly I document the choice!

I will force myself to finish the design or complete going down the path, no regrets. Then if possible when we have more time I go back to that fork in the road and re-examine the choice. Though to be frank it’s rare that you find yourself going back and re-evaulting.

Conclusion

Keep It Simple Stupid! This is all very basic advice that I was hesitant to post but then I recall watching a 30 minute cooking show on cooking Potatoes and thought well sometimes simple advice is very useful.

Do you ever open an academic text or scary PDF, scan for code snippets, pretty pictures, maybe read a bit then run for the hills?
One of the most important skills you learn in university, or rather you should learn but many don't, is the ability to read and write academic texts. Often when tackling a topic, someone more knowledgeable than you has spent a great deal of time on the topic, possibly with peers to research the topic. If not your exact topic then I guarantee the supporting topics have been researched. So why not stand on the shoulder of giants? These are a few little tips I often give for tackling the wild white paper.

Tip #1: Notebook or Note Taking tools are critical

First you will need a note taking method, I recommend paper if you're reading on the computer. You will need a text either printed or digital. If you're on a computer, Google Scholar is your friend. Most university computers have IP access to the PDF in the search results, some employers have paid for it, as well as libraries. Your home computer will not have free access to most papers and you will need to hand over cash.

Tip #2: Google Scholar rocks, if your employer hasn't got access check a library computer

When looking at a paper in the search results the number of citations is a good quick reference for the authority of a paper. Also if you know a well known person in the field or university known for the field you can track down papers that way.
The title is often the first stumbling block, an undecipherable mess of words which seem to obfuscate rather than initiate. This is not intentional, the academic world is about concise precision trying to eliminate the ambiguity of natural evolving language. I would mention standards but that is more a dream than reality.

Tip #3: Build a list of common terms or words and their meaning

So process the title and write down every word you don't understand. Find the meaning of those words. You will want to build notes on the subject matter and commonly used words. Both to help understand the paper but also to help find other papers on the topic. Remember some words change their meaning based on context.

Tip #4: Abstract: if you don't understand it, read it

An Abstract is mostly there to tell you if you need to read the paper. If you are familiar with the field the abstract should have enough information in it to summarize the ENTIRE paper and tell someone if they should read it. If you do not understand the abstract or are unfamiliar with anything mentioned in it then chances are the paper has new information for you. In terms of the abstract readability, well, you try compressing a year of study into one paragraph

Tip #5: Intro, Expansion, Summary

In an academic paper the introduction comes first and tells them what you're going to tell them. Secondly a body which tells them, then a summary repeating what you told them. The body or sections can have this structure recursively depending on the size of the paper. As my old supervisor told me, academic papers are NOT mystery novels, there are no twists.

Tip #6: Note it, Stop, Search it

Read every sentence, do NOT skip over. If there is a single word or phrase you don't understand then WRITE IT DOWN. Stop reading, then go search it. Find the meaning as relating to the field. Sometimes there can be a rabbit hole effect. They might mention a mathematical term which leads you into a deep hole as you try understand it and process it.

Tip #7: Make note of all references, websites and sources

This is a GOOD thing. You are plugging a hole in your understanding. Academic papers should not have any throw away terms, unless a sentence says: "we dismissed the pink peanut method". Make note of any place which has useful information and make your own notes. The process of writing things down will often anchor them in your mind. If you go down a deep rabbit hole then always take a break before returning to the paper.

Tip #8: Look for alternative explanations

Sometimes a concept just won't stick in your head. Often there is a basic concept or well known crux which many people learned in high-school or university and they just take it for granted. Sometimes you've just developed a brick wall in your mind which you need to circumnavigate. Looking for alternative sources such as lecture slides, podcast, blog posts or just asking someone to explain it to you will help.

Tip #9: The deeper the rabbit hole, the more important it is to YOU, not the paper

This is going to sound strange but a really deep rabbit hole of understanding does not mean that a concept or term is important to the paper. It does mean it is important to you however. Your knowledge and mind are critical to your growth and the deeper the hole, the more there is to fill on the topic. The harder that hole in your knowledge is to fill, the more important it is to fill it. Once you're done not only will you have learnt something but you will have often solved a lot of other related problems.
In my 3rd year of physics I was trying to understand a field problem, which I couldn't get. Finally my tutor helped me with it, but it took a long time and we found out that some of my basic high school level understanding of vectors and matrices was just wrong. In the process of re-educating myself on that topic all the sudden a bunch of other things I had struggled with over the last 5+ years started making sense.

Tip #10: After trying, ask for Help.

Which leads to my final tip, always be willing to ask for help after trying. Do not be lazy and immediately ask for help as that will irritate and annoy. Though once you've done some leg work, ask for help. Most of us love our fields and love talking about them and sharing our love for our personal pursuit of knowledge.
I hope that this will help transform those white and black walls of text into the amazing resource and works of love they are.

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.