Caped Koala Studios hibernates its operations in Poznań in September. As part of the last month at the studio we are doing a small marketing push just to reach anyone who might be interested in educational games for children.
As part of the action I’ve decided to write a small Post Mortem. This is still an early version so if you have any questions or comments – please don’t hesitate and contact me directly or through the comments section.
Pora Pal HQ – www.poraora.com
When I joined Caped Koala Studios, Pora Ora was a browser game. They hired me for bug fixes and development of new features. My beginnings here were mainly getting through the thousands and thousands of lines of code with sporadic comments (some of which written in Hungarian. Good thing we have automatic translation these days). Debugging filled my days.
One of the curiosities was that the code had obviously been written by various programmers coming from different perspectives, so there were systems written with MVVM in mind just as well as some “I can do the whole mini-game in one function with a lot of ifs”. It took some crazy context switches when reading the code ;). Later I’ve found out that this is part of a known antipattern called “lava flow” and today I must say I am not without fault in this regard too.
Back to the story. The game at the beginning had been developed on a contract formula. On one side a designer in London and a backend developer(s?) in Poznan and on the other side an outsource game company. The process looked something like this: in-house team designed the game and all the required APIs and sent a specification over to the game company. Those iterations took about 2-3 weeks. If that’s not a nightmare creative process then I don’t know what is :p. They had used JIRA as the main communication & tracking tool which I think had contributed to overspecification and drove quality down.
Looking at it now from current perspective, taking over the code sounds much worse than it actually was. Of course I’ve cursed a lot about the, umm, plain stupid solutions, but it was also very fulfilling to see that I could do some of the systemic things to better improve the quality with simple tricks.
It was also a very differently structured workspace to what I’ve been used to in my short career. My voice was heard, I could propose solutions and the advice was actually acted upon. This felt great. I was also learning a lot daily, both about the tech stuff and also the applied soft skills. The guys I’d been working with appreciated that I was frank about things, but I definitely had been too rough at times.
Anyway, we’d shortly established a balance in which I’d have a lot of freedom while at the same time making sure that we share the vision when it comes to the core ideas and the general direction provided by Conor, our designer. I worked hard jumping between systems and introducing new features hoping the game to skyrocket any day now (then?).
About half a year later I’ve realised that we clearly need a more coherent vision for our product proposition. Don’t get me wrong – I had known that the game was a patchwork of various ideas but I had assumed a common truth or value that would drive the creative process. It spawned some discussions about the core loop and engagement and we have ended up adding some new systems and iterated upon the old ones.
This is about the time that Conor wrote the blogpost about monetisation on our internal blog. This meant we were not going to use any of the aggressive practices that most of F2P games use. We wanted to provide a demo and ask for money only after you’ve liked the game. I agree with the mission statement wholeheartedly, but from a business perspective I’m afraid that we would just need to look for money elsewhere and support our edutainment efforts as if it was non-profit. To a point it feels we’ve become the JCPenney of edutainment. In the way that being too honest and fair has set us back (yeah, slightly far fetched comparison).
In perspective I think we, as a product company, have also lacked a strong audience definition. Our audience was semi-defined as teachers, children and parents. The issue with that approach is that those groups have very different goals when it comes to edutainment. Teachers want education, children want entertainment and parents, well, they might want those educational games to serve both purposes.
Defining the teachers as the target audience we would need to focus on improving the for-classroom capabilities of our games, which are present but were not the focus. On the other hand if we had focused on children as the audience we could make the decision to put more weight on the fun component and possibly at times sacrifice education. This has actually happened later on to the new Spellfire game that we have released recently on mobile (iOS, android) but we didn’t follow through with other games.
Back to the story – later came the news about browsers no longer supporting the Unity Web plugin and the decision to turn the web game into a PC (Windows/Mac) game. This took a lot of effort to increase the quality given the unleashed processing power we’ve gained through switching platforms. There was also the launcher work so that the game updates itself auto-magically. Those technical challenges were in a way a relief presenting fresh opportunities to learn and improve the game. However, speaking from perspective, solving those issues distracted us from looking at the basic conceptual problems like the target audience definition.
Then we’ve got back to the core loop and engagement improvements until I’ve moved to the Green Hotel project which was work for hire we’ve done as Caped Koala.
This is almost end of the story. Now when my focus is back to PPHQ for the last few weeks. I work mostly on adding the small touches I’ve always wanted to add, like growing up Pora Pals, which add some fun to the game but don’t really impact the core dynamics.
Let me know if you have any questions.
To sum it up here I’ve prepared a small list of good, bad and ugly:
– Creative freedom and the feeling of responsibility which made the work both challenging and fulfilling, really good conditions for growth.
– Some of the ‘big changes’ like the UI revamp turned out to be really cheap, (to the point that the local team decided to ask forgiveness not permission and we could treat it as a side work from our main tasks.
– In slightly over a year from forming the team we’ve completed 3 mobile games and redesigned a Windows/Mac game.
– We’ve got some experience launching a game on greenlight. You can vote for us here
– Working remotely with a designer makes it harder to iterate quickly
– Lack of structured playtests made us, at times, feel like running circles
– 5 years in development (with a couple of releases along the way) and a huge total project cost