our rambling
Want to be notified of new blog posts?

Elwin Verploegen

Lessons learned after 1 year in business March 26, 2015

By Elwin

March 1st 2014 is when we moved into our first office, and is also when we started working on Fragments of Him full-time. Since then we’ve learned a lot about making games and running a business. This blog post will go over some of the lessons we’ve learned and mistakes we’ve made.

Setting up shop

Setting up shop

We officially registered with the Chamber of Commerce on the 8th of March 2012, with a different name than SassyBot Studio. In this period Tino and I were still in college so setting up shop early gave us some time to figure out what it takes to run a business while there was still little risk involved. Signing up to be a company in the Netherlands is cheap and easy (all it takes is a single meeting). Running a company, however, isn’t.

We used the roughly 2 years of start-up time to write up a contract between the partners. Some of what this contract covers are things such as splitting of profits & losses and what happens when a partner leaves the company. There are a lot of things to think about and talk about with your business partners, so make sure you spend the time to do so or it might come back to haunt you. In the Netherlands you can get a basic template contract provided by the Chamber of Commerce (at least for our type of company). We amended this with a couple of points that we thought were important. Make sure to get a lawyer involved if you want this to be 100% secure.

We also joined a government funded organisation called Starterslift that helps startups with business, legal & financial support (including loans if required). They helped us lay many worries to rest and answer questions that would normally keep us up at night. In return, Starterslift asked us to fill out a yearly report (takes roughly 15 minutes to fill out). Try looking around in your area to see if there are anything similar startup support organisations, I’m guessing some of the bigger universities will have similar services and facilities available.

Spend some time to get your name out there, start networking. We picked up some minor contract
work along the way, which wasn’t only great for having the extra bit of cash in college, it also helps you build up a portfolio and a network of people. Our very first client is still with us to this day and we regularly benefit from those long term relationships.

Running a business

Something I was told by almost everyone, was that running a business actually costs you a lot of time in simple overhead. At the time this sounded silly, and it was at first. And then you realised that there’s actually a lot of things you have to do outside of building games. There’s bookkeeping, public relations, communication with clients, team management, update all the various relevant social channels, acquisition, travel to meetings all over the place and in between all that there is the challenge to find time to develop a game.

Whenever you make a planning, add time to manage these things. We certainly didn’t think about everything, so make sure you dedicate time to handle the various other things that come up, including contract work.

Administration and taxes

Administration & Taxes

If there’s one thing I hate doing, it’s my bookkeeping. I find it tedious, boring and I’d rather be writing code instead. However, it seems that the government is quite keen on everyone keeping track of what they’re doing with their money. I have spent roughly 2 weeks studying up on bookkeeping, making up a balance and in general how to handle money for a business. This is time well spent and you’ll hate yourself if you don’t do this right from the start.

We got an accountant to check if we’re doing our bookkeeping right, but you can also just pay a bookkeeper if you can spare the money. Just make sure to do everything according to the rules. If you’re in America you’ll probably need to hire someone to file all of your taxes. In other countries, like the Netherlands, most of this is actually not that difficult to do (but you should probably always get an accountant. You don’t want to make mistakes here that may bite you in the ass after a couple of years).

Keeping the lights on

This is a recurring topic with almost every entrepreneur, where do you get money from? Well in our case we looked for government funding. There are a lot of people looking at the same bag of money, so you better prepare one hell of a pitch. Browse around on your government websites, there’s usually a lot of funding that applies to games (multimedia, art, innovation in technology, and even cultural funds). Adriaan de Jongh, from the game studio Game Oven, has written an article on how they managed to receive funding for their game concept from the same fund that we had success with.

Something that most of us will end up doing while developing our first game, is contract work. Contrary to popular belief, this rarely ends up being “make a clone of this game please”. We’ve had a wide range of projects coming our way, and all of those ended up being an interesting experience. Finding contract work however, is a completely different beast. Remember how I mentioned that you should start building up a network as soon as possible? This is why. If people know what you do and what you could mean to them, it’s likely that they’ll think of you when something in the general area of games pops up. Animation? You can do that. App? You can probably do that. There’s a lot of areas of expertise that you can cover with a game development studio, make use of that.

Making a game is great, you know what’s even better? Having food on the table every day. You’re a business now, think like a business.


