Weeks 63, 64, 65: B-U-S-Y pt.3 (finale)

Hey there, it’s been a while!

So yes I’ve been super busy these last few weeks making a game for The Frosty Pop Corps. The game, ‘Invaders… From Space!’ looks like this:

That’s actually from two weeks ago, the UI has changed a bit since.

‘Invaders… From Space!’ is about bringing the apocalypse to Earth as some sort of Earth-traffic-control engineer. In the game, rockets are slowly coming down on Earth and you have to rotate the Earth so that the rockets hit their target city!

All of this is in a strong home-made retro aesthetic with the Pico-8 palette and a noisy CRT effect!

And we have a tentative release date towards the end of August!

That’s what I’ve been up to these last five weeks and I learned quite a bit from it! I want to go through some of that here!


In particular I want to write about Unity! Unity is a game engine that’s pretty cool and a lot of people use it, a lot of people love it and I am not part of the latter group. However, I was teached to use it professionally in school and so making things in Unity is part of my skillset.

The main reason I do not like Unity is that it forces a design philosophy on you, a philosophy I like to call Almighty-Object-Oriented-Programming-and-Design. (AOOPD) Basically, anything you want to do, you gotta go through some OOP to do it. While OOP is all about have a clean, manageable design, Unity’s approach makes it, to my eyes, very very messy and dumb. Because if all you can do is make and program objects, by the end you have a mountain of objects, for a mountain of different things. And even if you’re super strict about putting order in your objects and their scripts, those objects have to interact between each other, they have to be linked. So you better be super good at architecturing your code’s design because otherwise, your project will be a mess.

Anyway, that’s the overall feel I have about Unity. Now let’s look at individual things I noticed while making this game in Unity, one year and half after the last time I had last used it.

Let’s start with a bad thing!

So I’m making a game and I want it to have a strong home-made retro aesthetic. Naturally, the first thing I do is looking for the drawing functions I have available. Tough luck, Unity does not have any. Or rather, it doesn’t have anything between GL primitive drawing (which is very impractical) and creating a new object with a Line Renderer component. (not making that up, I swear) You can’t just draw a circle, you can’t just draw a square, you can’t just draw a line. A line.

So instead you go through AOOPD and you create a Line Renderer object that will draw your line by itself (like a real boy) with the parameters you give it. And if you wanna draw any type of shape, I recommend you give up now and just make a sprite for it and use a Sprite Renderer object. Any text you might want to draw will also have to go through Text Renderer objects, with very limited control and if you want to do fancy text effects with moving letters or letters that change sizes, prepare to have a lot of Text Renderer objects. (or use plugins)

So here’s my first point: Unity please kindly give me my drawing functions back.

Now a good thing!

Having a debug interface to check on individual objects at runtime is cool. Like, the game is playing and I can just make sure an object has the right states and the right values. It seems simple and I think the large majority of game engines have that too, but it’s just really handy and I realized it only while working on that game. Unity’s inspector in particular is really good for that purpose anyway as it lets you browse through the objects currently in the game and see the values that you chose to make seeable in the editor beforehand.

Unity, you did good on letting me debug my many objects sprouted from the design you forced on me.

Other bad thing!

There’s quite a few different systems available in Unity. From the top of my head, there’s the lighting system, the physics system and the AI system for example. All of them are great because they basically take care of themselves and using them is extremely easy. But. In ‘Invaders… From Space!’ none of these three systems were used. Obviously no physics or AI were needed, the game’s code can take care of itself, thank you. But also no lighting because it would totally mess up my home-made retro aesthetic. Problem is, I can’t disable these systems. Whether I want it or not, these systems will be included in the final build and they will be present in the editor all through the process of the game. It’s unnecessary clutter and it makes for bigger builds.

Unity, just let me disable parts of yourself entirely please. OOP is about that too. Thanks.

Other good thing!

So I know I already talked about the debugging interface but being able to modify parameters on the objects while the game is running is also really super cool. While it can break everything, it’s fine because when you exit the game, the parameters are set back to normal and you can just go ahead a break everything all over again in play mode. Super good to check on behaviors. Particularly useful for testing things such as UI elements and their placement. Amazing at breaking everything and watching what happens.

Editing object parameters while the game runs is like a game of itself, and it’s very useful and efficient. Nice job on that Unity.

Last bad thing!

I realize this is not really on Unity itself but; dear plug-in makers, please learn what a documentation is and looks like and try to make a PROPER ONE. Seriously, I’ve spent waayyy more time than planned just wrestling with plug-ins I had to use for features like ads and gif making + sharing. Having a “Quickstart” on how to use the plug-in is great and all but every game isn’t the ideal environment for your plug-in and that’s why I need a documentation that lists exactly what functions I can use and at least some insights on what is happening behind the scenes, just in case I might need to modify some of that. Because I needed to modify some of that. It was not very fun.

Unity, I dunno, get some guidelines on your asset store and tell everyone to make proper documentations, at least for premium plug-ins.

Last good thing!

Animation Curves! An Animation Curve is a type of parameter you can set on objects in Unity. It’s great because you can edit the curves in the editor and then the code can use it just like that. Curves are super important in animating things, I usually do it through the math approach with sin()’s, cos()’s and sqr()’s but having an actual curve I can just edit and make just right is very good.

Uniyt, Animation Curves were a great idea, well done, I’m totally stealing that for my framework now.

I did get the plug-ins to work in the end

I’m very much looking forward to getting back on making things with my Love2D framework and improving it with these insights I got from working with Unity in mind. If all goes well, this framework may well be used for a bigger project soon-ish!

Thank you for reading my rambling about Unity!


These last three weeks were really intense and I was not able to keep up with the articles at all. Sorry about that. Things should get back to normal very shortly!

We’re already halfway though the next week but anyway, here’s what I want to do! I want to finish my Wave Function Collapse implementations and finally write the Doodle Insights on procgen algorithms. And then more things, but actually I learned a few hours ago that Ludum Dare is happening this week-end and I might do something for that, I dunno, maybe, we’ll see! Also I have a cool idea for a Pico-8 Doodle!

Have a nice second half of the week!

Take care!


2 thoughts on “Weeks 63, 64, 65: B-U-S-Y pt.3 (finale)

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: