Design

After completing and releasing my first game, Monkey Game, I immediately set my sights on something larger, a frog raising game with a unique genetics system. I worked tirelessly, implementing a variety of features and getting the genetics system working.

However, after completion I ran into an issue I had never considered before. It wasn’t FUN. I had gotten so caught up in trying to get it working, that I had forgotten that I wasn’t making this game to function, I was making it to be fun. The project was doomed.

This is the most important lesson I have learned in my game dev journey so far, there is no point to complicated features that serve no purpose. And player experience has to be considered from day one or your project will crumble.

When creating my first VR game, Project Blue Book, I had the plan of the demo level taking place in a dark forest from day one. My plan was to lead the player around the map, with them discovering a new thing of interest to photograph every few hundred feet. Being led straight to each one with sound and visual cues, as well as the players Geiger counter.

I ran into a now familiar issue though when I ran this scenario through my head, it wouldn’t be fun. There is nothing interesting about walking through a forest for 20 minutes just waiting to get to the next thing. You could also see so far in front of you that whatever it is you were looking for would be visible long before you arrived to it, ruining any mystery.

I researched a variety of solutions in attempt to solve this, putting off designing the level until the last few days of the project while I tried to find a solution. I experimented with fog, movement speed, and watched video essays on “walking sims” in an attempt to make gameplay more engaging.

What I realized though, was that I was trying to bend over backwards to accommodate this setting that honestly, was just not going to work for the way my systems were designed. Mechanics like the Geiger counter were fun pinpointing hidden items in a small range, not vaguely leading you in a direction. When I took a step back and realized this, I quickly redesigned the entire level to be set in a cave, exploring in the dark for mysterious alien mummies, thankfully, saving the game. Making play testers feel engaged while playing and satisfied after.

When helping create Temple of Xibalba for the MSU Spartasoft Prototyping team we ran into an issue. Being the prototyping team, we had a limited amount of time to work on the project. Complicated systems like procedural generation for the dungeon were not feasible within our scope, leading us to hand place the rooms.

This brought up another interesting issue, runs were always the same, if you memorized the layout and enemy positions you could breeze in and out without a sweat, making gameplay only really fun the first time.

Our solution to this was too “fake” the randomness normally achieved by procedural generation, by having podiums, enemies, and relics spawn at a certain number of preset points.

When playing, players are led to different parts of the dungeon on each run, and experience unique enemies and podiums along the way.

This taught me a valuable lesson about time management, the scope of your project is important, and if an extremely complicated system can be faked with a simple script, then it should (at least at first).