t was the Thursday morning of PAX East, right before the show was to open, and my anxiety was starting to spike.
PAX has always felt like the big leagues of game conventions, so getting our humble indie game accepted into the PAX Rising showcase was both an immense honor and incredibly intimidating.
Our PAX Rising kiosk before the show opened.
And here I was: nervously standing at our kiosk, waiting for Thursday’s attendees to start pouring into the expo hall. The rest of the team and I spent the past month and a half intensely polishing and bug-fixing the demo, but was it enough?
I didn’t know what to prepare myself for, but I surely didn’t prepare myself for this: the overwhelmingly positive response we got from attendees.
So many people had such kind things to say about the game, and the vast majority of players played the demo all the way through to the end. There was almost always someone playing the game, and on PAX’s busier days, we would have a line several people deep.
After watching several people playing — and enjoying! — Lexa, I let out a huge sigh of relief. We had a game people liked! Hurray! With my anxiety dissipating, it was time to focus on getting the most out of exhibiting at PAX as possible. Like I mentioned in my post-EGX write-up, demoing your game at conventions serves two primary purposes: promotion and playtesting, so let’s dive a little deeper into how we strove to accomplish both at PAX East 2026.
Promotion
Exhibiting at PAX is obviously a huge opportunity to get the word out about your game, but having a booth at the show is just step one. You have to make sure people actually stop and play the game. That’s where great booth art comes in. PAX Rising was kind enough to print standees for all of the games in the showcase; all we had to do was provide the assets. And I think our key art does a pretty good job at catching people’s attention.
Our custom key art for our PAX Rising booth.
Once your signage gets an attendee to stop at your booth, they usually try to glean some information about the game by watching someone else play, but if the game has interested them enough to stop them in their tracks, they’re likely interested in hearing your pitch.
And when you’re demoing your game at a show like PAX, you end up saying your game’s pitch a lot, so much so that you just automatically start refining it as the show goes on.
Quickly, my pitch for attendees became some variation of:
Project Lexa is a sci-fi language mystery. You play as a communications officer whose ship crash lands on an alien planet. You find that everything on the planet is written in a glyph language you don’t understand, and it’s up to you to translate these glyphs and discover what happened.
Plenty of this language is taken straight from the short description on our Steam page, so this framing came easy. After giving an attendee the elevator pitch, I usually left it open for them to ask any questions or otherwise continue the conversation.
[H]aving a booth at the show is just step one. You have to make sure people actually stop and play the game.
At this point, a lot of folks — if they were familiar with conlang games — brought up Chants of Sennaar, which is a game I was more than happy to be compared to! But I also took care to highlight what differentiates us. For example, Chants of Sennaar allows you to record only a single translation for a glyph at any given time, so entering an alternate suggestion for a translation means deleting the existing one. This removes the opportunity to hold onto several possible translations to compare and contrast until you’ve discovered the correct one.
We wanted our translation system to be more open-ended, so I drew inspiration from other types of puzzle games, most notably the increasingly popular subgenre of “notebook games” — games like Blue Prince or Tunic or Outer Wilds that give you a vast amount of information to remember, so most players tend to play with a physical notebook beside them to record information. If an attendee was familiar with notebook games, I usually hit them with this additional pitch:
It’s a notebook game where the notebook is built into the game.
And that definitely lit some eyes up. I always figured there were players like me that liked the idea of a notebook game in theory but didn’t particularly enjoy having to maintain their own handwritten wiki. As a player, I’d rather focus on the more interesting parts of those types of games — using my collected hoard of information to problem solve — then be tested on my ability to keep notes. And obviously games like this exist already: The Rootrees Are Dead is a perfect example of a “notebook game with the notebook built in.”
Another differentiator for Lexa that I was keen to mention was:
The game never tells you if your translations are correct. Only by continuing to progress through the game do you know if you’re on the right path.
This got a lot of nods too. There was clearly a lot of love for other games where translation was the primary gameplay verb, but there is a desire out there to have translation gameplay that is more open-ended. That’s what we’re striving for with Lexa: giving you all of the tools inside the game without pressuring you to use them in a specific way.
At this point, an attendee usually had enough information about the game to determine if they wanted to give the demo a try, and they would jump in line. Once they started playing, we focused on our other PAX goal: playtesting.
Playtesting
One of the biggest takeaways from watching people play the game at EGX was that the game simply needed more polish. But not just any type of polish. I’ve started to mentally separate polish into two categories: aesthetic polish — art, animations, and audio that is used to increase the production value of the game — and functional polish — art, animation, and audio that improves gameplay or user experience.
A side-by-side comparison of Lex, Babbitt, and Boltzmann standing in front of a forcefield after the ship has crashed. The top image is how the scene looked at EGX, and the bottom image is how the scene looked at PAX. Note the damaged ship decals, new forcefield art, and the subtly darkened lighting in the PAX version. These are all aesthetic polish changes.
An example: for PAX, we added more aesthetic polish to the ship’s post-crash state such as damaged decals to the walls and floors to better communicate the state of the wreck.
This is good polish to have, because it makes the game look better and gets us closer to our final vision for the game! But nothing about how the player interacts with the world has been improved. By adding functional polish, you have an opportunity to add clarity to the player experience.
A good example of some functional polish is a little feature I added a little while ago I call prompt tabbing. In Lexa, any object that’s able to be interacted with will show a prompt above itself if Lex is inside its trigger box, but a problem occurred when multiple trigger boxes overlapped with each other: our interactable system didn’t know which prompt to prioritize, forcing any active prompt to stay active for too long and any subsequent prompt to appear for too short a time.
To alleviate this problem, I modified the system to allow the player to switch between interactable prompts whenever they’ve intersected with two or more interactables. This is not a core feature; the fundamental gameplay experience doesn’t change much from its omission, but its addition allows for better player flow, since players don’t have to constantly reposition themselves to make the correct prompt appear.
A GIF of the prompt tabbing feature in action. Lex is positioned between two medbay lockers she can interact with, so the player can use the minus and equal keys to switch which prompt is active and therefore determine which object they’ll interact with.
We focused on adding little bits of functional polish like this across the game before PAX. Most of them were to address points of friction I observed from playthroughs at EGX. Did PAX expose any new points of friction that need to be addressed? Absolutely.
Let’s talk about stairs.
Stairs in a 2D game are pretty simple: they’re usually just a ramp collider that you layer a sprite overtop of to give the illusion of a staircase. If you just have a single 2D plane that only goes left to right with no intersecting elements, then you just add your stair-ramp to your level and you’re done
But in the ship’s crew quarters, we decided to be a little fancier: we created switchback stairs that have the player ascend the first staircase normally to a landing, crossing in front of a second flight of stairs, and then doubling back to climb up the second set. But how does the game know if you want to ascend the second flight of stairs or walk back across the landing? The system we built is aware of how you’re moving — either horizontally to cross in front of the stairs or diagonally upwards to ascend.
Lex standing on the middle landing of a switchback staircase. Note the prompt to help direct the player up the top half of the staircase, which shows a thumbstick prompt with an up arrow.
I always thought this system was pretty intuitive — I first saw it utilized in Mae’s house Night in the Woods — but when helping on the game, Heather Flowers convinced me that we’d at least need a prompt to communicate this functionality to players. So I added an interaction prompt that simply pointed up as opposed to specifically upwards diagonally, assuming that players would understand it well enough until I added a more specific prompt later. That assumption was… poorly founded. Over the course of PAX, I saw so many folks get stuck on navigating this single flight of stairs. With the thumbstick prompt pointing straight up, most people just held their thumbstick upwards, assuming it would automatically walk them up the second flight.
Most players figured it out eventually (others I had to explain what the prompt was communicating), but it was still causing too much friction to leave it as is. Developing a game is mostly just a giant todo list of features to build and bugs to fix, ranked by priority. Over the course of development, as tasks are completed and playtests are observed, the remaining work gets reprioritized. Updating the stairs prompt has been a rather low priority on the ol’ todo list, but it has shot up the list quite a bit in light of the playtesting at PAX.
There were additional small points of friction that popped up over the course of the show, and it’s another reason I’m grateful about showing at PAX: you’re exhibiting your game to so many people that patterns quickly emerge, showing you the common pain points to address.
Overall, showing Lexa at PAX was an incredible experience. I was so happy at the positive response, letting us know that we have something really special. I want to thank PAX Rising for selecting us for the showcase and for all of the attendees that stopped by the booth to try out the demo!
Thank you to my friends and colleagues that helped out with the Project Lexa booth: Seth Rosen, Pat Brennan, and Shawn Dermer. Additional thanks to Seth who gave me tons of amazing design feedback before and during the show that I’m sure keen on incorporating into the game!
And of course, thanks to everyone on the development team that helped get the game PAX ready and added a whole bunch of extra polish — aesthetic and functional — to the build: Nick Nazzaro, Chris Lucca, Chris Marcon, Jaime Ugarte, and Nelson Johnson.
Now it’s time to rest and recuperate from all that hard work and travel so we can get back to working on Lexa!
