Because of my involvement with the TAMK Games Academy I’ve had a bit of a voice in how the course is structured. Back when I first got involved, many years ago, students got the opportunity to make one game over the course of a year, but I’ve long argued that more, smaller games, would give everyone involved a better insight into what it’s like as a profession. It’s too easy for team members to hide, or worse, disappear, over a year-long project, and it’s practically impossible for a green software developer to risk assess and get a handle on scope. Should those mistakes really mean they bounce out of the course with nothing to show for it? So now we get the students, in groups, to make one game per semester.
A semester isn’t a very long time – by the time you knock out holidays, and all the top and tail admin of getting things setup, it’s basically 3 months and change – so scope is a real issue. Every developer has eyes bigger than their bellies, but young developers even more so, and it’s pretty common for one of the projects to fail. It can go one of two ways: the initial excitement of working in a team means the first project is wildly out of scope, has to be pared back (normally by me) and the result is a half finished mess. Or, the listeners in the class make a very small, very casual, single mechanic game, and manage to apply some polish to it, meaning their second project will be an attempt at an MMO. MM No! As they used to say at MGS.
My advice has always been the same. Pick a single (or very fucking small) set of mechanic[s], that you can evolve over time, and use this to do some proper level design. Even better, steal an arcade game, or something small from the 16bit era, and clone it. You’ll still have to solve all the same problems as the original developers. But, do that and actually attempt to build the ramp for the player, from the initial introduction of the mechanic, to them finally acting like a master, and you’ll have a game with a bucket load of content. You might even start to realise that polish takes up 90% of the time…
I’ve never actually made a game in 90 days. Even with modern tools. (Don’t get me started on Game Jams, that’s a whole separate rant that I’ll save for another day)
Back in Feb there was a small confluence of events that made me consider this. I was starting to notice that I was a little Rusty in C# and Unity – having moved to UE4 after Lumo – and I was also concerned that the programming students didn’t actually have access to a full, open source, reasonable quality game, made in Unity that they could draw from. I know from my own experience that I’ve learned far more from reading other people’s code than I have from a book (thank you John Carmack) so I figured this might be a really useful diversion. So I set about making Cecconoid/Eugatron, which I’ve posted about in the last few Dev Vlogs.
I’d set myself a deadline of the end of May – the same duration the students had – and that deadline’s made a nice whizzing sound as it’s gone past. So where am I?
In short, not finished. Lol.
- Development ‘days’ spent so far: 71
- Of those, full-time (6hrs or more): 50
- 550 commits to get to alpha
- 20k lines of code
- 260 sprites/env tiles made
- 50 levels in Eugatron
- 42 rooms in Cecconoid
- 6 power-ups
- Dunno how many baddies, but double that, because each game mode ended up with it’s own version
- 30-ish unique SFX
- ~350 hours of work, so far…
Most of those stats don’t surprise me. 350 hours sounds about right for a bare bones arcade game. But 20k lines of code? Damn, that’s way more than I would have guessed. Turns out Lumo was 120k, and that’s less than I would have guessed, so even after all these years I basically have no clue how much code a thing will take… Hmm.
But, this really is just an alpha. The following are missing:
- Cecconoid doesn’t have enough content. Maybe another 20 rooms needed
- Eugatron isn’t balanced as well as I’d like. Probably a few more days to give that a proper tweak.
- Neither mode actually has a high score table
- Cecconoid doesn’t have a save game, although it’s debatable that it needs one
- I’ll need to do some sort of settings screen, so the postFX work on a toggle
- I’ve not produced a Linux version yet, but I will bet good money this will cause problems.
So maybe another 5-10 days or work to get most of that knocked off.
And then you have to consider the stores:
- Steam: Leaderboards, controller, cloud saves, achievements, trading cards
- Discord: Rich presence?
Steam is reasonably easy, and it is the one thing that I can pretty much lift wholesale out of Lumo. But it’s still a few days work. Discord, well, lets maybe pass on that and save it for another game.
But we’re still not done. The stores all need art of various sizes, all of which are different dimensions on each store. Hero images, capsule headers, icons, detail view listings, page banners, sale banners… it all adds up and very few of them can be cut-and-paste out of a single piece of key art. In fact, I’ve already spent three days on this.
Oh, and you need a trailer. And some screenshots. And a web page of some description…
So Cecconoid isn’t finished. Although it kinda is. I mean, the fun, development part is basically done, bar the boring bits, but those boring bits are another 60-100 hours of work, if you count all the stuff needed to make it ready to sell.
It’s been an interesting experience to tackle a game in this way.
Like every developer before me I still struggled with scope. I stupidly made two games (but, but, Eugatron!) instead of putting all my focus into Cecconoid, and then to make matters worse, spent days playing the thing I shouldn’t have made, trying to pop a million points.
Unity still gets on my tits. There’s a massive amount of scaffold code that needed to be written just to get a well structured base for the game, and I’m spoiled that UE4 just provides all this stuff straight off the bat. The editor is absolutely rubbish for editing 2D tile based stuff, and their plugin for it didn’t come anywhere close to doing what I needed. The UI stack still annoys the shit out of me. Input still isn’t fit for purpose, so I had to go back to InControl half-way through the project. The audio system is still laughable bare-bones unless you bring in FMOD (I didn’t). The project window, where you organise all the files, is so weak compared to UE4 that it gave me constant rage. In short, none of the failings I wrote-up, post Lumo, have been addressed in a way that I’m happy with.
But, Cecconoid does appear to work everywhere, even the web, and for that the Unity Player does deserve credit.
Would the project have been done any faster in UE4? Probably not, as the C++ compile cycle is definitely slower than C#. But, I’ve noticed that it doesn’t take me very long to slip back into bad habits with C#. It’s far too easy to let things slide…
So I’m in a lucky position where I’ve made a game that I wasn’t expecting to, and I’ve no immediate need to push it out to the stores. This gives me a rare chance to let the thing sit there for a while, meaning I can go back to it with a fresh set of eyes, do the balance pass, and give it a proper tweak without being caught up in all the niggles of development.
But I’ve answered the question; yes, it’s definitely possible to make a good quality, simple game, in 90 days on your own. It’s probably not possible to make that and a Robotron clone, though.
Oh, and, look, shiny trailer!
I’m going to be doing some contract work over the summer, but in-between that I’ll be back on Maenhir, and normal service will be resumed. Enjoy the sun, everyone!