This past week has been an interesting one as far as what we’ve added. I feel like we were all over the spectrum with what new features were added. Let’s get to it!
R-Stick Targeting
This past week or so we had some people play around with what had implemented. A friend of mine had a suggestion about being able to use the R-Stick for targeting and manipulating the camera. Interestingly, I had tried implementing an R-Stick selection feature many months ago, but did away with it because the algorithm I was using to “select” the target was not always consistent from a game play perspective. However, many new features have been added to the system since then, so I thought we would give it another go.
The biggest problem we were trying to solve for was being able to target the enemy in the back who was sniping with arrows. The current method of targeting is to select the closest enemy within reason. If one presses the L Trigger, it will toggle to the next nearest. If we have 3 or more enemies, one of them in the back snipping (as they are programmed to do), it makes it impossible to select these enemies without moving the hero towards the enemy snipping.
In the picture above, the bigger yellow triangles represent what the player is currently targeting. The smaller white triangles to the left of the current target is the what we would select if we were to press L Trigger again. We can think of this as the “next nearest”. To the south of the current target, and in the upper right of the picture are some even smaller tan triangles. Along with the white triangles, these represent what we would select if we move the R-Stick in a certain direction. For example, if the player were to press the R-Stick in the right or up direction, it would choose the Orc with the bow. If the player were to press the R-Stick down, it would select the Orc with the sword. And finally, if the player were to press the R-Stick in the left direction, it would choose the Minotaur.
The trickiest part of implementing the system was getting the UX down. Originally we thought it would make most sense to color specific directions of the R-Stick. But with so many different colors moving around, plus the “next nearest” concept, it became overwhelming and hard to keep track — especially when colors don’t really represent directions (I even tried googling to see if there was a set standard). Currently we are using the small tan colored triangles, but those might end up going away. We figured the best experience with the R-Stick method of was to make sure it “just works”. If a player can simply know that if they press R-Stick right and it selects the “right” enemy, there is no need to have different color triangles, indicators, etc.
We believe this will work for combat because the player using the R-Stick to select a target is not focused on melee fighting, at that point in time. This is because it is practically impossible to use the R-Stick at the same time as the face buttons (A, B, X, Y), thus making it impossible to fight with melee weapons (since melee weapons are bound to face buttons). Therefore, the player who is using the R-Stick is focused on moving the target and not the combat at that point in time. Colors, indicators, etc. then is not important, as long as selection in a certain direction with the R-Stick “just works”.
R-Stick Camera
My friend’s other suggestion from months ago was to have the ability to move the camera with the R-Stick. My friend is a very stealthy player, and he wanted the ability to know what was coming up so that he can sneak better. I’ve personally am not a stealthy player when it comes to games, but I still want to reward those who are. Thus, we finally got around to building this feature out. When moving the R-Stick when the player is not holding L Trigger for targeting, the player has the ability to move the camera until the hero is on the edge of the screen. When the player releases the R-Stick the camera will “snap back” so the hero remains in the center of the screen.
The nice extra about this feature is there is now an object we’ve created for the camera follows. Before it was always the hero. Now it is just an invisible object, which during the R-Stick movement, gets controlled. You may ask “what is so nice about this?” Well, this gives us the ability to move the object wherever we want. During a cutscene, for example, we can use that same object, give it some inputs where it should be, and walla! We have a camera moving about in a cutscene.
Swamp / Long Grass / Fire Updates
Hannah supplied a few swamp graphics this week. We decided to use the same grass tile, but color it differently. I was okay with this approach as long as we added a lot more “decor” tiles. Below is a screenshot of a “vanilla swamp” area:
We still didn’t think it looked swampy enough, so we decided to add some long grass that could be laid over top background tiles. I thought this idea could be used not just in the swamp, but in other regions as well. By simply using the Color Palette Swapper, we were able to make this work very easily:
The player can now walk through the long grass. When walking through long grass, speed is much slower. This also applies to enemies, animals, and NPCs as well! Grass can of course be cut down with a melee weapon. The best part though is grass can easily catch on fire! And when I say easily, it was causing a huge forest fire! I ended up reworking the fire spreading algorithm a bit because the frame rate was plummeting. Flames of fire can now “combine” into one other to form a bigger flame. This drops the amount of fire objects on screen, which helps the frame rate. In return, the combining of fire also makes it look less uniformed, and more “fire like”.
Audio Controller
The audio controller was the biggest new feature being worked on this past week. I believe music and sound can make a game that much more memorable, if done right. It’s like extra frosting on the cake, if you will. Tyler and I met this past weekend to discuss how we wanted music to work. We concluded that:
- We wanted our music to have the ability to change if a certain circumstance were to arise. For example, if an enemy were to approach, we wanted the music to add more rhythm to the current song to make it sound more intense. Another example is we wanted music to play the same melody, but change instruments during a day / night cycle.
- We wanted our music to have an introduction, and then for the music to loop after being completed.
- We wanted our music to naturally fade out when approaching the next area, and play hard when we reached the next area.
We ended up solving the first problem by having n variations of the same song playing in sync. Then, for each variation, the system can control each volume separately. When it is time for the enemy music to come in, we cross fade between variation 1 and variation 2, giving it the illusion that we’ve added instrument tracks — when in reality we are just playing a different song, that is the same song with different instruments. This works awesome with the day / night cycle, as it will slowly cross fade as day ends and night starts, and vice-versa.
The second problem was tricky, but we ended up solving the problem with a little help from this video. It’s actually from the same author who created the Color Palette Swapper.
TLDR; we essentially have one music file. We note the length of the introduction and note the length of the loop. Then, with our audio file, we add the first two seconds of the loop to the end of the loop as a “buffer”. During game play, if an audio file’s position is greater than the total length (which can be summed by intro length and loop length), we set the music to it’s current position and subtract the loop length. This was a very clever way of looping music on a certain frame rate cycle!
The final problem took the longest to get right. Most games will start a new audio file when entering a new room. However, since our game will only have one room, we needed a way to figure out if we are close to boundaries. Currently, the system supports to methods of fading music out — entering a building, and entering a new section. Both use similar approaches in that we need to figure out if we are close to the edge of the polygon. The closer we get to an edge, the quieter the music becomes, until we cross the boundary. Once we cross the boundary, we play the next song at full volume. If we continue moving, no problem. If the player doesn’t move away from the boundary, and immediately turns back, we cross fade from the current song back to the old song, but at the “distance away from the polygon” volume they are currently standing.
This solution is very hard to explain in writing, so it’s best if you play the game to get a better understanding of what we are talking about. 🙂
Music Samples
I asked Tyler if he was cool if I shared some of the audio he was working on. I meant to post these Sunday. It’s Friday. 😀
Below we will find 30 second snippets of audio we have been working on. These are all working samples and are bound to change. We’ve purposely reduced the quality a little as well as added some white noise in the sample. But it shouldn’t be too distracting. Let us know what you think!