Discovering Ways to Play - JWAW Ramblings #1

The goal of this (long, rambling, stream-of-consciousness) post is to bide the time while I work on actual updates to Journeys Weird and Winding by talking about my experience playing my own game, sharing some learnings that helped me enjoy the design process more and find the energy to get across the (first of many) finish line. I'll be releasing a Part 2 to this next week, diving more into the specifics of what I learned from play-testing the game and how I applied it back to the design. 

Playing Your Own Game

"Emergent behavior or gameplay" is a fun concept thrown around in the design space, whether it's games, websites or whatever digital, even analog, experience you're trying to put together. I was first introduced to the idea while studying user experience strategy in college, before I'd put any thought toward game design. It's the kind of idea that might feel obvious once you've heard it explained: you can't account for every way a user might interact with your experience. Once a game or an app is pushed out into the world, people are going to discover ways of using it that the designers might never have considered. This principle extends outside of the strictly "experience design" space; surfers first thought to pop a lime into bottles of Corona well before the brand itself caught on and started advertising that emergent practice as a product feature. 

So we know, and have known for awhile, that emergent gameplay is just a part of the process. It's one of the many reasons that play-testing is a critical part of the development/design cycle. You want to see what players do with the systems you've prepared, so you can fix or enhance the motivators for that play behavior depending on how it fits your vision. 

When it came time to begin play-testing Journeys Weird and Winding, I initially had that kind of player-focused study as my main, and really only objective. I wanted to see how players interacted with the game, what their pain points were, if it made sense, if they had fun, etc. What I was initially much less interested in was actually my own experience with the game. Given the small scale of the initial playtests I was able to organize, these sessions were all run with me acting as the GM. I imagine this is a position other first-time TTRPG designers may find themselves in, and it was one I started off resenting. 

I thought of my need to step in and GM the sessions as an obstacle, a confounding variable that introduced my own bias as the game's designer into the mix of player feedback. This is true in part, the game's beta (which it's currently in, woo) will be the first time I get feedback from GMs who aren't me. That's a core part of the experience that I wasn't able to get outside insight on before this period. 

But, experience running those sessions has entirely changed my perspective on that restriction. Yes, I missed out on early feedback from other players GMing the game, but in focusing on that I was also setting myself up to miss out on what I might learn from approaching the system as a player and not a designer. Starting off, all I wanted to know was what my players thought and whether they understood the system. I had presumed that, because I had built the system, I would understand it too well and didn't have anything of value to add during the play-tests. And then I went and played a few sessions... and I had a lot of fun. 

Not just fun in the sense of "it was exciting to watch players get hands-on with my world," thought it absolutely was, but fun in the way that I enjoyed running MÖRK BORG games or other systems from other designers. I was just enjoying the experience as a GM and I found myself actually playing throughout most of the sessions instead of observing. 

This gets back to one of the fundamental principles behind emergent behavior: the user experience cannot be simulated or assessed without users. In the realm of games, this is a reminder that the goal of a game is, by and large, to enjoy your experience playing it. Again, much like emergent behavior, this is a concept that's obvious when you say it out loud, but easy to forget when you're in the weeds doing the design work. This learning is touched on and explained a lot better in a recent Game Maker's Toolkit video that I highly recommend checking out. 

For me, my time actively playing the game – shedding my "I designed this" lens and just using the systems at hand to have fun – led me to realize that there was a critical aspect of the game that I hadn't taken the time to think on. Until I actually played it, I didn't know what made my game fun. 

Why Fun Matters

I felt silly just writing that. Of course fun matters. Why else do we make games? Why else do we even play them? One of those ideas that's so stupid obvious when you say it out loud, but so stupid easy to forget. 

Going into the design process for JWAW, I knew what I wanted to do, more or less:

• Make a game, for starters.
• Design a system that built on my favorite parts of MÖRK BORG and other OSR-likes while also fitting, both narratively and mechanically, into the original fantasy world of Vaream.

That was it, really.  I started there and focused primarily on fulfilling these goals that, in hindsight, are fairly limiting. The result was a way of working similar to how I felt when completing the first novel-length manuscript I ever worked on – all I wanted was to finish the thing. I'm sure plenty of other creators have felt the same way. What comes from this way of working is usually a finished draft, but more often than not the draft is at odds with itself. It isn't sure why it exists. 

This is why I'm thankful that I got the experience of playing the game myself, not just observing the reactions and collecting the feedback of other players. Until I was in there with the game, seeing my own mechanics in motion, I could tell you what I'd been trying to do with this game, but I really couldn't say what I'd actually done. I had a similar epiphany when reading back through the first draft of my still-in-edits manuscript: the story I'd set out to tell was only there to get me started, and something entirely new and stronger had emerged from it, hidden until I stepped back to assess the project from end to end. 

This experience was crucial because it empowered me with more than just the knowledge to explain what the game was to others, but also to return to the core systems with a significantly clearer understanding of what they should be coming together to create. The idea of game's needing a "core" is foundational to game design, and I've found it can be one of those "need this to start" things that newer designers – like myself – get stuck on. You have an idea for a game, a few mechanics, but everyone says you need to know your core and you just aren't sure, so you fret about it for ages instead of making the actual game. Of course, everyone doesn't work like this, but if you do it can be a fast track to analysis paralysis. 

What I can say is that you don't need to know everything to get started. You will likely get a little lost while putting that first version together, I know I did. You might forget why you're making this game, or what makes it fun. You may very well have nothing approaching the "core" that you're supposed to be building around. That's okay. Finish something and play it, not as a tester but sincerely as a player. Look for what makes the experience enjoyable, even if it's by and large not refined enough to be that fun yet, make the effort to notice when something clicks. It might not be what you expected, you might stumble on the heart of your game lying miles away from where you thought it would go, but that's just how this process works. Creativity is a lot of stumbling around until you aren't anymore. I don't have a better metaphor than that. 

Don't let your players have all the fun messing around and discovering what's actually fun about your game, get in there and break stuff.