Apr 22

Improving GearHead Caramel’s Combat Interface

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?

Apr 19

The Inevitable Bugfix Release: v0.510

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.

Apr 13

GearHead Caramel is now Public

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.

Jun 12

Caramel Dialogue: Real Procedural Personalities

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.

Jun 04

Don’t Hug Me I’m Scared

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.

May 14

The Mechanical Tarot

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.

May 07

Progress Report

The western gate of Wujung, highway to the deadzone.

GearHead Caramel is getting closer and closer to a first real release. The character generator is working, the shops are working, the skill training interface is working, and missions are working. I’m adding a bit more content so Wujung doesn’t seem so empty; it should be ready to go soon.

(Of course, if you want to see what I’m doing right away, you could always download the development version from GitHub and run it with Python2/PyGame.)

In other news I’ve started a Patreon page for GearHead development. My immediate goal is to commission more artists to work on portrait bits and terrain tiles. This would speed things up immensely. Check it out if you think this is the kind of thing you could get behind.

Apr 15

Victory!

The fundraising campaign for GearHead Caramel was successful, and the image recoloring method has been translated to a C extension. The new version is literally 100x faster than the Python one. Changing portrait colors used to cause a noticeable delay, but now it’s instantaneous. Many thanks to A Bunch of Hacks for their good work!

Work on GearHead Caramel has been continuing at a good pace. In addition to the new recoloring extension, missions are now working in the DeadZone Drifter scenario and there are two new eyecatch screens by Thomas Noppers of Mutant Gangland fame.

If you ever arrive at this blog and it hasn’t been updated in a while, check my twitter feed in the right column. I’ve probably just gotten stuck in a loop of “I’ll update the blog when this thing is finished”, but in a roguelike game there is always something else to do…

Feb 27

Power Level Surging

For the past week and a half I’ve been raising money to hire some C++ programmers for GearHead Caramel, and I’m happy to say that we’re almost there! I’d like to thank everyone who has contributed, ordered art, or bought stuff from my itch.io shop.

Another $100 or so is needed before the programmers can start work. My regular commissions are still open, and I’m adding another option- for just $20 you can add yourself (or a custom character of your choosing) to the GearHead universe! I will provide files for use in GearHead 1, GearHead 2, and GearHead Caramel, as well as a full color version of the portrait suitable for use as a social media avatar.

If you’re interested in a portrait, just get in touch.

Feb 19

The Adventure System

Today I updated GearHead Caramel’s adventure system. This is the bit that allows temporary content to be added to a campaign and then removed later- the same kind of stuff as GearHead 1 and GearHead 2’s random plots.

GearHead Caramel inherited its plot system from Dungeon Monkey Eternal, and while DME has the ability to add and remove adventures to a campaign the method for doing so is awfully kludgy. I won’t go into the gory details here but suffice it to say you needed a dead pheasant and access to a graveyard at midnight.

In the refurbished adventure system, you can simply define an adventure object, and this will be inherited by all subplots. You can end the adventure or any individual subplot any time you like. Similarly, when you create a new scene you can define it as temporary. When the plot that created it ends, the scene is removed from the adventure (along with all of its children).

One problem right now is that if you end an adventure while the PC is still inside one of its temporary scenes, bad things happen. I’ve stuck a notice in the code that you should only end an adventure when the player character is leaving that area. I’m sure I’ll find all kinds of other problems, limitations, and unintended consequences as development continues.