seannaber

What is a game? Why is it fun to play games?

There is no “official”, or at least a commonly agreed-upon definition of a game. Wikipedia offers several definitions, which are all kind of true. Chris Crawford’s definition is probably the best articulated. But all of them lack the “essence” of a game, as the sum of components is not the whole in this case. It’s like defining an elephant as an animal with four pillar legs, a small tail, a trunk and big ears – while true and useful, it does not necessarily add up to an elephant.

Another piece of the puzzle lies in the “play” part. Wikipedia to the rescue again, and we see the same pattern – opinions of what play is are quite divided, and the definitions are rather generalizing than specific of what play is.

Simply put, playing is our natural way of learning. Like cubs get prepared for the real life through pretend attack, ambush or flee, we use the hands-on playing to learn in a most productive way. And when we are most efficient at it – it is the most fun we have. It is our hard-wired instinct that makes it attractive for us.

The reverse is true as well – when we are not learning efficiently, the instinctual reaction makes us feel “bored”, which is extremely unpleasant, and forces our behavior into a more effective learning. There is no need for any other motivation, playing is intrinsically motivating as long as we are having fun, that is – proactively learning.

Of course, learning is not necessarily fun and is not always play. And this is a fundamental problem of our modern institutionalized education system. Playing, in turn, is always our most efficient learning method and is subconsciously rewarded as “fun”. We pour so much energy and drive into it, without any second thoughts, that it easily overshadows even the extreme efforts put into traditional non-play learning.

It is important to note that playing is always a pretend activity. It is a simulation of the real thing or situation and it offers the safety of experimenting. Once we step into the real world, we stop experimenting and apply the most efficient method we’ve learned to the situation at hand. Often times we do switch back to a simulated play and resume the learning by more testing of the boundaries. But, by and large, playing is a pretend make belief activity.

Games are the activities we play. They have rules that define the scope and means of our actions, as well as goals to be achieved, that serve as benchmarks of progress. These two components, rules and goals, can range from well defined and obvious to obscure and dynamically altered. Sometimes they are clear and documented, and sometimes subjective and known to the playing person only.

Just for an academic point, I would argue that playing with a toy is a game as well. The rules are of the physical world (if it’s a physical toy), and the goal is to find out how it works (to discover the rules). The toy in itself, however, is not a game, as it does not have the rules nor the goals defined – it’s the player that supplies them and creates a game. That’s why one of the best toys is a stick, seconded only by an empty cardboard box.

Once we master the goals and we get good at it (and “good” is defined by lack of further material improvement) the game becomes boring. It is boring when there is nothing else to learn. A game that’s too easy is boring for the same reason.

Games can also be frustrating, when they are too hard to master or when the rules are not consistent. This is a natural reaction of pushing ourselves beyond the limits of our maximum comfortable effort to overcome the challenges of difficult goals or making sense of contradicting rules. Successful games, therefore, have consistent rules and allow the player to progress at their own pace.

Now, all of the above, summarized into definitions:

Playing is our natural way of learning in a simulated environment. It is intrinsically motivating and it is “fun” when learning is efficient. A game is the structure of playing and it is comprised of rules and goals. Rules define the skills to be learned. Goals are the benchmarks of learning.

While these definitions may look quite similar to the ones found elsewhere, there is a fundamental difference in that games are not true entertainment. They are associated with entertainment because “fun” in games is pleasurable, but their first and foremost function is learning.

This leads to many observations and conclusions that may seem counterintuitive and contradicting to the established views. More on this subject is explored in upcoming posts.

alancleaver_2000

Human perception is logarithmic. This goes for sound, light, force, and so on. Even the stock market charts are displayed on a logarithmic scale. There is plenty of academic research in this area already, but I guess grasping change and making something meaningful of it has more sense in relative terms than absolute, and hence our logarithmic scale of perception.

Regardless of why it works this way, our perception of quality is also logarithmic. And this has a very counter-intuitive impact on the amount of work we put into projects in development.

It is typical for development budgets of modern AAA games to go over $50mln. Investments like these are applied primarily towards the quality of the content, as they seldom have that much more content than lower quality projects.

