Hello everyone! It's been almost a year since the release of Kernel and in that time I've gotten a lot of feedback about what's strong about the game and what needs improving. We're going to get into some ideas I have for how I want to touch up the game's systems but first I'd like to make it clear what my vision for the game is and what my ability to work on it is.

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.

My Favorite Kernel Session

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?

1. Players are surprisingly tough.

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. 

2. Don't limit interpretation of mech ability.

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.

3. Keep Resources Tight

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. 

So... where do we go from here?

First I'd like to summarize my intent on these changes with two statements.

"Kernel is a game about disempowerment."

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.

"Kernel is a game about resource management."

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...

Momentum Dice

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:

• It's rewarded by the Game Director.
• It doesn't take up Tank space.
• You can only have one at a time.
• Using it for an action doesn't take up your turn (& can be used out of turn order)
• The recipient may choose to give the die to another player.

My hope with this system is to accomplish a few things:

• Create variety in threat scenes not through giving players more combat options but instead by encouraging them to narrate or think of creative ways to apply their rig's systems.
• Create energetic "Fuck Yeah!" moments.
• Create a way to get a little more momentum in your fight that isn't too easy to abuse/predict and if it does get a bit abused won't ruin the resource economy completely.

Here's some examples of how a system like this can be used.

• A player decides to jump headlong into a spider nest with no regard for their safety. Their buckwild energy rewards a momentum die.
• A player charges into a raging fire to save civilians, their bravery instills a bit of miraculous power. A momentum die represents the adrenaline of a moment of truth.
• A player with a chain on their weapon system uses it to trip up a larger opponent. A momentum die is granted to represent the opening and the player gives it to an ally who they think could do a better follow up attack.

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.

Zone Mapping

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.

Community Oversight Update

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.

Conclusion

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.

:)