Roguelands (aptly named) an action-adventure, rogue-like platformer in which you play as a galactic cadet exploring planets and gearing up to ultimately take on The Destroyer, a creature which threatens your world. The game is Early Access on Steam and currently has "very positive" reviews on Steam.

My primary criticisms for Roguelands aren't what I usually mention -- its font color, type, and sizes are fine (and its dialogue format nostalgic, if you played JPRGs), its UI is intuitive, and its controls easy to pick up.

The place where Roguelands has the largest room for improvement is in player onboarding and crafting.

The First Few Screens

The first few minutes of the game are self-explanatory -- on the main menu, you can click Play, Data, Options, and Quit. Clicking on 'Play' shows you seven Empty save slots -- and when you click on one, you're led to the character creation screen.

This screen was easy to figure out - clicking on each button had a predictable effect, and the 'Stats' icons had a mouse hover effect so that I could learn what each meant. No too much to much to elaborate on here, but I have a fair number of recommendations/enhancements that don't require length paragraphs to explain.


Recommendations:

• High Priority: Stabilize the initial menu/setup screens by either eliminating the movement of the buttons or slowing down the movement speed of the background.
  
  Having both a scrolling background and slightly moving platform buttons is disorienting. I'm prone to getting motion sick when playing video games -- and I feel the risk of getting sick when on those initial screens.
  
• Low Priority: Consider allowing 'Esc' to be used in the initial setup screens (such as in the Race Selection screen).
  
  Enabling 'Esc' in the Race Selection screen will save time in the instance that the player doesn't want to change their character's race after reading the other abilities. It's weird to press 'Confirm' for something that's already in place. Plus, in the game itself, you use 'Esc' to close menus -- so why not do it here, too?
  
• Low Priority: Consider allowing both left and right clicking on the Character Creation menu to allow players to more easily cycle between options.
  
  Currently, there are six types of Allegiances that a character can take. If I left click and see the Church of Faust, but decide I want to be The Galactic Fleet, I have to left click six more times to return to The Galactic Fleet option. Allowing for cyclical navigation will save the user time.
  
• Low Priority: Add a kerning in the Variant field, "Variant:1"should be "Variant: 1"
  
• Low Priority: Consider adding a mouseover effect for the character class type and character allegiance.
  
  While the names are super cool, I want to know more about what those mean. Sure, they might not have a stats effect -- but I don't want have to Google the game's lore to learn about what I'm selecting. 

Starting the Game

After creating your character, you appear in a space ship and can navigate with WASD. The game also clearly illuminates what items you can interact, as a 'W' appears above your character's head. Simple enough. But once I had explored the space station and talked to all the NPCs, I couldn't figure out how to get off the ship. I first went to my character's computer, which showed two location options: the Desolate Canyon and the Deep Jungle.

Since this computer was showing me where I could go, I assumed that the way to get off the ship was on this computer screen, and that 'Select' would display a 'Teleport' option.

This was not so.

It turned out that in order to get off the ship, I needed to go to what I thought was another computer, but was actually a portal. When I stood in front of it, it said 'Hostile Zone,' which I assumed (incorrectly) was some sort of multiplayer arena.

It was only when I selected 'Deep Jungle' that I saw the connection between the computer and the Hostile Zone machine -- when the Deep Jungle was selected, the screen's color changed from orange to green.

This led to my first death -- I teleported to the Deep Jungle, and being woefully undergeared, I died my first death. A horrible, terrible death. Alas, poor Bubba, I barely knew thee.

My next dozen lives were spent in the Desolate Canyon, and could be attributed to two things: me not understanding the level's puzzle traps, and a woeful lack of health packs.

For the latter, I was desperate to find health packs, but I couldn't find a way how. They were infrequently in treasure chests, and all of my attempts at alchemy failed.

What I discovered, through Googling how to get health packs, was that I was using the alchemy station completely wrong.

When in the alchemy station pane, shown below, the player is able to place three items in crafting slots, and then press the potion button in order to craft. When that happens, the alchemy pane shows a green bar, that swiftly decrements back down to zero, after which the crafting fails. What I assumed  was that I only had to press the potion button once, and that if the items were a viable combination, I would receive a potion. I wasn't sure what the green bar represented.

