GearHead Caramel v0.620 has just been released. There are a lot of changes this time around- as you’d expect from the length of time it took me to release this version. Every town in DeadZone …
I have finished the paperwork and am preparing to release GearHead Caramel on Steam. I think I have everything set up correctly to compile the Linux binaries for SteamOS; we’ll see how it goes. As …
In part one of the tutorial, we created an empty city scene and stuck an exit in it. In this part we will add a building, a shopkeeper, and a shop. You can download the …
Once upon a time, in the distant past, there was a GearHead forum. Now, in the sparkling future, there is a GearHead Discord. You can use that link to join and talk about GearHead, mecha/games …
One of the great new features of GearHead Caramel is the ability to add your own content that will automatically be loaded and used by the game. If you check your ghcaramel user folder (which …
Itch is running a bundle to raise money for the NAACP Legal Defense and Educational Fund and Community Bail Fund. Right now you can get over 1000 indie games for $5. I’m not sure, but this may very well be the best deal in the history of computer entertainment. My comic “Voles of the Dusk” is part of the bundle, and as its regular price is $5 it’s like buying the book and getting 999+ games for free.
There’s a new release of GearHead Caramel featuring NPC memories, an improved shop interface, and even more mecha. Try it out and let me know what you think.
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 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.
Recent Comments