The mistakes I made when I decided to make a game

Posted 2017.07.22

Why did I decide to make a game, and in Linux? This is the first question anyone may think of asking. Well, first of all, I wanted to make a Game entirelly on Linux. I failed. I had to use Acoustica Mixcraft on Windows for the soundtrack, other than that, every tool is Linux software, but we’ll get on that later.

When at High School, my art teachers said I had talent for art, my english teacher said I had talent for telling stories. At Music School, my guitar teacher said I had talent with the guitar, I just needed to spend more hours playing, though my sol-fa teacher always said I could not sing properly. Therefore, after many years, I wanted to put all these together and tried to make this simple game, that now is in beta-test mode, and hopefully, will be finished by August 1st, 2017.

Before starting with this project, I had big plans for a game, story, plot, characters, blah, blah, blah. Thank God I did not decide to go with that project first, and took the advice from experienced game developers who said that your first project should be simple, if not… who knows. Most likely I would be already pissed by the time the project was taking without any proper outcome. Thanks a lot developers.

I wanted to do all the stages of the game, all the processes, in order to understand better the project as a whole, so finally, I did, and this post is a summary of that experience. So let’s get started with the mistakes’ list.

1- Time Jump, not Time Travel

I started this project back in September 1st, 2016. I planned to finish the game by the end of that month, and here we are at the end of July 2017.

As we see in Img.1, the total number of hours spent on the project goes over 102, in more than 6 months. Not good productivity ratio. Making the game in my free time is not easy, as sometimes, one just wants to rest, enjoy time with friends/family, relax, or even needs to do house chores. This makes it hard to find a good balance between work-leisure-game, when one has a full-time job. It’s clear that with full dedication to the game, it would have been finished in 2 weeks, maybe not; some would say that could be finished in a weekend, or in half day; I could agree with that too, if you have the skills well trained before starting the project.

I didn’t use project planning software, clearly, because the time extent of the project. With the Calc file everything fits inside the window. If I used some project planning software, the Gantt view would be so long in time that I might despair. And for starters, this is a simple and easy way to keep record.

One of the biggest issues of taking this long was Unity3d. Not the engine itself, but what I learned of it. Is quite different to spend time everyday working on the game, than spend 2 hours a week. Sometimes I forgot how to do things, again and again, and needed to check once, twice, thrice, even more times, over and over, the Unity3d script reference and manual to recall how to do something I just had done the past week. This was a complete waste of time, project managment speaking. I remember I took some vacation 4 years ago, and spent the whole vacation studying Unity3d 6 hours a day. All that study also wasted because the moment I decided to start the game I had already forgotten everything related to the engine. At that time, I hadn’t read the advices of experienced developers, and was still building castles of sand in the clouds with that game idea that was, oh well, in the clouds. And this issue also happened with C# as well. I learned C# while programming the game, so the longer between sessions, the harder to get back to code. Sigh.

So, when experienced developers say that if you plan to finish a project in one month, make it two, don’t get pissed if it reaches three, and celebrate it when you finish in the fourth, that is true. Many things can go wrong, many things unexpected may happen, it is what in project managment is called Risk Management, we must, MUST, think and count with this Risk Management in order to achieve the goal.

2- Stable Operating System, my ol’Ubuntu Hates me

When I planed and started this project I was using Ubuntu Gnome 16.04 LTS. But, it was an update on Ubuntu Gnome 15.10, which is not an LTS version. This update didn’t go as expected and every time I turned on the computer there was a system crash. While I was working on the game, system crash again, while I was doing other stuff, other system crash. Even these crashes were not so important as to turn computer unusable, they were too annoying, so when Ubuntu Gnome 16.10 came out, instead of clean install 16.04 LTS, I did a clean install of 16.10. This turned out not to be a good idea, as some issues with the Nvidia card drivers came out and, for some time, the system was a bit messy showing some display flicker when carrying out some actions. This means that I wasted time setting the whole system up in order for those issues to disappear and thus work on the project without distractions.

3- Stable Unity 3D for Linux