It turns out that the player needs to press the potion button multiple times in quick succession in order to receive a viable potion, if the player's recipe was correct. This process was not clear to me, not only because I wasn't sure of the green bar's purpose, but also because there was no notification telling me that my crafting had failed. As such, I thought I was putting in an invalid combination of materials, not engaging with the alchemy station correctly.

Screenshot with an alchemy station pane.

Once I knew how to create potions, the early game got significantly easier, and after that point, there weren't game elements that tripped me up.

Recommendations:

• High Priority: Consider changing how you display the progress bars for crafting.
  
  Currently, it's very unclear how crafting works from the existing visual language. While in retrospect the progress bar makes some sense, it is not intuitive enough to pick up without some explanation. One way to potentially make the crafting mini game clearer is to add percentages on the bar, and have the number decrease over time. That way, it's more clear that one must press the potion button multiple times in order to craft successfully.
  
• Medium Priority: Clearly display crafting failure from not getting the bar to 100%.
  
  This will help reinforce that the potion creation was not due to an incorrect material combination, but from player action.
  
• Medium Priority: Change either the teleporter's image or hover text in the space station.
  
  If changing the image, change it to the same planet icon used in the computer's planet selection page. But my recommendation would be to keep your formatting consistent. Since the teleporters at the end of each level have the next area's name as the hover text, I'd do the same here just to be clearer.
  
• Low Priority: Consider changing the layout of the very first Desolate Canyon trips so that the Tip text is to the right of the player, rather than under him or her.
  
  Because the tip text is below the player's avatar, they may be less likely to see it initially and will miss out on gathering materials until they spot the tip (this was the case for me). I'd potentially recommend making the very first part of the first canyon area lower down (so that they need to jet pack up), and then moving the tip text to the right, under the ledge so that there's better findability.
  
  
  
  

Final Thoughts

Roguelands is a thoroughly fun game, and I'll certainly be playing it in the future. Let me know if you get it -- the game has multiplayer! :) 

Explore, expand, exploit, exterminate -- Sins of a Solar Empire: Rebellion is a true 4X game. Released in 2012, the game still has a healthy following and mod community, with modders focused on changing the game's lore and maps to reflect Star Wars, Star Trek, Battlestar Galactica, Halo, Stargate... and more.

Overall, Sins is a solid game -- since I bought it ~three weeks ago, I've played 39 hours (thanks, Zeal, for the recommendation!). But there are certainly some usability elements where mods or game updates could make a difference.

Namely, Sins' issues rest in legibility, finicky notifications, and difficulty zooming into to planets.

Legibility

Sins, especially in the tutorial series, has an issue with font size. In this game, the yellow font color works both thematically (à la Star Wars) and practically, where other font colors may be difficult to read on a starry background. Sins' font size, however, is way too small -- to the point where the modding community has made mods to increase the font size. 

Recommendations:

• Add a setting in the Options/UI features to increase the font size throughout the game -- with except of sizes to the left of the world/ship/scuttling picture in the main UI bar (shown above). 

Finicky Notifications

There are many notification announcements in Sins. Notifications for combat, for successful planet exploration, for completed construction... and so much more. As such, the notification bar becomes overwhelming very quickly. In the tutorial, players learn that they can view more the most recent notification by hovering their mouse over the correct notification card (planet, construction, diplomacy, conflict) by left clicking, and that they can cycle through these notifications by left or right clicking. The issue is that because notifications come in so quickly (especially as you're expanding), it's hard to keep track of which notifications you've looked, and it's too easy to accidentally cycle past important notifications by clicking. Plus, it's easy to for a notification to "fall off" the queue (~10 are listed at a time) if there are so many notifications incoming at a time. 

And if the player wants to view the location of the notification's event (for example, completed construction), the player must press space bar to move the camera above the planet (not in planet-vision). This feels unintuitive -- for some reason, it feels like one ought to be able to double click on a notification to see its location, but that then cycles the notifications. 

While, over time, the player may become accustomed to the ebb and flow (well, torrent) of notifications, here are some recommendations for making the notifications less overwhelming.

Recommendations:

• Potentially lower the number of events that generate verbal notifications, or at least allow the user to specify which announcements they do/don't care about. For example, the announcement "Explorers have found natural resources on this planet" could be removed -- while sure, that's nice to know -- it doesn't have direct and immediate bearing on the situation. It would still be good to have in the notification frames, but doesn't need to be verbalized by the announcer/AI voice.
• Potentially don't allow users to open a notification frame by left clicking -- only allow the frame to open by pressing space bar. This would prevent players for accidentally clicking past the notification they want to read.
• Just as the planet icons flash when there's an enemy in your gravity well, it may be good to have other flashing notifications above planets (such as for construction). This may reduce the number of notifications that the user must interact with (so one doesn't need to open a notification pane to see where construction has just been completed.)

