Advertising professionals, wake up! Sink or swim, but bring your smartphone.

Games as a medium for advertising, social interaction, and branding have been around for over a decade now, yet they haven’t had much consistent impact so far.  I’d dare say they’re still considered a novelty or a nice cAampaign add-on by too many advertising professionals.

However, the disruptive events in the online world over the last four years, have drastically altered the landscape. Suddenly (but not unexpectedly) gaming has exploded, and can no longer be seen as secondary field of interest by innovative advertisers and digital agencies.

Consumers now spend more time on mobile apps than they do in the browser, even if desktop and mobile browser usage is combined. Furthermore, the largest chunk of app use is is spent on game apps. Consumers spend 32% of their device time playing games, 17% on Facebook, and only 14% using their mobile browser*.  As Forbes stated earlier this year, “The mobile browser is dead, long live the app.”

Gauging the trend, it suggests that it won’t be long before the consumer starts spending more time in mobile games than they do in the browser on any platform. Period. In an app marketplace where 79% of Apple’s revenue from the appstore is driven by games **, as a game developer I would add: “the browser is dead, all your consumers are belong to us”.

We’re not talking about some distant future either… right now games are the biggest piece of the mobile cake.

The advertising industry is taking note, and in-game advertising is on the rise.  However, with the projected global ad spending on “mobile internet” reaching only a meager 6.2% in 2016 ***, we’re still talking baby steps.

It’s astounding that so few digital agencies and innovative advertisers have caught on. It’s not that mobile is just happily adding new market share, it’s also cannibalising the desktop. This should be evident from your own online campaign analytics, compared to those of a few years ago.

Anyone considering a transition to mobile should also understand that Apple and Google have changed the playing field. Yesterday’s free and untamed internet is slowly being replaced with manicured and carefully maintained walled gardens. Apple, for example, controls the hardware, the software, the user’s permissions and most importantly the payment system, and through this combination of factors: access to the users.

This garden will soon contain the most cherished and valuable consumers, if not the majority of the digital consumer market. Apple, Google, Amazon, and all those others who are scrambling to create their own walled gardens, have no interest in breaking down their walls. If you want to enter, you play by their rules, and pay 30% of your revenues.

Harvesting from the garden therefore, will come at a tremendous price. Not only in adapting to the new paradigm, but also in physical investment, and the toll payable to the platform holders.

Please realise that every important buzzword of the last years – internet of things, location based, mobile wallet, health tracking, iBeacons and many more – are all locked behind the wall. Even if they still have a desktop use, they cannot function outside the garden.

That means if you wish to participate in the future, you need to learn to play the mobile game. Abandon web and browser as a primary medium for advertising and engagement. Prepare to labour for those valuable permission screens. Learn to create app real estate that will reach out and touch consumers, getting their feet on the pavement and your brand on their minds.

In a digital world where users critically manage their home screens, gaming is currently the ultimate if not the only trojan horse.

The mobile gaming industry has proven to be the most successful at engaging consumers within the walled gardens, generating over 23 billion USD of revenue from mobile consumers ****.

It does this chiefly by triggering in app purchases. The players’ loyalty is staggering and triggers not only engagement of incredible longevity but also a tremendous amount of purchases. And yet the advertising industry seems to be stuck to banners and lead-in video’s, which teach the consumer nothing other than to click away.

The psychological hooks in gaming allow the gaming industry to create audiences that will stick to games month after month, year after year, and to retain spending and other behaviours*****.  King,  the company behind Candy Crush Saga and others, is only 600 persons strong, and spends less than 6% of its revenue on actual development. However, it still manages to attract a whopping 124 million players a day, and nearly 408 million people returning monthly to play and pay.

What can we learn from this? One way we’re starting to use these same hooks for brands, is to combine social/brand loyalty with gamification. Rather than focusing on campaign based interactions with consumers, we are creating long lasting digital showcases of consumer loyalty and the rewards that go with it. However, the trend of gamification is also a dangerous one, as it has a risk of obscuring the most important thing about games: that they should be fun!!

