Tomorrow it will be my 50th birhday, so today feels like a good day to continue with taking a look at the history, the past decade and beyond.

I think that for ten years I was rather active at Facebook. The on-line social life balanced the tranquility of living alone. For me social media meant philosophical discussions, a lot of silly humour to brighten the day, personal communications, and also made it easier to meet friends in the real world. But slowly it started to feel more like draining time and focus away from the things I'd love to do. My on-line activity withered to minimum, more like keeping and eye to see what my friends are doing and if there are interesting events I'd go to if I had the time, money and energy to do so. And I feel that both are good; the period of active social media was good, and I also enjoy this more quiet phase.

Then, for Ancinet Savo development I started a Discord server to communicate with the test players; to post my development updated, to get bug reports, ideas and other feedback. That was different from my earlier Facebook silliness - more focused, contributing to the progress of the game project instead of feeling like unproductive procrastination.

For Ancient Savo I use a library called libGDX, and at some point I joined their Discord to ask for help. After a few years of coding I realized that I had learnt some of tha basics of the library so that I can contribute for the community by being active at the Discord, answering newcomers and helping them to learn the library or game development in general. Fortunately, that has not felt like procrastination, but just reading what other people post and sometimes participating in the discussions I've learnt things which help me with my own development.

Well, a few days ago an another user from the libGDX Discrod wanted to ask me some questions. I found the questions good, and maybe they'd be interesting for someone else too. So I decided to reply by writing a blog post. First, the questions, a bit shortened, edited and reordered by me:

1. How did you learn to code? What resources helped with the process?
2. How do you balance these different aspects of indie game development? Coding, art, sound, code testing, refactoring, gameplay testing, etc.
3. How do you come up with creative endeavors, be it a game story, a game concept, a story, music, etc.

---

Learning game development

I think I was about 12 years old when we (me and my two brothers) got our first computer, Commodore 64. After few days of intensive playing me and my older brother started learning toAnd code. First BASIC,then the 8-bit assembler. That was pre-internet times, so the main resources were two books, and articles in Finnish computing magazine MikroBITTI. At the early stage some of the learning was simply manually typing code published in the magazine, and running it to figure out why and how it works. So, it was pretty much learning by doing, a lot of experimentation and the good old trial-and-error. That was mid 1980's , before the internet was mainstream, before OOP grew to be a main paradigm. Or, if it already was, at least we didn't know anything about it. The main lesson learnt reading the magazize was: "Do some planning before writing code, break big questions into smaller questions and solve them one by one, organize your code, have fun!" - a lot has changed since the 1980's, but I still feel that these principles apply, and I do recommend learning-by-doing for anyone who starts learning game development.

I'm not sure but I have a feeling that in the 80's it was easier to start indie game development - the computer were more simple and the resources were limited, the big commercial games were something two teenages could do in six months. And at a times it really seemed like the trail-blazer showing way was not the big studios, but indeed some teenagers hacking code after school. Now, when I listen to young people thining about their first game ideas, it sometimes feels that one of the obstacles is the vast distance between what big studios can produce, and what a beginner coder can do. In my teenage years an average commercial game could have a 2D walking animation of two frames. Yes, two. Now I hear beginner coders struggling with how to manage a walking animation with 30 frames - and if they'd know how to do it in the code, then the pain is how to obtain those frames; should they draw all the pixel graphics by hand, or find a tool to try create something which looks like what the big studios have? Huh. Back in my day we didn't need to worry about that, drawing pixel graphics was fun, and often came with the art of representing complex things with very few pixels. In this regard I feel that my piece of advice might easily sound depressing: Scale down your ambition with assets, and it is perfectly okay to start with place-holder graphics. If making fancy animations feels like too much work, then don't let that sabotage your learning - start by coding what you can, and go on expanding from that. Eventually you'll learn how to make the fancy graphics you are dreaming of.

