Prototyping journal - Making a game in the dark

CHARACTER DEVELOPMENT

Animating the character was a simple enough task. Idle and walking frames were loaded up on a sprite sheet and implemented in Unity’s Animator, along with a simple velocity based character controller.

click any image to get a closer look

LIGHTING

The earliest mockups looked pretty uninspiring on their own. In an effort to capture the feeling of deep, suffocating darkness, I quickly ditched all ambient light and illuminated the scene with a spotlight that follows the player around.

The code below is the light controller for the trailing spotlight. Making the light look at the player was simple, but following proved trickier. It works by calculating the floor distance from the light’s position to the player’s position. It then uses a set “target distance” to tell the light whether or not it should start moving towards it’s target (using lerps to ease the movement). This creates a circle around the player in which the light doesn’t fuss about following them, reducing unwanted light movement. Additionally, it adds a slight bob to the lights movement that happens at all times, which I think helps to smooth the seams during abrupt stops.

POST PROCESSING

Early on I felt the darkness color looked harsh and dead. So I added a post processing volume and edited the color curves. Adding some color to the lowest values helped to set an ominous mood, and now lights cast livelier shadows from large objects.

SHADOWS

2D sprites don’t inherently cast shadows, and that fact started to be a glaring shortcoming as I progressed more and more. So I dove into the URP’s lit shader graph, and was able to piece together the following; which grabs vertex color data and the texture from the sprite and runs them through Unity’s fragment shader to finally produce the elusive character shadow.

The shadow silhouette is formed by standing the sprite up 90 degrees from the floor, tilting the camera 45 degrees, then distorting the sprite so that the correct sprite height is projected onto the camera. This idea was taken almost directly from researching how the developers of Enter the Gungeon handle sprites.

So this shadow method looked great, so long as the light was close to normal to the sprite it was shining on. But as the light approached parallel, the shadow flattened, creating an obvious effect.

I remedied this issue by overlaying a copy of the character sprite at 90 degrees, which isn’t visible to the orthographic camera. This does sometimes create some odd shadows cast onto the main sprite, but adjusting the shadow biases minimized the unwanted effect.

I set up an animator for this perpendicular shadow, same as on the main sprite, and the result is a pretty convincing 3D shadow effect that bounces along with the characters movements. I have to concede that doubling the sprite and animators just to mimic a 3D model is a lot of work, but the resulting style is satisfying nonetheless.

FOLLOW CLICK

As happy as I was with how the look of this environment was coming along, I still felt that the player could use more control when it came to the spotlight. So I got to work adding the ability to control the spotlight via mouse click to my light controller.

I accomplish this effect by having a held click of the mouse cast a ray from the screen to try and collide with the world. When it does, the collision position fills the transform of an empty object, which becomes the new target transform for the light. Additionally, I added some more lerping to smooth the transition from a mouse click target to the player target, and vice versa.

FORWARD LOOKING

As I become more familiar with Unity basics, I’m looking to further integrate my artwork into the scenery and additional characters. This environment is certainly a long way off from telling any kind of coherent story. But as I continue its development, I hope to explore what treasures and mysteries the darkness could have in store.

2 x Four Racing Game Design Post Mortem

A Journey From Lawful Good to Chaotic Neutral

Two x 4 racing began as a grad school project, a working version completed in 3 weeks with the goal of applying to GDC’s alt ctrl, and subsequently polished for another 3 weeks when it was accepted into the event. The final version of the game is a chaotic and unruly dash full of shouting and exploding cows. But it began as a more serious, overcomplicated downhill sprint. In this post, I’m going to reflect on trying to highlight the fun in playful chaos, as well as analyze the project’s design iterations from my perspective, the team’s level designer, mechanical engineer, vehicle physics programmer, and sound designer.

Game Overview

A quick overview of Two x 4 in its current state: this is a cooperative single car time trial where two players control the same vehicle while back-to-back in real life. The 2 controllers are composed of a bike tire steering wheel (my bike was rotting in the garage), two duplicate arcade buttons, and a wooden spoon dial. The goal is to complete one lap of the track. The player in front is steering and looking forward, the other is looking behind and operating the car’s “engine crank.” They rotate the wheel in the direction indicated onscreen to make the car speed up, and in the opposite direction to apply the brakes.

Their car’s fuel depletes over time and to collect more, players drive underneath one of the “fuel balloons” scattered around the track, and hit the button on their steering wheel. This button both collects fuel and flips the car’s chassis 180 degrees, swapping the roles and screen views of the players.

Lastly, there are cows everywhere you look on the track, in groups, by themselves, big and small. When the players hit the cows, the poor creatures explode as if made of a hundred tiny lego pieces. The spoon dial on each controller tracks your cow count, and when it maxes out, an angry bull will chase you down and knock your car way up in the air.

