Devlog 3/31/18 – Radial. Menus. Pt 2 // No Weekly Devlogs

Single-player games have plenty of advantages over multiplayer games in terms of design – one of my favorites of which is the freedom to mess with simulation speed (or time scale) to help control the flow of gameplay. Slowing down a game can help players through difficult sequences, inform them of critical situations like low health, or just show off cool moments with a “slow motion” effect. The Witcher 2 comes to mind – time slows down while the player switches weapons and abilities – because the combat is so fast-paced that the player could easily die while trying to make those decisions in real time.

Unity 3D 01.06.2018 -


A game with free-running elements and several abilities (many of which are necessary for survival or reaching certain areas) is a prime candidate for the same method that The Witcher employs. The only issue I found with the slowdown while using the menu in that game was that I would often bring up the menu just to watch enemies and predict their actions. It gave me a leg up in deadly situations but it felt a little like an exploit to look past the menu and use the time scale manipulation as an extra ability in itself.

Well, that (hopefully) won’t happen in The Seeker, thanks to a brutally blurred-out main camera while the menu is open! Obviously testing will show whether coming back to the game after using the menu is too tough on the player… but it may solve the time-manipulation-as-an-ability issue. In any case, I like the attention that it draws toward the menu.

Unity 3D 01.06.2018 -

Unrelated but relevant: level design and world building being pretty time-consuming means weekly devlogs don’t make much sense for the time being. Stay up to date with fresh gameplay screenshots and gifs every Saturday on Twitter! Devlogs will feature substantial development updates only but this way I should be able to make them more in-depth.



Creating powerful experiences requires
studying life
to find meaning
to build challenges
to inspire action.


You’ve landed on my portfolio website. Use the menu button in the top-left to view my past and ongoing projects!

Devlog 3/3/18 – Radial. Menus. Pt 1

After figuring out the way that the player will unlock new abilities in The Seeker, I had to take a fresh look at my placeholder system for selecting abilities (using the d-pad to cycle through them) and due to the fast-paced ability switching that will need to happen, I landed on the idea of using a radial menu.

That was two weeks ago.

I’ve tackled some interesting geometry problems already in this project (which I’ll probably write down later just so I remember how I solved them) but this one was a doozy. After scouring the web for ready-made radial menu solutions, I found none that avoided putting a cursor on the screen and comparing its location to the center of the menu to get an angle. I wanted a “real” radial menu – like in The Witcher 3, where you move the mouse or hold a stick on the gamepad and a selector rotates. With no starting point except some working knowledge of how rotations and input work, I went through many (many, many) potential solutions that completely flopped until I arrived at this.

Unity 3D 01.06.2018 -

The player unlocks a new ability and can select it and find more information about it in the radial menu.

Its appearance will probably change a lot but I’m happy with the way that gamepad and mouse movement are apparently identical in moving the selector around. The player just holds a button, moves the selector and lets go of the button to select an ability. I’ll be going into more detail of how it works in a later devlog – for my future self and other devs. 🙂


Devlog 2/10/18 – Super Bros. Snapshot

Like so many games, The Seeker has power-ups. Throughout the tutorial and main levels the player will gain and upgrade new abilities to help them along. A logical person might place something in the game representing a power-up, then give the player the power-up when they run into it or interact with it. TO BE FAIR this was my original intention – and implementation – and it worked well enough… but it didn’t make sense. So I did what any sane person would do: write an entire layer of backstory, research and write a comprehensive object pick-up-and-insert-into-things system (complete with inverse kinematics), and essentially spend a week of development time chasing an elusive “good enough” goal.

Unity 3D 01.06.2018 -

A modification to Jose Diaz’s hand-made IK solution attempts to smoothly pick objects up and keep the elbow at a stable position relative to the hand.

Well, I’m calling this good enough. This game is ripped off of the original Super Mario Bros. for the NES (these cartridges are how your guide gives you unofficial “mods” that extend your abilities) and features home-made artwork and that creaky sound of inserting the cartridge into the slot (and one for yanking it out after it’s been used), and should help add a fun, quirky element to the game’s dark vibe. 

