Modules and Tasks: Things to Do to Get Things Done
In August, I had a handful of furniture objects that could be placed randomly around the board. They wouldn’t block doorways or result in unreachable tiles, and each one could have multiple points of interaction defined. This interactivity would be similar to the wall-mounted switches used to toggle lights and doors. It was time to combine the two systems, even if it meant doors would be impossible to open until I was finished.
The result is that now furniture objects can have wall-mounts defined in their footprints. This opens up a lot of possibilities that will come in handy once I start creating proper assets for the game: purely cosmetic wall decorations of any size, an environmental control system with a duct that connects it to the wall, etc.
It only takes a few seconds to define new furniture objects and assign them to different types of rooms. I just need to speed up my modelling/texturing skills!
As I’ve mentioned before, each board in Kitbash is made up of zones, and each zone contains nine sectors. Each sector houses one of the nine modules required for safe space travel.
These modules wouldn’t matter if Kitbash was your typical “space marines shooting at aliens” game. I could plunk down a bunch of waist-high barriers to crouch behind and move on to the next milestone. (Or the previous milestone. I seem to be doing them out of order.)
Your crew will have plenty of opportunities to express their violent urges, but they’ll also be expected to get some work done. [Aside: Did anyone else play Seed, the combat-less sci-fi MMORPG? If only they’d had Kickstarter back then!]
Modules are the cubicles of the future. And they’re now in the game, albeit in a limited form. I’ve been focusing on life support and power first. The other modules will be fleshed out along the way. There’s a lot of GUI work involved and so far I’ve been making do with Unity’s terrible built-in GUI. I picked up NGUI recently but I’m still hesitant to dive into that area of development just in case Unity’s new GUI finally gets released…
Anyway, modules don’t do a lot on their own. (Except catch fire.) But they were necessary in order for me to implement:
Tasks are the things you can do when interacting with a module or other interactive point like a door’s control panel. The terminology will likely change.
The idea behind a task is that some activities should take longer than one turn to complete. I didn’t want to get stuck in a system where hacking a computer and running across a room both take the same amount of time. Once I’d made this decision, the rest quickly fell into place and I’m really happy with how it works.
Tasks require a certain amount of effort to complete. This effort can come from multiple sources (potentially even enemy units) over multiple turns. If a turn ends and no one contributed to the task, the accumulated effort will start to decay. If everyone leaves the room before the task is completed, it gets cancelled. The effectiveness of multiple participants depends on the task — throwing 5 bodies at a computer problem shouldn’t mean you fix it 5 times faster. (As any programmer could tell you!)
A crew member can choose to contribute more effort on their turn if they rush the task, risking a mishap/malfunction. The amount of effort your crew members contribute to a task usually corresponds to one of their skills.
I’ve implemented a bunch of general tasks such as Repair, Lock, Unlock, Toggle Power, etc. Each module will also have tasks related to its function, with some tasks only available if your skill is high enough. Depending on the module, you’ll see tasks like “Lock All Doors in Zone”, “Heal”, “Deploy Additional Units”, “Vent Oxygen from Zone”, etc.
Attributes and Skills
I needed to put a proper system in place for these important character stats, now that the values are being put to use more heavily. I’m doing something a bit different with the basic attributes but won’t spill the beans on that just yet.
There are about a dozen different skills, including one for each module. Crew members specialize in one module and its module category (biological, mechanical, technical — again, the terminology will likely change) and also have a few combat/leadership skills.
All fun stuff. Not something I can really show off without a GUI though!
Life support was the first module I implemented, if only to give my weary test crew a way to put out fires.
My initial thought was that as long as the life support module is powered and online, its zone should gradually fill up with breathable air. I mean, surely a space-faring people would include some basic air ducts in their ship designs, right?
In practice, it’s more fun for the player to manipulate the flow of oxygen using doors. So most of the air comes from the life support module itself, spilling into adjacent sectors (assuming there’s an opening) until the whole zone is filled. Each sector also gets a tiny amount of air pumped into it, regardless of openings. I did that just to see if it leads to any interesting results.
At the moment, fire is the only consumer of oxygen. Hull breaches will come later. They’ll probably suck.
I’m still pondering the visualization for oxygen levels. Obviously the floating numbers you see here are temporary, for my own debugging. I was originally going to use the black room borders for this kind of information (pulsing red to show an inhospitable environment, for example) — but that was when oxygen levels were going to be set per room, not per sector. Hmm.
I’m about to start working on a proper Health system. Right now I’m just using buckets of hitpoints for everything and I’ve been itching to move away from that because it’s so boring.
I mentioned my favourite Atari game, Six-Gun Shootout, in a post late last year. Each unit had a set of hitpoints for each body part, and wounds affected their abilities accordingly. Getting shot in the leg would usually knock you down and make movement quite difficult, although you could still shoot. Likewise, a serious wound to your arm would leave you unable to shoot on some turns. It may sound overly punitive…but it was actually fantastic!
After I’ve tinkered with the Health system, I’m going to do a very quick Morale/Leadership implementation.
And then it’s time to stop coding for a while and concentrate on graphics. No more placeholders! A design for the GUI! A final character design for the little humans! Ugh.
I’m considering submitting this post to /r/devblogs on Reddit. I really have no idea if any of this makes for interesting reading or if it’s just for my own personal record. If you happen to find this on Reddit and have read this far, please comment to let me know what you think! Should I be posting more about the technical side of the game’s development? Should I stop wasting time with stupid words and replace those damned placeholder assets already? Thanks.