Teaching players through puzzle design

We were already pretty far in the production process of Tricky Towers when we decided to add a completely new mode; Puzzle mode. Based on missions in 99 Bricks Wizard Academy where you had to place a number of bricks below a certain height, this mode was a nice variation to the stressy Race and Survival modes. We made a single player and a multiplayer Puzzle mode which differ slightly from each other, but I want to talk about the single player for now.

In a single player puzzle level there’s a small floor, a laser somewhere above it and you get a specific set of bricks to work with. The goal is to place all bricks below the laser. When a brick crosses the laser or a brick is dropped the game is over. The trick is to find a way to fit all bricks in a relatively small space.


The first puzzle level in Tricky Towers was designed so each brick has a logical place.

The first puzzle level in Tricky Towers was designed so each brick has a logical place.


Because each level has only a small number of possible solutions this mode is great for teaching a player specific ways of placing bricks. The first puzzle is designed so that by placing each brick in the most logical place available at that moment you arrive at the solution. This design creates affordances; hints on how to ‘use’ this puzzle and each of its bricks.


Affordances are created to give the player hints on where to place a brick.

Affordances are created to give the player hints on where to place a brick.


In the second puzzle we wanted to teach the player a much needed technique we call “overhanging bricks”. To do this we created an affordance for the placement of the first brick of the puzzle by pre-placing a brick using this technique. Even though it’s an obvious hint, players still felt as if they came up with the solution themselves.


The second puzzle teaches the player a new way of placing a brick.

The second puzzle teaches the player a new way of placing a brick.


We try to ramp up the difficulty in each puzzle by keeping in mind what the player has learned so far in terms of brick placement. Based on that we either test their understanding of those skills or give them a surprise that forces them to think out of the box again.

In the first 3 puzzles affordances that were offered always led directly to the solution. In puzzle #4 we wanted to teach you to look at the order of your bricks. The first brick you get fits perfectly into the base without moving or rotating it. However, doing this will get you in trouble later on when you have to place a long brick. Most playtesters figured out in the 2nd try that they should leave the gap for the 4th brick; the long brick. After doing so each brick becomes a perfect fit again and the puzzle is easily solved. You could argue that you shouldn’t punish players for doing something you taught them earlier on. But when the steps to understanding such a switch are small enough you can play with their expectations without creating frustration.


Puzzle #4 teaches the player to think ahead by starting off with a misleading affordance.

Puzzle #4 teaches the player to think ahead by starting off with a misleading affordance.

When the sequence of bricks is taken into account, and the previously learned overhang technique is used, the design makes sense again.

When the sequence of bricks is taken into account, and the previously learned overhang technique is used, the design makes sense again.


As always, it’s easy to design puzzles that are very difficult. The hard thing is to make them so the player is constantly on the border of not understanding and then suddenly getting it. If you can ease that in with little nudges and hints hopefully they’ll feel as though they came up with it themselves. I think it is in those moments, when you realised you’ve learned something, that play is most satisfying.

Snappy Analog Controls

When you create a game one of the most important things to get right from the start are the controls. If your controls are nice and solid then it’s a lot easier to create layers of gameplay on top of that. If your controls are weird and twitchy then you’ll find yourself tweaking a lot of gameplay simply because everything feels off and the way your game plays is just not what you expect. This is exactly the same for Tricky Towers. Because our game relies heavily on smart thinking and precise stacking of bricks the controls should be really solid. You don’t want to slam your brick down while you were just trying to move it slightly to the left.

When we started implementing the controller support for Tricky Towers we found that most of the development team preferred to use the D-Pad to move their bricks around. It’s fast, precise and chances of making an error by using the wrong button are very slim. But after testing we found that quite a lot of people still pick the analog stick to control the game. It was pretty obvious that we didn’t have a choice: analog controls had to work, because people expect them to.

To achieve the optimal way of handling input we came up with the system of ‘filters’. On top of the raw input that we get from the controllers we apply filters that handle the way we want to interpret these values. This can range from simply making analog input digital, to more complicated methods to see what the player is doing. In case of the left analog stick we started out by simply dividing the analog stick into 4 regions.
analogQuadrants