By default, one would assume that the more effort you put into something, the higher the quality of it becomes. While generally true (and we assume that that effort is appropriate), it implies a linear correlation – i.e. if I put in 10% more effort, the product or service will become 10% better. The truth is – it doesn’t work this way, and it is because of our logarithmic perception.

Generally speaking, for us to perceive something as being the next step on the quality ladder, it has to be twice as good as the preceding one. Or, put it differently – the effort doubles for every step of perceived quality.

Here is a graph representing this, in terms of effort required to achieve it:

Quality vs. Effort

By “effort” I mean time, money, work, whatever contributes to the development of the final product and to its quality level. And “quality” is a customer’s subjective value assessment of your product.

As you can see, the initial effort yields quality results pretty quickly. Similar to the Pareto Principle, I call this the 80/20 Rule of Development, as the first 20% of the effort will yield about 80% of the quality. The actual numbers may vary, say 30/70 or maybe 10/90 – it depends on the actual specifics of your project. But no matter how you look at it, it’s pretty darn good – getting more with less!

While anybody with experience in game development can attest that the first impressive results come online quite early in the project timeline, the final 20% of quality is the hard part, and it takes the rest of the 80% of effort and resources to get done. This is what differentiates successful titles from mediocre ones, and is really difficult to achieve, if not just plain expensive.

There is, however, a way to exploit this mechanism and get top results with a mostly 20% effort. It is not unheard of games that are blockbusters and got developed with a fraction of a typical budget. Successful websites do this as well. So, how do you develop a product with a 20% budget that achieves close to 100% perceived quality?

The essence of this approach is that what matters most for a customer in a game (or pretty much in any consumer product) is its core feature. Maybe it’s a set of specs instead of a single number, but the vast majority of the secondary components (physical or not) just have to be at a generally accepted level.

With just about 20% effort you can put your product or service at the 80% mark across all the specs and features. In fact, you should not invest more than 20% effort in any non-core and non-defining features of your project, because going for more quality gets expensive really fast and offers diminishing returns. It does not make sense to waste all that effort (time, money) on non-essential parts.

Now the primary feature, or what often is referred to as the “focus” of your project has to get that 100% effort. And since you save on the rest of the non-essential areas, you can invest even more in what counts!

Looked at it this way, the 80/20 Rule of Development states that you should invest 80% of your budget into your core competitive advantage area, and spread the rest of 20% across everything else that just has to meet the market standard.

filologanoga

Since the world of games is so varied, we classify games by their core game mechanic. You probably know what these acronyms mean: FPS, RPG, MMO, RTS. Then there is also Racing, Sports, Arcade, Sim, Action, Adventure, Serious, Puzzle, Casual and so on… Fun stuff!

While this classification triggers good memories and is definitely useful, I think there is a need to introduce an additional meta-classification of multi-player games that defines how players interact within the game world. It is especially timely now, when the established videogame industry starts to migrate to the social networks and mobile platforms.

Synchronous vs. Asynchronous

A synchronous game is where players play together at the same time. In fact, they have to play together at the same time for them to play the game together.

As an example is the World of Warcraft game – for you to participate in quests with your friends you have to be online at the same time as they are and go battle side-by-side. While you certainly can play when they are not online, you don’t play with them as a result.

In synchronous games your online identity elements (your stats and/or possessions) are linked to your presence. You do not exist in the virtual world if you are not logged in.

An asynchronous game allows players to play with each other while not necessarily present in the virtual world at the same time. What your friends are doing in the game affects you regardless of when you log in and play.

FarmVille is one example, your farm can be looted by other players whether you are online or not. In iMobsters your stats get modified when you are attacked (either you being online or not) and you get experience points for “winning” the fight or lose money when “defeated”, in an automatic resolve based on your attack/protection stats. You just see a log of what happened while you were away when you come back into the game world.

Your online identity is persistent, present online and dynamic without you being connected to it.

Symmetric vs. Asymmetric

Symmetric games are games where my friends play with your friends. Everyone participating in the group plays with everybody in that same group.

