I’ve made a short video of GearHead Caramel to show off some of the new features.
I’ve just uploaded a new release of GearHead Caramel, v0.520. Probably the most exciting change this time around is the addition of cybernetics; there are also improvements to the Mechanical Tarot scenario generator and cosmetic enhancements to Wujung. And you get to punch nazis. You can see the full list of pages at the GitHub releases page.
I have just done an upgrade of the Mechanical Tarot scenario generator, and I think it’s ready for prime time. The concept behind the Mechanical Tarot is that various NPCs, factions, locations, and props get “Cards” attached to them. These cards define the role of whatever they’re attached to, and also define how this thing can interact with other things. By constructing a sequence of interactions we can procedurally generate puzzles and situations for the player to interact with.
The refactoring gives the Mechanical Tarot cards a well-defined interface for describing interactions. Cards now have lists of Signals and Sockets; a Signal is a message this card can send to other cards, while a Socket is a possible game event waiting for a signal to activate it. The cards themselves are now bare-bone lists of interactions; the game content gets handled by subordinate plots that the card loads upon activation.
These subordinate plots just need to focus on one purpose each, so they can be relatively small and reusable. For instance, the plot for discovering a clue just needs to place the clue item somewhere in the world, while the plot for linking the clue to a crime just needs to check that particular socket for activation. Neither plot needs to know or care about the other. This is much better than previous versions of the Mechanical Tarot system in which the cards had to handle both their interactions and their game content.
GearHead Caramel v0.511 has just been released. You can grab the ready-to-play versions for Linux, MacOS, and Windows from GitHub.
GearHead Caramel has been out for a week and a half, gotten its first update, and so far I’ve been hearing a lot of good things about it. I’d like to thank everyone who has supported GearHead development whether through code contributions and bug reports, itch.io and Patreon, or just sending me encouraging messages.
One area where GearHead Caramel needs to improve, though, is its combat interface. Several players have pointed out that it takes an awful lot of clicks to do anything. In places it’s not quite as intuitive as I hoped it would be. Plus, allowing some more configuration options would make the game more accessible to a lot of players. So here is what I’m planning to do:
- Consolidate all of the action types into a single library. Right now you have to switch between movement, skills, attacks, and EW programs using the radio buttons on the upper left. It would be better if you could access all of your abilities through the up/down keys and the mouse scroll wheel. The buttons can stay, but they’ll be bookmarks rather than completely separate sections.
- Speaking of consolidation, right now every skill gets its own action library shelf. But most skills have only one use. So, I think it would be best to move all of the skills to a single “Skills” shelf.
- The movement widget should be redone in the style of the action widgets, with each available movemode shown as an action icon. That would make it much more obvious that you can switch your movement mode.
- Speaking of movement modes, I don’t think there’s any reason to store them outside of combat. During exploration the party should only be able to move through tiles that all members can move through (excluding immobilized members, who should get left behind!). Once combat starts, each player mecha should start in the fastest movemode that can legally enter the tile it’s currently in.
- The action counter that was previously part of the movement widget. It can be moved to the upper left hand side of the screen, and changed to a counter/hourglass display similar to that used in certain other RPGs (I think Temple of Elemental Evil had something like this). The rule is supposed to be that you can move up to half your movement rate as a free action before performing an action. However, this was not obvious in-game, and the only pre-action movement allowed was the automatic moving into position that was done when you tried to make an attack/use a skill while out of range. The new display would show your number of actions as a number and your movement allowance as a color behind the number.
- Hotkeys support. If you press an alpha key while hovering over an action icon, that action gets tied to the key. How do we keep track of keys when the action library is dynamically generated every time? The key stores the names of the shelf and option.
- Aside from props which have a destroyed sprite and remain as obstacles even after they’ve been destroyed, models will be moved off the board when they are destroyed. There’s no reason to leave them lying around as gear icons.
What do you think? Is there anything else you’d like to see changed, or anything you don’t want to see changed?
As I should have expected, as soon as I released GearHead Caramel v0.500 last week a whole lot of bugs that had been hiding for months suddenly made themselves known. So this week I present to you v0.510, a release with far fewer bugs but one extra crab mecha. You can download it from the github releases page. The precompiled release packages don’t require you to install Python3 or any other dependencies; just unzip to a convenient place and start playing immediately.
I’ve just made the first public non-demo release of GearHead Caramel. Character creation is working. Mecha engineering and design is working. There is a lengthy playable campaign with an endpoint. You can import your characters from GearHead1. Obviously there’s still a lot of work to do, but the next game in the GearHead series is finally here.
You can download ready-to-play binaries for Windows, Linux, and Mac from GitHub, or download the source code and build it yourself. Try it out and let me know what you think.
In previous GearHead games, dialogue trees had to be constructed manually. Each NPC could have an assigned dialogue tree, and random plots could override this with their own dialogue tree. This worked well but was labor intensive and somewhat inflexible.
GearHead Caramel does things a bit differently. When a conversation starts, a list of all the things this NPC could possibly say is generated. These get linked together into a dialogue using a process similar to a context-free grammar (it’s almost context-free; context-lite maybe?). For instance, a “Hello” node might link to an “Info” node or an “Open Shop” node. A “Mission Offer” node might link to “Accept Mission” and “Reject Mission” nodes. It’s also possible for a conversation node to come with pre-attached replies, for situations that don’t match any of the standard contexts.
These conversation nodes can come from a variety of sources. An NPC might have nodes directly assigned to it, such as a shopkeeper’s “Open Shop” node. A random plot might assign new dialogue nodes to an NPC, such as the “Mission Offer”, “Accept Mission”, and “Reject Mission” nodes that the mission-giver needs. It’s even possible for an NPC to receive dialogue nodes from a generic source, such as requests for information that you can ask to anyone living in a certain area or belonging to a particular faction.
Once the dialogue has been built, the last step is to construct the text. GearHead Caramel uses a token expansion system to procedurally generate a lot of the text used in the game. For instance, instead of assigning the NPC the dialogue “Hello. Nice to meet you!”, I can instead assign the tokens “[HELLO] [NICE_TO_MEET_YOU]”. The dialogue processor will check the grammar dictionary and replace tokens with appropriate text, recursing until no valid tokens remain. There are two main advantages of doing things this way: first, dialogue lines will be subtly different each time they’re seen, helping the world seem a little bit more alive. Second, this technique allows dialogue to be tailored for different personality traits and other character attributes. The grammar dictionary has multiple options for each token, sorted by tags. This helps characters to speak with a consistent voice, even though I don’t know who is going to be speaking a line when I write it.
The token expansion system is also used for the PC’s dialogue, so different player characters should sound different.
I’m not saying for sure that a new season of Don’t Hug Me I’m Scared is coming up in two weeks, but June 19th is fast approaching, and whatever happens I think Red Guy would want us all to be prepared.
For those who have never seen DHMIS, it’s a creepy musical puppet show about learning, friendship, and WHAT THE HELL DID I JUST WATCH. You can see all of the episodes on YouTube at the link above.
The last big part of GearHead Caramel that I need to work out before making a release is the mechanical tarot system. It’s sort of but not exactly a random story generator, since the idea is for it to create an interactive situation rather than a sequence of events. Sort of like the difference between Fallout and Final Fantasy.
The system is loosely based on Smart Terrain Causality Chains, but instead of physical objects the puzzle pieces in this case describe abstract things about the scenario. Things like the roles and motivations of NPCs, or the environmental factors affecting a city. The player can trigger interactions between cards which change the situation. Cards enter play in a “face down” state and must be uncovered by the PC before they can interact.
To generate a scenario, first a desired outcome is chosen. For instance, a village suffering from drought might need a new moisture farm. The scenario generator then works backwards from the desired end point by finding card combinations that lead to it. A moisture farm might be generated by a broken moisture farm plus a water chip. The water chip might be found by bringing an ancient treasure map to a scholar. But the scholar has been falsely accused of murder, so first you need to clear their name… This scenario would begin with cards for the drought, the falsely accused scholar, the broken moisture farm, and the evidence to clear the scholar’s name.
One interesting thing about this scenario generator is that there is no guarantee things will end as planned. Depending on the cards generated, the player might do something completely different from the desired outcome chosen for the scenario. This is perfectly alright. The more cards in play, the greater the chance of unintended interactions being possible.
Because of this, the mechanical tarot scenarios have to be designed with the assumption that the end state is unknowable. I’ll describe how I’m handling that in a later post.