The tiny red circle in the center of this image represents the current direction of the analog stick. When you press the stick upwards it counts as pressing up on the D-Pad. Press it left, it’s just like a left button press. Sounds simple enough to work right? Unfortunately, it’s not. The controls felt twitchy and even though as a player you might think you have a solid reference as to what direction your thumb is pushing the analog stick into, most of the times it’s not as precise as you’d hope. We’ve seen many cases where players would rotate or slam a brick down on their tower even though they just wanted to give it a little nudge. Especially on the edges of the quadrants (the white lines) the input would get jittery because of slight imprecision of the input values.

The solution we found is quite simple but very effective. Every time you move the analog stick into a certain direction we enlarge the quadrant you’re in. In this example we push the stick to the left. We register this input and therefore enlarge the left quadrant. Now there’s a lot more room for you to move the stick around without accidentally hitting up or down. Once you actually do cross the edge of the left quadrant to for example the upper one, we do exactly the same thing but for the other quadrant.
analogLeftanalogUp

Since the scaling of these areas is done instantly there’s a lot less jittery input between the different directions. Every time you cross the borders between two areas we move the border, so there’s no way you can go back and forth by accident.

There was still some weird behavior when the stick was around the center position because the margins of the areas would become very small. With the slightest movement you would give random input because you actually were switching quadrants by just the slightest movement of your thumb. To fix this problem we simply added a ‘deadzone’ to the center of the analog stick. As long as you stay in this area there won’t be any input registered at all.

analogDeadzoneanalogDeadzoneUp

And that’s it! Now we have nice, solid controls for the analog stick and it’s a matter of preference whether you want to use the D-pad or not!

Utilising Unity shaders to recreate Photoshop blend modes

During the development of Tricky Towers it was my responsibility to research shader effects in order to spice up our graphics a bit. I was quite new to WeirdBeard and working with Unity, and WeirdBeard were quite new to using shaders, since we’d predominantly made games for mobile and browser in the past. I’m by no means experienced with writing shaders, but I have amused myself writing some OpenGL projects and had some experience with HLSL when I was working on XNA games – so I at least knew the correct questions to ask when starting my research.

Our artist especially wanted me to look into recreating blending modes that he was used to using in Photoshop. There was actually surprisingly little online about this – so hopefully this blog post helps others.

Basics

Since I’m used to glsl and hlsl shader files – and the communication between those and c++ and c# respectively – I first had to get my head around how Unity does this.

ShaderLab

Unity (unsurprisingly) has done the hard work for us and provides us with an interface between the shader itself and the Unity material it will eventually be tied to. This is called ShaderLab. Each shader file must begin with the ShaderLab root command “Shader”

Shader “name” {

     //rest of the file goes here

}

This is all set up for you by Unity when you create a shader within the editor – but it can be useful to change the name.

Properties

The first command inside these braces is usually “Properties”. In here is a list of parameters that can be set in the Unity material inspector (or of course, via script). These properties will become inputs in your shader code later on. General syntax for these is:

name (“displayed name in editor”, type) = defaultvalue

Subshader

Next comes the Subshader command. A shader must have at least one Subshader – when the game is loaded Unity will choose the first Subshader that is supported by the user’s machine.
Within the subshader there are three different types of shaders that can be written. Surface shaders, vertex & fragment shaders and fixed function shaders.
Fixed function shaders are deprecated in Unity 5, so I won’t talk any further about those.
Surface shaders are most useful for lighting calculations – and since we’re not using any lighting effects in our game (so far) I did not research these any further. Also because I’m more familiar working with vertex and fragment shaders, I found the surface shaders quite restrictive.

So, on to vertex and fragment shaders. These are more complex to write than surface shaders, but they are more flexible and can achieve more. They can be written in CG or HLSL, but Unity recommends CG for performance reasons.

Pass

The shader code needs to be written inside a pass block inside the subshader. A pass block causes the geometry to which the shader code is attached to be rendered once. So, multiple passes inside a subshader will result in multiple renders of that geometry.

The vertex and fragment shaders are embedded within a pass with the CGPROGRAM and ENDCG keywords.

Vertex & Fragment shaders

The first things to write in here are the compilation directives. Most useful are:

#pragma vertex <name> //the name of your vertex shader
#pragma fragment <name> //the name of your fragment/pixel shader
#include “UnityCG.cginc” //contains a number of really useful functions to use in the shaders

