A year ago I decided to make a videogame on my free time. A year later, the game is “finished”, if anyone can say that software is ever finished, though at least it is released. Was released on August 14th, 2017, meaning that it took me almost a year, about 11 months ,to “complete” the project.

AROTiming
Img. 1 – Time management for Project ARO

Even it took me about a year, the actual time spent on the project reached 157 hours by August 28th 2017. Comparing these hours with a monthly job of 8 hours per day, 5 days a week, 40 hours per week, it took me about a month, 4 weeks to complete this project.

It’s clear that is quite different to work on a project on a daily basis, as compared to work on the same project on your spare time. I wrote already about the mistakes I made when deciding to make a video game (see www.roired.com), and that is one of them, that is, taking time from session to session made me forget about what I was doing and how I was doing it, needing more time to review and re-learn. This is also a good example of CTFC (Comment The F***ing Code) theory. Lesson learned.

With this project I pretended to make all the assets myself, so I did. Each asset, be it a 3d model, a texture, a particle system, a sound, everything was made “in house”, with the sole purpose of understanding the whole process of building from the ground up on Unity 3D Editor for Linux. And keeping track of the time, is as important as any of the other tasks. Even if one lacks project management knowledge, keeping track of time is extremely valuable.

Let’s make a coarse analysis on this time tracking and evaluate its cost. The moment the game was released, a total of 157 hours were spent on the game, on the different tasks altogether. We won’t separate the tasks for this analysis, though in actual project management, each task would have its own cost and assigned resources. This game project is a one person only, so there is only one resource, so no need to separate costs. Those 157 hours almost matches a whole month of work time at some company, so depending on the position, this time cost would vary from 500€ to whatever top you may choose. So, for the sole purpose of this analysis, let’s be a bit humble and assume we are millennials, in the sense of our income is around 1.000,00€/month, therefore, this game project would have, excluding depreciation costs of equipment (computers depreciate quite fast) a labor cost of about 1.000,00€.
This game was released as a free download, so no ROI (return of investment) was planned, though you can do the math in order to find out how many copies, and their price tag, are needed to sell in order to get the cost back, and how many in order to get some profit. Same analysis could be done on a cost per hour basis, and the outcome would be similar, at least the conclusions would be the same even the cost would differ depending on the assigned cost per month/hour.

This time/equipment/cost analysis is good to realize how much it does cost to complete a project, even if it is Open Source or Free. It helps us, indie developers, to get some perspective, even if projects are released for free, and understand and appreciate what other people do. Remember the “time is money” motto, well, actually Time is just time, it is what you do with time what turns it into something, be it money, experience, happiness, though we should have a way to evaluate the value of the time we spend on a project, and this analysis is a simple way to get an idea.

At the beginning, before starting the ARO project, I had plans, bigger plans, of a bigger project. I must say that I took the right path choosing ARO as the first game project of this “new” era. Being it simple enough, each task is simple enough, mechanics, models, textures, even music, that I did get to “finish” the game. Had I chosen other projects I had in mind, I might be absolutely crazy by now trying to figure out how to do things and the game would be far from completion. So it was the right decision to pick a simple 3D arcade game instead of picking an AAA type project that I might never be able to finish.

On the other hand, by choosing this simple project I set several simple goals:

  1. Learn to use the Unity 3D Editor in Linux (Ubuntu)
  2. Learn to code C#
  3. Use Open Source Software to create all assets
  4. Make a fully functional game

Of all of them, the only one who is “completed” is the 4th. I couldn’t use 100% Open Source Software, as I had to use Acoustica Mixcraft to record the soundtrack, as the OSS equivalent was not working on my Ubuntu Gnome 16.10 64bit setup. The first two, learn to use Unity 3D and learn to code C#, I started the process of learning, and I still have a long way to go in order to master both. Thus I can say that I am able to use the Unity 3D editor in Linux and use some C# to code, though improvement on both is needed if I pretend to achieve higher level projects and the goals implied. So setting a small group of simple goals was also a good decision, and these are project goals. Small milestones where set too “in-project” to keep spirit up and measure achievements.

Now I started a new project where the goals have been modified a bit:

  1. Get a better understanding and knowledge of Unity 3D Editor in Linux using tools that I haven’t used for the first project
  2. Improve C# coding
  3. Use Open Source Software to create all assets but sound -will keep using Mixcraft-
  4. Make a fully functional game with better input support

This new game is going to be simple enough to be able to achieve this goals, and the associated milestones, and if possible, will be “finished” in a shorter period of time. In fact, the plan is to release it before April 2018, when Ubuntu 18.04 LTS is released.

The due date is chosen to be April 2018, matching the Ubuntu release, because of the issues I have experienced when developing the ARO project under Ubuntu 16.10, issues regarding stability of the system, the apps, even the Unity 3D Editor. On Unity 3D Editor I must say that it took me some time to get a version (5.5.3xf1) that could be used for the project. Before that version, plenty of annoying issues didn’t allow me to make prefabs, add some components, blind scene design among others that finally “disappeared” in 5.5.3xf1.
So now I have a clean install of Ubuntu 16.04.3 LTS and won’t update it until 18.04 LTS is out and the project is finished, as I learned the lesson on this too; keep the gear as stable as possible to avoid issues and delays. Though I know I will have some issues regarding SQLite support with Monodevelop or Visual Studio Code as I have already tested it and have yet to find a way to solve it. Fingers crossed.