Category Archives: Uncategorized

Using outside experts

Developer friends of mine started working on a really intriguing project several years ago. They had this concept for a puzzle game based on language and having to understand the meaning without being able to understand it. You played a robot that was teleported back to the stone-age and your goal was to help the cavemen progress. But all the cavemen could do was communicate in body language resulting in a symbol and the robot had to interpret the meaning of the symbol to be able to assist in solving the problem.

Now language is a really tricky thing in videogames on it’s own. It has to convey a lot of meaning and instructions to the player. But all the developer can do is hope that the player understands it the same way that it was written. Language is technically highly structured, but the meaning of what is said or written is not, it is inherently multi-interpretable. Converting language into a game mechanic, seems an even more risky task to set out on, for your first game.

The developers knew this and they decided that instead of winging it and go for the ‘fail a lot until you succeed’ method, they asked help from outside the game industry. They contacted a linguist, to come by the office and talk to them about language, to teach them what language is made up of, how it originated and what to keep in mind when creating your own language. They recognized that they knew a lot about making games, but not necessarily about the subject of the game. Sadly, the game still hasn’t been released, and I lost track on the development.

What they did, is something a lot of developers struggle with. Asking for help from people who know nothing about games. A lot of developers think that the most important thing in development is to understand games. Know what makes a good game and the rest will follow.
So a lot of games are released as technically and designed masterpieces, but fall flat on communicating their own ideas.
The risk of designing a game that relies on language wasn’t that they couldn’t design a game or develop it. It was that people could not connect with the subject. That the language concept would feel off and take the player out of the immersion. Almost no player will have theoretical understanding of language as a concept, but every player has extensive experience with using language and when the usage wouldn’t be right in the game, the player would instinctively know.

A few years later, after releasing our first game (with my studio at the time) we prototyped a concept of our own that dealt with a concept that we had no in-depth knowledge about. We wanted to make a game that centered around several fictional religions, that would each consist of playergroups that would ‘battle’ for the dominance of their deity. Each religion with their own customs that would connect with players on a level with more depth than just an ordinary ‘clan’ system. We wanted to make these religions as close to real-life religion and make the players ‘belief’ in their in-game ideals.
The biggest risk we identified, was that the religions would be nothing more than fluff. That players would min-max the experience for results, game the system. Or that we would misrepresent existing religions in a way, or maybe even create unintended and problematic side-effects in the behavior players would develop to obtain the in-game goals. All these things would ruin the experience for the player, or create situations that would make us liable for issues that we weren’t going to be able to deal with.

What we figured was that we were not going to be able to learn enough about religion on our own in time to develop the game. Understanding a concept so complex, that normally would take decades of research to ‘get’ was not on the cards. So the next best thing would be to get someone into the project that already had researched the topic for all those years. We were going to need a theologian, and we were going to need it from the start of the project.
We had zero budget to hire someone, so we contacted several universities whether a student was looking for an opportunity to research religion in games and was interested in helping us out. We found something even better. We ended up being referred to a Dutch theologian that had been researching games & religion for years and was looking for an opportunity to take part in the development process. The knowledge he had about religion, already in the context of games, was something we would never had been able to replicate on our own.

Ultimately the project was canceled because of other factors outside of our control. It did however convince me of the usefulness for game developers to involve outside expert on topics as early in the process as possible. Game developers generally think that to develop a game, you need to understand the industry, but games are more than just gameplay. It is presumptuous to think that developers can learn about complex topics during development on a level really needed to convey the topic in a fair and useful way.

So for the next project that you start, think about what you want to accomplish and whether an outside expert would be useful. Most are waiting for the opportunity and willing to even do it for free in exchange to be able to use the results in their own research. It even allocates more time to focus on development, instead of having to research these topics yourself.

Got any questions or feedback? Hit me up on Twitter (@Ithunn).

Design philosophies and preventing feature creep

One of the biggest problems when designing and developing a game is to decide when it is done. There is so much cool stuff you can think of to add to the game, so much you can improve on. A game is never really done, but at some point you have to finish it up and put it out there.
So how do you decide when to stop?

In general a project starts with a rough idea of what game you’re going to make. But you should also start a project with a few philosophies in mind. What is this game going to do? For who is this game going to be or what is it going to tell the player?
You should write these ideas in your design document and use them as guidelines to which you mirror every decision you’re going to make during development of your game.

So if you have a really cool feature you want to add to the game, you have to ask yourself if it fits one or more of your philosophies. Does it add to the core of what your game is going to be? If it doesn’t scrap it from the plan. It doesn’t mean the feature is bad, but it will only add to distract the player from your game, meaning that both the game and feature aren’t going to shine as much as they deserve. This goes for planned features and elements, but also for every on the fly decision that you make.

If you wish to improve more on an already added element, like polishing some art, work out an existing mechanic, etc. You should also use your philosophies to decide whether spending time on improving the element is worth it. Like asking yourself if the already present feature already fulfils its purpose? Or does it further add to other elements to fit even better towards your goals? If it doesn’t, don’t waste time on it.

