Starting off, a quick pitch, Sensory is a game in which you must choose which sensors to power in order to make it through an environment without running out of power or taking too much damage. If you have not done so, I recommend playing the game first before proceeding with this post as discovery is a significant portion of the game.

Link to the game: https://ldjam.com/events/ludum-dare/39/sensory

This is my 4th ludum dare attempt and 3rd submission, and I’m quite happy with how this entry has turned out. I’m going to make a quick post to discuss some stuff that I feel like I did differently this time that improved the quality of my game with the next post being over some of the design decisions I made. Splitting this into two posts to avoid a giant wall of text.

Applying lessons learned from previous Ludum Dare participations:

First off, my number one issue for short time period projects is that I always over design them. I tend to try and write every component in a way that will be versatile, reusable, and extendable. This time, within reason, I forced myself to throw out that methodology and focus on getting to do the thing I set out to do. For example, the radar/sonar effect in the game could be implemented in a lot of ways, but I went with a quick and dirty method of having a preset 8 float4’s passed into the shader for the world geometry. They are initialized to something very far away and moved to a location upon use. Probably not the way I’d do this if I were making a full game, but it was quick and easy to implement.

In a similar fashion, I broke my design into tiers where stopping at any tier could be a full game. My design has three obvious tiers in this case, the three sensors used in the game. I started with just the sonar effect, designed a couple of levels that could be played and beaten with it, then moved to the infrared/heat sensor, and then to the sound sensor. I have more designs stacked up behind those, but I made it to my self-imposed cut off for new features and this is where I was. I then designed two final levels that incorporated all of the sensors and that was it for the bulk of the content.

Lastly, I knew I was entering the jam, it’s my personal preference for Ludum Dare, so I left the entirety of Sunday night and Monday morning to playtesting, sending out versions to all of my friends and letting my coworkers try it. This gave me a lot of good feedback to make adjustments and it really helped the feel and communications of the game mechanics.

Next post will be about the coming up with the idea of the mechanics and how I iterated on the design.

For those interested the tools I used were: - Engine: https://unity3d.com/ - Level Design: http://sabrecsg.com/ - Audio Editing: http://www.audacityteam.org/ - Graphics/Editing: https://www.getpaint.net/

Starting off, a quick pitch, Sensory is a game where you must choose which sensors to power in order to make it through an environment without running out of power or taking too much damage. If you have not done so, I recommend playing the game first before proceeding with with this post as discovery is a significant portion of the game.

Link to the game: https://ldjam.com/events/ludum-dare/39/sensory

This is my 4th ludum dare attempt and 3rd submission, and I’m quite happy with how this entry has turned out. This post was is over the design process of the game, to see the previous post over previous Ludum Dare lessons applied, click here: https://ldjam.com/events/ludum-dare/39/sensory/sensory-post-mortem-part-1

Initial Concept:

I did not go into this LD with any initial idea of what I was doing, so I started clean with the theme. My starting off point for running out of power was that you’re a robot. I asked myself the question what would a robot do in a situation where they were running out of power, or operating under very limited resources. I’ve had some experience programming an RC car to navigate a maze using sensors, so my thoughts went to the need to power sensors. This lead to the idea of using sensors sparingly to get an idea of the world, and then extrapolating or reasoning from there. This laid the basis for the game concept.

Jam outline:

I planned out several sensors and then ordered them in how I thought I could make interesting interactions for the player. I then implemented them in that order until I ran out of time under a self-imposed timeline. My plan was then to combine all of the sensors I had used into a few final levels to try and tie the game together.

Key design decisions:

I made a few key design decisions throughout the process that I feel are crucial to the design of the game.

No real tutorial:

This one is more of a personal preference and also a self-imposed design challenge. I don’t have a particular disdain for tutorials, but I wanted a key part of the game to be about discovery and I wanted to try and design the game in such a way that the player can fairly understand how it works without me directly spelling it out for them. After playtesting I did decide on adding a small kinda tutorial on the first command screen.

Slow movement:

The movement speed actually came out of playtesting. With a faster movement speed people often stumbled in and out of hazards with much less of an idea of what was going on. Based on current feedback, I have a feeling I may have overdone the slow speed, and have some ideas for future iterations to help smooth out this experience.

Sound traps:

These were/are my hardest design hurdle. Players aren’t used to avoiding something based solely on sound, and communicating this mechanic is something I’m still working on. My biggest change that helped this come across so far, based on some friend playtesting, was the addition of some small geometry on the walls to indicate the location of the trap, as just the heat signatures alone were not enough.

Another sound change that came out of playtesting was the moving platforms. Before they always made a sound and you had to use a combination of the sonar and sound to figure out when you could step on them. This was way too much of a challenge for such a simple mechanic. In response I changed the platform audio to make a switch noise and then cut off the audio when not moving. After this change I have not seen anyone miss the platform while using the audio.

That’s it for now. If I have time I’ll write a third post over the sonar effect as I’ve had some questions on how I went about implementing it. Thanks for reading.