My gamebiz predictions for 2010.
I submitted these predictions to the Deloitte Fast 50 TMT Contest:
In 2010 we will see a huge shift in the game marketplace. Where 2009 was all about games on social networks, this “social influenza” will find it’s way to all major consoles and mobile platforms. Connected gaming will be more important than ever. With key players like Apple betting harder on the gaming scene, new business models will arise in an accelerated pace. Apple will start selling games through their retail channels for multiple platforms (including the iPad and an Apple-built media/gaming console). This starts a butterfly effect where players like Sony, Microsoft and even large publishers like EA start to open up their own direct-to-consumer stores. Whether it’s retail or download, the major trend will be that developers are directly in touch with their end users. They will thrive by providing Games as a Service – access to social universes.
(PS: This applies to all media industries.)
So what do you think? 
Dinos vs Birds
Organizations everywhere struggle with their existing markets, organizational structures, communications. They are fighting for survival in a fast-changing world. They are like dinosaurs.
Dinos: Hierarchical, hungry, big bones, heavy, thick skin.
Birds: Flocking, migrating, feathers, light, vulnerable.
If you are a dino, you need to evolve. Grow lighter, grow feathers. Start flocking: give stakeholders autonomy and purpose. Stop growing bigger bones (solidity, structure). Start growing feathers (fly!). Dare to be vulnerable.
Some dinosaurs evolved into birds. We all know what happened to the rest of them...
Three lessons from our first game on Facebook
Today we launched EnerCities, which is our first experience with launching a game on Facebook. As with all firsts, it has been quite a challenge. And already I can say that we have learned a lot about the platform and it's best practices. I also believe we have seen nothing yet, and most of the stuff I am about to post is so basic that it's painfully obvious.
Enough disclaimers, here are my three take-aways so far:
1 - Design It Social
EnerCities has been in production for about 8 months now. And one month ago, we decided that we should use Facebook as the main platform for the game (besides the website on www.enercities.eu). We thought that the game was suitable enough for the platform, and with the "simple" addition of a friends bar where you compare highscores we'd be there.
The problem with this approach is obvious and important. Facebook is above all a place where people socialize and hang out with their friends. It is not only a timekiller, but for many people the primary way to stay in touch with their friends. This means that if you do not facilitate social interaction, you are actually competing with their friends for attention. This is a battle you will lose, so the game needs to have a strong social element in it's core mechanics.
2 - Testing
We are a game developer with a background in 3D visualizations and heavy-duty simulators. Web games are something new to us, and we are struggling for a solid production pipeline with adequate testing capabilities. Only now have we found a way to run Facebook apps on a local server - previously we had to create a separate developer account for development and testing purposes.
We have run several tests internally and even have a great testing company on board (Sogeti) who were willing to share their expertise with us as a pilot for the games industry. With Facebook and a website online, and hundreds of people playing it, testing is no longer nice-to-have "Hey we're testing this stuff! Works great!". It is essential that we get it all right all the time.
Obviously when you release an online game it needs to be solid as a rock on launch day. However, and this is new to us, any updates you make on it after launch day requires a lot of testing as well - and that is putting releases in an untouchable position after they launch. The common "quick fix" simply doesn't cut it anymore, and the review phase should probably be more strict from now on.
3 - Limitations
Facebook seemed to us like a platform where everything is easy and the API carpet is laid out for developers. Funny as it seems, this is not the case. We use Unity3D and while this gives awesome graphics, it is less flexible than Ajax or Flash when it comes to FBML, PHP calls and Javascript events. There are tons of ways to achieve one thing, and to choose the right way is not always that easy.
Note that I'm not the techie here, but the simple fact that we cannot overlay anything on top of the Unity player is a great example of one of those limitations we face.
Concluding
All in all, it has been a great learning experience and we have hardly started yet! I will keep you posted on our adventures to come. Stay tuned!
EnerCities: The Story
This is a presentation I made for E-Virtuoses, a serious games conference in Lille. It's about the project EnerCities, how we got it, what we've built so far and what we're currently working on. Enjoy!
Why we went from Scrum to Kanban
I love agile and lean management. If it were up to me, project management would be a bit like farming: prepare the ground, sow the seeds, harvest when ready. I´m a treehugging tech hippie.
So when Scrum arrived in our backyard, I was pretty happy with it. Here was a semi-formal methodology which we could use to handle larger projects with relative ease. And it worked pretty well for us - I even consider myself a bit of an evangelist.
However, things change. At Paladin we are currently making a big shift towards consumer products instead of smaller B2B projects. And during this transition, we have to balance our time between paid B2B projects and our upcoming flagship 3D game which is launching later this year.
When we started our first sprint recently, we had trouble defining it. First of all, we didn't know what the heck we needed in terms of technology, let alone the design. We did not know all the details of what was needed to get it done. Because of this, we were unable to commit to a defined set of outcomes, as we knew there might be small commercial projects coming to intervene with the schedule. As we didn't want to downscale our ambitions for the project, we needed more flexibility.
Enter Kanban!
Above is what our kanban board looked like a couple of weeks ago. It´s a little unconventional, and this was in an early stage of adoption, but it worked for us so far.
Here's 5 reasons why we adopted Kanban:
1. We can work on any project at any time
We can switch between our game and small projects at any time. This means we do not have to wait for a sprint to finish before we pick up the commercial projects.
2. It allows us to aim higher
There are many uncertainties with our game, as it involves some complex things like cloud computing. We have little experience with these areas, and so it is hard to determine the required time for a task. As a result, we were holding back with our commitment for a sprint. Kanban allows us to focus on the tasks themselves - we simply focus on what needs to be done, without worries about delivery on a specific date. The daily standup meetings take care of the rest.
3. It integrates with the art pipeline
Functionality is best described in use case stories. Art, however, is organic. One cannot describe it, nor put a deadline on good art. It's done when it's done, and most art assets go back-and-forth from To Do to In ProgressReview. Sometimes on a daily basis. With Kanban, the art director can give his feedback without disrupting a milestone or the production flow.
4. We are more relaxed about emergencies
When something unexpected comes up, we know what to do: we make a sticky note, slap it on the "To Do - Urgent" row, and pick it up when someone capable is ready with his current task. There is no disruption whatsoever, the pipeline keeps flowing naturally.
5. There is more focus on the actual work
When you eliminate the stress of deadlines, you simply focus on your task at hand. This is the single most powerful thing to improve flow, and it increases productivity tremendously. The result is that at each weekly review, we are all surprised by the sheer amount of work we got done. Even with plenty of `distractions´, our main project is still on track, and there is little pain involved in keeping it that way.
Working this way has been a joy so far, and I see some big potential for Kanban in the upcoming months of development. Of course there are issues as well, but most of these are addressed during the daily standup meetings.
Further reading:
- Kanban at Wikipedia: http://en.wikipedia.org/wiki/Kanban
- Scrum vs Kanban: http://richardsbraindump.blogspot.com/2007/10/scrum-vs-kanban.html
- "Scrum-ban": http://leansoftwareengineering.com/ksse/scrum-ban/