After this we can list the input variables we specified in the Properties section. We also have to create a struct to be used as the output of the vertex shader and the input of the fragment shader. We can then list the vertex and fragment functions. The vertex function should return an instance of the struct defined earlier. The fragment function should return a fixed4 that represents the colour of the pixel.

struct v2f {
     float4 pos : SV_POSITION;
     float2 uv : TEXCOORD0;
};
v2f vert (appdata_base v)
{
     v2f o;
     o.pos = mul (UNITY_MATRIX_MVP, v.vertex);
     o.uv = TRANSFORM_TEX (v.texcoord, _MainTex);
     return o;
}
fixed4 frag (v2f i) : SV_Target
{
      fixed4 texcol = tex2D (_MainTex, i.uv);
      return texcol * _Color;
}

The vertex shader above takes in an argument of type appdata_base which is a structure defined in UnityCG.cginc. All this shader does is convert the vertex and uv coordinates for the texture from world coordinates into screen coordinates – if you aren’t sure how this works, then the following links give quite a good introduction: link1 and link2.

The fragment shader is sampling the texture using the correct uv coordinates for that pixel (as calculated by the previous step and then interpolated per pixel) and multiplying the result by a colour that has been passed in to the shader. So if the colour is white then the texture will be displayed on the geometry with no change.

Applying the shader

Within unity the shader file needs to be attached to a material. This material can then be attached to a component that’s attached to a game object in order to affect that game object.

Shader model version

By default Unity uses shader model 2.0 (equivalent to 2.0 for Direct3D 9). Usually this is enough, and will work on the most platforms. I did once have an issue because I was using too many arithmetic instructions, so I moved up a version with the command:

#pragma target 3.0

Apparently this only knocks out Windows Phone 8 and Windows RT, neither of which are platforms we are targeting.

Errors

You will make mistakes during development – and Unity actually gives you a fair bit of information about shader compilation errors. When looking at the shader in the Unity inspector, you can see a list of errors that will usually point you in the right direction.

shaderErrors

 

You can actually still compile and run the game with a shader error – the offending shader will just colour your object bright pink. This does mean you can edit your shader code while the game is still running though!

 

Blending

So far so good. All of this has been pretty basic, and there were a lot of resources online (especially the Unity manual) to help me with this information. Blending is actually part of the fixed-function pipeline – meaning that the graphics card will handle blending and the only way to customise this is to tell it which blending methods you’d like to use. The graphics card will compare the colour results of multiple shaders for a pixel and decide how much that colour will influence the final pixel. Since photoshop blend modes are not built in, I needed to simulate the effect of blending. So within the one shader I need to compare two colours and mix them together accordingly. The two colours I need are the colour of the object being rendered at that texture coordinate, and the colour of whatever was behind my object at this position. The first is not so difficult – we can actually see it being calculated in the code above. For the second I would need to have already rendered the screen in order to determine the colour the screen behind my object. Luckily Unity provides a method to do that. This comes in the form of an extra pass called a GrabPass.  Grabpass saves the current contents of the screen into a texture which you can then access in the next pass (with the variable _GrabTexture). From this texture – I need the colour at the correct pixel co-ordinate. Calculating the colour needed from the texture of the object is easy – in fact the shader example above is doing exactly that. But I will also need to calculate the UV coordinates for the grab texture – I can do this by calling the ComputeGrabScreenPos function in the vertex shader and passing along the result to the fragment shader. EG:

struct v2f {
     float4 vertex : SV_POSITION;
     fixed4 color : COLOR;
     float2 texcoord : TEXCOORD0;
     half4 screenuv : TEXCOORD2;
};
v2f vert(appdata_t v)
{
     v2f o;
     o.vertex = mul(UNITY_MATRIX_MVP, v.vertex);
     o.color = v.color;
     o.texcoord = TRANSFORM_TEX(v.texcoord, _MainTex);
     o.screenuv = ComputeGrabScreenPos(o.vertex);
     return o;
}

Then in the fragment shader we can calculate the colour like so:

fixed4 colour = tex2D(_GrabTexture, float2(i.screenuv.x, i.screenuv.y));

Alright, now that we have two colours we can actually get started with blending them together. So far in Tricky Towers we’ve used Multiply and Overlay blending.

Multiply is quite easy – all we do is multiply each channel in one colour by the corresponding channel in another colour:

fixed4 base = tex2D(_GrabTexture, float2(i.screenuv.x, i.screenuv.y));
fixed4 top = tex2D(_MainTex, float2(i.texcoord., i.texcoord.y));
fixed4 col = fixed4(0, 0, 0, 0);
col.r = base.r * top.r;
col.g = base.g * top.g;
col.b = base.b * top.b;
col.a = top.a;

Overlay is only slightly more complex. For those people like myself who are allergic to photoshop – the Overlay mode lightens the light areas of the top colour and darkens dark areas of the bottom/base colour. The algorithm is actually on Wikipedia and is quite easy to implement: https://en.wikipedia.org/wiki/Blend_modes#Overlay

float Overlay(float base, float top)
{
     if (base < 0.5){
          return 2 * base*top;
     }
     else {
          return 1 - 2 * (1 - base) *(1 - top);
     }
}

And within the fragment shader:

fixed4 base = tex2D(_GrabTexture, float2(i.screenuv.x, i.screenuv.y));
fixed4 top = tex2D(_MainTex, i.texcoord);
fixed4 col = fixed4(0, 0, 0, 0);
col.r = Overlay(base.r, top.r);
col.g = Overlay(base.g, top.g);
col.b = Overlay(base.b, top.b);
col.a = top.a;

So what was the result? See for yourself!

brickGuide

On the left you can see the effects of the overlay shader on the brick guide (the vertical lane of lighter area surrounding the brick). On the right is the same texture but with just a regular alpha blend. The overlay effect certainly provides us with a richer tone, and makes the brick guide easier to see.

Note: We’re using SV_POSITION instead of the normal semantic POSITION in order to be compatible with PS4.

Game Show Pack List (GSPL)

I was going to write a blog about my experience exhibiting at Paris Games Week and compare it to GamesCom, but rather quickly it turned into a list of what to take when going to a conference (a bit like those vacation packing checklists). Maybe not as fun to read, but definitely more useful.

Download the google sheet checklist which you can use when packing. Feel free to contact me with suggestions.

Also I want to thank tinyBuild for their blog on surviving a game convention, which was really helpful for me this year.

Here we go.

Basics

Stuff you always need to take with you.

  • Business cards – obviously, put your name, contact info, and website on it. Maybe use the back to show a nice image of your latest project. It is free promotion and it looks nicer than a boring corporate business card, so people will remember you better. Make sure to bring enough!
  • Presentation – have a presentation showing projects you did, projects you’re working on and concepts. Maybe some videos if you have them. Put it on both your phone and tablet so you’ll always have it with you. You never know who you’ll bump into!
  • Demo – make sure you have a WORKING demo with you. Better to show less stuff that’s working than a lot of stuff that doesn’t work. More on ‘the demo’ later.
  • Mints & deodorant – Always have these close by. Everybody smells after three days of standing at their booth and going to parties till late in the night, there is no shame in that. But there is no reason to leave it like that.
  • Internet; get a local sim-card or try a Karma hotspot

You are looking for publishers

So your main goal for this show is to find people who want to give you money?

  • Prepare your pitch! There are a lot of good articles on Gamasutra about that. (1, 2, 3)
  • Make appointments beforehand – people will be fully booked by the time they get to a conference so make sure to contact them beforehand and make an appointment.
  • Bring a hard copy appointment schedule – Better safe than sorry, you don’t want to miss your meeting because your phone was out of juice or internet connection and you didn’t remember what meetings you had.
  • Research – look up who you are meeting with on LinkedIn, what games did this publisher recently release? Did they win any prizes? Use this knowledge to compliment them, show them you know stuff and impress them. Meeting with publishers is like going on a first date.
  • Pen & Paper – Old fashioned? Yes, but you won’t have your tablet or laptop available to type stuff because that is showing your demo.

You are looking for press

Basically you are craving for attention. Youtubers with a million followers, famous Twitch players, journalists, anyone who will spread the word about your game.

  • Prepare another pitch! Pitching to press is different from pitching to publishers.
  • Make appointments beforehand; Try to leave some space between meetings, because they can easily run over.
  • Have a press kit ready, and always follow-up by sending an e-mail with a link to your press kit. Check presskit() by @tha_rami for an easy to set-up presskit.

You have a booth

Hurray, you have your own booth, arcade cabinet or whatever. That is awesome because now you can show your game to the public. It is also horrible, because standing at a booth is like having a thousand speed-dates in a few days.

  • Make sure your booth is asshole proof – controllers, monitors, dev kits, pcs, tablets, cables make sure they are all connected to the table. Because people will steal your stuff and you won’t be able to keep an eye on your stuff all the time.
  • Throat relievers – Strepsils, Anta-flu, Ricola, cough medicine – anything that will help your throat, because you will be doing a lot of talking.
  • Giveaways – Always have something for people to take. People love free stuff, so it’ll draw them to you. And it gives them something to remember you by when they come home. It can be anything, flyers, candy, buttons, t-shirts, stickers.
  • Game controls hand-out – a laminated hand-out to give to players waiting in line so they will already know the controls and can start right away when it’s their turn.
  • Food and drinks – bring water and energy bars or fruit, you’ll get hungry and thirsty and won’t always be able to leave your booth. (Also: food at convention centers is often crap and expensive).
  • Banner – make something nice that draws attention to your game.

You’re just going for the talks

Really? Going just to listen seems like a waste of time, most of the talks will be available online anyway. It may be worth adding something else to make your trip more worthwhile. Meet-up with some other developers, do some live blogging, go to parties, or maybe even try to be a speaker yourself? In any case here is what you’ll need:

  • Social media set-up – set-up your Tweetdeck or Hootsuite for the conference by creating lists of speakers and other interesting streams.

Pack like a pro

These are some things that may always come in handy, but are not a necessity.

  • T-shirts – print t-shirts with your company or game logo on it. Have more than one if you plan to wear it all week!
  • Free keys – print business cards and with steam/iOS keys on them so you can give them to that special person.
  • Money – don’t be cheap, when you talk to someone offer them a drink or pay for lunch. Especially when you want to impress them. Don’t stand there waiting for others to pay.

Also check this video to help you packing: https://www.youtube.com/watch?v=LIk8v__Osm8

The DEMO

Finally we’ve come back to the demo. Please remember: A demo is not the latest build of your game! It is designed for showing the core experience of your game to a new audience in a short session!

  • Don’t try to show everything – show the core. Maybe create content just for the show. A level which is easier or shorter than it would normally be, but does allow a new player to jump right in.
  • Have a video to show all the other cool stuff that is in the game and leave the players wanting more.
  • Automatically go to the video when no one is playing.
  • Don’t explain everything. People just want to have fun, not play a lengthy tutorial for a game they may never buy.
  • Localize your game for the host country. People will understand your game better and it is polite. Maybe learn to speak some basic words.
  • Make sure everything works!

Normal stuff

Stuff you would also need to take when going on holiday, which I’ve put here just for packing convenience.

  • Laptop + charger
  • Phone + charger
  • Power adaptor + power board; to save money on buying multiple power adaptors for all the items you need to plug in.
  • Passport
  • Flight/train/bus ticket
  • Hotel / AirBNB reservation
  • Clean clothes and underwear
  • Comfortable shoes; you’ll be doing a lot of standing, walking, dancing
  • Toiletries; don’t expect the AirBnB to have everything ;)
  • Something to read, get your mind of things

 

99 Bricks insight: A slight breeze

We already told you about the happy accidents we sometimes had during the development of 99 Bricks. The idea of adding wind is one of them. In the classic version of 99 Bricks we used Box2D as our physics engine. Because of the imprecision of Box2D, your tower would start wobbling around after a while, messing up all your carefully placed bricks. “Turn that damn wind off!” was one of the most heard comments, even though there wasn’t any wind to begin with.

But with 99 Bricks Wizard Academy things are a bit different. We have a more rigid physics engine, meaning your tower won’t topple over that fast. Building a rigid tower became a pretty easy task. A little bit too easy actually, because placing bricks on top of each other without much thought turned out a very effective but boring strategy. There isn’t much fun in just swiping those bricks down over and over again to reach a highscore, right? Exactly! So that’s why we decided to add wind as a feature.

Our first shot at simulating wind was pretty rough: We took every brick that was capable of moving and applied a force to it. But we figured out soon enough that this wasn’t the way to go. If the wind was strong enough to be noticeable, the tower would fall over no matter how well constructed it was, because every single brick was being influenced by this force. If we brought the strength of the wind down to be acceptable, the game became too easy again. No matter how instable your tower was, the wind wasn’t strong enough to make the bricks fall. Also, by applying a force to all bricks, things felt really unnatural. Sometimes bricks would fall over, even if something seemed to block the wind, like a couple of stacked bricks. So applying a force to all bricks wasn’t an option and we had to think of another solution.

