Gamedev Gone Wrong: a case study - part 3 (Patreon)

Hi everyone!

Two days ago I wrote about why I should have taken more precautions before accepting to make the game 'Ninja Attack!' for The Frosty Pop Corps and yesterday I wrote about how the development of the game has been going. (not well) You can read about these things here and here!

Today, in the continuation of this mini-series, I'm writing about my workflow for making this game and mainly complaining about Unity again (sorry) but this time I'll try to be more honest than usual and also not leave out the complaints that I have but I feel are a bit petty.

After having made 'Invaders... From Space!' in Unity, it seemed almost like a no-brainer to also make 'Ninja Attack!' in Unity. In fact, even if I do regularly complain about Unity, the development of 'Invaders... From Space!' went rather smoothly. The game was done in time and the engine has been a major problem only two times, rather early in development - early enough for me to forget about them by the time I finish the game.

So when I started making 'Ninja Attack!', I didn't ask any question and just went with Unity again. After all, it is the engine that I trust has the portability and the plugin support required for what I was asked to make. (a freemium iOS game)

Time to be really honest. I hate Unity. I genuinely despise it and its philosophy. Unity doesn't want you to make your own systems. Unity doesn't want you to not use all of Unity's features. Unity will not let you avoid its anarchic architecture. Everything is objects! Nothing else than objects has ever existed! GameObjects are the new molecules and Components are the new atoms! Who needs anything else?!?

It truly feels like Unity is the opposite of everything I stand for.

Yes objects are cool, they very handy, but if you only have objects, then you're in for a really big mess. And no, I do not want to use Unity's systems, why would I? The systems I need are less than 5% of everything Unity is offering to me, so why oh why would I want those other 95% to obstruct my project?

And that's not all these 95% do! I don't know about you but I don't really have a beast of a computer. I work on an ok HP laptop, with a Windows 10 install that's giving trouble to my hard drive for no reason. Unity takes 3 minutes to load up. And then Visual Studio takes 5 more. Plenty of time to go get lost on Twitter or on Youtube "while it loads" and stay there for 30 more minutes than necessary. (ok this is definitely bad practice on my part, but what am I supposed to do while it loads up??)

That's not the type of workflow I enjoy at all. The software I want to use should go fast. Usually, I just use Notepad++ to code things and then I compile it with Love2D or I load it up in Pico-8 - either of those things take less than 30 seconds. Even with GameMaker, which takes about 2-3 minutes to boot up, at least from there I have all I need: the script editor is included, so is a sprite editor, a map editor which I can pretty much choose to ignore if I want to, and compiling generally takes less then a minute.

You may not think this isn't a big deal, but to me it kind of is. I mean, when I load up Unity, I don't want to be loading up Unity. (because I don't want to work with Unity) So making that step longer is just torture to me. And besides, let's talk about why this step is so long for a bit.

I think Unity has a problem with optimization. The games made with Unity generally run ok (although it does depend on the platform), while still being a bit more demanding than a similar game made with what my programming teachers would have called "something more serious". And considering the quantity of features available, that's actually pretty impressive. Yet it does beg the question: why can I not disable some big features, like collisions or lighting? The problem is not even that it slows down the game if you don't use them, it's that it slows down the editor which is always checking for that stuff and also it makes for exported binaries that are much much bigger than necessary.

If Unity would let me lighten itself by disabling parts of itself, I would probably feel a huge lot more friendly towards this engine. Besides, it's really the irony for an engine that forces you to do everything object-oriented.

This hasn't been super specific to 'Ninja Attack!' but I do think about these things a lot while making the game. I often find myself working around Unity's features to make what I want to make. My scripts are messy because I don't feel like it really makes a difference when they're not. I have a lot of singletons which in my book are a terrible practice, but when you're so deep into OOD, that's really all you have for custom systems.

In the end, I guess I just really miss doing things my way. Being forced to accommodate to Unity's rules is just incredibly frustrating to me.

To be honest, the argument that I'm just not using Unity properly is probably valid. But then again, I don't want to do things Unity's way.

And that's why I will certainly not be using Unity for my next projects, even if I do continue to work with The Frosty Pop Corps! (I'll write more about this tomorrow)

If a tool isn't working for you, even a big mainstream one that everyone uses, ditch it, find another one that works better for you.

Thank you for reading! I really don't know if you got something from this part but at least maybe you got some more insights on my philosophy when it comes to the more hands-on side of making games.

(oh hey by the way I've been thinking a lot about the accessible code architecture write-up I promised a few months ago, I've been trying to find the time to do it and will likely make it happen in the next few weeks!)

Join me tomorrow as I write about making games for mobile and then conclude this mini-series with an overview of the lessons learned and a small announcement!

Take care!

TRASEVOL_DOG