Of course you can always improve that piece of art, make it more detailed, but if it doesn’t make your game noticeably better according to your standards, it is time you’re wasting that could be spend on other elements that actually would make the game better.

If you don’t trust in your ability to make these decisions as objectively as possible, you can always ask someone else what they think. If the game wants to do A, do you think feature B will be a good fit? And be sure to ask multiple people if possible.

By approaching every design decision of your project on the core principle that it should always work in favour of your design principles, it is easier to keep an overview on what you spend your time on. You will be able to decide when your game is done and diminish the risk of diluting your game with ‘cool stuff’ that on it’s own would be awesome, but together would form a feature creep mess that your game doesn’t deserve.

Got any questions or feedback? Hit me up on Twitter (@Ithunn).

Is a difficult game a bad game?

The still somewhat recent release of Cuphead sparked a debate among gamers and media that time and time again comes to the foreground when a frustratingly difficult game is released and raises to the top of gamers their attention.

Is a frustrating/difficult game bad game design?

Well, it can be and most of the frustrating games out there are at least not great. Because difficulty and frustration in a game are very hard to balance for a designer. If done wrong, it angers players and quickly turns them away from your game. However, when done right, it elevates your game to a new level of recognition. Take Dark souls for example, a terrifyingly difficult game, but with a huge fan-base and almost unanimous critical acclaim.

The reason for a difficult game to be great, instead of bad or mediocre lies in the way the player either consciously or subconsciously experiences failure in the game. For a player nothing can be more annoying than getting pulled out of the flow by the game throwing a curveball that the player can not anticipate on. Having the feeling that the game is actively trying to make you fail quickly throws away any good will that the player has for your product. However, a game can make tasks almost impossible to complete but still succeed at giving the player a rewarding experience. Take Super Meat Boy for example, it shows the player where he/she died, what mistakes were made, leading towards failure. This is a very clear and easy way to get to the core of what is important in a well designed frustratingly difficult challenge. Letting the player feel like they know where they went wrong, that the mistake could have been prevented and that the player has success within his/her grasp.

A curveball out of nowhere takes away the agency that a player has over his/her failure. If the obstacle is not avoidable without previous knowledge, or without foreshadowing, the player will inevitably die without taking extreme luck or skill into account. This is unfair since games are not there to force a player into behaviour, let alone dying. Games are there to challenge players and give them a fair chance to succeed, when they’re skilled enough.

So next time your game gets critiqued as being to difficult and thus badly designed. Ask yourself this question;

“Does my player have a way to know what is coming and does he/she feel that dying was a mistake caused by their own wrong choices leading up to it?”

Got any questions or feedback? Hit me up on Twitter (@Ithunn).

How we finished our game on time

This blog was also featured on Gamasutra on 01/05/2016.

I have met a lot of creative people in the past few years. Most of them have high ambitions and great ideas, but there is one thing most creative people are really bad at: deciding the scope of their project. Part of their strength is being able to look outside the box, to think of outrageous new concepts. By doing just that they tend to overlook other important factors. These are money, time and polishing. A project, for most people, is the great concept materialized in a playable prototype and from there on the process of playtesting, iterating and playtesting some more. But when is it time to call it quits, when do you decide when your game is finished? Well, not by working till you think it’s perfect, because it will never be perfect. As an artist you’ll always find new things to add, things to change or omit. Like a painting, it takes discipline to decide when your game is good enough to be released in to the wild.

When we worked on Lumini, we made a pact to release the game before we’d be finished with school. That date was two years away from then, but it was important for us to have a goal to work towards. We had two years to create a polished, finished project and have it released on Steam, starting from just a concept that got approved just prior to that. By setting that goal, we knew that every decision we made for the game, would have to fit into this time span. Without really knowing how much time everything would take, we decided that this would be a sheer impossible task for us to do. First we were going to make a vertical slice of our game. A demo that people could play, so we’d know what we did right and what we needed to change. But also a marker, to see what we could do in three months time. The demo was going to be as long as it could be within this time span. We ended up with a shorter game than we personally anticipated. It was about 10 to 15 minutes long and still missing a few things here and there. It did however give us a number with which we could work.

Announcement trailer (November 2013)

Accepting the fact that the full game could never be something more than a few hours was hard. However, we decided to stick to our plan to finish the game in two years time. If we decided to stray from that path, it would’ve meant that we also needed to focus time on getting funding beyond our schoolproject. Something we were not comfortable with. Releasing the game withing these years also meant that if we were going to quit the team after graduating, we’d have a fully released game on our resume, thus considerably strengthening our position in the highly competitive field that is game development.