Apply a force to every single brick

The final implementation of the wind turned out to be pretty simple. We tried to think about how wind actually works: a lot of air particles bashing into your tower. And that’s exactly what we did. But instead of using particles to throw at our bricks, we are using raycasts to ‘scan’ the top part of your tower from left to right. Every time we hit a brick, we apply a small force at that specific point, just like the air particles would. This solves the problem of bricks being blown away that are actually being kept out of the wind by some other part of your tower. Also the strength of this force varies a bit over time to make it feel more like small gushes of wind instead of a continuously storm messing up your tower. This way the wind becomes a fun but hard to predict factor in the gameplay and gives it a more realistic feel.

Perform a raycast and add force on impact

To save some performance we only apply the force of the wind to bricks that are still allowed to move, so we skip petrified bricks. We also limit the wind to the top part of the tower that is visible to the player, because it feels unfair if your tower collapses outside of the screen without you knowing what caused it. Therefore it doesn’t make sense to raycast the entire tower.

As a finishing touch we added some animations and dust particles that float around your screen. This also makes sure the player understands the presence of wind and really gives the impression of being high up in the sky where a magical breeze flows through your wizardous hair!

Creating a loveable character

There are many uncertainties in life. But one thing we all know for sure; if your mobile game has a character it needs to be loveable and cute! Of course this should be taken with a grain of salt but we knew we wanted it for 99 Bricks. The nature of the game is very unforgiving and challenging so we tried to make everything around it as friendly as possible to compensate for that. Since our players will probably try to identify with whatever character we put in their faces, the tiny wizard in 99 Bricks serves a great part in setting the mood of the game.

We wanted him to radiate joy and fun, never giving the player negative feedback. During the meeting in which we discussed the setting of Wizard Academy I was already doodling for the main character. Even though you never really do anything with the character in 99 Bricks I still wanted it to be on the screen during the entire game. This meant it had to be small so it wouldn’t distract or obstruct any of the relevant game elements on the screen.

 

The first character sketches made during a meeting.

Because of its size the amount of detail in the outfit couldn’t be too high. In fact every dark line would quickly be too much. This meant I had to prioritise what would make him look like a happy wizard most. Besides that, we had a wardrobe system in mind allowing the player to mix and match different cosmetic elements to customise their wizard. This meant its shape should be generic enough to fit different costumes and it should be as easy as possible to produce so it wouldn’t take too much time to create a bunch.

 

Early sketches for the character, outfit variations and color ideas

This is also the reason our character only has 7 different frames of animation. The 12 basic principles of animation had to be stripped to the bare minimum; only anticipation, timing and exaggeration remained. The 2 action / casting animations have 1 keyframe for anticipation and 1 keyframe of the action itself. All the in-betweens were left out. Obviously the result was a bit too static, so to disguise the lack of frames I added 2 small effects that do have more frames. This makes it feel more dynamic because something is always moving. On top of that we made sure the cloud the wizard is on gently floats around (originally we planned to have the wizard standing on the highest brick. However, while we were prototyping this system, we figured it would be much easier to have him fly around the screen on a cloud instead).

 

The frames used in the "action" animation with an added effect.

So, big smile, easy to reproduce shape, simple details and effective animation. It was time to add some sound. We wanted a broad range of voices so we decided to record some stuff ourselves. Apparently, if you pitch my voice up with 15% it’s enough to make it sound like a tiny wizard. We made up some words that didn’t sound like any particular language at all and went for it without too much thought.

The final result looks and feels alive enough to help set a positive mood. We left out all negative reactions the wizard could’ve had, when you drop a brick or when a jealous wizard appears, to accentuate the happy moments. When you pickup some magic he cheers. When you accidentally tap the wizard, he waves at you and blarbs something that sounds like a baby trying to talk. This almost always resulted in a smile on the play-testers’ faces. Earlier versions of 99 Bricks would test your temper. Now, when you drop a brick or your tower collapses, there’s a tiny fellow there to remind you it’s not all that bad.

 

The final design for the ingame wizard.

The wizard customized with different outfit elements.