For some reason, this has become some dirty word to many game developers. Marketing, however, is quite possibly one of the most important things you do as an independent game developer. Marketing takes time and you can’t expect to reach the audiences that matter to you with a single push effort when your product is released. With any released product, you would like people to know about it and buy it if it is any good. As a proof in point, in the past we have shipped a little game called Small Bang Theory to Ouya, Android, and iOS supported by a website and a press release. It is no secret that this has not been a success in sales although it has been a success in valuable lessons learned. We believe that one of the reasons this game did not do well in sales is that it did not provide an appealing value proposition and that it did not reach enough people. We fault the latter to a lack in support from fans and followers that will gain us the outreach we need for when one of our products is released. So what have we set in motion since then and learned about this in the past years?


Every 2 weeks (we miss one every now and then, things get busy!) we post a blog about things we have going on at the office or updates on the game. As with every form of public outreach, consistency is very important. Try to stick to a schedule as much as possible and people will frequently return. Our blog contents have reached around 30000 people last year, just using our websites.

Setting up a blog is trivial, especially if you know how to make games. Grab a domain & hosting and set up a WordPress blog, most companies allow you to set one up from within their backend panel. Find yourself a nice template (if you have knowledge in building websites, customize one to your liking) and you’re good to go. Do some research into what’s cheapest in the long run, most companies charge you $1 or so for the first year, and then ask you way too much for all years afterwards. If you need a recommendation for hosting a website in the Netherlands, get in touch with me and I’ll send you in the right way.


If you aren’t on Twitter yet, you should. There’s an amazing amount of indie devs on Twitter, and it’s a great way to get in touch with them. It’s relatively easy to start buildin relationships with other devs & journalists. You have to get used to typing in 140 characters, but that won’t take you very long. Do note that your message will get buried insanely fast, and it’s difficult to keep your messages relevant for longer than a minute. We’re currently around 450 followers, how many people we can effectively reach from our Twitter account is not known (I assume not that much, since Twitter moves very quickly).


Even after recent changes that your Facebook messages will most likely not be shown to a lot of people, it’s still worth it to maintain a presence. There are a lot of people that actively use and search Facebook. It makes it easy for people to get in touch with you and to start a conversation. We try to keep our posts on Facebook limited to high quality post (and usually around 1 per week), as to not spam our followers on Facebook with random things. You can be a bit more lenient with this on Twitter. Currently, we have 477 likes on our Facebook page, giving us a reach of around 500 people per post.


Tino started up a SassyBot YouTube channel back in 2013, mainly to post our teasers & trailers, but in January 2014 he decided to make a video tutorial called “Lightmapping: 3ds Max to Unity“. So far we have made 5 more tutorials, which seem to be in high demand on YouTube. As of today we have over 1400 subscribers and almost 140000 views on our channel with the channel peaking at 2000 views on a single day.

While this probably isn’t the regular approach that you will find regarding YouTube, we found this to be very worthwhile. First of all, we are helping other devs by sharing knowledge that we gained over the last year(s). Secondly, our company name will be out there for a lot of people to see, and we even had people email us for contract work after seeing a tutorial on YouTube.

Data Management


I will keep this one short. Back up your data. Back it up somewhere that isn’t at your work station. There have been too many cases where something happened at the work station of a developer, amounting in the loss of weeks or months of work. People can rob you, fires happen, floods, cyclones and whatever else that could potentially happen in your part of the world.

We use Tortoise SVN for our version control, and have this running on a server on the other side of the country. If something happens to all our computers at the same time, we can just get new computers and pick up where we left off. While this is something that you may never actually need, it is good to have the safety net set up for when you need it. You will thank yourself if something does happen.

So far we haven’t had anything major happening to us, but it’s good to know that whatever happens, your game is safe. Ah, it is also nice to not have to transfer project files using USB sticks by the way.


One of the issues we had throughout last year was that we did not have a very clear planning on how long things would take and how much there was left to do. We already used Google Sheets to keep track of tasks, scenes, locations, characters & other random stuff. What we added later was an estimation of how long each task would take (based on tasks we did earlier that year).

We have a detailed list of everything that needs to be done to complete the game. This includes audio, animations and even how long it will take to implement the interactions in the game. We then keep track of how long it took us to do each task and map that out in a Burn Down Chart. Here’s what our current chart looks like.

Fragments of Him Burn Down Chart

Fragments of Him Burn Down Chart

It takes some time to set all of this up, and it might be difficult to estimate what you exactly want to have in your full release, but it’s worth knowing the road ahead. It’s also very satisfying to cross things off a list.

These were all the lessons that we could share from the top of our heads although I can imagine there are many more that were overlooked. As always, if you have any questions or want to discuss something with me. You can find me on Twitter @elwinverploegen.

Elwin Verploegen

Introduction to Game Design: You can absolutely start with a story March 3, 2015

By Elwin

This article is in response to Chad Carter’s article, “Don’t start with a story“.