So knowing that we had two years, minus the three months it took us to finish the demo. It was easy to decide the length of the game and how much content we could fit in. Lumini had to be a bare minimun of two hours long. So that would mean eight times the development time we took for the demo. So in 24 months it had to be finished. That was a problem, because 24 months is exactly two years, but we had to do our internships, Steam API implementation and we had already spent three months on the demo. So we were forced to either make an even shorter game, or get more people involved in the team. We decided the latter was the best option for us. Mind you; going to college here in the Netherlands, meant you got financial support from the state. So we didn’t have to pay fellow students for the project, making it relatively cheap to expand our team. So other people might be forced to take another route.

Having expanded our team from six to nine people (of which two worked for half a period) we had tackled one problem and were confident we could finish a two hour game within the time we had left. The fact that one of our programmers built a toolset, so we could build levels more efficiently and thus faster, also helped a lot. The next thing we had to do, was make a list of everything that had to be done. This had to include stuff a lot of people forget about until the very end. Like Steam API implementation, achievements, option menus, localization and marketing. Also factoring in buffer periods that would be necessary to counter bug problems, events and other things you can’t plan ahead. And of course, leave room for polishing the game.

We made a MOSCOW list (for those who don’t know what it is: http://www.dsdm.org/content/10-moscow-prioritisation) of all components of the game. Mechanics, features, assets, audio, technicalities and pre-production work. That way we could make a rough schedule of milestones that we needed to clear. We also had a few deadlines from our school that were mandatory, helping us a lot, since we had no choice but to deliver on those dates.

This, of course, doesn’t mean we knew what would and would not make the game. Nor prevent us from thinking of dozens or more awesome features that we wanted to implement. The list changed a lot, but with every iteration, we needed to make sure that the deadline never changed.

So how do you handle the ever growing amount of new things you want to implement, when you have a tight deadline to keep control of? Simple, about four months before our final deadline, we sat down with a long list of all the things that still needed to be done and additions from every team member that they would like to see in the final game. We went by them one by one and decided on a few simple premises if it would make the cut or not.

1. Could it be implemented within the time left?

2. Does the majority agree it will make the game better?

3. Does it possibly interfere with core elements already in the game?

4. Could it be implemented within the time left? (This one is really important!)

For every possible addition we started with question one. If it didn’t pass, we crossed it off, however cool it may have been. If it passed we put it through voting for question two, etc. If it met all four the requirements we scheduled it in. A lot of hearts were shattered that day and a lot of great features are catching dust on a shelf now.

We also agreed that if by the time we needed to deliver the game, a feature wasn’t finished or poorly implemented, we’d omit it from the game, no questions asked. In the end, only one big element failed to make the final product (big emotional set piece, in which you walk with a herd of giant dolphin-giraffe-dinosaur creatures).

So, why did we decide not to take more time to implement really awesome features that would’ve surely made the game better? One, we had negotiated an official release date with our publisher. Two, we wanted to finish the game within school. Three, money. While three wasn’t the most important for us, it is for developers who are on a budget. For every month you develop, you need to sell more copies to break even. So if you decide to take a month extra to implement something, that extra feature better sell you more than a month’s salary worth of copies. In reality, most features don’t. Most make your game better, but aren’t part of the equation that people make to decide if they’ll buy your game or not. So to postpone your deadline, it either needs to gift your game with another strong hook that can be used to sell it, or must be so memorable, that people will talk about it afterwards with their friends. This decision isn’t easy and takes a lot of discipline. If you’re not sure, talk to people about the feature and ask them for their opinion.

Now for some honesty that I didn’t mention yet. I made it look like we never had to change the final deadline didn’t I? Not true, even while taking all these precautions, we made one big shift. When negotiating the official release date with our publisher, we had set the date on early July 2015. But when it came to signing the contract we talked about making that deadline and how it would leave us with very little time to do QA testing. Our programmers were also uncertain about implementing the Steam API on time, since they had no experience doing so. So we decided to postpone the date to early September 2015. It still fitted within our timeline, since we officially needed to be done before August 30th.

So that’s how we finished our game on schedule. While doing our internships, graduation presentations and other irrelevant stuff a school makes you do. We started in September 2013 and Lumini released on Steam on September 3rd 2015. I won’t say it definitely works like this for everyone. You’ll have to try out a few things yourself, but I hope it helps teams to have a better grasp on their scope and release games within budget and within time.


Lumini teaser trailer (April 2015)

Bonus tip: When working on a project for a long time, you’re bound to run into some motivational issues. Keeping motivation high is mandatory to keep meeting your deadlines, while also keeping the content of sufficient quality. What we did to prevent motivational problems, was to write down parts of our MOSCOW list on a big whiteboard in our office and when an asset or feature was done, cross it of with a big red line! That way you keep clear track of your progress and the entire team knows what to do next. Also, don’t forget to have fun! Making games is the best job in the world after all. 😉

If you have any questions or don’t agree with something I wrote, let me know! You can contact me on Twitter (@Ithunn) or send me an e-mail (steven[at]speelbaars[dot]com)

The consequences of failure

This blog was also posted on Gamasutra on 12/28/2015.

Introduction

I’d like to think I’m a reasonably emotionally stable guy. I’m sober, passionate about what I do and not one to easily be distrought. The last time I cried was when my pet rabbit died and I do get angry and frustrated from time to time, I’m human.

Games are for me a medium to make people experience emotions, to tell stories. Captivate people in a world different from your everyday life. That’s why I make games, to do exactly that and I will try to do that until I’m forced to stop.

My first experience with making a game that was to go public was probably instantly the worst experience possible. We made a tiny arcade game for a school project and send out pressreleases to all the big sites. They probably weren’t gonna pick up on it, but it never hurts to try right?

Boy was I wrong. The title of our game was by some, interpreted as racist, or at least controversial. It sparked a discussion on the internet with several articles on big sites like Kotaku, Polygon, Giantbomb, etc. Even though we still think that the racial connection was a little far fetched, we decided to change the name of the game, to prevent any further trouble and make sure we didn’t step on anyones feelings. So we decided to team up with some other developers and try our luck with a new game, with more ambition and a bigger scope. I mean, we had already experienced the worst thing possible, so why not!

We decided that for the game to be successful, it needed to be special It had to do something new and couldn’t just be another iteration on so many games already out there. We sat down to come up with some ideas and fast-forward, came up with Lumini.

Lumini is a relaxing emotional adventure game, in which you control a swarm of creatures that you as a player need to keep safe and guide through the treacherous world around them. The game was meant to be an experience that would play with your emotions through art, design and sound as a complete package. A trully immersive adventure.

We worked on it for two years, from September 2013 until release on September 3rd 2015. Man were we proud of what we had accomplished. We had succeeded in all our design philosophies. We had been nominated for a few awards over the past two years and press never stopped telling us that we had possible gold in our hands. On every event people stopped by, curious what ‘this beatiful game’ was about. Played it and left in awe, telling their friends to go play it as well. We made a lot of friends with developers all over the world and played many other cool games. We were full-fledged developers now.

So that’s my story till about three months ago.

The Rise

As I said earlier, Lumini was about making a game that was different from what was available on the market. It drew a lot of inspiration from Journey and Flower, but with more traditional game elements thrown in the mix. The idea was to create a game that was not about reaching a goal, but about making a journey, in which the player was responsible for the protaganists (or in this case a whole swarm of them). Making the journey successful was in your hands and the game was gonna let you do it in every way that you wanted to. No intrusive tutorials, no unneccesary UI reminding you of it being a game, no telling you what was right and what was not, other then through elements and mechanics present in the gameworld. There was a story, but not one we as a developer were gonna tell you. You needed to figure that out through the environment of this planet you’re exploring, through the emotions that you felt when you’re swarm was dealing succesfully with obstacles and by the decisions that you as a player were free to make. That all, with the goal to not make it to ‘artsy’, it still was a game in it’s core after all.

Our school immediately sides behind this idea. Being an art school it loved the innovative nature behind the concept and we presented them with a solid team of diverse skills and experience in every facet to make the game a success. Or so we thought. We found out that marketing your game is a little bit more difficult when it’s not controversial or provoking.

However, when we released our first demo after three months of hard work and let everybody know about it, we soon felt that we were on the right track.

We did not initially get the high profile media exposure we were hoping for, but knowing that we still had to go through Greenlight to be able to distribute our game on Steam, it was understandable that our game was flying under the radar. The people that did play it however were really enthusiastic and didn’t shun to compare it to Journey in it’s visual quality and overall atmospere. Yay! Job well done right?

We decided to throw the game on Greenlight in Januari 2014 and see how it would fare and were greenlit in May. Around March 2014 we were contacted by the first publishers that wanted to know if we were open to making a deal to publish the game on PC. We had never thought about that, because based on experience from teams around us, you needed to contact a publisher if you wanted one. The luxary position of having not one, but multiple publishers looking to sign our game, while it was far from done made us somewhat proud to be honest. So in the summer of 2014 we had everything going for us. We had positive media exposure. We had publishers battling it our for our signature and we had praise from a lot of people in the Dutch game development scene. Yes, some people were telling us , that we should not let the attention get to our head. But we knew the game wasn’t done yet and a lot of issues would need to be tackled to make this promising demo, into a full-fledged game fit for release. We weren’t idiots, silly people!

After doing a lot of events in the first half of 2014 and finishing our mandatory internships, we were ready to go at it full time around September. We got two more artists on the team, because the game was gonna be art heavy and got a brand new ‘office’ assigned by school. One year we had to make our dream a reality. We were Greenlit, we had a gentle-men agreement with a publisher that we trusted most we has a team and a place to work. No excuses to not finish this game!

Now I’d love to talk about every hardship we encountered during development and what design decisions we made, but this blog is gonna be long enough without it, so maybe for another time.

There are a few things that I do like to mention though. We got nominated for the student art direction award by the Dutch game awards (that we lost to Lionade games currently working on Check-in, knock-out, with the other nominee being Grotman games with the Indiecade award winning Tribal&Error) and got invited as a nominee for the indie game showcase award for Momocon in Atlanta. Our trip to the US, finally gave us the means to get in touch with some mainstream websites as both Kotaku and The Escapist were represented in the jury. We got the contacts and postives that we came to expect, but this time by even more respected people in the industry.

And that’s what the problem is. Throughout these two years I grew accustomed to positive feedback , even though I knew that the game was likely to fail and we were just starting out. You can’t block out all the ‘experienced’ people telling you the game is gonna be big. You’ll start to believe and every critical thing you tell yourself, is just a facade that you pull up, to not come of as arrogant. I mean these two or three people telling us that we should really plan ahead for a big financial failure, because games nowadays almost always fail, can’t know it better then the other 95% right? Lumini had been on national TV, national newspaper, more websites than I can count and during Gamescom 2015 we had five more publishers lined up to talk, even though we already had a deal. You start to believe in the fairytale.

The Fall

The first real wake up call came through fellow classmates of ours that worked on their own game during roughly the same time. They were developing this asymmeterical multiplayer suspense game that got even way more attention and praise than we did. They made all the big sites and got a massive hype going before release with this crazy idea of making the game available for a limited time through a shared lifepool mechanic (some of you might know which game I’m hinting at).

They released a month before we did and had even higher expectations. Well they failed, and big time. The game got a lot of criticism and made me aware for the first time in a long time, that we might actually do not as well as I thought we were gonna do. Well no way back for us now.

We finished the game right on time and made our deadlines. So the game was set for release early September 2015. We agreed to gather at our programmers house to celebrate the release of Lumini. The game we worked on for two years with blood, sweat, tears and most of all passion.
We made a game, as students, and were releasing it on Steam fresh out of school.

We had accomplished all our goals, which we wrote down on paper and stuck to the wall in our office and accomplished design wise what we had intended. We had a publishing deal, media contacts and did a lot of events. So according to everything you can learn about marketing your game on a limited budget, we did everything right and had everything in order to go.

The game was going live on September 3rd 14:00 PM EST. We had implemented google analytics to track the amount of players playing our game, so we could track how we were doing. Our expectations were not big, we had learned from teams before us and were counting on maybe between 500~1500 sales.

Well, things were looking good, we had a small amount of players, but we did get 3000 players the first two weeks and were happy. Lumini was played on all the continents in over 150 countries. To put that in perspective, we were students, with no real industry experience beyond internships and this adventure of making, finishing and releasing a game. This was gonna be the first time for us that people all over the world could buy and play our game.

Doomsday, the first sale reports from our publisher came in. I was brave enough to ask them to share early numbers. We had sold…almost nothing. Approximatly ~250 people had bought our game and sales numbers were dropping fast. We did not hit the Steam front page, we did not do as well as our numbers showed. Harsh reality check, 90+% of our players had pirated the game. They played and enjoyed our hard work for two years and payed nothing for it. This wasn’t the biggest problem, because at least they enjoyed it (I hope at least). But the impact of piracy was way bigger then we anticipated and the response from people pirating the game, was what hit me personally the most.

We just graduated and had made the game during our last two years in college. Most of us had spend personal money on the development and marketing of the game. We had spend time developing and not networking with the aim of getting a job like most of our fellow students. That meant we took a big risk with releasing our game. But we only needed 2500 sales to play even and be able to sustain ourselfs as a company and being able to pay our living expenses. But 250 sales? This meant most of us had immediate financial problems and had to drain their personal savings right after graduation. The response of players when confronted with this? “It’s just a pity bargain, you have your own company, you are rich enough”. The public opinion was that we were rich enough and they had the right to not pay for two years time of our lives and I can’t even blame them. We traveled, got media attention, got on national television. All these things are associated with succes and succes with money. But dealing with this harsh reality was something I personally wasn’t prepared for. Instead of people being happy with the game we made, they saw us as people wanting to make money of them with releasing our game. Yet we hardly made any money, let alone got our personal investements back.

The other thing I learned the hard way concerned the media involvement around our game. We had spoken to a lot of journalists and most of them liked our game and we’re interested in covering it on release and contrary to a lot of stories about media in a negative way, most of them did. But the impact of reviews was near to nothing. We had received a lot of positive reviews (and some negative, everyone has their own opinion) but none of those ever sparked even a little spike in sales. So the fact that our game was received positively, people didn’t pick up on it. I had no clue as to why or a way to track it. At the moment of writing this blog we still have a 97% positive review rating on Stream. 40 our of 41 people rate our game positive. Yet we’re in the dark what should have been done better and as a designer thats hard to swallow.

Consequences

So that’s our story from my own perspective and I’ll try to tell you why I told you this. I’m a proud person and not easily bothered by mistakes. I believe failing is part of learning, because that’s what I’m thaught. I can deal with dissapointment and am always ready to go on. I still am. When dealing with dissapointment I tend to make jokes about it and so I did now. Problem is, some of the jokes hold a truth. I have joked about not being able to sleep because I can’t handle the incertainty about what went wrong. I have joked about being a bad designer with a big ego. I’ve joked about ending up in a gutter somewhere making card games for hobo’s.

But I do not sleep, I do doubt my skills every moment and most of all, I do not deal well with the uncertainties caused by this situation. People tell you if you can’t handle criticism you shouldn’t enter the industry, because of all these things. But they do not stem from criticism, they stem from uncertainty because I just don’t know and no one is able to give me reasons that ease my mind.

I had this idealistic idea about making people happy with games I make, I don’t need to get rich, but I do need to pay my rent, that’s enough. But I feel like I’m an enemy towards the people I make games for and a failure to people that share my passion. My health is suffering, because I’m not able to accept that I failed, because no one can tell you how to fail. There are countless blogs about succes, but a few about failing. None of them deal with the consequences on a personal level, none consider the emotions of the creative people behind the product.

I’m not writing this down for pity. But I do believe that anyone reading this, who’s working on their own game should keep in mind that there is an impact. Succes or failure, you’ll have to deal with, everything that’s thrown your way. I have a wonderful girlfriend who supported me all the way and cried with me when my game failed. I have great friends that I can talk to about stuff that bothers me. If you’re making a game and intend to release it, be sure to have a social safety net of your own, you’ll need it. It might be the single most important thing after releasing your game.

Positives

Isn’t there anything positive about releasing your game? For me there was. I learned more about making games and selling them then I ever could have, if I did not take the plunge in to the deep. I have met people from all around the world and many of them I now call friends. I have played many awesome games that are still to come. I have a resume that says I released a game and went through the entire process of releasing it. I know a lot of faces behind the games that I love to play.

As a designer, the most positive experience of all was when a YouTuber shed tears over the ending of our game (https://youtu.be/nsJs2dpQqHs?t=863). For me that’s the proof that I can achieve anything I want to. I will not stop making games for as long as I can. Even though gamers might see me as the enemy (not all of them, a lot of them are great) I do aim to make them experience and enjoy the worlds, stories and adventures that I create.

We’re working on our next game, that is totally different and hope that people will enjoy it just as much. It’s gonna be completely different because for us, developing games is a journey that teaches you new things every day and an opportunity to keep trying something new. We’ve learned a lot and are confident we can do a better job. I mean, it can’t get any worse this time around right?

If you want to share your story or have any criticism on what I wrote down. Don’t hesitate to contact me on Twitter (@Ithunn) or send me an e-mail (steven[at]speelbaars[dot]com)

Thank you for reading this large wall of words and I wish you all a happy 2016!

125 things I learned while developing games.

This blog was also featured on Gamasutra on 07/10/2015.

First I’ll provide some context by introducing myself. I’m a 4th year student/graduate from the HKU in the Netherlands. During my time there I’ve created several games with the aim to release them. Not all were published, for several reasons. The last two years I spent working within my own company(Speelbaars) and we were supported by school on our debut title ‘Lumini’. I’m not that good at making constructive stories, so I’ll provide you with a handy bullet-list about stuff I’ve learned over the past few years.

 

1) Don’t think about making a game, start MAKING a game.

2) Don’t talk about ideas, show ideas (prototype!).

