Decks, Devkits and the Peak District

You know the drill by now, it’s time for the weekly update! It’s been a crazy week here; we’ve had some cool new developments so, without further ado, lets dive right into it!

First up, work on Horde is still slowly but surely progressing. This week saw me trying to remember how writing editor functionality works in Unity. I spent longer than I would have liked trying to remember how to write an editor class that I could use to generate the functionality I needed in the property panel without exposing information that could make the game crash if incorrectly modified… Ok, let’s unpack that, as that might not mean much to some people…

Background for non-techies: In Unity, you have an editor that you can use to make things without writing code. When you write code (or scripts) in Unity, often you need to add them to something in the editor before they’ll do anything.

The property panel is a portion of the editor that lets you change values on things you’ve added to the scene (or level) in the editor. So if you add a script that makes an object move, you may have a value called speed. Rather than changing it in code, you can make it appear in the property panel in the editor, allowing you to change the speed without having to change code.

By adding editor functionality, you can change how things appear in the editor to make them better suit your needs. For example, instead of writing the speed in the editor, you could make buttons that adjust the speed by a set amount each time.

That one was a lot. Hope you’re still with me. Anyway, I wanted to write a class that lets me specify what zombies I have in my “deck” in different levels. However, I am not yet certain which zombie types I will be using in the game, so I wanted to make it flexible; I wanted to use an array of zombie types (a list essentially) that looked like this:

Which is not super readable. I don’t know which element is which zombie type, and I can just change how big the list is in editor, causing potential crashes and instabilities. So I wrote an editor script to generate the elements and name them based off the zombie types I’m specifying elsewhere in code. It took a little while to refresh myself on the code, but eventually I got here:

Then I hid the array from the editor, so it only drew my custom code:

Techie Tip: I use [System.NonSerialized] to hide public values from the editor, and [SerializeField] to make private ones visible. Always keep your protection as high as it can be!
Unity may well give you warnings that a variable will never be assigned to, but you can disable those with #pragma warning disable 649 for clean, warning free code – You know it’s going to be assigned in editor after all!

EDIT: I have discovered since writing this that I have been mis-using [System.NonSerialized] for some time. As you might expect, this stops the value being serialized. this will stop the editor script saving the changed values. Use [HideInInspector] instead!

Cool. But to set those values I have to click, then type the number manually, which is still a pain, given the number is unlikely to exceed ten or twenty at most. So I added some buttons to either side to increase or decrease the values:

And this is where we are. I played around with the idea of making the number “read only”, so we are forced to use the arrows, but decided against it in case we actually have a situation where we want twenty of every zombie and don’t want to mash left click till our fingers bleed.

At the moment I’m not sure if that is how we’re going to be playing hands, or if you are going to have a “point buy system” and every zombie you unlock is permanently available but costs points to spawn. But for now it is useful, and an excellent reminder of how editor code works!

In SockMonkey news, I’ve now reached a point in the project when I’m hitting the bottleneck of waiting for things that need to be done by someone else. This means it’s very difficult to know what to do next, as for the most part, I’m blocked. The solution came from an unexpected direction. It was suggested that I start working on a different platform. As I mentioned in a previous post, I’ve been using a Nintendo Switch devkit so far, but that isn’t the only platform the game is targeting. Someone else has now started work on the PS4, which leaves me with the Xbox One. I don’t own an Xbox One. Or at least, I didn’t. We had a call, and discussed options for getting me developing on the console and, long story short, I now have an Xbox One X that I can develop on! As I think I mentioned in Coffee, Clay and Catching Up, the Xbox One devkit is just an Xbox One, all you do is pay for the right to develop and you can get developer mode access. So that is what I have done. Turns out its not perfect, as retail kits can only be used to make UWP builds (don’t worry about it), which comes with some limitations, but it get’s me started!

It does also mean that I now have the full might of Game Pass at my fingertips during down time, as you can switch between developer mode and retail mode with relative ease, but that’s just an added bonus. It’s all about that development!

Now I just have to do everything I’ve done to get the Switch working again, only on Xbox now, and hope I’ll be unblocked by then! In my previous job at Tt Games, the Xbox One was always the console that hated me the most, to the extent that I couldn’t develop on it for two years ’til I got a replacement PC. Fingers crossed things go smoother this time around!

And finally, as this post has been almost entirely development based for once, I’ll wrap up with some non-dev shenanigans. As the lockdown restrictions have now eased and we are permitted to travel, and to have “UNLIMITED EXERCISE”, we took the opportunity to head out to the Peak District, which is a 15 minute drive away. We first tried going to Stanage Edge, which proved… Unwise. Everyone had the same idea it seemed, and it was about as socially distant as my local supermarket. So to try and avoid the droves, we scouted out along Snake Pass until we spotted a lay-by with a dirt track leading off into the wilderness. For the first time in months we were able to get out to nature, and be completely away from the world. It was nice, we climbed a hill, some rocks and generally enjoyed fresh air, at a distance of about a mile from the nearest person (who we saw walking a dog).

Back to Nature

I haven’t forgotten the livestream by the way, I’m working on ideas for things I can add to the game that will be fun to make and watch. In the meantime,

Matt out.

5 thoughts on “Decks, Devkits and the Peak District

  1. Great! Love the combo of techie and non-techie stuff, and the finding out about your life outside of a computer at home. At some point you may have to explain what Unity is to me…

    1. Thanks! I appreciate the support! Unity is a games development engine, basically a shortcut so we don’t have to write the engine from scratch every time we want to make a game. Unity provides an editor to do non-codey things in, Input, Audio, Physics, Graphics, and a bunch of other really useful tools that we can use to build from.

      In theory you can build a game without writing a single line of code, but rarely will it be the game you want 😛

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top