Let’s look at FreeRealms as an example – if I invite my friends to play in a group and we go racing – everybody in that group will race together, with me and with each other. In fact, if I play with you and you invite a friend of yours, I will have to play with your friend as well (or not play at all). Real life soccer is a game like that too.

The game world in these games is a common persistent and cohesive virtual realm.

Asymmetric games is where my friends don’t have to play with each other. Everyone I play with can select who they play with and I don’t have to play with those.

If in CastleAge, for example, I choose to play with a friend of mine and we help each other out, my friend can continue to play the same game at the same time with her friends without me having to play with (or even be aware of) them. SuperPoke on Facebook is an example of a core asymmetric minigame.

An asymmetric game world is comprised of a collection of personal persistent mini-realms that do not add up to a cohesive whole.

What now?

Of course, this classification is just an overarching guide and real-life games do not necessarily fall into absolute boundaries. Like an RPG can have elements of Adventure or other types, Symmetric games can have Asymmetric elements, or the other way around. When classifying games we should think of their primary multiplayer interaction mechanism, with the other mechanics being secondary.

Current multiplayer games are primarily Synchronous and Symmetric. Even FarmVille in the example I used above is actually a primarily single-player game with Asynchronous and Asymmetric elements that enhance its primary single-player farming gameplay mechanic.

The field of true Asymmetric and Asynchronous multiplayer games is still wide open for new games to become iconic in this area. Are you up for this challenge?

holisticmonkey

You know why ideas can not be stolen? You know why the top team members get to sign “stay” agreements when their company gets acquired?

Well, actually, ideas and tech can be stolen and copied. Specifically their implemented form. And this surely can do some damage in the short term. But it doesn’t really matter in the long run.

Because technology and ideas are dead without the people behind them. Sure, some ideas and tech are strong enough and have enough momentum to carry through for some time. But once you remove or replace the brains behind them two outcomes happen – either the idea/tech will start decaying and fall apart over time, or the new leader will disassemble it and build a new direction.

Ideas and tech are not static immutable things, they are like a living entity – developing, growing, adapting, evolving. They are never done and finished unless dead and out. The people behind it are the inner soul – remove them and you get a zombie.

A tricky part is that within a team it is not apparent who’s really the vision holder of successful or promising technology and who’s just getting in the way. The one making it happen and evolve is not necessarily the most outspoken proponent, and it is often times not the lead. It can be an introvert tech guy quietly working on it, most likely between other tasks, and making things happen without much fuss.

The vision behind any idea or tech is very subjective and is based on a specific person’s experience, beliefs and values. Put a different person in charge and she’ll bring a different experience, belief system and values to the table – resulting in a different direction, no matter how subtle it may be.

To make things more complicated, some systems are like an ecosystem, where the composition and the dynamics of the team make it happen. It does not reside with any single person, it’s a collective entity. This, however, does not last, as these structures are very volatile.

Successful managers and leaders invest time and effort to identify the key people behind each of the key technologies and work with them to give them the power and resources needed to foster their work.

True, there are no irreplaceable people, but this doesn’t mean their ideas and vision will carry on without them. New people bring in new ideas and directions, most likely at odds with the orphaned ones.

Untitled blue

Tech risk management is an intrinsic part of the planning process of any project. It provides answers to questions like – “What if the technology we rely on fails?”. It is not unusual for many projects to have new unproven tech at their core, or even tech that has not been developed yet. How can you guarantee that it is going to work out?

Often times, the answers to questions like these are sought not only by the internal team managers, but by investors as well. If nothing else, they are putting their money on the line and it is only natural that they would want some reassurance their investment is not a gambling venture.

Good tech risk management structures the work in a way that guarantees project’s success even if the tech behind it doesn’t work out. It essentially reduces the risk of project failure, therefore making the investment (both of time and effort from the team, as well as money from investors) a safer venture.

For those unfamiliar with risk management this might sound like some black magic voodoo. After all, how can one guarantee that some tech yet to be developed is going to work out? As it turns out, though, one doesn’t have to predict the future to be able to minimize the risks. It all boils down to a few management techniques that take care of it.