Moving the Camera

If there were one aspect of Sins I could change, it would be making camera transitions smoother. When interacting with notifications, such as "your planet is being attacked," the player can press space bar to then be brought to that planet. But it's quite difficult to shift between two planets that are under attack, or really just quickly zip from planet to planet to monitor their progress. For example, if two of your adjacent planets are being attacked, you need to scroll out, move your mouse over to the adjacent planet, and then scroll in. As such, it's difficult to micro-manage your own armies -- and when you need to spend so much time entering and exiting planet-vision, combat can feel tedious. 

Sure, the side bar (shown right) creates a way to quickly look at the number and types of units stationed at a planet, but does not make zooming in and out of a planet any easier.

In addition, it's not clear how to navigate a ship through a wormhole. On some maps, players can send their ships through a wormhole to travel to new galaxies. In order to do this, the player must navigate their ship into the middle of the wormhole (I found this out through the might of the Great Goog), and then scroll out to see adjacent galaxies. The player must then hover his or her mouse over one of the planets within a specific galaxy (no easy task), and then zoom in to individually select a planet to send their ship/s to. It's fun to expand to other galaxies, but it's a pain to have to scroll in and out of each galaxy (and then hover over a planet, then scroll back in, etc) in order to keep track of your empire.

Recommendations:

• Allow for easier zoom into a planet, potentially by double-tapping the space bar
• If a player has sent a ship to a wormhole, and then attempts to path it to a planet/star in a distant galaxy, automatically move that player's ship to the center of the wormhole
• Potentially make a way to quickly switch between planets -- so you press a key combination to shift between the last three planets viewed in planet vision

Final Thoughts

I took a week-long break in between starting and finishing this post because, as I've now learned, it's bad to over-play a game when you're trying to review it for usability issues. The more I played, the more I 'forgave' troublesome elements, and the less I saw them as issues. Sure, in any (well, most) program, a user can learn how to navigate the fiddly bits and overcome complicated usability aspects -- but that doesn't mean that the usability issues aren't there.

Well, I've learned my lesson. From now on, I'm not going to play more than three hours of a game before finishing a review. Or I at least need to return to writing it after some time so that my brain isn't as muddled with forgiveness. Or something.

Thanks again for reading! I hope you all had an excellent January, and are expecting an excellent February. 

In Shoppe Keep, an Early Access Steam game, you play as the main merchant in a small medieval town who sells a variety of goods to adventurers. Furnish your store, order and price goods, slaughter shoplifters (I paid good money for that Health Potion!), and craft new items to sell in the store. Since there's no (apparent) way to speed up time, the game is almost zen, as you must wait real-time for customers with creative names such as "Dick Butthead" to saunter in and purchase items. And, though I'll be covering quite a bit in this review, the game can be quite fun (and I believe has earned its 9/10 rating on Steam). 

The usability problems Shoppe Keep displays are inconsistency, legibility, a lack of 'guard rails,' and unexplained elements. 

Inconsistency

Probably the most inconsistent element of SK is its font usage. Playing through the game, one will see at least five different fonts throughout the various menus and text bodies. While font inconsistency doesn't necessarily make a game harder to play, it's good form to keep font faces constant throughout a product.