Gaming is about play. It’s not a medium or a channel, it’s not a spreadsheet filled with loyalty versus reward ratios. It’s a basic human activity that is natural to every single human on the planet (and their pets). Gaming is fun because it is our natural method for learning, and learning is rewarding because it makes us feel better about ourselves. It’s not just about the dopamine winning gives you. The ultimate reward is personal growth, learning, achievement, triumph, and the knowledge that you have had to earn it.

Human beings can learn nearly anything and feel that joy of playing. Music, sports, news and other thematic ties to a brand have to be carefully nurtured to work, but playing will work with nearly any brand or story.

It’s something we as game designers have built our industry upon. We’re not providing a means to an end; when we succeed, we provide instant happiness, instant satisfaction, and instant personal growth. Even if it’s just you getting better at navigating a flappy bird around a level.

If we were to draw any conclusions from the current market, it is that it’s baffling how in this huge success story of mobile games, branded content and advertising has only played a bit-part role.

Now that the initial gold rush of mobile gaming has come and gone, gaming has taken its seat at the head of table that is digital content. The gaming industry has accepted change and disruption like no other, and has made it a point to be the first at the party. The advertising industry can no longer afford to be a late comer.

Consider this carefully when discussing loyalty and digital engagement. The advertising industry doesn’t need to reinvent the wheel here… it exists already and you’re probably already hooked.






About the author:

Tomas Sala is Creative Director and co-founder of Little Chicken Game Company. Through his Amsterdam based studio, he has been designing and creating award winning applied games since 2001.

After 15 years in the industry, Tomas has come to realise that in fact, he doesn’t have all the answers but that’s okay, because neither does anyone else. The trick is to find them together.

Tomas believes the two best things in the world are his dog, and telling stories through great games. He regularly sets out on independent  design quests, leading to the creation of the popular Skyrim mod series “Moonpath to Elsweyr” and the (hopefully) upcoming Indie game “Oberon’s Court”.


1,581 total views, 1 views today

Delegation in game code structures

written by: Joris van Leeuwen


We’re currently working on a game in a production team of 3 artists and 3 programmers. During the development of the game’s prototype we heavily used delegation in the main code structure. This resulted in such an easy to read codebase that we’ve decided to use delegation in our main code structure for production as well. I decided to make this blog post to share some of our experiences using this technique!

Knowing this technique can help you to make code-bases that are able to rapidly respond to game design changes.

This article is meant for programmers that are interested in pros and cons of delegation. You can expect code examples in C# and solutions for hierarchies in code. Please note that this is not a “you should do it this way” article. Just my thoughts on the subject that I’d like to share!

Coding for redesigns

During the making of a game you always learn how to make it better, this is why you should iterate. Try something out, learn from it and make improvements accordingly. I think Game Programmers should therefore always prepare for redesigns in game mechanics. In my opinion, good game code embraces redesigns by making it very easy to change or rewrite parts of the code structure later on.

Hierarchy and encapsulation

To easily change or rewrite parts of the game you make distinctions between functionality. This is done by creating classes and putting them in a hierarchy. Each class should know as little as possible about other classes, as concealing functionality makes it easier to read code because you don’t have to travel around to other classes for it to make sense. This is called encapsulation.

By creating a hierarchy you effectively distribute the responsibility of functionality to separate classes. Parents manage their children, who serve as parents for their children and so on. Parents should only be able to access what they need from their children (I don’t know how you do it, just get it done!). Children shouldn’t know anything about their parent. This way children can easily be attached to another parent without breaking anything. If there is a redesign in game mechanics, the programmers can decide from what point in the hierarchy the code should be altered or rewritten and the rest of the code can stay as it is.

Communicating upward in a hierarchy

How is it possible to communicate upwards in a hierarchy? Or more explicitly, how can a child say something to its parent if the child may not know about its existence? Let’s say the parent of a child needs to know when the child is hungry so it can enable a pizza alarm. How does the parent know?

Well the parent could, for example, ask the child if it’s hungry every second of the day. If the child would be hungry the parent could enable the pizza alarm. But this does sound kind of strange.. it feels inefficient for the parent to ask his child whether he’s hungry or not every second of the day.