Introduction to Game Design Header

If you want to make a game, you can absolutely start with the story.

You read that right, you absolutely can.

While it’s true that if you’re about to make the next procedurally generated dungeon crawler with exploding skeletonstm, a great story probably isn’t your 1st priority. In that case, your first priority is getting a proper gameplay loop going. If your gameplay loop is fun, that’s when you will start adding content. The story is just 1 of those pieces of content. I do urge you to think about the story early on, as adding one later just to say “there’s a story” generally ends up with something that just doesn’t make sense.

If you want to write a great story, write a book, graphic novel, movie, short story, or something else. Like a game. The last couple of  years we’ve seen a huge increase in games where narrative is suddenly more important than gameplay. Games like Dear Esther, Gone Home and the Telltale games like The Walking Dead. I don’t think anyone playing Gone Home has ever said “Man, those mechanics were the best thing I’ve seen in years!”.

You can design your game around a story, we’ve done it succesfully (you can read more on how we made the Fragments of Him prototype here). We started with the idea of a game where you follow the story of someone who just lost someone. I will quote Dr. Mata Haggis from the above link on the first steps of the design:

The theme was minimalism, and I wanted to do a game with a very prominent story in it. I worked on several ideas in my head, but the one that stuck was investigating why a person would choose to live in a minimalist style in their house. The result of this was the idea that the lead character had lost their partner and couldn’t stand to be reminded of the loss.

The story was pitched to myself and my colleague, this is  we started brainstorming on how we would turn this into a game. We brainstormed for a bit and settled for the simple mechanic where the player clicks away memories that remind him of his partner. This makes sense within the narrative and it was actually possible to do within the very limited time scope of a game jam.

No matter what your game is, story is important

I think there aren’t enough designers (or developers) who ask themselves a very simple question.


Call of Batman: Duty Ops

Call of Batman: Duty Ops

Why is my character doing this, why would the player be interested in following this person around for the next 10 hours of his life? Taking a game like Batman: Arkham City, a game with amazing fighting mechanics. Would that game be the same if it didn’t start from a story? Batman started out in a comic book and eventually made his way over to games, and its mechanics are based around how Batman fights, moves, talks and interacts. While I’m sure they didn’t write the entire story of the game on day 1, these are extremely important things to think about when designing a game.

Think of it this way, what if they decided to put the Call of Duty mechanics in the next Batman game. The story will remain the same and you’re still the mysterious guy in a bat suit fighting crime. But now you’re going from cover to cover with a sniper or assault rifle. Would this make sense or even be fun? It might actually be fun, but you’ll probably wonder why this is a Batman game in the first place.

Even AAA games need to have (at the very least) a global overview of what they story will be like before they start building things. Modifying the ending of a game because you didn’t like what you wrote last week will cost millions, changing the location of an event is also something that you can’t just do. These things need to be planned well ahead of time. The fleshing out and details can be done as you go along.

Building Fragments of Him

Fragments of Him is an interactive narrative experience, and we’re building it in the exact opposite way that Chad is suggesting. We wrote a story first, and are building the game and mechanics around that story. This is something that works great for our type of game, and will probably not work for other types. If you’re building a game that focuses on great gameplay and a fun experience, I definitely wouldn’t recommend starting with writing a fully fleshed out story.

I don’t think you can flat out say “Don’t start with a story”, because you can. There’s just so many different types of games and so many variables that come into play when making a game that there’s no best way of doing things.

Completely disagree with me? Got a game that focuses on narrative that I probably don’t know about? Send me a tweet @elwinverploegen!

Elwin Verploegen

Snippet: Swapping Rendering Mode in Unity 5.0 on Run Time March 2, 2015

By Elwin

If you’ve ever tried to switch the rendering mode of a material in Unity 5.0 on run time, you might have run into some issues with it not updating properly. This is what I thought would do the trick just fine (sidenote: 0 = Opaque, 1 = Cutout, 2 = Fade, 3 = Transparent), but it doesn’t actually update anything (in my case, I wanted to fade out an object).

mat.SetFloat("_Mode", 3);

If you look in the GUI code for the shader (Editor/StandardShaderGUI.cs) you can find the following code that handles the changing of rendering modes, and will show everything you need to solve this.

