EMMA

A Catgirl Software product

Week 4

I’m not really sure what to write about this week. I’ve been doing a lot of trying to design useful systems this week, so maybe that?

Unity and Object Structure

Unity has a very modular structure to the way it thinks about objects. A thing that exists in the game world is a GameObject, which has a series of Components (a sprite or 3D model it uses, a collision box, a section of code to run) to give it state and behaviour. It can also have other GameObjects as children, which have their own components, and so on. Groups of objects and associated components that need to be replicated can be saved as Prefabs, and called into being as a single instance easily.

I’ve written a lot of poorly designed code over the last few years, and it’s left me with an obsessive need to work out a decent structure for my code before I go in, which… sometimes helps, I think. Sometimes I even manage it!

One of the benefits I got out of my last job was that I started thinking about objects being composed of different parts, and using inheritance as a promise of fitness for a task. So that’s the way I have been designing cool little spaceships - a ship is composed of a Component that moves it around, and a Component that fires weapons, and so on. Strictly, those are two components; one that makes a decision on what to do, and one that acts on a decision it gets given. So, for example, I can change the behaviour of a ship by changing the AI Movement Controller component it has, and the change is smooth because they both plug into the Movement Enactor component in the same standard way.

A/N: My partner just reached over and checked my word count, revealing that I have written more words for this than I managed for NaNoWriMo this year. Remember when I said I was a writer? I am in fact a not-writer. It’s really unfortunate.

This way, it’s easy - or it should be easy - to design new ships for whatever purpose I need. Give it a base, pick a movement component and a systems component and whatever else, and that’s done. As I get more into things I will probably start composing individual sections into Prefabs, and maybe shuffle around what is a full object vs a component vs a set of parameters within an object, but I think the base idea is solid.

This Week’s Progress

I got my tasks done! It was an interesting experiment in the effectiveness of the Controller/Enactor structure; my player ship has the same movement Enactor as both of the AI ships I have cobbled together, and the same system Enactor controlling the weapons, but where the player has a single input Component acting as a Controller for both, the AI ships have separate movement and systems AI components.

This sadly involved so much fucking up; turns out there’s no compiler error for “hey, this code that you are intending to run every game tick isn’t actually being called in Update at all”, and I can’t figure out a way to design my code structures such that it does actually do things like that. But it’s something.

This week, my tasks are to implement actual collisions between ships and the projectiles that other ships are presumably firing at them. I am also meant to implement a health system, at least rudimentarily, and work out a design for how health and damage will actually work in game.