The wizard as shown in promo art.

99 Bricks art styles through the years

In a previous post I promised to tell you more about the art style of 99 Bricks and in ‘Burning Pockets’ I talked about the shift to the Wizard Academy theme. Below I’m showing you a timeline of all the styles we had for 99 Bricks since 2008:

2008: 99 Bricks Classic

The classic 99 Bricks on Kongregate.com was very techno. At that moment we didn’t have a schooled artist, we were just a team of programmers, so that is also reflected in the design somewhat. The Bricks themselves were made by a friend of ours.

99 Bricks Classic

2009: 99 Bricks Legend Of Garry

A level-based version of 99 Bricks with puzzles and a story, released first on Armor Games. We still didn’t have an artist, but we did have some budget this time around, so we asked M. Vermeulen of 9meter design to help us out. Also we tried our hands on a story. You play Garry who has to save Brickonia from Evil Harry by building towers to spread the light… (…seriously????)

I think we stretched it out too thin, I still love the puzzle levels though.

Legend of Garry

2010: Technoid Trouble

A special adaptation of 99 Bricks for the Club Galactik MMO created by Virtual Fairground (based on the series Galactik Football). By completing missions in Technoid Trouble, the player unlocked new areas in the Club Galactik world. The art for this version was done by Virtual Fairground.

Fun fact: S. Louwe, our game designer and the artist for 99 Bricks Wizard Academy, was working at Virtual Fairground at the time and did the mission design for Technoid Trouble.

Technoid Trouble

2010: 99 Bricks 2 Concepts

From here on we finally had an in-house artist in the person of D. Grinwis, so these were the first designs we made since the original!

For GamesCom 2010 we created a game design document for 99 Bricks 2, which was about creating shapes instead of building the highest tower. We pitched the idea to Sony as a Mini, but it didn’t work out. (Read more about why here).

Maybe 99 Bricks Wizard Academy will make it to Vita??? Let’s hope so…

Concept for 99 Bricks Mini

99 Bricks 2 Promo

2011:  99 Bricks Mobile Concepts

We started with the development of 99 Bricks for mobile in 2011. We started out this project as a quick port from Flash to mobile, that’s why the first designs look a lot like the 99 Bricks Classic. Here are some of those concepts.

    

2012: 99 Bricks Wizard Academy

In 2012 we decided a straight port just wouldn’t cut it. We worked on new gameplay, did a style poll amongst our fans and tried out multiple designs to get to our final look and feel for 99 Bricks Wizard Academy.

Style Poll

    

So here we are, the final product. Is this better than anything before? Let us know what you think on Facebook or Twitter!

 

Free-to-Read articles on Free-to-Play

Wow, it has been a while since our last blog post. What have we been doing you are asking? We have been monitoring the 99 Bricks Wizard Academy Soft Launch and working on some other projects. We have had a lot of discussions on free-to-play design and how to improve 99 Bricks’s retention and monetization, without being complete dicks. Though we haven’t completely figured it out yet, we have read a lot of interesting articles on F2P. so if you’re interested, here they are:

http://gamasutra.com/blogs/NicholasLovell/20130919/200606/The_Pyramid_of_FreetoPlay_game_design.php

http://www.tipsfromsiliconvalley.com/2013/03/24/how-to-improve-user-retention-in-your-video-game/

http://melvindbanares.wordpress.com/2014/02/06/game-retention/

http://12storiestall.com/freemium-game-design-dictionary/

http://www.gamasutra.com/view/feature/207779/ethical_freetoplay_game_design_.php

http://www.developereconomics.com/mobile-gaming-dirty-secret/

http://www.gamasutra.com/blogs/RaminShokrizade/20130626/194933/The_Top_F2P_Monetization_Tricks.php

http://www.gamasutra.com/blogs/RaminShokrizade/20130516/192386/Systems_of_Control_in_F2P.php

Burning Pockets

So last time I promised to tell you more about how we got to the Wizard Academy theme after the Facebook style poll. Well here we go.

We went to a Local Multiplayer Meetup in Utrecht organized by Vlambeer’s game designer Jan Willem Nijman. We all had an iDevice with a build of 99 Bricks on it in our pockets and went there with the intention to show it to all our well-known colleagues in the Dutch Game Garden. But after showing it to 1 or 2 people and getting nothing more than “yeah, pretty cool” out of them we weren’t so eager to show it anymore.

