Close Encounters of the Close Kind

I've been working on the encounter system, and I think I've arrived at a working draft that serves well enough for the time being. Here's what it looks like:

NEO Scavenger's first encounter!

When the player has an encounter, this screen pops up. The player can see this encounter's details, and navigate to the other inventory and character sheet screens on the left menu, but they cannot exit back to the game board and continue moving until this encounter is dealt with.

The encounter screen itself is roughly divided into quadrants. Clockwise from the top left are:

1. Illustration - an image depicting the encounter.
2. Description - a text blurb describing the encounter. Also, there is a blurb of yellow text showing what your current response to the encounter is set to. In this case, the player has done nothing to respond yet.
3. Response - This is the response area. The player can drag any number of items or skills into this area to formulate a response. At the bottom of this quadrant is an "OK" button. Once the user clicks this button when they are happy with the response they've chosen.
4. Specials - This is the special encounter item area. Any items specific to this encounter which can be used are shown here. These items disappear when the encounter is resolved, and are replaced by new items when a new encounter occurs.

In this case, the player has awoken in a cryogenic stasis facility, and has no idea what is going on. The image in #1 is only coincidentally isometric, the game board has no such tiles. I was briefly tempted to create a cryo tile set, but I'm not sure I want to commit to making tilesets for each locale yet. #1 is mainly isometric because I'm better at iso pixel art than perspective painting.

#2 is currently some of the first game plot text the player sees. The player does not know who they are, why they're here, or where they are. Part of the game will involve answering those questions. However, a greater concern is pressing: something screams from down the hall, and is approaching fast.

#4 shows two scene items that were called out in #2: a door control panel and a broken window to the outdoors. The player can use these items (by dragging them into #3) alone or in combination with any items from their inventory, or skills they've chosen for their character (bottom item in left menu).

Once the player is satisfied with the response items they've chosen, they click the "OK" button. The screen updates to show the player the result of their response. This will usually take the form of a new encounter with no responses possible.

Basically, a dialog box.

During such a "no response" encounter, all navigation options are hidden, so the player isn't confused into thinking they can do anything to alter it. In this case, inaction has killed the player. But such "no response" encounters might also include parting words with an NPC, a status change on the player, new items being deposited in the current hex as loot, etc.

The result could also be another encounter, allowing a chain of encounters and responses to ensue.

I've written the encounter system such that there is a list of outcomes for each encounter, based on the items the user chooses as a response. If they fulfill the pattern for a response, a corresponding new encounter occurs. If not, there is a default encounter outcome that occurs. I wanted this to closely resemble the type of play that occurs in a pen and paper RPG session. The game master presents the player with an encounter, and the player can use any of the items or abilities available to their character to deal with it.

One issue which may surface as a result of this design is the temptation for "kitchen sink" responses. The player may just assume that if they throw everything they own into the response, they'll safely pass the encounter. That sort of breaks with the role-playing tradition, but I'm not sure it's my place to be policing play style in my game. Still, it would be nice if the game presented an actual challenge requiring critical and creative thinking to progress, rather than brute force.

Originally, I thought I could discourage this kitchen sinking by having any item used in the encounter consumed. It would definitely cause the player to be more stingy and selective. However, there are things like skills that I don't want consumed, even if used in an encounter.

I think an alternative way to dissuade kitchen sinking is to have the game simply take the first valid response it finds. Particularly, if undesirable outcomes are matched before more desirable ones, this should encourage players to be more selective with their responses.

This design is still subject to iteration. But it's reached a stage where it roughly matches the design, and I can create some test content for it.

Skills and Abilities
As part of the above system, I also roughed-out a skills and abilities system for the player. It's still very bare-bones, but it's enough to make encounters work reasonably close to the proposed design.

When the game starts, the player is presented with a skill selection page

Choosing skills for one's character.

The right side of the page has a list of available skills, and the left side is for skills the player already has. In this screenshot, the player has three skills: Hak (Hacking), Hid (Hiding), and Cbt (Combat), and the Med (Medicine) skill is available to take.

One thing you'll note is that skills are treated a lot like items. You can drag them around like items, and you have a place to store them. I want to see if this is sufficient for handling skills and abilities, as it allows me to leverage the existing inventory system code (and the player needs only learn one system for both items and skills).

One neat side-effect of this approach is that I can handle character development by adjusting the size of the player's skills container. As the player gains experience, I can simply increase their container size, so they can fit more skills into their space for use in encounters later.

When finished, I expect the right side of the screen to include many more skills than will fit on the left, so the player must choose carefully. I may even decide to have each skill item represent an increment of aptitude in a skill, such that a player can choose Hiding multiple times. Unlike the current system, where the simple presence of the Hiding skill determines success or not, I could change it such that each copy of Hiding used in an encounter increases the chance of it succeeding.

This multiple-copy approach would be a major leap towards mimicking traditional pen and paper RPGs, and I'm excited to give it a shot. I'd simply have to determine what scale to use for determining probability of success.