Another element of SK's inconsistency is that it breaks from traditional UI elements. For example, when the user first opens the game to input their Shoppe Keep's name, they see two buttons in the pop-up. But the left button, which reads "Enter your name," isn't a button. While it does give the visual clue that you can click on it, the format doesn't immediately read as "this is where you will be able to type in your name." Of course, once you click on the button, your typing cursor is shown, but up until that point it isn't immediately clear what'll happen once you click on the name button.

SK also falls into a familiar in/consistency trap --  re-using the same key to perform different functions. In SK, it's guaranteed that something will happen when the player presses Q, but what happens depends on which stance (combat, shoppe keeper, building, cleaning) the Shoppe Keep is in . So the fact that something will happen is consistent, but the effect is inconsistent.

While re-using the same key means that the user has to learn fewer keys and shortcuts, in the end it results in wasting some of the player's time. For example, one might be in the cleaning stance, and want to open the Order menu, but has to press (1) to change stances and then Q to open the Order menu. Sure, requiring two steps means that the user can't accidentally open the Order menu in combat -- but safeguards could be put in place such that the player is not able to open the Order menu while in combat.

Recommendations:

• Choose two fonts and stick with them. Use one for menus and one for text bodies. Make sure the fonts are legible (more on this later).
• Instead of making the "Enter your name" bit look like a button, make it look like a traditional textbox and have a flashing cursor in it. That gives a good visual cue without confusing the user as to why it's a button.
• Consider adding shortcuts to open menus, rather than having Q be the catch-all. For example, "O" could open "Order," "S" could open "Skills," etc. Allow these to be pressed regardless of stance.

Legibility

Now, this is a topic that I've touched upon in many a post. SK isn't the most illegible I've seen -- I think Karos Returns takes the cake on that one -- but there's certainly room for improvement. 

For example, one of the main font styles that SK uses is a white, old-fashioned font face.

My favorite part of this is that "greatness" is spelled "grateness."
Is grateness an excellent cheese grater? Who knows.

While I understand wanting to include a thematic font face for a medieval game, SK sacrifices clarity for theme. Written on a light-peach background, the font is very difficult to read. If the font were bigger, and the background a different shade, this might be easier to read. But I wouldn't advocate for keeping this font -- or the formatting. Light on light is difficult to read -- and when reading is the only way to learn the game (I'll get to that), the designer needs to make reading as easy as possible.

One other location where legibility was an issue was the Ordering menu (shown below). Showing the hands while browsing the menu is a cute idea, but the font angle of purchaseable items is hard to read. 

Recommendations:

• Ditch the light-on-light font. If you want to use a parchment look/feel, check out classic manuscripts such as the one shown here and try to replicate that feel
• I'd recommend also swapping out the old-fashioned font you're using in text bodies for something more modern. Sure, you're reducing some of the theme, but it's more important that your users can read. Using fancier font is fine for menu text (such as on the main screen)
• Don't use yellow as a highlighting -- or font -- color (as done in the tutorial text). It's hard to read on both light and dark backgrounds. Try a different color.
• Flatten the Order menu so that the font isn't angled. You can keep the clipboard look while still making the menu easier to read. 

Lacking Guard Rails

While trial and error is one way to learn a game, it's not always the best to let players fall into traps that they can only escape by restarting their saved game. 

For example, my first game, I didn't know I had to place furniture before I could sell items. So I used up all my gold buying items, and then couldn't actually put them down to sell them. I couldn't recover any of that gold, so I needed to restart the game. 

I was doing pretty well in my second game, and eventually had enough money to purchase armor. This time I knew how to place pedestals to display wares -- but the game wouldn't let me place the armor on the pedestal. I had, again, spent all of my money buying items -- and wasn't able to sell my stock. Fatal. 

In games with low stakes, it's okay to let players make these kinds of mistakes. But SK requires a lot of grinding to unlock new items -- so needing to re-start your game is devastating. 

Recommendations

For a game like SK, I'd recommend putting in what I'll call guard rails, or really safeguards against players making fatal mistakes.

One way that SK can address my first mistake -- buying items before placing furniture -- is to redesign the tutorial to provide context-sensitive tool-tips. As soon as the user loads into their first game, begin the tutorial, and tell the user how to access the build menu (and switch placeable items, which took me a long time to figure out). After they've placed furniture, show them how to open an Order, tell them about the wait time, and then show them how to raise/lower these prices. While all of this information is in the tutorial menu, walking the player through these steps aids learning.