Same thing that happened with the OS, happened with Unity 3D editor for Linux. I started working on this project not so long after the Unity 3D editor for Linux came out. The first releases were not so “complete”, some bugs showing on here and there, menus not showing properly, drag and drop too. So I did some dancing among the different versions trying to find one that would allow me to work, not 100% flaw free, but at least, stable enough to keep on with the work.

Changing from version to version meant that the project also got updated to the new version, be it beta, final candidate, or release… Also wasted too much time doing these jumps and dances, and when 5.5.3 came out for Linux, it proved that, even still having some display render flaws, at least I could do get the job done. These flaws I am not sure yet if they are related to Unity 3D, to Ubuntu Gnome 16.10, to the Nvidia driver, or to any combination of all or some of them. Not being able to see the GameObjects inside the Scene view gets disappointing sometimes.

4- Stable Software or Crazy Software

The other software I used in this project that didn’t show any issues are Blender (OK), MyPaint (OK), Inkscape (OK) and Gimp (OK). I tried to configure Ardour in order to get the soundtrak recorded under Linux, resulting in a complete failure, and an extended waste of time. Finally I decided to drop Ardour, and stuck with Acoustica Mixcraft, which I own, because I was spending too much time trying to figure out why Jack didn’t work, resulting in Ardour completely useless; checking config files, changing settings, adding software…

Same with MuseScore. I wasn’t able to get MuseScore not to quit by itself when trying to open or create a file that I finally gave up writing the score, I wrote some tabs the old style way, pen and paper, though. And Audacity. I used Audacity to trim the audio files, add effects, level the sound and such, but… Audacity is a funny software, no matter what, no matter how, it always adds some silence at the start of the track by itself. Regardless of how many times I remove the silence, the moment I save the file, Audacity puts it back there. This, of course, is not an issue for a start-end track, but is a no-good for loops, as there always be a clip in between them.

5- Features Galore

Such a simple game as ARO does not need too many features, and I tried to abide the KIS (Keep It Simple) law. So feature wise, there are not so many features in this game, being a “first game”, the less features, the best. There is one though, that I had planned at the beginning, and I spend quite some time to get it working to finally find out that could not be done that way. Unity 3D editor does not allow to do what I wanted the way I wanted so, instead of finding a different approach, I decided to drop that feature. This now I know, and will never forget, and is due to my short knowledge of the Engine as of today.

So, when thinking about features, I should have known more what can and can’t be done with the Engine, but then again, one of the purposes of this project was to LEARN, and for sure that I did

6- Skills Running Wild against Hardware

The last time I did some hand painting was a portrait back in 2002, using pen and paper, and the result was quite appealing. But that was pen, paper and 2002. I have now a, smaller than A5, Wacom that I used for this project. It turned out too small for the job, as can be seen in the backgrounds where dots are too big. Well, to be honest, the Wacom is small, but also it is due to the fact that this project was extending too much in time, and I had to get things done to finish it before I retire. So for sure I could have spent more time tweaking the backgrounds in MyPaint with the Wacom, but I remembered the previous Features Galore item and just let the backgrounds be like you can see in the game now.

Same happened with the ship model and its texture. MyPaint and Gimp are truly capable, but I decided to quit detailing and focus on the game itself to finish it. This also applies to the models of the projectiles. I made about 20 different models in blender because I did not like the results. The ones that finally made it to the game are not amazing either, but they serve for the purpose so, no need to worry too much this time. Their trails were made using the standard Particle that comes with Unity 3D, nothing more. Sure I could paint some particle myself but, then again, Feature Galore kicked in.

Music and effects, just as painting, I hadn’t written a song in the past 20 years, and I don’t play guitar as much as I did back then. So before getting back on the fretboard I had to train the fingers again. I posted a pic on twitter showing the result of the training on the fingertips, which now are fine, thanks for asking, to keep record and remember myself that I should play more often. Bass is not my strength, as I decided to learn to play the bass a couple of years ago, and I haven’t trained enough, so it took longer than expected to get the bass line too. Hopefully next time it will be better. A microkey midi keyboard is not that aproppriate for keyboard playing as the keys are a bit small, and you have to be very careful not to hit two keys at once, but it served for the purpose, at least for this project.