3) Don’t try to do everything by yourself.

4) Learn something about every part of development (programming, design, art, business).

5) Trust the people you work with,

6) But still get your contracts done in time.

7) Plan ahead, especially for longer projects.

8) Don’t be afraid to ask for help, information or feedback.

9) Don’t be afraid to kill your darlings, omitting is the art of creating.

10) Learn what a ‘minimal viable product’ is and means.

11) Make mistakes and learn from them.

12) You can’t prevent every mistake, you will make them, accept that.

13) Don’t panic; there is always a solution.

14) Make a game for your audience, not for yourself.

15) You won’t reach your potential by staying in your comfort-zone.

16) You’re competing with thousands of developers for the same spotlight.

17) Don’t let this scare you.

18) Not everyone will like your game, that doesn’t mean it’s bad.

19) There will always be people that will like your game, you just need to find them.

20) Almost everyone you meet in person will tell you they like your game, even if they don’t.

21) You (probably) won’t get rich by making games.

22) You (probably) won’t get famous by making games.

23) Your games will have an impact on someones life.

24) Don’t let others discourage you.

25) Be realistic about your future.

26) You will have to talk to others a lot!

27) You’ll have to do the social media thing.

28) No matter how much you hate Twitter or Facebook 😉

29) Networking is important.

30) Don’t dismiss anyone you talk to as unimportant, everyone has value.

