I felt like writing a bit about some of my thought process while making my game, and some reflections, I’ll also talk about some of the changes I’ve been making and planning as I’ve continued development, since it’s taken me so long to get around to writing this. This might just turn into me rambling on for a while about my game, but maybe someone will find at least part of this interesting or informative. For reference, I’ve also posted the art and sound effects from the jam version here. Anyway, if you haven’t played it yet you might want to check out my entry here before reading more (and thanks to anyone who has played and rated it).

 

Concept

The first idea I liked when thinking of the theme “beneath the surface” was some sort of traditional platformer where the level and action is being controlled by someone underneath the level. The general concept I eventually turned this into is that Jumpland is a theme park based on classic platformers where the main attraction is to travel through a platformer. The inspiration from classic platformers is why I went with “grassy” visuals similar to what you would expect out of an early Mario level, or Green Hill Zone in Sonic. Though one of my plans for future development is to have more “lands” with different visuals and obstacles, such as a “snowland” and “desertland.”

The above ground character (referred to as the “Guest” from now on) is a guest at this amusement park, while the underground character (referred to as the player character from now on) is using the underground maintenance tunnels to run the park. Thus you only directly control the movement of the player character to see where the Guest is going and use underground buttons to move pieces of the above ground level to help them get farther. In addition, the jumping of the Guest is actually the result of the player character triggering the jump boots the Guest is wearing. (Though in game there is no real indication that this is how jumping actually works).

I felt I wouldn’t have the time to do a good job building static levels, which is why I went with a randomly generated endless “runner” style game. When working on the post jam version I’m going to continue to focus on the endless mode, but at some point in the future I would like to at least consider also working on a set of static levels for this, possibly focusing on more finely tuned challenges or puzzles requiring more precise timing or thinking to get through.

Characters

For the Guest I went with an obvious grin and big eyes to reflect the idea of a kid enjoying a big amusement park. I went with a red cap due to the Mario inspiration and to avoid having to worry about drawing hair. Since the idea was for jumping to be triggered by the player character from underground, I needed some sort of “jump boots” instead of regular shoes. Thus the design was actually loosely inspired by the “Thwomp Stompers” from the Super Mario Bros. live action movie. The walking animation for the Guest is an exaggerated march to reflect how he will continue to blindly walk forward, oblivious to whatever danger he might walk into. Other details like the shirt color didn’t get much thought aside from getting something that I thought looked good.

For the player character I used a faster animation because I wanted an effect similar to a short cartoon character scurrying about. The lack of eyes is mainly a result of how I started with just a head and hat and liked the look of it without eyes, especially after I added the big nose. I guess the general concept of the character design initially came from the idea of an old construction foreman. This was why I started with just a yellow hard hat, which then led to the idea of adding a miner light. That was probably what also inspired me to add the notepad. There isn’t much reason for the green skin aside from how I felt more natural skin would blend in with the hat, and I thought that shade of green looked pretty good.

As seen in the above gifs, I’ve started working on improvements to both sprites. I added some shading to the edges of both their heads and bodies to help the sprites stand out. I’ve made the guest a bit slimmer which should help make the march animation clearer, and better differentiate them from the player character. In the case of the player character I’ve changed the shirt color to make it more visible in the dark tunnel. I’m also considering ways to allow customization, such as changing character colors or alternate hats, though this will likely require some significant changes to how the sprites are made and displayed in game. My current idea for this would be to have each character made up of multiple sprites (separate sprites for arms, legs, head, body, and hat). This would likely simplify the process of character customization, but I’m going to continue considering other options since there could be a hit on performance by using multiple sprite renderers for each character.

One of the things I’m really happy about is the mining light of the player character. When initially designing the character I quickly fell in love with the idea of having a spotlight attached to the character to handle the lighting in the tunnel. However, at first the character and light felt very disconnected due to it being a flat sprite using an attached spotlight to light a 3d tunnel. This was partially fixed by moving the light source further into the sprite, rather than actually coming from the headlamp on the sprite. This still didn’t look right due to the headlamp being dark like the rest of the sprite, so it didn’t look like the headlamp was actually on. This was then finally fixed by adding a point light positioned on the headlamp, and setting it to only illuminate the player character.

Original Configuration

Moved Spotlight

Added Point Light

 

 

 

 

 

 

 

Spikes

Originally when I came up with this idea I didn’t plan for there to be so many spikes. But, since I needed a way to kill the Guest, spikes were the most obvious first choice, and were quick to make. Then as I worked I never got around to making other ways for the Guest to die (such as being crushed, or other hazards). In addition, given the nature of the game I didn’t want to allow the player to leave the Guest walking into a wall while slowly looking and planning for what’s ahead. Thus I ended up with some obstacles with extra spikes thrown on the front to kill the Guest. Luckily there are a number of things I could do/have done in the post jam version to avoid the repeated use of spikes:

