Get updates by email: Subscribe
When I left off on the last update, I was flailing wildly in the void, unable to find my grip. In less pretentious words: I was having design problems.
My immediate goal then and now is to create a vertical slice, which is a demo, that can to some extent demonstrate all the functionality in the game. It won’t have the finished graphics, polish or even menus, that the final game will, but it’ll be a very accurate representation of the final gameplay.
The trouble was I didn’t know how to put all my mechanics together and every time I tried to put something in, I realized it wasn’t done enough to play nice. It seemed that the AI was the root of my problems as it’s a major part of the game, so I tackled that first. I overhauled the entire AI and made a “Central Control”, that can give commands to guards.
What does this Central Control do? Firstly, it has a global alert state. Should guards just patrol normally or should they chase down the player? You can think of it as a default state, that the guards will act based on.
Next it handles all kinds of situations that the individual guards might get into. Say, a guard hears you running around nearby and goes to check it out. Firstly, he’ll report it (this will be important later), then he’ll go check out the area, and if you’re not a pacifist, you might take him out.
This means that Central Control got a report from someone going to check out a suspicion without ever hearing back. Central Control will after a while send another guard to check out what happened. This guard might; discover you, find a dead guard, find nothing, find a guard with a hacked radio, or any number of things…
Example where a guard found a dead guard, which put everyone on suspicious-alert. Then while suspicious they found the player and initiated the chase state.
ANOTHER BIG UI FACELIFT
If you’ve been reading my previous updates, then you know that I spend way too much tweaking the UI (in my defense, it IS an integral part of the game), and this month was no different. I was starting to do more advanced stuff and I soon realized that my homemade PixelCanvas could not keep up. Besides working with my half-assed editor controls was tiresome and slow, so I decided to give Unity’s UI another go.
Always research your options before you just assume… This is what I learned when I looked over the Unity UI documentation. There are actually a decent amount of options for pixel perfection, some of which came out right after I finished my PixelCanvas (sigh).
It wasn’t quite plug-n-play however as lots of things broke when I started applying my pixel stuff to it. For example; there’s seemingly no good way to get pixel perfect text, that isn’t blurry as hell. I’m currently doing a bit of a hack, where I scale the text way down but then give it a higher font size, which kills the blurriness somewhat. This isn’t perfect and it also creates issues with anchoring/resizing/etc, which was the main reason to switch in the first place. Oh well…
I decided to take my new UI for a spin and I made the radio-program, which is used to conversate with allies, but also spy on your enemies (like reading those reports from the guards). I quickly ran into some issues with my original design, which had no way to call people except remembering their frequency, so I added a contact-panel, which can be toggled on and off. I also made sure to do a shitload of layout stuff, to really take advantage of the UI (no going back now).
Another main part of my game, that I had been actively ignoring was a way to have files in the game. Since the game’s inception there’s been an ability to replace a camera’s output with an image, but never has there been any way to store images… Until now!
Ok it’s not that exciting but in essence there will now be two folders in the game for images and documents, which can be accessed by programs such as the cctv.exe. It’s not done yet, but here it is so far:
So, here’s another bit of design foolishness. Imagine that every key in your keyring had to be turned in slightly different ways to unlock their locks. Wouldn’t that just be extremely annoying for no reason? We’ll that’s sorta how unlocking things in my game has been up until now.
You can unlock variables via the password field in a hackbox and you unlock keypads by typing directly on them (but they also have a hackbox somehow). On top of this, there are area-based locks and individual locks, so some keypads have to be unlocked with a pin and others with uuhh a keycard? What a mess.
I boiled all these confusing unlock-mechanisms down to just 1 because anything else would just be confusing, so here’s what I came up with. Everything now uses the password-field in the hackbox, since that one might also be used for other things. So instead of typing directly on the keypad, you now temporarily open the UI (with only the relevant hackbox visible).
This works because the UI will go away once you’re finished with the hackbox UNLESS you select something else, in which case it’ll be as if you opened it normally (it won’t close on you).
When I tried to smack together a demo level last month, my mechanics were still to immature, but I feel like they’ve really come along way since then. On top of that, I’ve also upgraded a lot of the background stuff (such as UI), making for a much smoother development-experience. This means I wont immediately clutter up any level I try to make and also it should be much quicker to fix bugs. This is especially true for the UI, even if it’s still not 100% clean.
In general I’ve used my time well this sorta-month, especially considering I also moved to another part of the country and had a lot of freelance work.
I’m obviously gonna be a little busy over the holiday, so the next almost-monthly update will have an emphasis on the almost part. That said I’m hoping to really finalize the UI and get my AI perfect along with an actual working map. Once that’s done, I’ll pretty much have my vertical slice. Or so I hope…
-Hjalte Tagmose (@hjaltetagmose)
Indie Game Developer, Real Fast