Unity 3D 01.06.2018 -

Devlog 2/3/18 – Ouch. Pt 2

This devlog is all about losing. It’s not necessary in every game, but you’ll find it in different forms almost everywhere you look. Maybe you don’t have “lives” in a game, but mistakes force you back to the beginning of the level – so you lose time. Maybe you did pretty well on a level, then a scoreboard appears revealing that thousands of players completed that level faster.

This I-could-have-done-better feeling is a vital part of providing rewarding goals in games: the presence of the risk of loss is what gives victory value. The greater the risk and/or cost of losing, the bigger the high will be when a player overcomes a challenge. But because greater risk also gives way to a higher loss rate, increasing it will inevitably frustrate players who don’t learn as quickly as expected or just aren’t good at your type of game.


If you’re not good at platformers, for example… [source]

Of course many games have player-controlled difficulty levels to help scale challenges to their skill level. Puzzle games present a problem in this area; without time limits, puzzles tend to have fixed difficulty levels. A more skilled player might solve one faster than another, but generally everyone should be able to figure them out – especially in games where puzzles drive the narrative. Portal is a great testimony to the fact that having loss scenarios in puzzle games can and does work – as long as challenges are paced and segmented properly.

Unity 3D 01.06.2018 -

Small levels make reloading almost instant!

A primary goal here is avoiding the player losing and deciding that trying again is not worth it. In The Seeker, several puzzle areas have no constraints on the player dying or “failing” (losing a resource necessary to complete the puzzle) and many of them even let the player use abilities like switching between hosts and double-jumping without consuming energy. I’m essentially trying to tell the player, “Take your time, I know you can do it!”

To mitigate frustration from the only thing the player does lose in these scenarios – time – I’m shaving the cost down as much as possible. Where it makes sense, respawn chambers are placed throughout levels and linked to checkpoints. Using respawn chambers gives a way for the player to die and reset without reloading the level, saving about 5-10 seconds – and a way to show the switch mechanic before the player has access to it, as they leave their dead body and fly into the brand new one dispensed by the chamber. This also lets the player see the strangeness of their previous bodies lying all over the place, as bodies in this game are just resources.

Unity 3D 01.06.2018 -

Where it doesn’t make sense to place respawn chambers (like in abandoned areas that haven’t been modernized or areas requiring fine-tuned configurations), the player can reload the level and be placed at the most recent checkpoint. For more skill-heavy challenges like running away from bad guys or beating a time goal, this threatens gameplay flow: if someone spends 10 seconds attempting a difficult jump, for example, only to die and spend 5+ seconds reloading… that’s a huge chunk of their playtime wasted.

Until I have a solution to the reload problem, I’m just keeping scenes that’ll need to be reloaded relatively simple. How have you approached this problem? What games have you seen that do a great job of keeping reset times low? Leave a comment or let’s chat on Twitter!

Devlog 1/27/18 – Elevator Snapshot

Sometimes after a week has passed, I don’t have a new game design solution to elaborate on. I haven’t done anything monumental since I last wrote – or anything worth writing about, in fact. That’s why I’m doing snapshots! They’re just little glimpses into the game and its slow and steady progress. This week I’ve finished – wait for it – an elevator. Whoa.

Unity 3D 01.06.2018 -

The tricky part was a home-made world-space interface for it, where the player simply aims at a panel to interact with buttons.

Unity 3D 01.06.2018 -

The model itself is modified from zerstoren at CGTrader. Replaced all the materials, removed the button panel and indicator lights, added emissive cabin lights on the floor and ceiling for the conduit, and added the sliding metal door and interactive panel.

Devlog 1/20/18 – Ouch. Pt 1