Then again, I spend a lot of time involved in playing without composing that should be accounted in the project time, but I didn’t. If so, the hours spent on the project would rise quite a lot.

7- Code Warrior

Coding has never been a good strength of mine. I know the code of this project is not as clean and lean as it should be. The first game I made, back in the old times, was programmed in basic on an HP-86B computer with green phosphor screen. Then I had to study Pascal, some Octave (Matlab clone), and finally I did some simple HTML-CSS-PHP-Javascript things. Different from C# in Unity 3D. So, as I went on with the project, I learned C# and Unity 3D at the same time. As stated before, leaving the project in standby for a week or two resulted in part of that acquired knowledge gone with the wind, and needed to get back to the same place where I had left, going over tutorials and references again and again. And even the auto identing preferences of Monodevelop left the code in a way I feel is not so, let’s say, mmmm…. ordered, I decided not to invest time tweaking the settings, and adapt to the default identation for the time being.

Once this game is finished, I will check the settings and try to get the editor to ident the way I want. Hopefully.

Ay, code commenting. It is true, it is important. And I started to do it but, when I found out that it was taking way too long to get something playable, even with the flaws the Beta has, I stopped commenting the code. Wrong idea. Going through the code of the scripts to refactor without comments made me waste more time than if I had spent the time commenting the code in the first place.

Conclusions

Would I do this again? For sure. I learned a lot even there is a lot more to learn, because even though I learned a lot with this project, it is still quite few compared to what is needed to build a proper project.

It is clear that the better the hardware, the better the results if you know how to properly use it. I mean, not only a powerful computer and a big 4K display, my gear is old and display is just FHD, musical instruments also affect too, and drawing input tablets also.

Stable, stable, stable, stable, stable. I repeated it 5 times. Stable system, stable software. Very important to not waste time. I knew that the Unity3D editor for Linux had some path to go through before being properly usable, but playing with betas is out of the question if one wants to get the job done. I did, wasted time, lesson learned.

Training skills takes time. Even if you had the talent before, regaining that talent is not effortless. Needs patience, perseverance, confidence, and will to learn, as your skill might be outdated today even at your former top level.

Time is important. The more time you have, the better the result, but just if you focus on the important, and needed features. Spending time polishing effects, textures, soundtrack is good to give the project a better overall look, and make it more appealing to players. In the end, it all depends on the goals you set when you start. Actually, the mechanics of this game are quite simple, and were done long ago. The rest of the time I spent was on the different scenes, joining them together, the UI, models, art, soundtrack… Programming does not reach the 50% of the time spent on the game… yet.

Making a game in your free time is very hard unless you have plenty of free time. When this project is finished, I will start a new one, and hope that I can find more free time more often, so the project would be finised closer to what initially expected.

Never be afraid of change and be willing to learn. This project is absolutely different to anything I’ve done before. Granted that Gimp, Mypaint, Inkscape, Blender are software that I use, not as regularly as desired, but I do use them, I never had used a Game Engine before, or programmed anything in C#.

When I got the bass, a cheap Epiphone SG, it had some issues with the pick-up switch wiring, so I took it to the store, and the Gibson representative was there, he said “you are a guitar player and buy a bass?, this is no way to go, the moment you go the bass way you are wasted as guitar player”… I just thought I wish I could play piano, bagpipe, violin, tambourine… too. Of course no need to reply to this guy, and it is clear I’ll never buy a Gibson/Epiphone product again.

Learning new things is good for our brain, keeps our brain active and demanding instead of turning it lazy. Learning new things doesn’t mean that we stop improving our previous knowledge.

Even it may sound as a contradiction, it almost impossible to be a master on everything nowadays. Not easy to find a Leonardo daVinci in the 21st century. And with such a wild competition, market tends to focus on specialization, so one should care only on a single branch of knowledge, be it coding, art, marketing, whatever. Nontheless I like to think that understanding all those helps integration, and helps communication among the members of the team. Well, in my case my team is me, myself and I, so not much of a big deal, at least, just yet.

The whole post is a personal opinion, and you may or may not agree. So feel free to comment below.

One thought on “The mistakes I made when I decided to make a game

  1. Pingback: So I finished my 2nd (eeer 1st second) game. – roired

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s