• Slopes.
• Crush deaths (Removes need for spikes on bottom of moving blocks)
• In ground pits (so that traps like the ones using a bridge would only need the bridge to rise to ground level,  while the spikes, or some other hazard, are below ground)
• Allow the Guest to get “stuck” walking into a wall, but set up a fail condition if they spend too long not moving forward.

Here are some screenshots showing some differences in the post jam version after implementing slopes and crush deaths.

Jam Version

Post-Jam Version

One of the issues I found while continuing to play after the jam was how the spike collision detection seemed unfair sometimes when jumping onto blocks. This is because I originally set the collision as a trapezoid to more accurately reflect the visuals of the sprite, Unfortunately this meant that sometimes when it looked like the Guest should of just landed on the edge of the top of a block, they would still barely hit the corner of the spike collider and die while standing on top of the box. As a result, I’ve now switched to using just a normal box collider on spikes, which fixes the jumping on blocks issue while not having any noticeable impact on other spike interactions.

Collision shown by green outline. Left=old, right=new

Buttons

In the jam version all the underground buttons behave the same, hold the button to raise a portion of the obstacle, which lowers back down while the button isn’t held. I originally wanted more variety in how the buttons affected the above ground, but I didn’t have time to rig up different types of button behavior, such as toggles and other ways to manipulate obstacles. In order to maintain consistency for the player in the post jam version new obstacles using this button will likely keep the same “hold” mechanic, though possibly with more variety in direction of movement (such as a platform which moves right while the button is held and goes back left when let go). I may also still implement toggle type obstacles, but they would likely have a different model used for interaction (such as a switch or lever).

In order to make it clear when the player could hit a button I added a spotlight above the button which is only turned on when the player is in position to press the button. I used the color of the light to signify if the button was being held. I felt this visual feedback was really important given the darkness of the tunnel and the possibility of a user not getting audio feedback if they are playing without sound (which would be very likely in the case of a mobile user). An extra bonus of the spotlight is that it allows the user to get a clearer view of the player character which usually only has the slight lighting of the headlamp on part of the head and hat. In the post jam version I’ve also made the button itself a little larger to help with visibility.

Sound Effects

The sound effects were all generated using Bfxr. I’ve included the sound effect WAV files in the assets zip (available here if you missed the link at the start of this post, or don’t want to scroll all the way back up), however you may notice they don’t sound the same as in game. This effect was done by adding an audio reverb zone to the camera and using the StoneCorridor preset to make it sound more like you are hearing the sounds while in the underground tunnel. I didn’t spend too much time generating sounds, so I will likely go back at some point and modify the current sounds, or create new ones, so that they sound better when heard repeatedly.

Music

The music was generated with abundant music. My process was mostly just using random seeds to generate MIDI files, which I exported to WAV using LMMS. Once I got something that I liked the sound of and fit well enough with the game the only other editing I did to the file was using Audacity to cut out some of the ending silence to make the loop less noticeable.

You can download the music track from soundcloud below.

Under The Hood

I’ve also been working on some internal structure changes to help make future changes and additions easier. The most significant of these is how I create and manage obstacles. Originally I created each obstacle as a prefab, and the script generating obstacle placement had a list of these prefabs. The main problem with this though is that Unity does not currently support nested prefabs (unless you use a third party plug-in, or build some system yourself). This meant that if I wanted to make a change to a common object (like the spike collision mentioned earlier) I would then have to waste time copying that change into each spike of each obstacle prefab, instead of simply changing the base spike prefab and having that change automatically propagate into the obstacle prefabs. So for now I’ve removed the large obstacle prefabs and now have an empty “Traps” gameObject in my scene, whose children are the gameObjects for each obstacle. With this I’m able to have individual objects like the blocks and spikes maintain links to their prefabs. Another benefit of this change is that the script generating obstacle placement only needs to be given the one “Traps” gameObject, and can then read its children at start-up to generate a list of obstacles to work with.

Newly split segment prefabs

In a similar manner, I’ve also split the “segment” prefab I was using to build the tunnel and ground. Now the underground portions are in one prefab, while the dirt and grass of the surface are in a separate prefab. This means now new prefabs used for different environments on the surface (such as the snow and desert I mentioned earlier) only need to contain the unique surface portion, while the underground tunnel is still only contained in one prefab.

The Future

In addition to some of the changes shown above I’ve added an options menu to allow for adjusting music and sound volume, as well as some options for input layout. I originally planed to have the initial release of the post jam Jumpland Underground for Android before the end of voting, but I think I’ll delay it some since I want to add a tutorial and maybe a few other small things before releasing on the Google Play store. Anyway thanks for reading all this, I’ll probably make another post once I’m ready for the initial release of the post jam version. But for now I’ll go play and rate some more games since there’s less than a day left to rate.