public static void SetupMaterialWithBlendMode(Material material, BlendMode blendMode)
	switch (blendMode)
		case BlendMode.Opaque:
			material.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.One);
			material.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.Zero);
			material.SetInt("_ZWrite", 1);
			material.renderQueue = -1;
		case BlendMode.Cutout:
			material.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.One);
			material.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.Zero);
			material.SetInt("_ZWrite", 1);
			material.renderQueue = 2450;
		case BlendMode.Fade:
			material.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.SrcAlpha);
			material.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.OneMinusSrcAlpha);
			material.SetInt("_ZWrite", 0);
			material.renderQueue = 3000;
		case BlendMode.Transparent:
			material.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.One);
			material.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.OneMinusSrcAlpha);
			material.SetInt("_ZWrite", 0);
			material.renderQueue = 3000;

As you can see, you need to set more variables in order to swap the rendering mode in real-time, so to switch an object from Opaque to Transparent you will have to do the following:

mat.SetFloat("_Mode", 3);
mat.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.One);
mat.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.OneMinusSrcAlpha);
mat.SetInt("_ZWrite", 0);
mat.renderQueue = 3000;
Elwin Verploegen

Goodbye Maik. Hello Chris. There’s also a new office. February 12, 2015

By Elwin

January 22nd was the last day of Maik’s internship, we really enjoyed having him around and we’re looking forward to seeing what he will be able to do in the future, we’re sure it’ll be awesome! You already saw some of his modeling work in the Christmas banner.Fragments of Him ChristmasKaylee decided to stick around and work on her graduation project at SassyBot, more about that in the future (it’ll be really awesome, that we can say).

From left to right: Kaylee, Elwin, Maik & Tino

From left to right: Kaylee, Elwin, Maik & Tino

Meet Chris

Chris BrunneChris normally studies at the HKU in Hilversum but will be working on Fragments of Him for the next couple of months as part of his internship. If you played the prototype you might remember the restaurant scene, which is the first scene that Chris will tackle. Welcome to the team Chris!

The new office

Our current office is pretty sweet, but we got an opportunity to move into the newest location of the Dutch Game Garden (which happens to be near our current office). We’ll be moving there somewhere next week, assuming everything goes according to plan. We’ll be sure to post some pictures once we’re all settled down. We’ll be staying there for the foreseeable future and hopefully this location will become an amazing place for new game development studios. We’ll update you with the exact location once we’ve actually moved in.

New office

Sneak peek into the new office.

What we’ll be showing next time is a mystery



Tino van der Kraan

Dear Stranger Post-Mortem, Augmented Reality and an MDA Perspective January 16, 2015

By Tino

In the course of last year we, SassyBot Studio and Mattia Traverso, created an application called Dear Stranger. I have written a little bit about this before on our blog but the experience and lessons gained were otherwise largely left undocumented. What you read in this blog is my perspective on how we approached making Dear Stranger. Dear Stranger was the result of a 72 hour hackathon/game jam. Even though it has been quite a long time since we created this application, I have not yet taken the time to explain exactly what Dear Stranger is and how it was made. In order to make sense of it all, I will explain the event that motivated us to create Dear Stranger, the thought process behind creating it, and how it exactly works.

Hack the Park!

In June 2014 an event called Visual Design Week XS was organised to promote visual culture in Breda, The Netherlands. As part of this week a hackathon/game jam called ‘Hack the Park!’ was organised. This event was a competitive challenge with several constraints as well as a reward for the winning team. Some of the constraints were:

  • 72 hours to create either an application or a game based on the theme ‘Hidden Garden’
  • Up to 3 people per team
  • The use of augmented reality using Vuforia is mandatory and will need to use a provided target image
  • Needs to run on a smartphone

Design constraints are great for coming up with unique concepts and can help narrow the focus for new and refreshing concepts. It can also reveal possibilities that were otherwise not considered feasible.

The thoughts behind Dear Stranger

When you get to work with technology that is different from what you are used to it is often the challenge to imagine what the technology enables you to do which would otherwise not be possible. Of course you can use an existing game concept and make that work with new technology but is that really exploring the possibilities of that technology?

Some of the new possibilities that we arrived at included making use of the connectivity and mobility of the smartphones. Additionally, some phones have very cool tech such as gyroscopes, advanced cameras and powerful hardware. However, we knew that if we decided on using too much exotic tech that we could exclude certain users from using the app. Furthermore, in the case of gyroscopes we have noticed that this is not yet that reliable on different devices.

Keeping all of these things in mind we started brainstorming all kinds of crazy ideas. Eventually we landed on the idea of letting people leave hidden messages in plain sight. Considering the time and tech constraints we felt that this concept was simple in mechanics, could be executed nicely in terms of aesthetics, and would allow some interesting dynamics to emerge for its users. Furthermore, after getting the minimum viable experience up and running during the jam we were able to quite easily expand and polish onto this core concept. The concept finally evolved into the simple notion of having a public, but hidden, message board with a unique and fitting presentation. We called it, Dear Stranger.