Another option would be for the child to tell its parent to enable the pizza alarm when it feels like it’s hungry. But that would break encapsulation. The child would be able to know the parent is able to enable the pizza alarm. And in addition to that, the child would even know that a pizza alarm exists! What if later in the project the Game Designers want to change the pizza alarm to a mother that actually cooks dinner? Multiple classes would have to be changed just for one change in game mechanics.

What would be much more efficient, is for the parent to tell his child to notify him when he’s hungry, so the parent can react accordingly. The parent would only have to tell this once, and the child doesn’t have to know about what his parent is going to do after it notifies the parent. This is called delegation.

Delegation is a way to communicate upwards in the hierarchy tree, without losing the ability to split context and functionality. It enables parents to “listen” to their children and perform actions when they are triggered.


To show how a delegate system looks like in C#, lets start with using the callbacks from the Parent’s perspective.

class Parent {
  PizzaAlarm pizzaAlarm;
  Child child;

  public Parent() {
     pizzaAlarm = new PizzaAlarm();
     child = new Child();

     //Make the child trigger the 
     //OnChildHungryHandler method when it gets hungry
     child.OnHungry += OnChildHungryHandler;

  void OnChildHungryHandler() {

The child has a callback that is named OnHungry. In this example the method OnChildHungry is assigned to the callback. When the child internally decides to become hungry it calls the OnHungry callback, triggering the OnChildHungryHandler callback-handler in the parent. Notice the +=? Yes, it is possible to assign multiple handlers to one callback!

The beauty about this is that the parent doesn’t need to know how the child gets hungry. It only needs to know when it does so it can respond to it. The child also doesn’t have to explicitly tell the parent to enable the alarm, enabling us to encapsulate that functionality within the parent class. This way nobody has to search around other classes for the parent class to make sense, making the parent class much easier to read.

So what does this system look like in the child class?

class Child {

  //Define the delegate type
  public delegate void HungryDelegate();

  //Declare the callback
  public HungryDelegate OnHungry;

  void Update(){
     if (/* insert logic here */){

        //Check if the callback has a handler
        if (OnHungry != null){
           //Perform the callback

First a delegate type is defined. This is done to enforce the callback-handler to have a certain set of parameters and returning type. In this case only methods with a void returning type and no parameters can serve as a callback-handler.

After defining the delegate type it can be used to declare the callback OnHungry. This is a public field so it can be accessed by the Parent. From within the Child class the OnHungry callback can be treated as if it was a method. Calling a callback does need a callback-handler though, else it would be a null value. When it’s uncertain whether the Parent has assigned a callback-handler a callback must always be null checked before it’s called.

The child has no idea who is using its callback, which is great! If there would be a redesign in the game mechanics, it’s now easy to detach the child from its original parent and attach it to another without having to rewrite anything in the child!


We had some issues with the naming conventions of our delegates and renamed everything a few times. In essence, there are three types that will need a name. These are the naming conventions that we’re using:

  • Delegate Type: HungryDelegate
  • Callback: OnHungry
  • Handler: OnHungryHandler

The reason why we put “Delegate” as an postfix to our delegate types is because just “Hungry” misses context. The handler still feels a bit long, but when removing the “Handler” it will have the same naming as the callback, creating issues when defining a handler within the class that has the callback itself.

Don’t name a callback something like “OnAlarmPizzaNow”. To take full advantage of using delegation in code it is essential that the naming of a callback does not describe what happens as a result. This is to maintain valid context after redesigns. OnHungry doesn’t say anything about the actions that follow and thus is more reusable after design changes.

Our issues with delegation

There are some downsides to the way that we’re using delegation. One downside is that it can be a wall of text that arises in a class with a lot of different children when assigning all the callbacks. We use newlines between different instances when assigning the handlers but it’s still a big list.

Another issue is when the parent of a parent of a parent needs to be told that something is happening. This would need a big stack of callbacks before it actually triggers the action that should follow. This issue feels awkward but we haven’t found a solution that maintains the distributed responsibility of the parents in the hierarchy. You could suggest to use an event messenger system that skips a few layers of the hierarchy, but using event messages for actual game mechanics always results in spaghetti code in my experience.

Recursive loops are always a thread, but in delegation it is sometimes harder to detect. This happens when a parent listens to a child, and in its handler performs an action on the child which makes the child perform the callback again and keeps on going.

There’s also no clear stack-trace of what is happening. When trying to debug the handler of a callback the entrypoint in the stack-trace is the handler itself, making it hard to trace back where a problem is coming from.

The last big issue we’ve experienced is that you can easily forget to remove the callback-handlers without noticing. If this is not done, the system would never be able to wipe the child’s memory because the parent is still referencing it, resulting in errors that are pretty hard to trace back. This is scary in delegation and should be handled with care. All delegate callback-handlers that are attached to another object should be removed at some point. This responsibility can be given to either the parent to remove the handlers it has given to the child by using -=, or to the child itself to set its callbacks to null when it gets destroyed.


Delegation proved to be a really cool technique which makes implementing redesigns on game mechanics easy without having to remove functionality because it is too tightly coupled.

In the end it always depends on what kind of project you’re working on. How much the game design is already set in stone, the deadline and the size of the team should all have a big impact on your coding strategy. In our case we’re making a game in a team with programmers coming in and out and a project that can constantly get redesigns in game mechanics. We like using delegation and I’d very much recommend experimenting with it when setting up a coding strategy for a comparable project!


Something that is not discussed here but is very useful when using delegation are called actions. Find more about actions here!

41,384 total views, 4 views today

Making textureless 3D work

Textureless pure 3D

Creating a textureless “pure3D”  look


(This is a post about Oberon’s Court; a fantasy RTS/RPG game being developed by Tomas Sala (@littlechicken01) who is also one of the co-founders of Little Chicken Game Company. However the game is not an official Little Chicken Production, you can keep up to date on the game at

One of ways I decided to challenge myself when starting Oberon’s Court was to create a visual style that does not use any textures. There’s two reasons for this.

First of all, it looks beautiful. Having grown up with pixel games and the advent of 3D games has instilled in me a deep appreciation for 3D graphics. But the advent of pixel art has shown me that you can take any visual tech and distill it to its purest form. Creating 3D art without the use of textures does exactly this; it distills your modelling, animation and visual skills. Henceforth I shall call this style “pure3D” (feel free to add that your technobabble jargon).

Secondly, it’s very efficient, taking away the need to unwrap and texture a model removes a significant chunk from the development process. However, you will need to adjust your models and shaders to compensate for the lack of definition, seeing as you’re also losing an aspect or tool in your pallet.

This post is a how-to on approaching this style. This is by no means a “one-and-only” guide, as there are many artists and indie-devs using wildly different approaches to creating a stylized and purist 3D aesthetic, but it is how I did it for Oberon’s Court.

In this first post I’ll write about the general setup, and going through the process step by step.

Regarding shader code:

I’ll do an in-depth look into each shader and how to create them yourself in Shaderforge or Strumpy as a part two of this post. For those eager to experiment here’s a copy of my entire shader library that I used for Oberon’s Court:

In the meantime, please do download / purchase these two awesome shader tools for Unity3D. I highly recommend them, as I use these as essential tools for my development process.

Download Strumpy for unity3d
Purchase Shaderforge for unity3d 

Lets get started!

Evolving the aesthetic

When I started creating the visuals of Oberon’s Court I was very much into compensating for the lack of textures, adding lights and accents to maximize the impact of the style. However, I quickly found that increasing contrast, when you have nothing but gradients, edges and solid colors to work with, does not improve the clarity of a game. Even though visually striking, it was hard to discern units and foreground items from the background.

First true textureless unity3D test. Very striking, but sadly not very well readable from in-game perspective.

As development progressed I found myself removing and subtracting visual effects to create a visual style where the player could easily discern the “shadow” units from their environment. Additionally, I found it a very pleasing experience to subtract effects, instead of adding more and more.
If you compare the earlier screens with the latest screens you can see that some of the initial tests where visually more striking, however they weren’t very suitable for game play. I’m not saying that you can’t make a game using a more high-contrast approach, but it was not the game I was designing.

Cluttered and hard to read.

The final style.

The ingredients

To create the pure3D style I used a couple of recurring ingredients and themes. I’ll iterate on those here, explaining what techniques are involved and how I achieved the ingame results.

In essence the style is very, very simple. There is nothing new here for most game artists. But combining these ingredients can lead to striking result when you remove the texturing from the process.

  • using smoothing groups as shape definition
  • using additional dark/light vertex color data, such as radiosity solutions
  • using UV coordinates to create color gradients and color mixing
  • using shaders to add shape enhancing effects(fresnel etc.) to the model
  • using unlit shaders (without lights), but with realtime shadows
  • using select post-fx (bloom) to enhance/soften the look

1. Using smoothing groups as shape definition

When working without textures, you lose an important part used to help enhance the depth of your 3D model. Especially for mobile development, where textures are often used as main way to enhance the visual complexity and shape of an otherwise very lo-poly model.

In Oberon’s Court I used smoothing groups to enhance the definition of my 3D models. Usually smoothing groups are discarded, as normal maps and other techniques are used for describing the angles of faces. Nowadays we’re more used to creating high poly models and distilling that angular (normal) data in a texture. When you have the full dataset of a hi-res texture, smoothing groups seem quaint and only of passing interest. But using them effectively can provide a beautiful tool of enhancing the shape of your model. Both as it’s being lit as well as for use in shaders.

Some notes:

  • Unity does accept multiple normals per vertex, so your smoothing groups will transfer to Unity3d’s lighting models still intact. The same does not count for vertex colors (more on that later)
  • Edge triangulation: when creating smooth surfaces you’ll need to occasionally re-triangulate to create the smoothest look. Just make sure you’re modelling in basic shaded preview mode
  • Create smoothing groups that enhance the edges of your model
  • Break up over-convex shapes, if the angle between two faces is too big (too sharp) do not try to smooth over it, break it up in two smoothing groups
  • Create enough faces so you can create interesting edges and protrusions, which the smoothing groups can enhance.
  • Use a limited number of smoothing groups, just for practicality. You can repeat use smoothing groups, as long as they don’t touch another set of faces with the same smoothing group ID
Creating an interesting hill shape by extruding faces

Creating an interesting hill shape by extruding faces.

selecting faces to create smoothing groups, and the end result in preview shading

Selecting faces to create smoothing groups, and the end result in preview shading.

2. Using additional dark / light vertex color data, such as radiosity solutions

When working with shaders you want to be able to add as much additional information as possible into a 3D model. Most shader models work with data stored in the textures (normal maps, diffuse maps etc), but also with data stored in the geometry and vertices (points). The simplest form is the position: the normals and basic data required to display the model. But you can keep adding more data to each vertex. This can be physics data for physical materials, but also additional lighting data. In Oberon’s Court I used 3D Studio Max’ ability to render a radiosity solution on vertex level and save this to vertex colors. Basically creating a dark-light shading for an object based on a complex lighting solution. This allowed me to darken and lighten the model based on a pre-determined lighting scheme.

Some notes

  • Using skylights is a quick way of creating a soft outdoor look with radiosity
  • Object and vertex colors will influence the color of other faces, as light literally gets bounced off the geometry, and thus radiates color
  • Don’t worry if the radiosity is not very precise, you can add extra tesselation and vertices to improve quality. We only need a hint of dark-light to give depth to a model. It doesn’t need to be realistic, nor perfect
  • Only add radiosity after you’ve done the smoothing groups, as smoothing is taken into account during the calculations
  • Radiosity is found in the scanline renderer of 3D Studio Max and is an advanced lighting method. (Similar features are available in Maya, I believe)
  • You can assign the radiosity to be permanent, by using the vertex colors modifier, and use the “assign vertex colors” function in the roll-out
  • Detach each smoothing group! Unity does not retain multiple vertex colors per vertex over the same channel, so if you want to retain the radiosity solution and the sharp smooth edges, you must detach each smoothing group to separate elements.
First detach all the smoothing groups, so they're seperated, then perform radiosty calculations.

First detach all the smoothing groups, so they’re seperated, then perform radiosty calculations.


First results of the radiosity solution, and then assigned to the vertex colors and graded. Notice how the smoothing groups really pop-out the shape of the models.

First results of the radiosity solution, and then assigned to the vertex colors and graded. Notice how the smoothing groups really pop out the shape of the models.

3. Using UV coordinates to create color gradients and color mixing

In order to diffirentiate height in the environment, I used color gradients. The easiest way of implementing these would be to create a texture. However, seeing as I committed to not using textures, this wasn’t an option. Also, gradients are something shaders can do quickly, without much fuzz. In order to create a gradient we need information on both the direction and length.
Initially I used world position data for this, to create a true height-map type effect. However, this approach is calculation-heavy, as the shader needs to retrieve the world position of each individual vertex. Therefore, this approach is not very suitable for mobile use. After coming to this conclusion, I decided to use UV coordinates to achieve the same results.

Simple shader that turns UV  Coordinates into gradient.

Simple shader that turns UV Coordinates into gradient.

You can even use UV coordinates to create not just gradients but entire dynamic gauges and bars, using shaders.

Creating the shader (using the Strumpy shader editor):

  1. Create a model with a simple UV set (in 3dsmax, simple planar mapping)
  2. Create a gradient by lerping between two colors based on either U or V component
  3. Floor or ceil the gradient value (makes it a hard line, either zero or one)
  4. Add a sine deform based on time, to the gradient value (sinetime)
  5. Add an offset to make the gradient rise or fall (add float value)

You end up with this:

This stuff will stay sharp at any resolutuion and zoomed  -in. All the way until your floating point unit will go BLERGH!

This stuff will stay sharp at any resolutuion and zoomed -in. All the way until your floating point units go BLERGH!








4. Using shaders to add shape enhancing effects (fresnel etc.) to the model

When writing a shader you can combine gradients, vertex color data, and finally some shader specific effects to create a nice unlit shading that is quick to render and accentuates the geometry, instead of hiding it.

The shader algorithm I used is really simple, and can be summed up as such:

  • Create a top down gradient for basic colors
  • Add a fresnel effect, (shiny rim effect based on the normals of your model)
  • Mask the fresnel effect with another gradient (so the shiny rim only applies on the top of the model, not the flat floors)
  • Multiply all with the radiosity vertex colors (adding a dark / light shading to everything)
  • Add a realtime shadow layer to the unlit shader
  • Tweak until right

Here’s how this looks in strumpy shader editor, and here’s a link to the strumpy shader file 

Creating two gradients from Uv coords, 1 to make a color gradient, and one to mask the fresnel effect.

Creating two gradients from Uv coords, 1 to make a color gradient, and one to mask the fresnel effect.

Mixing the fresnel, color gradient and vertex colors and outputting to emmisive (unlit)

Mixing the fresnel, color gradient and vertex colors and outputting to emmisive (unlit).

At one point I even multiplied the gradient with the Y component of the vertex normal, in order to have one color on flat horizontal surfaces and another on vertical surfaces, creating a true height-map look, however I discarded this as being to cluttering in the scene.

Here’s a link to a decent description of what “fresnel” means:

No fresnel effect on the left, and a red fresnel applied on the right, with it masking off towards the bottom.

No fresnel effect on the left, and a red fresnel applied on the right, with it masking off towards the bottom.

5. Using unlit shaders, without lights, but with real-time shadows

Nowadays in Unity3D 4+ you can use real-time directional shadows on mobile platforms, which is great. However, shadows in shaderlab (the in-between system Unity uses for cross-platform compatibility) are part of the lighting calculations. This means that if you make an unlit shader, you have to add shadows in a separate pass, as making shaders unlit or emmisive excludes the effect of lamps or lights on the model, and thus the ability to cast or receive shadows.

Luckily I’ve already done an entire post on this topic , which you can read here:

6. Using select post-fx (bloom) to enhance / soften the look.

Post-fx are effects that take the entire final rendered image of your game and apply different effects to it. Unity Pro ships with a few post-fx shaders that are optimized for mobile platforms. For example: the Depth of Field shader uses a black and white depth image to blur the 3D world, based on depth. This makes everything in the foreground sharper and at the same time blurs the background.

One of the post-fx I’d like to point out is Mobile Bloom and Fast Bloom. The bloom shader is simple: it makes a copy of your final renderview, blurs it and multiplies the blurred result back onto the original, thus creating a soft glow that is most pronounced at very light areas such as the sky.

Without and with the standard fastBloom shader. The effect can be subtle, but be aware of high contrast visuals where it can really go overboard.

Without (left )and with (right) the bloom shader.

End of Part 1

I hope this post provided some insight into making a pure3D or textureless 3D game. It’s not all that difficult, but it does require you to use your tools differently. That being said, much of what I wrote here also applies to more “normal” 3D art assets.

Please let me know on twitter or facebook what you think, or if there’s anything you’d like to see explained or shared. Just hit me up and i’ll do my best. I’ll try and get into specific shaders in the near future.

Tomas Sala


73,084 total views, 55 views today

Een respons op het artikel van Ferry Haan,

Vandaag verscheen het volgende  Opinie stuk van Ferry Haan in de Volkskrant

dit raakte bij mij een snaar, en ik heb dan ook een respons gestuurd naar de volkskrant in de hoop dat dit geplaatst wordt.  Voor de geïnteresseerden bij deze mijn respons:


Game verslaving, de positieve verslaving.

Ferry Haan maakt zich, als leraar en econoom, bezorgd over scholieren die veel gamen. Te veel aandacht en tijd gaat zo verloren, stelt hij. Als game ontwikkelaar besef ik ook dat games een onweerstaanbare aantrekkingskracht uitoefenen, op jongeren en kinderen, maar eigenlijk op alle leeftijdsgroepen. Dat men er verslaafd aan raakt komt voor, maar moeten we het daarom beperken of verbieden, gaan we dan ook Facebook, snapchat, mobiel bellen en internetgebruik inperken? Spelen is van alle tijden, en de computer is nu het platform voor alleen of samen spelen, zoals tennis en voetbal dat was in de dagen van Ferry Haan. Dat heeft ook voordelen, de enorme populariteit van games heeft ook in Nederland tot een succesvolle en bloeiende industrie gezorgd. Onlangs is de Nederlandse game Ridiculous Fishing door Apple tot beste app van 2013 uitgeroepen, maar ook zien we dat er steeds meer games in het onderwijs, de zorg en bedrijfsleven worden gebruikt, gamification is een duidelijke trend in alle sectoren. Ik zie gaming dan ook, anders dan Ferry Haan niet als een probleem, maar als een nieuw vakgebied waarin we jongeren kunnen bereiken en stimuleren. Hij ziet terecht in dat jongeren enorm veel tijd spenderen aan games en dat dit ten koste gaat van andere activiteiten, maar waardeert niet dat gamen ook past bij de multitasking en digitale flexibiliteit die de moderne tijd vraagt. Interactief omgaan met digitale media is een basiseis voor de samenleving van morgen, anders dan leren tennissen. Spelen is een natuurlijk onderdeel van de ontwikkeling van een kind, is nodig voor het ontwikkelen van de eigen identiteit en de toekomstige rol in de samenleving. Waar scholen inderdaad ingericht zijn om op een bepaalde manier vaardigheden en kennis over te dragen en vaak de eigenheid van de leerling (laten) maskeren, bieden games een andere insteek.

Wat spelen in de breedste zin van het woord biedt, is een kans om in de spreekwoordelijke magische kring te stappen (Huizinga, Homo Ludens)en een nieuwe identiteit aan te nemen,namelijk die van speler. Binnen deze veilige omgeving kan de speler veilig en los van echte consequenties experimenteren, zichzelf verbeteren en fouten maken, iets wat in de echte wereld met afnemende privacy steeds moeilijker wordt. De game-industrie heeft dit gekoppeld aan ongekende onderdompeling (immersie) waardoor spelers enorm kunnen opgaan in een virtuele identiteit en er kennis en vaardigheden mee verwerven. De speler moet niet alleen de regels van het spel snappen, maar wordt gebombardeerd met logische uitdagingen die opgelost dienen te worden en daarbij ook sociale vaardigheden oppikt. Identiek aan sport, niet alleen fysieke vaardigheden maar ook teamwerk, hoe om te gaan met regels en scheidsrechters, hoe om te gaan met verlies en succes. Door te spelen leren we ons staand te houden in een veranderende wereld vol met sociale conventies, regels en routes naar succes. Dat overdaad hier schaadt is duidelijk, maar dat geldt voor veel meer en ook voor sport, televisie, internet.

In relatie tot het schoolgedrag en het niet conformeren aan de normen van het systeem van de zogenaamde verslaafde leerlingen kan men het succes van gaming ook anders zien. Ons onderwijssysteem faalt blijkbaar om op eenzelfde manier als games het vermogen tot zelf-ontwikkeling aan te spreken. Zoals Ken Robinson in een ondertussen beroemde TED talk al stelde is ons onderwijs systeem gebaseerd op de industriële revolutie en de behoefte aan gestandaardiseerde vaardigheden en kennis. “Schools kill Creativity” stelt hij. Onze scholen kunnen simpelweg niet concurreren met de ongekende groei en persoonlijke avonturen die gaming kan bieden. Waarom leren over de Zilvervloot en Admiraal de Ruyter als ik diezelfde middag nog de gehele Engelse vloot naar de zeebodem kan jagen (Assasins Creed, Blackflag). Waarom leren over de Griekse oudheid als ik vanavond in de huid van de Griekse god van de oorlog kan kruipen en Olympus kan bestormen (God of War). Waarom zou ik willen leren over de maatschappij en economie als ik kan beslissen over de toekomst van duizenden in mijn eigen stad. (Simcity)

De zorg die Ferry Haan uitspreekt lossen we niet op met verboden en regels, door de geest terug in de fles proberen te stoppen, maar wel door te proberen om die kracht, de prikkeling van de fantasie die gaming biedt aan te wenden voor iets anders dan entertainment. Op dit moment wordt dan ook een nieuw vakgebied gecreëerd waarbij het onderwijs, academici en game ontwikkelaars samen komen om dit spelend leren te vatten in tastbare en verantwoorde producten.

Ik denk persoonlijk, als game-ontwikkelaar, dat we als games-industrie niet op zoek zijn naar een virtueel pretpark in het onderwijs, maar naar verantwoord gebruik van games en technologie. Geachte Ferry Haan u zou eens met eigen ogen moeten zien hoe een VMBO student met taal achterstand in eigen tempo door middel van een game de leerstof tot zich neemt, of wanneer diezelfde VMBO groep niet met de pauze bel het lokaal uitstormt, maar gewoon doorspeelt met de lesstof. Dan zult U direct begrijpen waarom de leden van de Nederlandse Game Industrie zo enorm gedreven zijn in de verdediging van hun vakgebied en we het buitengewoon belangrijk vinder dat er correct en met kennis over dit onderwerp geschreven wordt.

In een cultuur landschap waarin games nu al niet weg te denken zijn in de strijd om de aandacht van de jongere generatie, is het ook de taak van de media om een genuanceerd beeld over games te brengen. De Nederlandse game industrie worstelt zichzelf nu naar boven (zonder noemenswaardige steun van de overheid!) met name omdat we een alternatief willen bieden voor een stortvloed van buitenlandse games en producten, alternatieven die zijn toegespitst op bijvoorbeeld het Nederlandse onderwijs. Een mening waarbij games gelijk worden getrokken met alcohol en tabaksverslaving draagt dan ook niet bij aan een gebalanceerde discussie over het games.

Voor die ouders die zich zorgen maken over de spellen die hun kinderen spelen, een advies. Ga naast ze zitten, pak de controller, Ipad of joystick op en probeer samen te ervaren wat de aantrekkingskracht is. Dat geeft een kijk op wat het kind bezig houdt en zo kunt u zelfs samen beslissen welke game wel of niet geschikt is. Dus bemoeit u zich vooral wel met het spel gedrag van uw kind, niet elk spel is geschikt voor elk kind. Er zijn wel degelijk gevaren in een wereld waarin de virtuele identiteit van het kind zo gemakkelijk wordt geprojecteerd in het echte leven. Dat heeft weinig te maken met het spel plezier zelf, maar wel met hoe de digitale technologie ons dagelijkse leven steeds meer bepaalt.

Tomas Sala

7,615 total views, 10 views today