So this will be a bit of a jump for a first post, since these blogs should be following my game development journey yet they don’t start at the beginning! The reason for this is that I came up with the idea to blog about it a little while after I had actually started the games, so for these two at least I will be starting these a short time after the actual beginning. Some earlier work for these could end up in here as it becomes relevant, I’ll likely need to change most of it, and any future projects will of course have posts from their start.
I started this work session on my Rise of the Necromancer project, which is using the Unity game engine. The C# classes for the abilities were poorly done to start with. I had initially figured that they’d all have some set of functions that could be called by the controller/game manager as needed, and each would implement those functions differently depending on the ability, so I set them up as interfaces. As I worked with them though, I came to a “no duh” realization that most of these abilities will implement these functions in identical ways, leading to a lot of copied code. Obviously this was an awful, terrible plan, so I went in to redo it. I made an Ability class that they could inherit from, and put the basic functionality in there. Most regular abilities will inherit directly from the Ability class, with some special skills inheriting from a TriggeredAbility class that is derived from Ability, these would be abilities that are set up during the player’s turn then go off later if some conditions are met. I still have some work to do in this regard, but Unity started acting up on me as far as its connection to the internet for collab, so I put that on the back burner and switched to the other project.
In my other project, Awiens, developing in the open-source game engine Godot, which I am very much liking so far, I didn’t get as much done, having spent more of this session on the Necromancer project. At the moment I need to add a cross-hair to the screen when playing so that aim is much more doable. I’ve figured two ways to do this so far: one is to add a sprite as a child node to the camera, this nicely follows every transformation done by the camera so all that needs to be done is to center it to where the bullets spawn. The other is to put it in some GUI nodes. I’m not sure how the above setups would be effected by screen size and shape, but intuitively I want to say the first option would be more resilient for staying put in the middle, where the other might be susceptible to stretching. In the end it likely won’t make too much difference though. I’ll need to replace the quick texture I grabbed for this test (I used the Godot logo, as it happened to be in the directory already) with actual cross-hairs but this seems promising otherwise. After this is done, my test reminded me that I need to add code to actually handle when turrets are destroyed, because right now the code will merrily try to use the broken turrets right up until it crashes trying to call a function from them.
So that’s all I’ve got today, until next time!
Journey Before Destination 