Posted November 20, 2024 by Avagarde
#kernel
Firstly I'm a solo developer with not much online reach, this means my ability to playtest is usually restricted to friend groups of adults, secondly I do have a day job that restricts my ability to develop it fully and offer more opportunities to test the game. However, as some might have seen on this page I just recently wrapped up another big project so I'll be able to focus on Kernel a bit for the forseeable future. Regardless, my position as a small developer means the best way I can get feedback is to get the game and ideas I have for the game into your hands. It can be difficult however to communicate the vision for a game that's a little peculiar like Kernel is. A lot of people play it and wonder what sort of system they should expect: something narrative? something tactical? A lot of advice I've gotten about the game tends to lean towards the latter because of similiarities the system has to other popular mech systems. People expect things like grids and combat options, but before I present my suggestions today I would like to tell you all about the best session we ever had playtesting Kernel and how it solidified the game's vision to me.
One of our early playtests was a session with no combat, it was completely a question of beating the clock. What happened on this mission you might ask? Well, I had the players evacuate a burning city. A big tree to be precise. The tree was broken up into sections that needed addressing, there were the lower sections of the tree where walking rigs could evacuate civilians and hold the fire at bay and the branches were more civilians were trapped. In this way players already got a good idea of what their perticular builds could do. The clock however, was not in their favor, while rigs could hold the fire back for more time there was simply no saving the city and no saving everyone. At a certain point the fire was so out of control it meant helping anyone as certain to lead to taking damage. The player saved a lot of people, but there were also plenty that died, and some pilots only made it out by the skin of their teeth, one player saving people until their rig was only one breach away from catastrophic failure. It was the most fun we'd had yet, and from then on the idea of working against or with clocks to achieve objectives, became a pillar of our sessions. This is something I try to emphasize in the corebook, however if people think there are any other ways I could encourage this playstyle further I'd love to know!
So what else did this session give me going forward?
While the numbers can very much seem against the player, what with hull capacity being so small on average and breaches posing such a massive inconvenience, the playtests only really showed that player cooperation created exponential convenience. The numbers say one Rig can't do it all, and you're right! This is very intentional. But what wasn't intentional is how strong even just one other player to take the burden off your shoulders can be.
While combat is an easy area for improvement on rigs I don't want to engage in systems where combat has exceptionally more depth than any other system. There have been plenty of times where I toyed around with systems for special attacks, additional weapon systems, or just more combat variety in general but I never felt like it added anything to the identity of Kernel that made it unique. I wanted systems that made combat more fun also make scenes like this more interesting as well.
Players are very eager to spend resources, but I wanted to always create balance between wanting to spend resources and using them for the good of other people. This system will probably get the biggest change going forward but more on that later. Overall the pacing of player expenditure was good in playtesting, but I always wanted to keep the floor of pain close. I wanted a system that would catch up with the player and lead them down death spirals if they were too arrogant, forcing them into positions to fall back on their allies or come home with a broken nose. Players coming home unscathed was simply not interesting. Feeling like you spent just the right amount was better in my opinion then having just a little too much.
First I'd like to summarize my intent on these changes with two statements.
In Kernel you have a rig but your rig is small. Your rig is also a like an old tank, it needs so much to keep it going and has such fussy controls. Keeping the engine hot should feel like keeping a fire alive in the dead of winter.
And I mean SICKENING levels of resource management. I might even update the store page to really lean into it. I want to inflict resource TERROR.
But through these distinguishments I don't want people to thik I'm ignoring criticism. I mull it over in my mind a lot. (A LOT!) But I want to make sure we arrive at a place that is unique and interesting, I don't want to borrow too much from other systems. I want to create fun that you can't have anywhere else. I'd rather Kernel die in obscurity then wither in someone else's shadow. But there is a lot that can be done with Kernel's unique style of resource management that I think can immediately give it more energy. Which brings us to the first new system I want to add, it's a small one that I think will improve the pace of the game a lot. Introducing...
Did one of the players just do something very daring and heroic? Did a player just describe using their unique weapon system in a way that creates a big glaring opening? Well you as a Game Director can now reward players Momentum Dice, a Momentum Die is an extra die to spend with a few special rules:
My hope with this system is to accomplish a few things:
Here's some examples of how a system like this can be used.
Players should keep in mind these dice are given at the GD's behest, so they may need to be a bit creative. Game Director's are discouraged from rewarding Momentum Dice on repeated exploits. You also don't have to spend it on an Action or an Action addressing the same threat, the die can stay in your tank to prevent Breaches or used to run away with a Reposition.
One thing I'm still considering and hoping to decide on in playtest is what the best way to grant the dice will be. My current thinking is Roll 2d6 and take the higher but I'm also considering letter the Game Director pick what they want to give the player, or even just making it a flat 6.
I won't spend too much time detailing this but this will be a section detailing how I recommend making maps for the game. During playtests we imagined encounters being in scenes where distance was interpreted very losely and while this didn't create any issue for us other players are used to more detailed playfields. I don't want tactical play and positioning to overwrite the simple question of waying the pros and cons of what actions to make so there will never be detailed tactical maps in Kernel. BUT what we have used for bigger scenes is a simple system i'm calling zone mapping for the sake explaination. This just shows the immediate area and regions connected to it by simplified zones you can move between. The way they're connected can be gameplaye relevant but for the most part anything in the zone with you is close enough to act on. This is a very boxy example of a zone map but there will be rougher drafts in the final version.
Oh finally. The time for my greatest shame. The full depth of community oversight was never fully playtested, it was added a bit too late for us to get too deep into it. However, I always wanted to keep it in the game because even when not being interacted with it's presence made gameplay more interesting. The threat of needing resources down the line made gameplay more tense and exciting, even though players rarely got to see the final pay off. It's psychological component was undeniable, so even though I felt like it was rough and overcomplex I was scared to touch it. I wanted to give other players the chance to see what it could do, but unfortunately most players were simply daunted enough by it's complex nature it wasn't a hit with anyone. While I may have been able to leverage it in playtests as the person who made it, capitalizing on it was simply too clunky to be fun.
So the way Community Oversight will work will see a big change. There'll be no more community dice, calamities, or community grades. Instead there will simply be a system for the Game Director to introduce a community undertaking that needs to be addressed for story concerns and players will turn in a set number of Kernel Cargo to complete the undertaking. It will be up to the Game Director to decide how to apply them as opposed to relying on arcane system of automation that felt too boardgamey. My hope is by making the system simpler more Game Directors will engage with it and thereby create the tighter budgets the game's balance calls for, without too much rigmarole.
While I'll be taking a break from working on things here for a bit expect a pdf of these rules in the future for playtesting. Feel free to incoporate or play with these ideas. I'd love to here feedback on them! Once I feel confident in the systems they'll be rolled out with the corebook.
I don't think their inclusion will be too much of a shakeup to the game's rules. I also don't really want them to be. There will likely not be any further depeening of the systems from here because at the end of the day I want to keep Kernel a system I enjoy playing and can easily run as a more casual Game Director. My hope is through these new rules I can add more fun to the core of a system I already enjoy despite being difficult to run in many ways. Learning to run Kernel was a process for me, and the greatest challenge I experience as a solo developer is figuring out how to get ideas across. But I want it to be unique. And I do want players to squirm a bit.
Maybe a lot actually.
:)