Well, by and large my great ‘2016 Administerial Redmine Project House Keeping Event’ is now over.

All of the principal Trello tasks are now nestled happily(ish) in my Redmine instance. I’ve yet to go through and sort out the sub-tasks, which – too be honest – I’ll probably end up doing by hand. I can’t face trying to parse/split all the checklist items out of each card and then tying them to Redmine parent tasks… it’d be the same effort to just lift them by hand one at a time. Besides, I think my grand ‘import’ experiment has damaged some of Redmine’s metadata – a fair number of tasks seem to think they are the parent of all the issues in Redmine, despite actually having none assigned! That’s a problem for another day though.

As part of this grand exercise, I have now updated, and estimated every single task that I have, and it leads to a sorry truth – even if you only consider this lot as ‘guestimates’.

Before I reveal this truth, it’s worth pointing out how one I went about ‘managing the project’.

1) Breakdown

First, you have to know what to estimate – so you have to know what it is you will actually be doing. This is an inexact art… in that it takes great skill to analyse requirements, deduce logical complexity, determine areas of effort, and so on. Now while I might say I can do all the above in my normal day to day professional capacity, and can (and have) done the same for both games and application development alike, I don’t have the time to apply it on my own project sadly, so I’ve basically ran with gut feeling and ‘how I’d like to do things’ 🙂

Hence I now have a large list of most of the key things that I’d like to achieve for Dominium. It is not ‘correct’ and by no means exhaustive, and it does not detail features to a granular level. ie. ‘NPC Role – Pirate’ – that’s a single task in Redmine, but in reality there’s a lot more to it than just that.

2) Guestimations

That’s what you need. Estimations in a project are based on ‘known facts, and past experience’. In this case a Software Engineer will look at the facts presented (i.e. Create a Scroll List) and consider the complexity behind it, the UI design requirements, whether there are existing GUI components to use, and whether they have done something similar in the past, and how long did it take, what challenges there were, and so on. Then they can say ‘Yep, I can do that in 3 days’ or a week, or perhaps ‘Nope, I can’t do that’. (Though in the latter case, I’d hope that would not happen – they should think ‘Hmm, never done that, I’ll have to learn how’, and estimate more time to reflect that).

However, because of the (largely) fudged Breakdowns, estimations are not possibe… I have not set out requirements for ‘NPC Role – Pirate’ – other than, in my head, I want another vessel to act ‘piratey’… and shoot at you to try and nab your cargo. AI wise, there is a lot more to it than that – evading your fire, fleeing if badly damaged, or deciding ‘to hell with it’ and going on an all out attack. All the contributing factors to the gameplay need deciding, and balancing, and testing, and balancing, and testing… you get the picture.

So, here we ‘guestimate’… given what we ‘think’ we know, and what we ‘think’ the complexity is… we say ‘hmm, could be tricky… 2 weeks?’ subject to more detail becoming apparent later, allowing the guestimate to be revised to an actual estimate.

Summary

So, what does all this magubbins mean?

Well, for the first playable episode of Dominium – cunningly entitled ‘Alpha’ – it means this;

• 483 issues
• 154 closed
• 329 open

So it’s 31% complete! Woo!

But, wait… there’s that time / effort estimated against those issues…

• Total Estimated time – 2,877.75h
• Total time spent so far – 210.5h
• Total time remaining – 2667.5h

Which means 7.3% complete… ah, oh dear.

And therein lies the painful truth about project management. Being 50% through a list of 100 tasks does not mean you are 50% complete…

Let’s drag my bruised and bleeding body further still…

I can, at best, dedicate 2 hours per day, if lucky, with a following wind…

2,667h / 2h = 1,333.5 days to get it all done

Presuming the normal 210 working days per year..

1,333.5wd / 210wd = 6.35 years work

🙁

Then of course, 2h a day if I’m lucky. More like 1h on average. If I get to do any at all. So being pragmatic, double that estimate. So 12.7 years.

More sigh.

Ok, so I could work every day (365 days) and throw in weekends, say 2 days of 10 hours a day…

52 weeks x 5 days x 2 hours per day = 520 hours
52 weeks x 2 days x 10 hours per day = 1,040 hours

= 1,560 working hours a year

So 2,667.5h / 1,560h = ~1.7 working years

After which, I’d either be dead, divorced, or probably both.

Clearly, resourcing is a problem 🙂

‘Get help!’ I hear you cry. Ah, if only it were that easy… (I cordially invite Mr. Negative to the podium please…)

Help means;

1. Willing victims volunteers, eager to work for nothing but perceived glory and the vain hope Dominium will be finished/released/awesome. Ie. for free/nothing.
2. Being able to get anyone interested, who can dedicate more useful time to the project than I can, and is solid, dependably, reliable. Good luck there. Everyone is busy, everyone has ‘their own thang’, everyone has – frankly – a life to lead.
3. My being able to co-ordinate their efforts in a meaningful, productive way. This means probably my stopping doing any dev work at all.
4. My being able to tell them ‘what is to be done’ for the current project… I can barely get time to document what is in my head in a manner sufficient purely for my own benefit/sanity…
5. Tolerating ‘change’… new people means new ideas (good and bad, all judged on merits) which means me giving up my selfish stranglehold on the project (yep, all ego here), but also handling ‘change control’ and not deviating from the projects ambition or goals – ie. feature creep.
6. Technical Support – everything is bespoke – I wrote the 666 engine. I wrote all of the current Dominium code base, tool chain, etc. Bringing anyone else in means stopping what I’m doing, and helping them pick up enough knowledge to help out. I could use a more commonly available engine? Unreal? CryEngine? I could. And start all the Dominium game code again? Ouch.**

** Ok – I could conceivably take the game client code and move it to a new engine, I always write my games to be engine agnostic wherever possible. But even so, it wouldn’t be a fab idea.

Of course, there is an easy answer to the above. Money 🙂

Funding would secure my time to manage/develop full time, and also hire the necessary skilled people to deliver the product as I see it (and as they would influence it).

Fat chance of getting anything there.

Well, that wraps that up then! I’ll pack away my soure code, and grab my coat!

Not.

Despite the above, I am clearly unstable, and fully intend to plod on. I see the likes of Elite Dangerous and now Star Citizen finally (well, almost) delivering (some of) the vision I had in my head so many years ago, and I know full well that my chance to ‘get there first’ is long gone, and I can never deliver the Dominium before it becomes so old hat no one will care.

So what will I do?

Well, a rethink on the original rethink of ‘First Playable’ is first. Cut down the Minimum Viable Product feature set that I’d already striven to produce, and move to a ‘Barely Viable Product’ and see how much time is needed for that. Ditch some of the game mechanics for example – so throw out missions/jobs, exploration et al. Get combat and trading done, lock the player to a single vessel experience, go ‘old skool’ gameplay, perhaps more arcade like (start game, fight, die, new life, rinse repeat).

So rather than the above ‘approximately 14 years’ causing me to look for a convenient tenth floor window, or a stool and rope, (joking guys, joking!) instead it forces me to re-evaluate the project and see how I can deliver something sufficient to generate interest, and then perhaps build on that.

Of course, that’s going to be one mighty careful deliberation!