Game developer, and then what?

Wow, it’s been almost two years since Darkfall (Online) was released!

I was involved from the very beginning, in 1999 when we were a bunch of young inexperienced guys with a a dream of making “the best game evah” ™. We started a company here in Norway in 2000, moved to Greece in 2003 and released Darkfall, a badass full-loot player versus player  mmo, on the 25th of February 2009. That pretty much amounts to 10 years making one single game.

I moved back to Norway when Darkfall was released, and continued working remotely for the company until September 2009 when I took a job as a IT Consultant, working mainly with insurance companies.

That was quite a career change! Or was it? Well, yes and no.. I am basically doing the same technical job (solving problems and programming) and am working with great people, but I am working less and being payed more. I love computer games, but my passion for programming is what counts. As an IT consultant I suddenly had a completely different set of problems to solve, using new set of libraries and tools, in a very different domain.

Coming from a game developer background I had a lot to learn, and the last year or so has been a great challenge in that respect. I also got to see the way the Dark side does things. Dark as in enterprisey, and enterprisey as in lets-use-this-overrated-bloated-library-to-solve-this-insignificant-problem-as-difficult-as-possible. The game developer attitude of lets-just-get-this-shit-working-don’t-look-at-the-spaghetti-code attitude doesn’t work that great either. I am exaggerating of course, but there are clear differences in attitude between these two camps, and coming from one to the other is a good way to evolve as a programmer. Being able to see the differences I am also aware of how both could become better by embracing some of the “methods” of each other.

The game company I helped build and worked for already has most of the traits it needs, and from what I have heard is continually improving after I left. A game company is agile by default, as a necessity. There is no known way yet to completely pre-design a game and then just start developing it without significant changes to gameplay and/or concept. Darkfall went through many changes from the original idea to the end result. Most of the changes were small things, and the main concept was kept throughout, but still, it meant the game design was a moving target, and we had to factor that into the implementation. The project started with no version control, no proper backup mechanisms, no test-servers or testers, but as the company evolved, all of these points were solved.  Now the team even runs Scrum sprints, embracing the true agile spirit! 😉

Coming to an insurance company as a consultant, I was worried that everything would be designed top-down, full of bloated frameworks, and old enterprisey code, and I would be sifting through megabytes of xml to find the actual problem whenever anything bad happened. This is probably true for a lot of old insurance companies, but didn’t hold quite true for me. It turned out that while bloated Java web-frameworks were there and some people still adhered to omg-we-need-a-framework-for-this solutions, there are forces working to simplify things, cut the bloat and make things more agile. I am lucky to be working closely with some of those people, learning the domain and hopefully contributing a little too. Recently we introduced distributed version control and converted a bunch of projects, and started using the Play Framework too, which is great!

All in all, my experience in switching from game developer to IT consultant has been a pleasant one, and it gives me more time with the family too! Well, except for the fact that I am now making casual games in the evenings, under the banner of BadgerPunch Games. 😉

2 thoughts on “Game developer, and then what?

Leave a Reply

Your email address will not be published.