Unexplained Elements

???

Maybe I didn't read the tutorial well enough, but there were quite a few parts of SK that I didn't understand. For example, what is the K bubble? There's already an XP bar, so I don't know what the K does. Is it related to my shop's appeal? How do I increase my shop's appeal?

WHAT IS THIS?

How do I get a cauldron to make new items? How do I get seed packs to grow my own plants to sell? How do I unlock new furniture so I can sell armor and weapons? 

What are skill trees, and why do I want to use them? 

Why do I want to do quests, and how do I turn them in? Are there smaller quests that I can do (that don't require crafting fancy items? That seems like a late-game quest). 

I think this is one of the instances where I could've browsed community forms or the related Wiki, but I prefer it when I don't need to do research in order to play a game. I don't like having to pop out of immersion to understand how to succeed.

Final Thoughts

Shoppe Keep is a fun game, with room for growth in how it teaches and displays information. I wish there were a way to speed up time (those customers walk soooo slowly!) or other ways to spend time when waiting for customers to appear. 

But before SK's final release, the designers really need to spell-check the game. There are a lot of spelling errors peppered throughout. For example, "grateness" should be "greatness," "aparently" should be "apparently," "cant" should be "can't"... there's just so much. My final recommendation to SK's team would be to go through all text with a fine-toothed comb and pick out all the spelling errors. Accuracy helps your game look polished and complete.

Apologies for the radio silence!

I've been busy this December, and really since late September, so I haven't had much time to write. Here's what I've been up to:

View from my desk.

I started a new job as a User Experience Researcher with Fidelity Investments in Boston in late September, so I've been busy learnin' and getting up to speed with a myriad of tools and methodologies. I've decided that UserZoom is annoying, and have learned that anything that can go wrong probably will when you're moderating or seconding usability tests. To be honest, being a Dungeon Master/Game Master for Pathfinder games taught me some valuable skills that I've been using in my professional life -- namely dealing with uncertainty (best laid plans and all that), improvising, devising creative solutions for complex problems, and knowing when to help participants and when to let them struggle.

Also since late September I've been involved in a performance called the Boston Christmas Revels. Today is performance 12 of 17. Over the last four days (12/18 - 12/21) we've had seven shows. I'm in the picture below (all the way to the right with the plank and a sweet bonnet.) We've been getting great reviews from the critics, so that's nice.





I've also been working on a board game in my spare time -- whatever and whenever that is -- and have been making decent progress on that. My friends and I have been working pretty steadily on it since February, but we're now starting to involve a graphic designer and potentially an artist starting in January. Here's a picture of a playtest below taken at the Game Makers' Guild in Boston a few months back. The game is a co-op, resource management, survival game set in the post-apocalypse that sets itself apart with its sheer difficulty -- similar to Pandemic, the game hard to win, but the struggle is part of the fun. Hopefully by summer we'll have a print and play version of the game available for the public to play. Right now it's paper prototypes and clip-art. If you're interested in learning more about the game, you can check us out on Facebook or Twitter.

I haven't had time for my other hobbies -- painting, namely, but also D&D -- but I guess that's the sacrifice for having too many other hobbies and obligations. Alas, alack.

I hope all of you are doing well, and that you're having excellent holidays. I'll be back to a regular schedule in 2016 (!!!). If you'd like me to test out any particular games, feel free to ping me on Twitter (@keshiekay). On the docket are potentially:

• Evolution
• The Magic Circle
• Offworld Trading Company
• Roguelands
• Shoppe Keep 
• The Talos Principle
• Fallout 4 

Or if you know any designers who might want some feedback, feel free to send them my way! I love giving feedback to those who are hungry for it.

Thanks again.

This'll be a different kind of post, so bear with me here.

I've started conducting user research for Idle Action Studios, the creators of Paper Shadows. After some discussion with the team, I decided to run some co-creation sessions to help make Paper Shadow's UI elements (of which there are few) more intuitive. This post is about the process and results of the co-creation study.

First, I'll give you some context about the game. Paper Shadows is a highly stylized and artistic platformer built in Unity where the player controls two characters: the masked character and the lantern-bearer. On its website, Idle Action Studios describes Paper Shadows as a game about "separation and reunion," a theme strongly supported in the game. In order to progress in the game, the player must frequently separate the two characters. The tall, masked character can jump much higher than the lantern-bearer, and so often must go ahead to activate levers so that the lantern-bearer may continue. But some platforms are only revealed when they are within the lantern-bearer's light radius, so often the masked character must return to the light.

In later levels, the player finds talismans, ability-giving items that the characters may carry and trade. Up until the introduction of talismans, Paper Shadows is simple -- the player is easily taught that the arrow keys and WASD control the two characters.

Talismans throw a wrench into the works: to access talismans, the player has to press and hold spacebar to open the talisman menu, and then use the arrow keys to activate, swap, or deactivate talisman abilities. The developers, knowing it to be unintuitive, asked for my feedback on the talismans. I decided to put together a co-creation session to help brainstorm a new UI for the talismans.

1. Research Questions
   The developers and I created a list of four research questions to better understand how players expect to be able to interact with the talisman menu:
• How do players imagine being able to equip/activate talismans?
• How do players imagine being able to swap talismans between the characters?
• What do participants think the inability to exchange talismans due to distance would look like?
• How would the participants show that only one talisman can be active at a time?
2. Acquiring Participants & Setup
   I gathered three participants familiar with platform games, gave them access to the demo level, and asked them to complete the first level. I also asked the participants to write down any "passwords" they saw in the level so that I could tell whether they completed the level (there was one at the halfway point, and one at the end).
3. Scenario Development
   To answer the research questions, I developed scenario-based tasks for the participants to complete. These were:
• You just acquired your first talisman. Is it automatically equipped to one of the characters? If not, what happens to it?
• The tall character has the monkey talisman, and you want to give it to the short character. How would you do that, and what would that look like?
• A character can hold multiple talismans at a time, but can only have one ability active at a time. How would you switch the active talisman?
• How would you visually display which talisman is active?
• Visually, how would you indicate that you're too far away to swap/switch talismans with the other characters?
4. Explaining Talismans
   Since I didn't want to explain talismans in the context of opening menus (how it currently is), I decided to use pens & pencils as props to explain how players can interact with talismans. 
• Giving/taking talismans: I gave one of the pens to a participant, and then took it back.
• Swapping talismans: I exchanged the participant's pencil for my pen.
• Talisman distance restrictions: I moved backwards and tried to exchange pens with the participant, but couldn't reach far enough to switch (and thus the exchange didn't happen).
• Activating talismans: I could hold many pens, but could only write with one at once. 
• Deactivating talismans: I stopped writing with the pen and went back to holding it.
5. Session Overview
   The co-creation session ended up being about two hours long and was conducted with three participants and one of the developers in attendance. I prompted the participants to draw their ideas on paper, writing down both what they thought it would look like and the buttons they would press to accomplish the tasks. At the end, I let the developer who attended the co-creation session ask additional follow-up questions.

