So yet another blog has been started.
I spend a lot of times in hotel rooms when I'm travelling and I need something to do apart from watching TV and reading books.
During my years as a producer at Starbreeze I was maintaining a document where I stored all my lessons learnt. Most of these lessons were paid for fully with the cost of repairing for the mistake made. However, in my mind you have to make mistakes otherwise you are not pushing the boundaries. Thus the title of this blog.
Actually one of the lines in my document is "The only mistake is not learning from your mistakes" which nicely summarizes how I view team leadership.
To get to the point I intend to occasionally post a line from that document and write some explanation or perhaps war story to explain my thought processes around that specific learning.
Before we start this I want to give you a little bit of background of who I am.
How I got here
At the end of the nineties I met two guys at a job fair at Uppsala University. I was a soon-to-be graduated student that needed some topic to do my thesis on. The two young guys had been working on a game together with some friends over the last two years and it was not far from shipping. They were looking for someone that could develop a BSP renderer in their engine. To be honest I had no clue what it was but it was something that really interested me.
As a kid I was always coming up with new game ideas. Not for computers, but board games. I created a hockey board game and submitted it to a few publishers. It wasn't published, probably rightfully so, but me and my brother had plenty of fun playing the game at home.
Besides creating board games I was also very much into computer games. My first computer game memory was playing Decathlon on the 086 that my father occasionally brought home from work. I loved that game. But tragedy was lurking around the corner.
One day they upgraded the computers at my father's workplace. Next time he brought home his new 286. I was really excited about playing Decathlon, but it was totally unplayable. The game was running at lightning speed. Apparently the developers hadn't created the game so that it was independant of CPU speed. I didn't realize that then, but that moment was the beginning of my interest in game development.
Over the years we got new computers at home and I was fiddling with them to make sure that they could run my favourite games. I spent long nights connecting to shady BBS's downloading the latest games and distributing them to gain credits at other BBS's. This was an annoyance to my parents as I ran up a skyhigh phone bill and the home phone was blocked almost all the time.
Even though my childhood circled a lot around different types of games I never thought of it as a profession. It was a just a major coincidence that I stumbled across these two guys at the fair. This fortunate event is what led me into the games industry.
So I wrote my thesis at their company, O3Games, while the rest were finishing their first game, The Outforce.
Shortly after that O3Games joined forces with another Swedish developer under their name, Starbreeze.
At this point I had joined the game development team and worked as a game play programmer on their first title, Enclave. My main responsibility was the bosse. We had a really tough schedule and pretty much had to take each boss fight (and there were many) from prototype to final in about week.
I really enjoyed doing that project even though I was hit hard by a flu at the end phase, probably caused by exhaustion.
||With Enclave shipped Starbreeze was expanding and added another development team. I was still quite fresh in the games industry but was appointed Lead Programmer of one of our next projects, Knights of the Temple.
That project was extremely problematic for several reasons, the main one being that we thought it would be fun with realistic sword fighting. That is not the case! Swinging a 10 kg sword takes about 3 seconds, meaning that the player have to wait a lot between inputs. It was mind numbingly stupid that we for some reason thought that it would work and continued working with that design for at least half a year. Given my view on mistakes I look back at this as one of my best learning periods in the games industry, though it was a costly lesson.
While we were creating Knights of the Temple the publisher on another Starbreeze project went under. This in combination with our slow progress on Knights of the Temple put the company in a difficult position. After Knights of the Temple was shipped most of the staff was let go, I was one of them.
Starbreeze still had one project they were working on and I joined that project on my last 6 months at the company. This was The Chronicles of Riddick: Escape from Butcher Bay.
Working on that project was extremely fun as the team was just incredible talented. I was doing some gameplay code on that project, among other the the aiming mechanics.
My final day at Starbreeze was before the game came out so I was not there when the game was actually released. I did have a small problem though since I had so much fun working at Escape from Butcher Bay I pretty much didn't look for work. Luckily one of my colleagues at Starbreeze was offered a job at Ongame which he kindly passed on to me.
I spent 4 years at Ongame/bwin and got a good lesson in agile development.
In autumn 2007 it was time to go back to Starbreeze, but this time I joined as an Associate Producer. There were two projects running and for several reasons I quite rapidly became the producer for The Chronicles of Riddick: Assault on Dark Athena. This is when I started working on the document that will become the foundation of this blog. During my 4 years at Starbreeze as a producer I was part of making two shipped games, 1 canned game and a countless number of pitches.
Now I'm working as a Senior Production Expert at Hansoft and in my work I travel around to studios helping them make best use of our tool. These discussions often include how to organize a team and the best way of using agile methods. The document is a foundation for a lot of my opinions on how to set up a team to succeed and which pitfalls to avoid.
Not everything in this blog will be focused around the mistakes I've made. I will also touch the subject of how to implement agile methodologies in a game studio.
Here we go....