April 2, 2018

Efficient Development

I often get asked how I develop games so fast with high quality. Usually I shrug my shoulders and give an "I don't know" answer because it's half the truth, and I don't want to sound like a know-it-all fool. I've been pondering on it for a while, however. I think the actual answer is quite complicated and has to do with a combination of a variety of things that connect together. I'll try to put these thoughts in words.

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.


This image is here just to break the wall of text.


Experience


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. 















Art, Design & Audio


My projects often start based on other games, sometimes even straight up copying mechanics. But as the project evolves, it usually turns out to be something else than a rip-off. If it doesn't, and it feels too much like its predecessor, I'll just scratch it and start something new. However I think it's a good starting place to rip off something that works well, since someone else has done most of the design work already, and I can reap some of the benefits by making a new version of the same. In the end, everything is a remix anyway.

I'm not a good traditional artist but I've got an idea on what looks good. I've realized this early on, which has lead me to only approach simplistic art by using my technical knowledge. Most of the art in my games are just plenty of "disguised primitive shapes" put together with an idea of how the big picture should look like. This, again, enables me to create good looking stuff fast without having to spend time on concept art or even learning how to actually draw. I use a lot of references to skip the concepting phase, meaning mostly going to Google and search for "<desired thing> cartoon" and quickly glancing on how others have conceptualized the same thing.

For small mobile games I don't think audio even really needs to enter your thoughts, it just needs to happen. There are so many good-enough free or very cheap sources online that it makes no sense to create your own SFX or background music. It's fun, but not necessary in order to be efficient. I've done some audio myself, and had my friends do, but for the bigger picture I know it doesn't make sense. Sometimes, though ,it makes more sense to spend a little longer on something just to have fun, to keep one's motivation straight.



















Getting Downloads


A lot of people who I've discussed with about getting visibility on the mobile markets are strong believers that it's more or less lottery. They also claim that there are thousands of games that have earned visibility but just haven't. I don't agree on that at all. While it's true that there might be games that for example have a good mechanic, interesting meta-game or a unique idea, I claim that they all lack at least one or more key ingredients that don't make them worthy of publicity. A game doesn't earn its visibility for just one good thing while ignoring other aspects to it. It needs to have, more or less, "everything right." Most indie developers come from a programming background and may ignore for example art, first time user-experience or UX altogether over just good technical implementation or complex gameplay that they find fun.

This comes back to having everything 80-90% right rather than 20-100%. I strongly believe that the reason for my games' visibility comes through not ignoring any aspect of a game. I find it even more true for the fact that when I released my first game Monkeyrama, it didn't get the visibility I thought it had earned at the time. Now I understand that even though it had good visuals and core mechanic, it lacked the depth and consistency that my more successful titles have had.

Something else


I don't think I am a very good leader. I expect same efficiency, results and like-mindedness from others, and when I don't see it, I get frustrated and don't communicate my thoughts very well. I think the reason for this is that I spend so much time inside my own head consciously and subconsciously mixing everything I know, that it becomes something that I can't even verbally pronounce, it's just something that makes me efficient. 

But Part Time Monkey is already a two-person team, and I can always get better at teamwork by putting my mind to it, and employing the right type of people who can bear me being a little ... cranky at times.

Conclusion


By having worked as an artist, technical artist, core-designer, meta-designer, producer, audio dev, and a programmer, and having published close to 10 games on my own with and without publishers, I think my efficiency comes by being able to mash all the learnings and thoughts in my messy head, which leads into quick development by seeing with multiple eyes.

Or... I have no idea what I'm doing and I've just been insanely lucky. Who knows.

Games and Dev Times

Breakout Ninja, ~3 weeks
Monkeyrama, ~1.5 months
Space Bang, ~2.5 months
Silly Walks, ~4 months (together with Simo Kovanen and Asmo Jussila)
Space Frontier, ~1.5 months (published by Ketchapp, designed by Antti Ilvessuo)


4 comments:

  1. Very nice blog on domain detail the information provided is very useful can use for work. Keep sharing such informative content. We like to read about this.
    https://ludopot.com/

    ReplyDelete