31) Never be rude to anyone.

32) NEVER EVER(!) burn bridges.

33) Money isn’t evil, you’ll need it.

34) You don’t have to sacrifice creativity or vision for money.

35) You will struggle with the balance between vision and money.

36) You’re never done learning, about anything.

37) There will always be people that are better at something.

38) You’ll get jealous, but will have to deal with it.

39) Never bare a grudge, it’s not worth your energy.

40) Responding to trolls isn’t worth your time.

41) People will try to use you for their own gain.

42) Those people can still be your friends, they just think you offer value as well.

43) Your family can help you, even if they don’t understand games.

44) Make contact with your local gamedev scene, you’ll make friends and learn stuff.

45) Always try to help others when they ask, no matter how successful you’ve become.

46) Remember that everyone started at the bottom.

47) AAA isn’t soulless, people making them are just as passionate as you are.

48) Publishers aren’t evil, most of them are awesome.

49) Even the biggest publishers do their best, but big companies have a bad communication

structure in general.

50) Go to events if you can, even if they’re just local and small.

51) You do want to sell your game on Steam if it’s for PC (it’s 99% of your potential market).

52) But also sell it at smaller platforms (Itch.io, GoG, etc).

53) I don’t know much about console markets, sorry :’) (But you do remember tip nr.right?).

