The Indiepinion

August, 2006 – Phenomic acquired by EA – the product we pitched was a trading card RTS game with the working title BattleForge.

November, 2008 – BattleForge is still the title of the game and the beta is receiving welcome amount of attention from the beta participants.

It’s been over two years in development. We have changed so much in two years. We as in “we as a team”. New development methodologies were introduced, adapted and improved. Colleagues got married, babies were born. Some were not so fortunate and parted ways. Some decided to leave Phenomic to pursue other interests. Some came back after their internship. Some took on new roles, new responsibilities. Some went to visit other EA studios or presented our game to the public and press. They always came back with lots of positive feedback. My tasklist is slowly disintegrating. Last time i looked i have one lonely C bug left. I am about to move on … to another project in a new role. Time to reminisce!

One of the things that did not change was the vision for the game and correspondingly it’s name. I don’t know if there has been a decision to keep the name, but frankly speaking it somehow fits well into the BattleField line of games, and in a way we borrowed BattleField’s distinctiveness and extended it into the Realtime Strategy and fantasy realms.

From my perspective BattleForge has become the game we wanted to make. Granted, in our eyes it still has so many rough edges and unpolished surfaces … but we’re also looking at it through a magnifying lense, like the jeweler inspects his rough diamond. He sees imperfections where others see a jewel. It’s always hard for us to look at our game for what it is, and not looking through the lense, not being overwhelmed by the number of tasks and bugs that are still in our system. Not looking at the small imperfections, gloating over them. We are developers, we are perfectionists – in a way we can’t help it.

For me personally, the move to EA has opened up ways to grow in an environment that fosters growth. At the end of 2006 i was still a “junior” programmer, moving from the Level Design position to become a full-time programmer. I’ve had experience with Lua and C# and wrote our Script System and several tools. It seemed logical to continue with tools programming. But it took some time getting acquainted with the new job. I still remember that i was tasked to build our asset pipeline. I quickly discovered that this isn’t the kind of tool i wanted to work on. It was too technical, too low-level. It has no users at that point other than to be run automatically on our server.

I switched to working with our database frontend tool. That meant learning database concepts, SQL, Hibernate and also C# and .NET and several 3rd party UI libraries. If i had known back then that this tool would pose even more technical challenges, high expecations from users and numerous conflicts of interests when trying to balance technical design with user interface issues. It’s only now, almost two years later, that our new intern discovers all the oddities and design decisions which enables me to really look at it and see where i have succeeded, and where i gave up. Sometimes there was just no time to dig deeper. Other times i must have been in a certain state of mind, accepting ill-conceived notions of how things work that i don’t fully understand. It takes time to understand. It takes a different perspective. On the other hand … despite all the learning-in-progress that you can see all over the code, it was a success. It is stable, it is flexible, it scales well although performance issues did start to show when we added localization. And the dynamic UI did not scale as much with the enormous amount of data we are dealing with – much more than we initially estimated. But there is always a way, always a solution. The only limiting factor is time.

In late 2007 i switched to C++ for a few months and refactored and basically re-engineered our Script engine interface in C++. Here it was easy going, maybe a little bit too easy because some of the plug-in functionality was probably overdone and not used as much – on the other hand BattleForge will continuously be worked on so i hope that it will pay off in the long run. I knew exactly what i wanted to achieve, which things needed to be improved over our SpellForce scripting engine both because it made things easier for us and more powerful. Some of that power was absolutely necessary given the design -the little coop scripting we did in SpellForce 2 showed severe limitations of our scripting system regarding a scripting in a multiplayer environment. The BattleForge scripting system got the needed overhaul, and then some.

I believe in fall 2006 i evaluated, installed, administered, improved and costumized our wiki system. I was one of those who openly campaigned against our first wiki installation maybe another two years earlier. Back then we used TikiWiki which was coder-friendly but utterly user-unfriendly, irky syntax only coders can relate to, it was easy to mess things up. This time we went with a commercial product, one that has a true WYSIWYG Rich Text editor, markup syntax that is as simple as it can be, plug-in functionality to add nifty things like checklists, galleries, collapsing paragraphs, voting and so on. It was still complex enough so that i gave our staff training sessions and open support. Even today people occasionally come to me to ask me about the Wiki. It’s become ubiquitous.

On a personal level … i learned a lot about how emotional work can be. How i and others react in certain situations under varying circumstances. How frustration and anger come quickly with stress and fear of failure. How subjectively success and failure are perceived in general. How people tend to exaggerate. To blow things out of proportion. How others perceive “their” world and how they want me to share theirs. Gradually i had to learn to stand ground, or risk falling over. I learned that there can be demand and expecations hiding behind an innocent question. But I also hat to learn that most of the time, it’s just an innocent question and everything behind it the memory of a bad experience. But sometimes even innocent questions can be very demanding, when they show how little has been learned, or how much of my sanity it will cost me to answer it.

Managing expectations is probably the single most important skill you have to have when you have a costumer – even if it is an internal costumer. I learned that under-promise and over-deliver really works and makes everyone happier and more productive. You have to leave room – especially mentally – to be able to react to the people around you. To be able to help them when they need it. To enable them to help themselves so i don’t need to anymore. I was surprised about the number of issues i’ve got in the last months from our Level Designers – there were so few compared to previous projects, and most were easily solved.

It’s also hard work. The hardest work of all is being and staying a professional with what i do. It’s not their fault, it’s mine. Of course, there are exceptions but this is the general rule. It’s my fault. I didn’t teach you. I didn’t tell you. I didn’t understand you. I didn’t have to when i should. I shouldn’t have when i did. I dig it.

Still learning, though … always will be.