Dear Stranger from an MDA framework perspective

Allow me to pitch to you the application that we created. “Dear Stranger is an augmented reality application for smartphones that lets the user leave a single message per day in the form of a flower. Users can read messages left by other strangers and tweet those you think are great. Explore a garden of thoughts and conversations as you see it grow over time.”

While we developed this application with user experience in mind I can’t help but notice that Dear Stranger lends itself nicely for an analysis using the Mechanics-Dynamics-Aesthetics (MDA) framework (R. Hunicke, M. LeBlanc, R. Zubek – 2001). To explain this framework briefly,

  • Mechanics: The rules
  • Dynamics: The player’s response and interactions being constrained by these rules
  • Aesthetics: The player’s sensory experience such as the look and feel

In the case of Dear Stranger this would look a little similar to this.

  • Mechanics: The application starts working if the software recognizes the trigger image required by the augmented reality system. When recognized, the user is prompted with instructions on first use. After having confirmed reading these instructions, the user can post a single message of 126 characters per day. The user can read and tweet messages. The time slider indicates what messages are shown based on the date and time of initial posting per message. When the software loses track of the trigger image it stops working, indicating that the system requires the image target to function.
  • Dynamics: The user response was to share personal experiences, greet others via Twitter, or set up little stories by responding to other messages. Using the time slider, the user would get interested by the appearing and disappearing of flowers. This possibly led to the reading of messages and inspired the user to respond. When exploring the limits of this application we found that users would sometimes carefully abuse the limitations to leave messages in strange places, such as up in the sky, behind the image target or behind the assumed starting location of the user. Another way the application was used is to make a picture of the image target and fool the system by having it recognise the target image on a display device rather than in the intended real environment.

  • Aesthetics: The application informs the user by using a minimalistic font that it requires an image target. When acquired, a stylized wooden sign is fitted over the image target formed out of tree trunks and leaves. Using text and images, the sign explains the concept, how to use the app, and where the presumed limitations of the app lie. The application then shows stylistically designed flowers, containing messages, on the screen with the camera’s real-time result as background. When tapping on a flower it opens a fitting general user interface (GUI) allowing the message to be read, tweeted, and closed. Each flower indicates, with colored and animated feedback, which flowers have been read or tweeted. An also minimalistically designed GUI in the bottom of the screen informs the player of the ability to scroll through the messages in time ranging from ‘Day 1′ to ‘Today’. When scrolling this time slider, flowers will pop out of the ground or sink back in depending on when the message was posted or planted. The flowers and sign are enhanced by illusions of shadows and particles are used to simulate fireflies. Soothing music plays throughout the application and sound effects are prompted when the player interacts with the flowers or buttons on the interface.

Behind the Scenes

This application was developed using Unity3D 4.3.x and made use of a plugin from Qualcomm called Vuforia. The models were created in 3Ds Max and the textures were hand painted in Photoshop CS6 using a Wacom Bamboo drawing tablet. The interface assets were also designed using Photoshop CS6. The flowers are coloured using vertex paint in 3ds Max. We used a custom shader in Unity3D, limiting us to 300 vertices per flower. The reason for staying below that specific vertex count is so that we can make use of dynamic batching which is a blessing for performance on mobile devices.


Flowers – Click to enlarge


Draw call batching – Click to enlarge

Textures were, for the most part, placed on a couple of texture atlases before implementation in Unity in order to save memory and processing power. Player feedback on the flowers consisted of an animated sprite, aimed at the camera, that changed animation behaviour or colour depending on whether it was read or tweeted. Extra attention to detail was spent on animating the GUI by scaling when prompted, sliding text in from the side, and briefly highlighting a button to indicate it was pressed. An orthographic Unity camera was used to render the interface on top of the augmented reality layer. More about layering cameras can be read in our Elimu post-mortem.


GUI atlas – Click to enlarge

We limited the user to 126 characters so that we had 14 characters left to add ” #DearStranger” allowing us to comply with Twitter’s character limit. To store and pull user messages we used a database that would keep track of what the message contained and when it was posted. Using these dates we could set up a normalized slider that ranges from first posted message to the last posted message. To make the placement of custom text easy we used a small script that allows for word wrapping. When typing a message the application will use the keyboard provided by the smartphone’s OS.

Hopefully this article has given you sufficient insight in how Dear Stranger was created and some of the though processes behind it. If anything is unclear then I am happy to elaborate. Please get in touch via @tinovdk with any questions and I’ll help to the best of my ability.

[Update] Added credits and a disclaimer