54) If someone tells you, you can always contact them for help, they probably mean it.

55) If people don’t respond to your e-mail they probably haven’t read it, because their inbox is

flooded.

56) Don’t be afraid to send a follow-up e-mail, but don’t be ‘that guy’.

57) If you’ve got some kind of relationship (IRL, Online, etc) with the person you try to contact,

social media is a better option then e-mail in general.

58) Always start with the least amount of necessary people on a project.

59) Down scaling a team is something you want to avoid, up scaling is always an option if needed.

60) Look at everything around you for inspiration, don’t be stuck at just looking at other games.

61) Inspiration can come at anytime and anywhere, always have a way of writing it down.

62) Game design documentation is necessary, no one likes it though.

63) You’ll need someone in your team with a business focus. That person can still be a dev.

64) Marketing will need your full attention.

65) You’ll need to market your game as early as possible

66) Remember that everything that goes online, stays online though.

67) You’re always responsible for what you say (online). Even when sad, drunk, sick or whatever.

68) Some people will try to attack you on your weaknesses.

69) Again, those people aren’t worth your attention.

70) Do try to learn something from what they say, there is always some truth behind everything.

71) You can also call a person if you really need their attention.

72) Grammar check any text that you publish.

73) Strategies that worked yesterday, won’t necessarily work tomorrow.

