Get the latest Education e-news
  • Developing With An Eye For Efficiency

    - Tuomas Erikoinen
  • To start out with a simple statement, I think effectiveness comes through experience and focus; being able to steer away from time-consuming decisions early on throughout a project and knowing how the different processes evolve from start to finish.

    Keep in mind that I develop casual mobile games (mostly), so the following is written that in mind, and much of it I wouldn't suggest to a hardcore game developer.


    Since I've shipped so many titles on mobile, I've gone through the process multiple times, having stumbled on the same repeating problems. With every published title I become more aware of the problems that await in every project. Because of that I prepare for them before-hand making them basically non-existent. Many of these headaches change over time due to software updates, new devices, limitations, restrictions and whatnot, but by publishing often I keep my self up-to-date with them.

    The published projects build up a "framework" of solutions that I re-use in the next projects. This saves the most time I believe. There are so many aspects to a mobile game that need to handled in order for it to be considered a "full" game, e.g. in-app purchases, advertisements, social mechanics, UI, audio handling, cross promotion, input handling, economy and whatnot. For me this framework has built itself up over time. Each of the features take a lot of time to implement if done from scratch, but by using them in all my projects they get refined over time and take even less time in each new project I start. 

    I recycle a lot of other, non-technical, material from game to another, too. If you look at any of Part Time Monkey's games you'll notice that especially the UI looks more or less the same in each, with just different colors and compositions. I try to recycle much of the ingame art too, if possible, but always in a fashion that it doesn't feel like the previous.

    Having a technical background in game art for a number of years gives me the ability to make constant decisions that remove or minimize later development steps, for example performance-related issues. From the beginning of time I've approached game art in a more technical way rather than artistic. This means getting to know the software, its tools and shortcuts in an efficient manner, making it so that I don't have to learn new things when trying to achieve a certain look for a game.

    I've always been very nitty about naming conventions, project hierarchies and making sure that a project never has any legacy or otherwise unneeded assets in it. As I've done this since always, it has become a subconscious way of being, and therefore I don't need to think about it anymore, it just happens. This goes deeper than just the project hierarchy; I group and name layers within PSD and 3D files, have solid naming conventions in scripts and even keep my folders and files in Windows tight and clean. Having everything organized helps to save time for always knowing where something is and how it has been created, in order modify something or create more similar material. I think that this paragraph becomes even more crucial in effectiveness when working with a team, and needs to be applied to the whole team.

    I never start developing anything unless I have at least a hunch of how it needs to be executed and how it will look like. This way I avoid an uncertain timeline and can plan further without yet having everything in place. I say no to a lot of ideas of my own (and from others) just because I don't know how to do it easily. If there's something interesting to be achieved in an "unknown", I try to take baby steps towards it by using other people's expertise, or Google and Unity's asset store. Examples of this could be shader programming and advanced mathematics, or new software and/or plugins. I think it's much more valuable to execute fast with a good look 'n feel instead of waste time on forcefully trying to achieve something new and unique.

    Through experience I know I lose motivation on long-lasting projects and tasks, and I've accepted it. This "self-awareness" has lead me to drop projects early if I feel it's gonna take more than 2 or 3 months to get it in a presentable, almost shippable, state.

    I'm a workaholic but I don't often do long days. I'm a workaholic in the sense that not a minute goes by that I wouldn't think about something work-related. It makes relaxing harder but keeps my motivation straight.

    I don't stress or worry at all. I used to stress a little, but over time I've realized that it doesn't help me at all. Now I get tingly sensations when I'm on a tight timeline in an excited way. I might get frustrated too, but it's mostly about me not being able to solve something that I know should be solvable within minutes if I just did something right. It's a great challenge. This may sound weird, but deep down I don't care if I don't hit some specific deadline, since in the end I know that I did my absolute best, and the deadline wasn't met because I made some humane error in estimations or predictions. I take full responsibility, but I use the failure to be better next time. Don't worry, be happy!

    The next paragraph will sound a little vague, but it's something I often think about so I wanted to put it out there.

    Many people will say that the last 5% of effort mean the most, but I think it can be easily misunderstood by using a lot of time on some certain - often non-important - features, therefore leading into a game where parts have been done to "the full 100%" and others with a 20%-attitude. I'm a strong believer that with casual games 80-90% is enough, as long as it's executed all-around the project. 


comments powered by Disqus