Project "Nonfi Nis", Week 57

For several years I've been teaching students about the user-centered design process, which is essentially turning the coding nerd's approach on its head. I know from personal experience how tempting it is to jump right into the technical part - to try out all those shiny toys, solve the tricky mathematical problems below the surface and make the user interface pretty. But there are two main problems with this approach.

When you're a computer geek, it's so easy to forget that most people are not that geeky. Take my mother for example. When I was a kid, I thought she was similarly comfortable with computers. After all, she was playing Mah Jongg so often, so she had to know how it worked, right? Yeeeeah... eventually I learned that she only knew how to click on the pieces to make pairs, and how to start a new game. She didn't know how to use any of the helper functions hidden in the menus. In fact, she didn't even know how to launch the game or how to quit it - my father had set up it up to launch when the computer had booted up, and when my mother was done playing, she just turned the power off.

When I first learned coding as a teenager, I produced a number of little games that nobody else ever played. Let's just say, some of them had overly complicated control schemes or required a ridiculous amount of precision. And apparently, that's a common phenomenon - software that can only be operated by those who built it. Not really ideal for a game, unless you plan to follow in the footsteps of the Myst series.

One other thing that I've seen way too many times is projects that evolve into grotesque mutations of the original idea. Pieces of software that look okay on the surface but are a mindboggling mess behind the scenes, because people kept grafting on stuff without ever taking the time to plan ahead. Cool demos that never turned into an actual tool anyone could use, because the bugs kept piling up as the programs got older.

And yes, way too many times I've been one of the coders responsible for this mess. Oh, there were always "good" reasons for it - a deadline to meet, a necessity to move with the times, budget to spend on new devices before the year was over. But it's deeply frustrating in the long run - all that work done and nothing to show for it in the end. Sure, you may impress some people for a short while, but eventually you shove that abomination into a ZIP file on a backup drive where it can't harm anyone.

Now, between 2017 and 2020, I've started familiarizing myself with the Unity game engine. I've also gone on several shopping sprees whenever there was a sale at the asset store, and by now I own a lot of useful plugins that I plan to use on the games set in my Kaleidoscope world. I've had fun playing with procedural level creation, weather simulation, dialogue trees, various A.I. frameworks, character configuration, shader design and space ship piloting.

But in the end it was just that - playing. All the things I've made so far are technology experiments - sure, they may be good for learning, but they are far from being an actual game. And most importantly, they won't help me answer the big questions that stand between me and my vision for the game, like:

• What is the story about?
• What reason do the characters have for doing those things?
• What is the player doing to progress?
• What does the player get out of it?

This is why I want to take the time and plan things properly this time.

About two weeks ago, something else happened. I logged in to my itch.io account in order to download a game that I had bought a while back - and before the day was over, I found myself participating in a game jam. Remember what I said about distractions some posts ago? There's usually something inside them that I can use for the "real" project. So let's see what I got out of that experience.

When itch.io greeted me with lots of helpful recommendations for game jams, my first impulse was to feel mildly annoyed. I've got a full time job and the Nonfi Nis game in the works, so why would I waste my time on that?

Then my mind connected the dots. Why did I do cheap OC-tober sketches a while back? Why am I participating in many worldbuilding challenges that WorldAnvil hosts, even if the prompts take me away from my actual ToDo list? The answer is: Because it's challenging me to actually finish something in a short time frame.

If I'm being honest with myself, Nonfi Nis is already evolving into quite a complex project of its own, despite being intended as a simple practice piece. It may no be the enormous task that my main game will be, but it's still quite ambitious. So much bigger than the cute little games which teenage me coded in school... and which I happened to stumble upon just a few days earlier. Cue the nostalgia. So maybe making a small, unrelated game was not a bad idea after all.

I found a game jam that caught my eye - the Narrative Driven Jam looked like it would fit in perfectly with the things that I wanted to practice. And it was starting just that evening. I argued with myself for a few hours, then I joined.

The jam's main theme didn't really fit my Kaleidoscope lore, but that was just fine. Less at stake, then... I also couldn't use any of those neat toys that I had bought from the asset store. Well, technically, it was allowed to some degree, but I didn't feel like that was in the spirit of the jam. I figured that using Script Inspector for the coding (and Magix Music Maker for the soundtrack) was as far as I would go.

The main theme was "magical realism", with optional themes being "lying on a bed of stars", "memories" and "pizza lover". My brainstorming resulted in a story of someone recovering their lost memories from the star that is made of them. I won't say much more here, in case anyone wants to play the game first.

After I had my plot and protagonist figured out, it was time to look at the other side of the screen - what does the player do, and how can I make that part enjoyable?

The jam went for ten days, so I didn't have time for a complex, branching storyline. That ruled out the usual point-and-click adventure for me. So what could be the alternative - something skill-based? Reaction-based? Time to dig for inspiration - and here's what I unearthed:

• The game "Fahrenheit", also known as "The Indigo Prophecy", features several sections where the player has to solve minigames so that the character remains calm.
• Due to my research, I'm highly familiar with dimensional emotion and personality models.
• From my own battles with depression, I know how overwhelming emotions can be and how important it is to center oneself in order to keep functioning.