I think this is related to the more general theme of "learning your fist programming language is always the hardest part. Once you pick a langauge, it will be a lot easier to learn other languages, as you already know the basics, all the magic of variables, if-then structures, ints and arrays. Or, I mean - to me it seems that just coding anything is always better than not coding because of being uncertain about what would be the best language, the right paradigm, the optimal engine, the latest framework, the coolest IDE to use. Those are the things you can't know in advance - one just needs to start from somewhere, and as one gains skills it becomes easier to decide when to use the hammer and when to use the screwdriver, not worrying so much if hammer is better than the screwdriver. There are different tools for different purposes, and you first need to work with stuff to develop a gut feeling of tools and purposes. Or, to be more precise; this is how it has worked for me, and I'd guess the same applies for many of the other people, but of course there are different valid answers as well - maybe for someone it is better to enroll to a course, following a strict discipline doing given assignments. I have no formal education in programming, for me it has always been just a fun adventure of doing thigs and learning on the go. And again I feel it was easier in the 80's, as there wasn't so many alternatives to pick from. Want assembler, use the assembler? And as I grew older and more languages and approaces became available, it felt easy to upgrade step by step.

Hehe, sometimes I think that if I had more free time and energy, I'd love to host a small programming club for early-stage indie coders. If I had such a club, half of it would focus on technical stuff like "how to write code". And the other half, that would be zen, or which ever way you wish to call it; learning to observe how ones own emotional and mental patterns can hinder the progress, how to defuse frustration, how to culticate patience, how to cheerfully let go of the way one thinks ones own code should work and reading ones own code like one saw it for the first time. Embracing the deep unwavering sense of self-worth which is not tied to "being a cool coder" or "getting things right". No, it is okay to make mistakes, feelings of shame don't help so much with learning to write better code. You start with what you have, you are what you are that day and that is all fine. If you write poor code, that is good, because it means you write code and have an opportunity to develop your skills.

And the way I see it, one of the key traits of a coder is patience. Things take time. If you want to enjoy the view from the summit of a mountain, you can't teleport there, but you need to climb, step by step, no matter how many days or weeks that is going to take. And sometimes you need to retreat, to practice and learn new skills so that you can pass that difficult spot on the mountain trail. Sometimes you need to spend months with that training - it might look like you are not progressing up the mountain, but without the time spent learning the skills you'll never get past the difficult spot. So learning skills is progress, also when it means a few dozens of abandoned half-finished projects. When you feel frustration building up, stop there, take a deep breath and ask yourself where you are, where are you heading to, what are you doing and how long a break do you need to regain your calm. Again, this is just the way I've experienced things. Already before starting to learn coding I started to observe how losing ones temper often just is an act of self-sabotage, causing trouble both for oneself, others and the projects being worked on. So I wanted to learn how to meet my own emotions, how to cultivate calm withouth a sense of muting or suppressing my inner emotions. For me one of the keys was just breathing and switching the perspective - whenever a thing felt frustrating or annoying, I paused to see the thing in a broader perspective, and what seemed like a big problem started to feel like a mostly harmless little practical obstacle which can be joked about, allowing some time and experimentation to eventually solve the problem with no need to lose temper. I was happy to see how that attitude helped with coding, as both the creative and logical compartments of the brain seem to work better when the overall mood is unhurried with a gentle hint of silly humour.

Balancing

Well, but no matter how patient one is, there still are a whole bunch of acute questions - like how to balance ones development time between planning, writing code, testing, debugging, re-writing code, making assets, upgrading assets etc. And this is something I know I'm not an expert in =) But, the way I feel, one of the approaches which has helped me is focus. (And this might be one of the aspects where my mild autims kicks in, so maybe everyone needs to find the ways which work for them). Ah, so I was about to say: what has helped me is just immersing deeply at the task at hand. If I'm working with a single detail of a graphics asset, I focus on that and everything else fades into the background. Often I lose my sense of time, only later on understanding if I spent two hours or two weeks working with that detail. If it feels like something which needs to be done, then it needs to be done no matter how much time it takes. If it feels like "being slow" or "taking a lot of time", that is only relative to the inner expectations one set for oneself. (Assuming you are wokring without strict external dead-lines). So, for most of the cases my piece of advice is just to ditch the expectations. Two weeks in itself is not "fast" or "slow", it is just two weeks. And if you enjoy what you are doing, then two weeks is two weeks of fun. Please remember to cultivate the fun of indie development!