Incredible proportions. Daunting geometry. Dark, dystopian structures looming on the horizon. It’s a sci-fi game! And normally as a developer I could plaster some images of distant buildings to the edges of the world and get on with building out small-scale level geometry. But in The Seeker the player has superhuman speed and strength; they’re expected to traverse huge distances and gaps, and become more and more agile as the game progresses. A common game design question rears its head: How much freedom can the player be given before it can’t be contained? In other words, what happens if the player finds a way to those cardboard imitations of buildings in the distance – or at least close enough to see that they’re just props? The illusion of immersion can be broken and the whole game can start to feel cardboard-y.


Don’t look too closely. Source

This is why most games have “bars” in them – health, stamina, magic, experience, currency, etc. As backward as it sounds, limitations are core to having fun in games. Compare a self-made millionaire to a lottery winner. Which one would you expect to talk about their money with a greater sense of accomplishment? Plus, the boundaries of a game world – whether physical edges of the map or constraints on the player’s abilities – help to focus the player on the challenges that are intended to be central to gameplay. Ideally, the player should never “win the lottery.”

In The Seeker, swapping control over people’s bodies essentially turns them into resources. While there are no “lives” for the player to spend upon death, there’s a surefire escape from death as long as another robot is in view and close enough to use the switch ability. As such, to make the player use the switch ability and keep them from going through hosts like french fries… people have to die. A lot. It might seem dark, but it affords me plenty of design opportunities for making fast-paced, risk-oriented gameplay. For example: run into a wall doing 60 miles per hour – you’re gonna die. Run out of stamina while stringing wall jumps together and fall 100 feet – dead on impact. Sprint off a building without saving some stamina to roll after falling… not pretty. But it is pretty effective! To succeed, the player must manage health, stamina, energy for switching other abilities, and of course, people’s mortal bodies. And that’s not including running from lethal enemies!

Unity 3D 01.06.2018 -

I’m definitely considering having the bad guy yell “Just see how far you can get with ONE body!” at some point.

Devlog 1/13/18 – The Problem with Jumping

A big part of the inspiration for The Seeker to have a focus on freedom of movement was Mirror’s Edge. It captured the sense of “actual” first-person in a way I hadn’t seen before and the feeling of leaping over huge gaps, looking down and seeing your body and the distant street level, and having a moment of sheer panic was one of my favorite parts of the game.

Unity 3D 01.06.2018 -

But I found I wanted a little more control over movement in Mirror’s Edge – as strange as that may sound to anyone who’s played it – especially in situations where the player has to navigate several gaps and vertical paths in succession. As much as I wanted to problem-solve my way through these scenarios, my first plan (bashing the jump button and moving toward my destination) usually worked. And this makes sense: save for a few tricky escape-room-style scenarios, Mirror’s Edge is not a puzzle game. I started pondering methods to add to the player’s control of movement to incorporate situations where, for example, they might need a certain “jump strength” to make it over a gap – or be moving at a certain speed while jumping – or a combination of both variables.

Unity 3D 01.06.2018 -

Early attempts involved a bar indicating “jump charge.” Hold the jump button, watch the bar fill, release to jump with that much “charge” added to a base jump strength variable. It doesn’t make much sense for charging a jump to take very long, though, so I found myself just charging the jump for longer than I needed and only jumping with 100% charge. My eyes were also never on the actual bar; they were on wherever I wanted to go, of course! At this point the feature was useless, but I left it that way for quite a while – until a level included a gap that required a certain jump charge, and what was intended to be easy became a point of frustration for me as a player. In this instance, jumping with too much charge would cause me to hit the ceiling and lose forward momentum, and jumping with not enough charge wouldn’t provide enough momentum to clear the gap.

Unity 3D 01.06.2018 -

Even after dividing the jump bar into thirds to help make charge amount more obvious and placing it near the center of the screen, I was still struggling to hit the percentages of jump charge that I wanted. This was around the time I began working on sound design and replacing prototype sounds with ones I liked. Using short ticking sounds that play when a “cell” on the jump bar is filled and rise in pitch with overall jump charge virtually solved the problem. The goal is to train the player to get used to the connection between the blips of sound and jump charge before they need to use less than a fully-charged jump, so when the time comes they (hopefully) know what to do.