Factors of Fun in 48h

I just completed my obligatory post-jam pint of ice cream, and I think a development log is in order. My thoughts may be jumbled. It's been a lot of typing over the last couple days.

The setup

Recently my friend showed me old VHS tapes of Anne of Green Gables, a series adapted from the books. In it, the protagonist, Anne, is a linguistic architect and poetic genius, her only flaw is growing up an orphan. One such phrase of hers in response to some sort of denial is that she finds herself in "the depths of despair". My friends and I would joke about how dramatic Anne was, and some of the lines stuck.

While I've been playing around with some custom game engine frameworks, I thought it would be best to use Unity for the jam not only because I have more experience with it, but also for the level of certainty that the builds would run on most folks machines.

Design phase

Being a 48 hour jam, a lot of the design work tends to happen on the fly, at least in my experience. Still I like to build a picture in my head of what at least some of the game will look like. In this case, I've uploaded some of my preliminary sketches below:

The premise would be that you arrive on an island and descend deeper and deeper into a dungeon solving puzzles, fighting monsters, and who knows what else. If you can think of a more ambitious premise for a 48 hour jam, please let me know. Apparently it's kind of my thing.

Postmortem

It's funny in that the sketches form a remarkably consistent storyboard to what is in the game now. If I was rated on how well I was able to transform these squiggly sketches into a piece of 3D software, I'd give myself an A+. However if the grading was on more common terms, like how entertaining, fun, engaging, or challenging is the game, I'd probably give myself a D at best. While I'm happy of the visuals and even some of the music, I am conflicted about how the combat feels off, and the boss is easy, and the only puzzle in the game is barely even a puzzle.

If I could do things again, I would pick one item below and focus on it:

• Boss fight - develop a single arena, and improve things like telecasted animations, audio cues, etc. One of the failings with the boss in the LD48 version is that it's flat. It basically has one move, and that's it. If I focused just on the boss interaction, I could have implemented multiple phases and move-sets.
• Mob combat - I thought mob combat was fun when I made my first pass on it, which literally was all of Saturday. Today, after playing through the boss, puzzle, and island areas, I've come to find the mob combat a bit clumsy. I think a little bit more tuning, and perhaps a bit more redesign of the room itself, or a sequence of multiple rooms could go a long way. One thing I do like about the mob combat room is the way the central column is used in multiple positions to trigger different phases of the level.
• Puzzles - Lighting torches can only go so far. Perhaps the fireball could be used to push buttons or burn ropes. I think that a sequence of 3 or so puzzle rooms with a degree of polish and progression, would be better than the jam build as is.

Why I chose such a diverse range of mechanics to develop, still baffles me. Still, at the core of it, is the fireball throwing mechanic. I do like how that single mechanic can be used for both puzzles and combat. I think one additional item I didn't think of is story / character development. For example, aiding in the creation of a campfire, or lighting the torch for a fellow explorer.

I know that what tends to win in these jams is games that are highly focused and well tuned. It's a goal that I had at the start of the jam, but pushed aside with ideas of cinematic grandeur. Maybe in the next jam I can keep some of the cinematics, the graphics, even the audio, that I love to make, and focus it into an even tinier realm of play.

Factors of Fun

I've been thinking a lot lately about the distinction between work and play, game and toy, and the very definition of fun. While I am still a novice, I feel I have some clarity from just completing a jam, so below are some unstructured thoughts.

Play and fun are not necessarily attached at the hips. One can have fun at work, but that does not mean work is play. Work is something we must do, while play is something we opt to do, and could certainly survive without. Still play brings about a state of mind, which without being exposed to, can lead to a decline in one's quality of life. Besides we all know that all work and no play makes Jack a dull boy.

As I go through my levels and play test, the mindset I strive for is that of a child playing with a toy. A toy ought to feel sturdy, such that it can take a fall or an unexpected tug. And so a game ought to be bug free for a variety of different play styles. A toy is often colorful, and it's aesthetics are a strong selling point. Often for very young children the purpose of the toy is largely it's aesthetics. As we get older, perhaps there are certain advanced affordances we seek in a toy, like construction, role play, racing, etc. A toy should be comforting, something we like to keep with us, even if that means to the restaurant, where it may suffer some food stains, or to the fields, where it may get dropped in mud. This is why it is important for games to be sensitive of jarring sights, sounds, or unexpected reactions to input. Even in a horror game, where the purpose of the game is often to make the user slightly uncomfortable, this is done in spite of great ui / ux design.