During the planning phases of the project all essential tech aspects are analyzed and divided into roughly three categories – Negligible Risk, Moderate Risk and Substantial Risk. Each one of them is then treated according to its category, described below. If later during a progress review it is found that something worked out differently than what was planned, both in a good or a bad way, the respective items can be moved to a different category and re-addressed.

Negligible Risk

This is tech that has a proven track record, it is reliable and the team has experience using it. Or, even better, it was already implemented within the project and performs to expectations. There is little chance of something going wrong here. Ideally, we want as many of the tech items to be in this category, as there is nothing we have to do to court them.

Now, why would we pay attention to items that are low risk, why even mention them at all? Surely, they are not likely to create any problems, that’s why they are in this category to begin with.

The reason to list and track them is that the fact of them being low risk is not obvious to all the stakeholders. Especially to investors – they are seldom tech people. What they look for when they scan through the TDD (or the risks section of a business plan) is verdicts of “no risk”. It also shows that those items were considered for risk, not just omitted by negligence.

As a side benefit, you get a list for tracking throughout the project development, just in case one of these “safe” items silently gives up.

Moderate Risk

These are items that are not likely but might not work out, or maybe provide not quite the expected results. It can be tech that, though proven generally, the team does not have experience with. Or maybe proven tech that the team used in the past but it is being applied in a novel way or pushed to a new extreme. The tech guys say it can be done, but it wasn’t actually done yet, or not within your team.

The way to deal with these is to line up a back-up plan in case the tech in question doesn’t work out. For example – if solution X fails, we will use solution Y that is inefficient/expensive/whatever but it is proven and will provide the result within acceptable parameters.

Of course, all the work on the former tech has to be planned towards the beginning of the project and there should also be defined a cut-off evaluation point that leaves enough time to implement the backup solution if the tech in question fails. This way you know that the experimental tech can be pushed for as long as possible and still have time to safely switch to the backup in case it doesn’t work out.

Essentially we offer a Negligible Risk level backup for our Moderate Level risk item and making it safe in case of failure. The only downside cost is in the inefficiency/cost/whatever drawback of the backup solution, so from an investor point of view a failure of the tech item would only result in not gaining the benefits the new tech promised.

Substantial Risk

This category is for fun technology that has yet to be developed. It could look feasible but never attempted before, or it can even be items that “I have no clue how we will solve it”. It’s the cutting-edge of development and chances of it not working out are usually better than otherwise. It would be a gamble to pin your project on these kind of tech items, yet these are usually foundation stones of highly successful break-through ventures.

The way to turn this from gamble into a manageable process is to define a feasibility test, basically a set of questions that have to be answered to find out if this tech is working out the way it is expected of it. It can be done through an R&D phase before the full project development begins. It doesn’t have to be full tech development, just enough of the critical pieces to be able to see if it can deliver the promised goods. At that point it can be classified as a lower level risk item and then the project can proceed.

From an investor point of view, the risk is limited to the time and money invested in the R&D phase, which is considerably less than what a full project with a full team would carry, so the potential loss is small and under control. Moreover, if the full R&D phase is still too big and expensive, it can be split into several steps, each with its own feasibility tests and proceed from one to another only if the preceding one was positive.

Ultimately, one has to take a leap and risk some investment for a chance of the new tech working out, but it doesn’t have to be disastrous if it doesn’t. R&D investment is just an overhead item in any well defined budget, so these items then become part of a planned budget category instead of being categorized as loss outright.

Conclusion

Disseminated one by one, the above techniques now seem like common sense. Yet it is amazing how many teams do not employ them and then either struggle to adjust when technology inevitably fails, or even before getting to that point are puzzled why investors are skeptical to jump in.

Naturally, these Risk Management techniques are just a guideline and have to be employed according to the specific situation. A backup tech can be used for Substantial Risk items if the project is too critical not to proceed regardless of that tech, or in some cases the backup tech can be used to jump-start the project and then the R&D tech can be later substituted in provided it works out within an acceptable time frame. These kind of moves are possible with some planning in advance by structuring the work, protocols and specific implementation of your project.

Risk management is not about avoiding risk. This is impossible. It is about investigating the possible outcomes and minimizing the potential loss. Have a backup. Fail Fast.