First Playable Iteration

In our earliest meetings, brainstorming settled on inspirations such as cat-dog (back-to-back control), Code Name kids next door (2x4 tech theming), and Mario Kart double dash (two drivers swapping places). Our idea was that through solid communication and teamwork, the players could achieve extreme speed while flying down a hill soapbox derby style. With that settled, we had to move really quickly to meet our 3 week deadline. This meant that our team of 5 needed environmental art, level design, controller design, sound design and vehicle physics to develop in parallel. About a week and a half in we had our first playable, but it was clear there were a few design conflicts.

Physics

Since breackneck soapbox derby was on the brain, the vehicle physics were originally developed f-zero style, with the car not being able to turn around, rather it would just shift from side to side on the track. This was easy to quickly piece together in about a week but I had also just finished the bike tire controllers. And these wheels were begging to be whipped back and forth, not meticulously budged side to side. So I went back to the drawing board on vehicle physics. This time using unity’s built in wheel colliders. This a step in the right direction in that the vehicle could actually turn around, but this car felt like a car simulation a la beamng.drive, a far cry from our arcade racer vision. Another physics reset. This time I approached it from emulating physics in the simplest possible way. Manually applied forces would approximate my suspension/wheels, and my engine turned into simple forces applied from behind. This simple approximation succeeded in making the physics bouncy and playful, the suspension was left loose and the steering torque was generous and encouraged big turns of steering wheel.

Track Design

View fullsize

The first iteration of the track design was based on the F-zero physics. It was long, straight, punishingly difficult and ultimately.. boring. Even with the updated physics, the track being a downhill bomb made any serious turns impossible. Our controllers beg to be quickly turned, and once again we found elements of the game clashing with that basic need. So I got to work on another track design with flat, wide sections towards the beginning for a slower learning curve, and tighter faster turns towards the end for an increased challange. I also found that slowing the car down didn’t kill the excitement or chaos. In a game where the car spins around, it’s more important that the player steering have time to react when they inherit the role. (also speed lines help alot with speed perception)

Fuel Collection

Our first pass at a fuel collection system was having two different types of fuels. One for each side of the car. There were also two different types of fuel balloons that would only distribute fuel if the button was pressed when the correct side of the car was facing forward. Oh, and also the players needed to coordinate and press their buttons at the same time (one button would not swap the chassis). An absolute mess looking back. The design intent was that successful communication translated into more speed and more speed meant more excitement! But this turned out to be a LOT to think about while careening around a track. We were also firm on players being back-to-back, which further hampered communication. We decided to simplify.

First, we axed the need for buttons to be pressed at the same time, this was near impossible for players and that kept them from experiencing the swapping, one of the more interesting parts of our game. Instead, anyone could collect fuel/swap the vehicle with their button at any time. This lowered the skill floor significantly and furthermore, players still gleefully yell “SWAPPING” when pressing their button anyway, so our communication hopes are still satisfied.

Second, the car would now only use one type of fuel, this was needlessly complex. The intent was that players would swap more if gates required them to be facing the right direction, but this was uneccessary. Players swap to mess with eachother, or because they’d rather their partner steer, we don’t need to force it. These two major changes reduced the amount of thinking and coordination required by players, so they could focus on the experience of the controller and physics.

The Bull

The bull was our final mechanical addition to the game after we got positive feedback from players that loved exploding the cows. It felt like a great opportunity to inject more chaos into the experience. So why not add an angry bull that chases the car when a certain number of cows are hit? At first we leaned toward making the bull a bad thing, it would deplete your fuel, do damage, or end the game. But then I remembered that our goal was gleeful chaos, so instead I suggested that the bull should simply knock the car sky high. Sure, this was still sometimes a hinderance, but one that gave an exciting view, one that sometimes led to discovering the shortcuts around the track, and one that supported our decision that hitting cows was not inherently good or bad, it just was.

The bull also serves as a dramatic moment for the rear facing player. As the bull draws near, it will slow down and prolong the chase, which leads to players cranking the engine faster than they normally would. Looking back, I just wish that the rear player had a little more agency in the bull chase situations.

Takeaways

Developing this game kind of felt like we made several times. There were a lot of expensive redesigns that were caused by hasty development and a lack of early testing. We had skipped testing to save time, but in the long run we probably would have moved faster had we just tested. For me, this shines an emphasis on minimum viables. If I did it again, I’d play with the car for at least a full week and test it fully before even touching a track editor.

As for things that went well, the design of this project was most successful when we kept the game’s pillars in mind, every time we made decisions with playful chaos in mind, (adding the bull mechanic to our exploding cows, bouncy suspension, less complicated fuel) the game simplified and became more cohesive. I think designs that choose and focus on their core emotion/pillars yield more singular visions and more than that, are just easier to make.