Now for results. 

How do participants imagine being able to equip/activate talismans?

Scenario 1: You just acquired your first talisman. Is it automatically equipped to one of the characters? If not, what happens to it?

The players imagined that it would be automatically equipped to the character who first interacted with the object (pressed the down arrow/D key when next to the talisman). 

Scenario 2: The lantern-bearer is holding the bat and monkey talismans, and has the monkey talisman active. How would you activate the bat talisman instead? 

All three participants said that they would open a menu to change the active talisman. The three menu buttons they suggested were Tab, Spacebar, and T. Pressing this button would pause the game and add a faded overlay showing the characters with the talismans displayed horizontally over their heads. The players would then use the character's respective movement keys to navigate the talismans.

• Press Spacebar, Tab, or T (for 'talismans') as the menu key

• Horizontal bar with talismans

• Left/right keys to select a talisman

• Down (arrow or D) to activate a talisman

• Up (arrow or W) to deactivate a talisman

• Press the same menu key to accept the change and close the menu

Follow-Up Question: Would you want a way to quickly change what talisman is active?

Participants said no, they wouldn't feel the need to quickly change the active talisman. Since the game is slow-paced, they said they would not feel the need for some kind of shortcut to quickly swap/activate a different talisman.

One participant's sketch of the talisman menu