In line with the toy philosophy, there is no loss condition in Depths of Despair, although there is a debug statement to the effect of it. Mainly for time purposes I decided to leave out a game over sequence. I also didn't have time to thoroughly tune things to the point where the amount of lives the player would have would be appropriate for a broad range of players. So I decided to keep things toy-like, or even movie-like, where the goal is just to get through the experience, and no matter how much damage the player takes, they can also see it through to the end.

The process

I think the visuals were a big focus, and naturally they were the first to be developed. Below is the first render from a fresh Unity project, testing out surface shaders, lighting model, and outline effect. I knew I didn't have time for detailed models or textures, so I opted for very simple shapes, and a strong outline shader to clarify edges and depth.

Then, I knew it was time to get to work on gameplay, and trying to make something fun. So I started in the middle with the mob level. I figured the puzzle would be a piece of cake and I could save that for last, and the boss would be basically an extension of the mob combat. I was right in the relative difficulty, but miscalculated the overall difficulty to make these items great.

In an earlier concept of the mob combat room, the stairs were located in the center, and the button was at the start. I later decided to try putting the button in the hole in the second floor. Then I realized I could lower the button as though it were an elevator and button combined in one. Thisf it well with the design philosophy of using minimalistic input scheme.

In designing the combat, I was hoping to achieve something fun with a very simplistic model. The bots basically look for the player, move towards the player, and eventually pounce, all with varying speeds. I think one of the challenges in coding this was the ugly lump of a state machine I was using to code the things. State timers, and speeds set all over the place. There has to be a better way to design / visualize these kinds of state machines. Maybe it just takes more practice, or maybe some sort of written language could help. I think the ideal solution would be a node editor. May be a good side project for the future...

As mentioned before, all of Saturday (aside from look dev) was spent on the mob combat, and the first part of Sunday was designing the boss. Technically the boss's state machine is so similar to the mobs that it's not really worth going into here. Just that the animations and numbers were slightly different.

Finally it was puzzle time. This was exciting because it was the first puzzle of the sort I designed. It was stupid simple, a basic mapping and sequence puzzle. For the record this is basically how half the puzzles in Uncharted work. There's a key somewhere (on a wall in my case) and several interactable items that need to match a key, sometimes done in a certain order. Fortunately the underbelly of code was sturdy enough to support this additional piece. The fireball code is kind of funny, but surprisingly simple and powerful. As mentioned above, I'd be curious what other puzzle mechanics could arise from the fireball / and physics systems.

Last but not least was the Island. I thought to save this one for last because it was mainly static geometry, with the only interactable being the portal. However when I originally designed this, I thought the portal would be hidden on the island, a sort of scavenger hunt. Then in a flash of brilliance I wondered, why I would bother obfuscating the path, if my intention was to have the player be able to find it instinctively? Rather than letting the player wonder off into who knows where, I decided to put big bold markings on the ground with arrows screaming go this way ! It's such a simple device, but let's remind ourselves that AAA use arrows all the time. Whether they are in the form of fancy way-finders in Mass Effect, maps in Borderlands, or literal arrows on the ground in Bioshock Infinite, professional games have a tendency of making these navigational cues impossible to miss. Still it is worth noting that this kind of thing should not be overdone. If the whole game has this kind of markup, the game becomes super linear, and like a big game of connect the dots, Use sparingly !

So that's about it. Once I had the 4 main areas set up, I had a couple hours left to clean things up. I allowed transitions between scenes, in a relatively ungraceful manner, but it works... I added a settin options screen to allow players to tweak volume and sensitivity. I was even able to add in gamepad support, since again the control scheme was very simple requiring only look, move, and action. A dozen builds later and we have a final candidate. I learned a good bit of design from this, and while still not convinced that this is the best a game could be, I know that I gave it my best.