There’s been a (minor) flurry of emails in the air regarding Apple’s introduction of notarisation for
apps that are distributed outside of the Mac App Store. This affects everything on Steam,
including Lumo. As it happens, I’ve been working on Lumo since Cecconoid was released, with
an eye on adjusting the difficulty balance so it isn’t murderously tricky on a phone. The timing couldn’t
To be honest, I’ve wanted to go back to Lumo for a long time. I’ve never been happy with the end sections of the
game because they were put together as I was running out of cash. A bit more art, here and there, would go a long
way. But the main problem with Lumo has always been the way it was built. Part of that is my fault; I took a lot of
shortcuts, I bought in Asset Store packages where I thought there would save me time, and I chose to use Unity over UE4
because it was easier to get going, and slightly better documented. I’ve regretted that ever since.
The path from Unity 4.x to 5.x was horrendous, with every core system of the engine being re-written or
broken in some way. The entire 5.x range of Unity was a shit-show, stability-wise (see my personal blog for rants about that).
So Lumo needs a specific, hot-fix version of Unity, for every sku that exists, because there are show-stopping bugs on that platform if you use
the wrong version of Unity to build it. Because of this, the console versions diverged from the PC versions, and the PC versions ended up being frozen.
What I’ve wanted to do for the longest time is try and get a consolidated build, a “director’s cut” of the game, on a new version of Unity, with most of these problems fixed. Now seems like a reasonable time to do it.
Thalamus have made good progress. The iOS version of the game is basically a port of the Switch version, on 2019.2.x, that’s running well. We’ll be able to ship that, no problem. But it’s not the version I want, as we’ll be lowering shader quality and turning off a lot of post. Not to mention it’ll
have a balance tailored for touch-screen. It’s a compromise.
No, for me, the PC version has always been the canonical build, so I’ve been looking into what it would take to get that tidied up, get all the niggly, platform-specific bugs fixed, and the whole thing moved onto a new, “stable” version of Unity, and made somewhat future proof.
After a cursory look:
Scene management needs a re-write, as I’m on the deprecated API
All the use of GUI layers (all the HUDs in-game) need to be re-built, using the current UI, as they’re deprecated
The FMOD I’m using has been deprecated, meaning everything in-editor is broken. All audio needs to be moved over to a new version of FMOD
All the FMOD uses in code needs to be moved over to the new API
All the shaders built in Shader Forge (ie: 50% of the materials in the game) need to be re-writen as they no longer compile (Everything transparent is purple atm)
Post on all cameras needs to be re-done (simple) but the way I colour correct doesn’t exist any more, so most of the textures and all the lighting will need to be checked, or re-built.
InControl needs bouncing up to latest, meaning I’ll have to re-write the re-definable controls (I’ve hacked InControl to do what I need)
Steam API needs bouncing up to latest
The package I use for ropes doesn’t work on any new version of Unity
Reflections are broken (no idea why)
Fireworks and all particles with sub-emitters are broken (I’ve no idea why)
A few of these will have to be fixed for iOS/Android, but we’re going to ship with all the deprecated stuff, which is less than ideal.
As for the “main” version, well, it’s sold less than 300 copies on the Mac. There’s no way I’m going to do that work just to get Lumo on an updated Unity, so that I can properly notarise. The existing version of Lumo on the Mac will die when it dies, and that’ll be that.
Assuming the iOS/Android version turn out nicely (and they’re looking very good atm) then it’ll be possible to notarise a Mac build from that, and get it on a couple of the stores, which I’ll definitely consider, but it depends how much work it is to revert the balance changes. Even then, it won’t be the “PC” version, and my hopes of getting to a consolidated, official, “Director’s Cut” of the game are basically dashed. There’s no way it’s worth the effort to re-engineer that much of the game.
I’m genuinely sad about this. I was getting a bit excited about going in and polishing up the areas that I’ve always had a problem with, but it’s not to be.
I did, at least, learn my lesson with Cecconoid. I used the minimum of 3rd Party stuff, I wrote everything as simply as possible, and I didn’t use any of the Unity stuff that’s a moving target, because hey, it’s a stupid little 2D game!
So, Lumo is what it is. It will “die” at some point.
For some reason I’m always busier in the summer. It’s been a pattern since the last year of Lumo and 2019
has been no different. I’ve picked up some great contract work – so the rent is paid – but it’s not left
a lot of time for me to work on my own stuff. 1st World Problems… But it’s worked out really well, having
the opportunity to look back at Cecconoid and Eugatron with fresh eyes has been fantastic. I’ve been
able to pull them apart, spot issues and tweak stuff to get them much closer to what I was envisaging at the start.
This week I did the “final” balance pass on Eugatron. It’s hard. It’ll punish you. But it’s easier than Robotron,
which is my concession to modern gamers. I recorded 25 waves so you can have a look, and then I went back in and
made them more difficult. You can thank me later :)
I’ve finally bitten the bullet and started on the combat system. Here’s a little video discussing it.
It’s been a really busy month. I’ve nearly shipped an iOS game (contract work), Cecconoid’s store presences are
basically done, the trailer is up and I’m slowly gathering wishlists. Unfortunately a lot of the work I’ve been
doing isn’t on my own projects, but that’s a good problem to have. :)
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
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.
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
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!