74) Always be original, don’t copy other people’s work.

75) Always read stuff that you need to sign with a signature, ask if you don’t understand something.

76) When approaching journalists, think about what story you want to tell.

77) ‘I just want to make fun games’ isn’t a great story

78) Avoid the use of buzzwords like innovative, immersive, unique, etc as a way to describe your

game.

79) Think outside the box when monetizing your game.

80) Multiplayer games are fun to make, but really hard to sell when you’re just starting.

81) Winning awards is nice, but generally awarded by people that will not buy your game.

82) Although awards won’t sell your game, they do give you exposure with media.

83) Media attention is great, but what really makes you game successful is people telling their

friends about it.

84) Don’t shy away from giving away free copies of your game, even to smaller sites/ youtubers/ streamers.

85) If one free key convinces two people to buy the game, you make more money than it cost you.

86) Don’t buy games from friends, because they’re your friends, buy the game because you want to

play it.

87) The reason for this is that if you do, other ‘friends’ will expect the same treatment.

88) Nowadays, if your game is stuck on Greenlight for more then a month, it’s just not good enough.

89) This doesn’t mean it isn’t good, you just need to go back to the drawing board.

90) If your game isn’t remotely fun after the first few weeks of development, it probably won’t be

anytime soon.

91) Ditch that concept and start something new, instead of trying to fix it. Chances are it’ll

never be worth the time investment.

92) Every person you hire will cost you money. Even when it’s a revenue share.

93) Don’t forget to spend time on hobbies outside of gaming.

94) Don’t spend all your time on a project, you’ll lose motivation faster. Take breaks.

95) Don’t be afraid to invest money, it’ll be worth it in the end.

96) Avoid going into debt at all costs.

97) If someone promised you something, don’t be afraid to remind them of that promise.

98) Don’t be afraid to cash in favors.

99) A good game has meaning and value for a player.

100) The easiest way to accomplish this is to make your game ‘fun’.

101) If you lose motivation, and you will at some point, take a step back and remind yourself why

you’re doing this.

102) Fights will happen in a team and that’s OK. Just be sure it’s about something important in the

game.

103) Also be sure to really listen to concerns that people have in your team, even if you don’t share

them.

104) In general, never forget it’s a team effort.

105) Never hold back critique when someone asks you for feedback, but let it be constructive.

106) When pointing out a problem, be sure to consider possible solutions.

107) You’re responsible for your own successes and failures alike.

108) You’re never unique in your problems, someone already dealt with them somewhere.

109) Get comfortable with presenting in front of a crowd and public speaking.

110) ‘No’ doesn’t necessarily mean ‘Never’.

111) Submit your game to competitions and selection procedures for events.

112) Remember that games are made to be played by people. Don’t be afraid to let someone fail at

your game.

113) Some of your players will be idiots, design your game remembering this fact.

114) But never expect your players to be stupid, always take them seriously.