The next day Joram, our creative director, realized a good game should be burning in your pocket. You should be forcing it into every hand you can find. The images should be radiating from the screen and people should be in line asking what awesomeness you are playing. We took a step back and saw that what we made was not up to par with what we like to play. There was no place for our game in today’s market. We had to make a radical change once more to make it work.

Joram got into a no-nonsense mode and took the team along for the ride. He went ahead and made a more conventional F2P design for the game and told Samar to make a concept for a fresh and captivating world this game could be set in. The goal was to convince me (Niels) we had to take yet another U-turn to make this game a success.

After a weekend of concepting, a long serious talk and some rough planning they had me along. We were going to make this game about a wizard apprentice. Everything about the game should breathe magic, cuteness and humor. We wanted to redo all the graphics, add a little story, add a character, create a world for this character to live in, create enemies to fight with, add houses to build on, staffs to get perks from and outfits to choose from. It was going to be a lot of work and decided we had to stop overthinking everything and just produce.

Designing a completely new world opened a ton of new doors and we all realized we had not been having this much fun working on the project in a long time. There was room to add a lot of humor and silly things making both the work and the product more fun.

            

From Flash to Paper to Lessons Learned

We are an indie developer, but that doesn’t mean we shy away from publishers. Don’t get me wrong, we are very happy being independent, but from the very first beginning we have been looking for publishers for 99 bricks. Starting with the original Flash game, where you just had to build the highest tower with exactly 99 Bricks, hence the name.

We send e-mails to a lot of Flash portals, asking if they wanted to publish the game.  Most of them wanted to and offered a flat fee for all rights to the game and it’s sequels between $1000 and $2000. This was ridiculous. We had been around long enough doing work for hire to know this was a bad idea.

Finally we got in contact with Kongregate who gave us a good deal, where we could keep the rights, get royalties and some money upfront and do what we wanted. We are still thankful to them. The game was originally released in november of 2008. The game got badges, gained immense popularity in the community and after a while was spread via the Mochi network to hundreds of other portals and has been played in every country in the world since (even in the non-UN recognized countries).

So then what happened? The game was doing great but we couldn’t make a living out of the game. We started doing more (non game related) work for hire. And decided to find a publisher for a sequel to 99 Bricks before doing any further development. This was the wrong way to go at it!

It lead to hours of talking, writing numerous game design documents, creating flyers, basically doing a lot of work but no actual game development. At GamesCom 2010 we had meetings set up with a lot of publishers, who said: ‘Sounds great, do you have something we can play?’. And we only had the flash game to show them. Which is basically a tech demo when you are proposing a full disc title.

99 Bricks  flyer we created for GamesCom 2010

So that was the wrong way to approach this. When you have a great game you’ll just have to keep on developing, don’t expect to get money based on a piece of paper.

In 2012 we decided to start working on a mobile version of 99 Bricks, a straight port from the original to iOS. Just to get some experience with creating a mobile game. We wanted to keep it simple and do it fast. Luckily that failed.

Paid games weren’t making any money at the time and we decided to go with F2P, but do it nice and honest. We tried to make it more casual, using a more real world feel in what we called the Children’s room theme. The idea was to let you play in a kids room with wooden blocks, and have a giant bay stomping around to mess up your tower.

We started working and took the game to publishers at GDC and GamesCom and send out lots and lots of e-mails. Two times we almost signed a deal with publishers we knew very well, but in the end they backed out. This was in the first half of 2013. Dealing with the publishers was not a waste of time though, on the contrary. During the negotiations they gave us lots of free feedback, made us look at the game from more angles, pushed us to think about making money, while we thought about how to not turn it into an evil money making machine. But most importantly, we had remembered our first lesson; we kept developing. After the second publisher backed out we decided to stop looking for publishers for this project and do it our way and learned two other major lessons.

First, not everything in the game was aligned. What I mean by that is, gameplay and style, but also structure and business model all should go hand in hand. It just didn’t feel one hundred percent right.

Second, we were now officially indie. Therefore we had to get more out there and create a fan base.

The first action using both these lessons was posting a poll on Facebook asking people which theme they liked best. It came out 50/50 and we decided on a completely different theme afterwards. And that’s a story for next time…

Style poll among Facebook fans. Score 50/50