Taken together, this led me to my game's core mechanic. Whenever the player needs to deal with a memory fragment, a matching emotion is shown as a dot in the valence-arousal space. To progress, the player needs to return that dot to the center and thereby create a neutral emotion state. And to make things a bit more challenging, I decided that the dot would keep trying to return to the emotion's position, but loose strength with every moment that it was kept in the center.

Now, I'm aware that this is not a perfect metaphor. It does look somewhat like the player was repressing the emotion, when in reality it is much healthier to acknowledge it and left it drift away. But on the other hand, passively watching the emotion fade did not sound like something that I would enjoy as a player. Theoretically, the button mashing for centering the dot could also represent the need to actively focus on one's center, like paying close attention to one's breath. But in the end, I can't tell how many players are actually familiar with techniques like that. All things considered, I think this mechanic is a good compromise between something that's playable and something that fits the topic.

With that I had enough to create a first working prototype. I implemented the movement of the dot based on the two forces - emotion and control input - and added a postprocessing effect that blurs the image based on the distance from the center. The latter was meant to help the player notice when they were getting closer to the goal, and also represented how the emotions kept the protagonist from thinking clearly.

Once the coding for this mechanic was done, I felt quite proud and already saw myself re-using that mechanic for appropriate situations in the Nonfi Nis game later. But now it was time to put this idea to the test and see if it met my expectations.

I sandwiched this minigame between two halves of a dialogue scene, published the prototype on itch.io and tweeted about it to invite people for testing. Unfortunately, I did not get any response, so I did the next best thing and tried to put myself into the players' shoes. And I noticed something disturbing - I was not looking forward to playing a game that solely consisted of linear dialogue and this emotion mechanic. Well, damn.

So what was missing? The biggest problem seemed to be that it felt like watching a movie - with commercial breaks that had to be fended off by button mashing. Huh. Eventually I figured out that I would prefer to move through the environment and have more varied things to do. I began looking for ways to add that, but the short time frame kept perching on my shoulder and most activities that I thought of threatened to distract from the actual story.

Finally, I remembered the question that came up when I sketched the plot: What prevented the protagonist from flying straight to the star and retrieving the memory? And my answer was that whenever a memory is added to the star's mass, it drifts in the direction of the emotion attached to the memory. Eureka! This gave me the second minigame idea - chasing the star through space with a control scheme that was similar, but not quite the same.

Now, this is where the aforementioned experiments in Unity came in handy. Back when I toyed around with Ycalla flying through the Kaleidoscope system, I was confronted with a lot of problems that I now knew to avoid. Problems such as the lack of friction, the impossibility to create space-scale environments in Unity's regular coordinate system, and the tendency to get very, very lost in a vast 3D space. But I also remembered one other thing that I tried out with Ycalla - restricting movement to a sphere around a planet. That was the perfect starting point.

So I decided to turn that idea inside-out and have the spaceship move on a spherical surface. Which was very straightforward to code - I put an empty game object at the center, attached the camera and the ship to it and moved them down by about a kilometer. Then all I had to do was rotate the root object around two axes, based on the WASD input. The trickiest part was locally rotating the ship to match the movement direction.

Likewise, anything that the ship needed to hit was placed on the same sphere with a different initial rotation. But even with limiting movement like this, it was still easy to get lost - and according to the feedback that I received later, many of the other jammers did. I did add some hints, like placing targets juuust within the field of view to make people curious, or leaving a particle trail behind moving targets, but it seems that these weren't enough. Which further proves the point I made at the beginning of this post - just because something looks obvious to the developer, it's not necessarily so for the user.

The really interesting part began after the submission phase ended - when everyone caught their breath after rushing to finish their own game, and sat down to play and give feedback on the other entries. And gosh, there were so many wonderful games to discover...

I got some really encouraging feedback for my entry, which makes me feel way more confident about tackling my "real" projects. But most importantly, I finally learned what people thought of the game mechanics, what they found confusing and how it could be improved. I made a list of the things that need to be repaired, and will give this game at least one major update now that the rating phase is over. A detailed breakdown of the feedback and my plans for the update can be found here: What I learned from the jam

Another thing that I'm taking away from this jam is how quickly I grew attached to my protagonist. Over the course of those ten days, I've sent Pat on a heartwrenching journey with a satisfying conclusion. I set up facial expressions and body postures to show people what was going on in Pat's mind, and had to keep myself from tearing up in the process. Right now, I'm not feeling that attached to the Op family - but it looks like that will only be a matter of time. It's already starting, now that they have proper character articles and backstories.

Coding stuff without a plan may be fun at first, but it causes more problems down the line. It's also easy to forget that the players do not have the same background knowledge as the programmer - and I've seen this confirmed with my entry to the game jam.

The jam as a whole was a great learning experience. Not only was it rewarding to see a project through from start to finish, it was also a great opportunity to learn what works and what does not - either from feedback I received for my own game, or from giving feedback to other participants. And seeing what is possible in 10 days really helps to make the task before me less daunting.

I plan to take part in other game jams in the future, and will also try to prototype some stuff for the Nonfi Nis game soon - just to have something out there that I can get feedback on. It will probably be something related to dialogue, and maybe I'll already find a way to plug in the emotion mechanic that I made for the jam. Or maybe I'll focus on how the characters will express their emotions, so that I'll form a better bond with them? ... Or both?

If there is anything in particular that you would like to see, just let me know!