115) Never be discouraged when trying to get your game noticed, keep pounding on that door till it

opens.

116) Playtest your game and iterate a lot on it.

117) Collect data while playtesting, but don’t forget to follow your gut feeling as well.

118) If an offer sounds to good to be true, it probably is.

119) When you’re speaking from experience you’re never wrong.

120) But your experiences don’t have to be the same as someone else’s.

121) Never lie just to fit in or be part of a conversation.

122) Don’t be afraid to admit that you don’t know something.

123) Have one person be responsible for the PR and trust them to make the right decision.

124) You’ll have to release your game at some point, even if that means you’re not 100% satisfied.

125) Never give up!

Some of these might not be clear enough, if you want me to elaborate on some of these points don’t hesitate to contact me on Twitter (https://twitter.com/ithunn) or send me an e-mail (steven[at]speelbaars[dot]com). Really, don’t be afraid to ask ;-).

If you don’t agree with me, please let me know why, so we can learn from your point of view as well.


Start using Twitter!

 

This blog was also featured on Gamasutra on 12/04/2013.

A lot of developers nowadays use social media. For networking, marketing or just social conversation. Still a lot of people, mostly new developers, answer ‘no’ when I ask them is they have a twitter handle. It surprises me that in this day and age, not every developer or aspiring developer, starts with setting up a twitter account. Some say ‘yes, but I don’t really use it much ‘, which is a missed chance in my opinion. As in my experience, it’s one of the most useful and efficient social media tools there is.

So to all you game developers out there, be it rookies, me being a rookie myself, or veterans. Here are some reasons why you should start using Twitter, if you haven’t already.

 

1 Networking

It’s one of the most useful networking tools out there. You can connect with people by one click on the follow button and receive every bit of information they have to share. You can interact by reacting to tweets they make without having to deal with befriending them, signing up for something or start up a program to write them an e-mail. Maybe they’ll even react and you end up having an interesting discussion. Just keep following interesting people and engage them socially.

2 Marketing

Twitter makes reaching a target audience easy as can be. Every tweet you send out, gets posted on the Twitter feed of everyone that’s following you, if they re-tweet you, it gets posted on their feed and if someone re-tweets that..you get the message. Not only has it the lowest barrier for your message to get spread, Twitter also has the ability to add hash-tags to your tweet (#gamedev #games, etc.) With these you can reach an audience interested in a certain topic. A hash-tag, for those that don’t know (which is probably no one reading this, but still) makes it easy for someone to search every tweet within a certain topic to be displayed, without having the need to follow everyone. So marketing your product for a target audience via Twitter saves you a lot of work. Not that you should use only Twitter for this, but it’s a big help.

3 Discussion

Everyone likes a good in-depth discussion about an interesting subject right? I know I do! So when I’m bored, I send out a tweet with a question that’s (apparently) bugging me at that moment. Mostly about stuff that is game related, but it can be about anything. Send it out with the right hash-tag and wait till the responses start filling up your Twitter feed. Depending on the time, subject and I’m sure a lot of other stuff, these discussions can soon grow out to something that not only you talk about with someone, but everyone with each other as well. I’ve learned a lot about various subjects in a short amount of time this way. Everyone all over the world can share their thoughts and answers to your questions. What more do you want?

4 PR

Because talking to someone over Twitter is so easy, it’s often a better way of sharing something about the progress of your game with people that could help you get exposure. That is, if it’s short enough. It won’t replace the need to send out e-mails to your entire mailing list. But it could save you a lot of time to keep people up to date. Also in my experience it’s a way less intrusive way of following up on your e-mails, if someone hasn’t responded.

5 Lists

Twitter also has the option to create lists. This is a way for you to add people on Twitter, tweeting about a certain subject, to a list. Without having the need to follow them all first. You can make a list of game developers only and have it open in your browser. This way you keep up-to-date with everything that people withing your list post about game development. You can create multiple lists about just as many different subjects this way, So you don’t have to filter relevant tweets from your main Twitter feed yourself (of course you still have to create the lists and fill them with interesting people).

6 The core

Twitter only allows you to use 140 characters. This includes spaces, so it’s not an easy job to share all that info without crossing that limit. This is why you sometimes really need to get to the core of what you want to tell. Be it the USP (Unique selling point) of your game, the latest news about your game or just an opinion about something. It can be hard to get to the core, the most interesting information, about what you want to say. Twitter is a great tool to train this asset. So for every piece of information that you wish to share, at least try to make a version that fits the 140 character limit.

I’m sure there are a lot more reasons for using Twitter and just as many why you should not. But every time someone tells me they don’t have, or use Twitter, they miss an opportunity to share their wisdom and experience with the world. A lot of wisdom can be put in just those 140 characters. So whether you tweet about your game, your education, your job or your evening dinner. Just be sure to keep updating people with what you have to share with the world.

Of course you can follow me (@Ithunn) or Speelbaars (@Speelbaars) on Twitter. Try sharing your opinion about this blog with me.