How do participants imagine being able to switch/swap talismans between characters?

Scenario 3: The lantern-bearer has the bat talisman, and the masked character has the monkey talisman. You want to swap these two talismans. How would you do that?

Participants would first open the menu to switch/swap the talismans, and then use the arrow keys to select what talisman they wanted to trade. The participants did not reach consensus on how they wanted to accomplish this, but some themes appeared:

• When choosing what talismans to send over, they use the arrow keys to highlight a talisman. The highlighted talisman would be the talisman that would be given or swapped. 

•  The 'highlighted' talisman could either by marked by a colored aura (glowing), raising the talisman above the talisman bar, or otherwise separating the selected talisman from the rest. 

•  The talismans would also be swapped by either pressing a specific swap key (such as T) or by using the arrow keys again to move it. One participant suggested pressing the 'up' key twice: once to move it above the horizontal bar to say that it's selected, and then using the 'move' key to give it to the other person. 

The three 'selection' visuals by participants

Follow-Up: Let's say the lantern-bearer had the monkey talisman active when you decided to swap it. Once swapped, is the monkey talisman now active on the masked character?

Participants said that a talisman, when swapped, would not automatically become active. One participant compared this process to World of Warcraft saying, "In WoW, when you trade a pair of gloves, it doesn't automatically get equipped when it goes in your inventory. You need to equip it." 

What do participants think the inability to exchange talismans due to distance would look like?

Scenario 4: The characters are too far apart to swap items. Visually, how would you indicate this?

Participants agreed that there would need to be a clear way to show that distance affects the ability to trade talismans. One of the first suggestions (before participants agreed the either Spacebar, Tab, or T would be good keys to open the menu) was that the menu could only be opened when the two characters were close enough to press their 'down' keys together. If the characters were too far apart, and X would appear.

Upon learning that the menu can be opened when the characters are apart, this simultaneous down arrow idea was scrapped.

How would the participants show that only one talisman can be active at a time on a character?

Scenario 5: The monkey talisman is currently active on the lantern-bearer. How would you visually indicate this?

In the talisman menu, all three participants agreed that the active talisman would 'glow.' Only one talisman can glow at a time. If a player highlighted another talisman and activated it, the previously-glowing talisman would stop glowing.

Outside of the talisman menu, participants said they would want a visual indication on characters what talisman was active. So the character with an active monkey talisman would have a monkey tail as part of its silhouette. If a talisman is not active on that character, there is no such visual indicator.

Recommendations:

1. Use the Spacebar as the 'talisman menu' key. It's a good mid-point between the two control schemes, and players can easily tap it with their thumbs, rather than reaching for the Tab. The 'T' key could also work. Let this be a 'press' button, not a 'press and hold' button. It's more easily discovered that way.
2. Display the talismans horizontally, rather than vertically. All three users drew out the menu this way, and said it was more intuitive than a vertical design.
3. Each talisman could have its own location (for example, the monkey talisman could always be the first circle). 
4. When a character is not holding a talisman, grey out its location. 
5. Use the left/right keys for each character to highlight various talisman slots.
6. Use the down arrow to activate a talisman.
7. Use the up arrow to deactivate a talisman.
8. When a talisman is traded, do not activate it on the other character, let the player decide what to activate or deactivate.

Since Blogger is bad at entering photos in between bullet points, here's a few images I drew out:

________________

Thanks for bearing with me, folks! This project was rather fun to undertake, and it's possible I may run another co-creation session in the coming months. It is still to be seen. 

I apologize that I've been writing far less frequently -- I started a new job in late September, and have been super busy since then. I'm also going to be in a play in December (17 performances, whee) so my blogging time will be limited then, too. I hope to return to a regular, bimonthly schedule by January. That's the goal, at least.

Thanks again to you, my readers, and to Idle Action Studios for letting me run the co-creation session!