It needs to be said that I don't believe in universal solutions, so for every one-liner piece of advice there always should be a bunch of other approaches to balance things. In the above mentioned situation those other necessary and potentially helpful approaches would be "if thing X feels like taking too much time, then ask if it really is necessary, or if there is a way to make it simpler (like, starting with 4 animation frames instead of 34)". Also ask yourself if things take long because you are using a screwdriver to hammer nails - yes the internet says that a screwdriver is a super great tool to join timber, but details matter; if you have nails instead of screws, you'd better re-consider your approach. And, sometimes it might be simply wise to postpone thing X, go with place-holders and work on other aspects. For example, with my current game project, in the early stage I wanted to have rounded tile edges, but I didn't know how to best do it. I read a few posts in the web, considering several approaches, and then went back to my old school habits of programmatically plotting pixels on a pixmap to create shapes I wanted. That worked for more than a year, but eventually when I increased the tile size from 64x64 to 128x128 the old approach didn't scale well and often just crashed. So I needed to rewrite it, but now it was a lot easier as I had learnt many things since my first attempt at rounded tile edges. I mean, for me this is one of the ways to balance the workload - I can live with a bunch of temporary place-holder solutions, knowing that "eventually this needs to be rewritten, but at the moment it does the trick, allowing me to focus on more urget things".

One of my own weak spots is the testing. I always test the new features I add, but often it happens that a new feature changes something which might break another feature. But if I don't realize that, I just think "oh, I've already tested those old features, they do work", and so I send a new beta version to the test crew, who then kindly inform me that "the new feature works yes, but the old features X and Y are now broken", and I go back to bug-hunting and fixing. I'm deeply thankful for everyone who has the patience to test my code, as I'm aware that if I had to do all the testing myself, things would be even more slow, taking more time, and me needing to spend more mental energy on maintaining my calm, patience and focus in the middle of the long slow journey. If you can ask for help in testing, do it! A splendid piece of advice, isn't it? Yes I know, it isn't always easy to find people who would have time, willingness and patience to help with testing. The life of an indie developer isn't always easy (and then some players plainly expect everything to be fully tested and 100% bug-free, but not feeling like themselves doing anything to help with that, just consuming the ready-made-project. Sure, they can do that, and that is the point of being a player not a developer. It is just something I need to remind myself every now and then, for this "DIY and participate"-attitude has been one of the core elements of my own life, so sometimes I forget that a lot of people experience the world in a very different way. Again, one of these "non-coding" skills which helps with indie game development; the skill to make an attempt at understanding the another point of view, the different experience of different people.

Hmm, and maybe in a way this fits under the topic of balancing; once again I'd like to emphasize that re-factoring is progress. If you write code A, and later on realize it was not good and needs to be re-factored to A', and after six months you ditch A' and replace it with A2, does it mean that you wasted time writing A and A' ? No, I don't think so - especially if you do the refactoring because you learnt new things and gained new skills so that you can upgrade your code. But never ever do any refactoring simply because a random person or article on the internet says that HHGzB-pattern is the super cool perfect way of doing things and everyone should use that. Never refactor your code because someone says that they don't like your formatting (unless that someone is a close colleague working together with you and you both need to develop shared standards). Never refactor your code simply because you realize that another way of doing it might be 10 ms faster, or consume 4 bytes less memory - only do such optimization when you hit a need for it. Refactor only if it helps you solve a problem. If you don't have a problem, keep going.

And, lastly the basic approach, which I felt that has greatly helped myself to balance the different aspects, and to maintain my focus when things take time and development is slow:

No matter how complex and great your game idea is, start with trying to think what would be the absolutely minimal basic core of the functionality. If you'd love to make a roguelike with multilayered skill trees and a super cool crafting system, it might be easier to start with the bare fundamentals; like, make a map where you can move around. Then add items. Then skills. Then the crafting recipes. And the same for every stage; first add the bare mimimun functionality, later on you can add more details to the core. The idea of this approach is that very soon you will have something which is functional and "playable", just lacking features. I find that being so much different than first spending a year or two just coding stuff to make everything perfect; trying to build a system to manage crafting recipes, but having nothing to attach them to. I'm not sure if I can verbalize this in a good way, so I will try a metaphor instead; observe the way a plant grows. First, from a seed emerges a root, and the first leaves. That makes a living orgnanism, which then keeps on expanding and growing, until it is big enough to bear fruit. The apples don't appear hanging in the mid-air, so don't start with coding the apples. Start with coding the seed, then the roots and the leaves, make sure your organism is alive, and then just give it enough light, water and nutrient so that it will organically grow to the project of your dreams. That way you'll spend less time feeling frustrated about all the great features which you don't yet have, but you can focus on all the nice functionality what you already have. Being happy about what you have, enjoying what you do, and seeing it grow. Start with the seed, the core. When you feel like losing your balance trying to juggle testing, refactoring, assets, planning, coding - then always just return to the core, take a look what you have, decide one (and only one) thing to add next and work on that. Hehe, this could be a recipe for a catastrophe in a big collaborative projects, but if you are working mostly alone, I think that the organic approach almost all by itself ensures that eventually everything will be done. Most of the time you only need to ask yourself one question: "OK, given what I have now, what would be the most natural and easy addition"? If you don't yet have all the branches, don't rush to add the apples. The apples will appear when everything else is ready to support them.

Ideas

Really, this is the hard one. My problem has always been that there are too many ideas, and I've often found it difficult to pick just one and focus on that. And while working on that idea, new ones keep on popping into my mind. Where do they come from, and what do if the stream would run dry? Hmm, this might be something I can't say a lot about, simply because I don't know.

So, just a few observations: I have noticed that many of my ideas start with some kind of a pun, or an unexpected combination of element which don't seem to belong together. In my teenage years one of the game ideas (which I never made, but still sometimes think about, if it would be fun to do. Well, but I claim no ownership, hereby writing the idea here knowing that anyone is free to implement it if they feel inspired), ah, so, yes was a game called Deathris. At the bottom of the screen there'd be beatiful pristine nature, with wild animals roaming the woods and fish populating the sea. Rectangular blocks in different shapes (a factory, an apartment house, an airfield and so on) would randomly fall from the top of the screen, the player can rotate and move them, and they'd fall down crushing innocent plants and animals, there'd be sound effects of screams of pain and agony, and probably just no way to win the game, just doing the glorious economical growth until the life-sustaining ecological serices collapse and it is game over for the mankind. (Sure, yes, I packed a lot of teenage angst, and wanted to express that in various ways). Well but let us not wander into ecological philosophy or the possible justification of teenage angst - I explained the game idea simply because it feels like a combination of a pun (playing with the name of a well-known game) combining element from other games (sim-city and Monopoly). And I think that many of the other, less angsty ideas get born the same way - as if random loose particles collide in my mind forming a new molecule.

And that having ideas is just one thing, the another thing is evaluating and polishing those ideas. In the brain-storming stage the evaluation needs to be silent. But once the brain-storming is done, all the ideas need to go through various iterations of evaluation and inner testing. Sometimes they need to simmer a little. Sometimes they get abandoned. Sometimes you realize that another person has already done what felt like a brilliant unique idea for you. That is how it goes.

Finally, it often helps to have friends to share with. I've felt that the best ideas are born from shared brain-storming, so that afterwards it is not possible to say whose idea it was, as it feels more like an emergent creation born out of different people brining their own ideas together. Sometimes simply discussing the idea with another person leads to upgraded versions of the idea, or new aspects getting added to the idea so that the result is something you would not have thought yourself.

That is all for today. Happy coding, folks!