After spending a great portion of time developing mechanics into Unity to all of a sudden losing the progress was a major set back. However, as of doing development for several years, this was something that was accustomed from doing programming and creating games. Due to this, realizing the expectations for the project needed to be further understood. So as a solo developer, the original aspirations could be explored further by looking at smaller scoped projects and how they incorporate Sound Design for games.

The mini games that were made within RPG Maker were to be very simple and this was because of the limitations and general knowledge using this engine. However, because of these limitations, exploring possible sound related game projects on Itch.io to see what examples of mini games could be developed within the time frame.

All of these games used sound differently to identify their mechanic. For example, Sound Garden is a game where you grow different flowers to create different audio cues. Allowing you to make your own musical beats and tracks. These were good starting points as it would allow the focus on keeping the mini games short and simple.

RPG Maker - Garden level example:

As a test to learn the new engine and it's coding language, a good practice was to understand a way to re-create the Sound Garden game. However, this was more of a test to understand how this concept worked so that the fundamentals from this could be taken or expanded in other projects or areas. 

Trying to keep this as simple as possible, a basic script was created to check if a tile had been triggered through the Action Button (which by default was left mouse button), it could play the track examples used. This also used a Text Event so that a message could be displayed on screen if the player had triggered this tile.

As the Events were to only work when the player triggered them, the priority needed to be set Below characters. Meaning this script would only work when the player clicked on the tile rather than whenever they moved their character on top of the tile. 

For the first example to show this working, a flower sprite was not used. Though for the second it was. This made it easier to show when different tiles had been pressed, a different object should appear on screen afterwards. 

Here is a short video to demonstrate this:

Understanding the core basics of how this type of mini game worked, it was used as inspiration towards the first mini game/mechanic that would be implemented inside of RPG Maker. Although this example was not further expanded, this small and short test showed the early steps of progression towards creating this style of mini game as a concept. Further improving the understandings of Sound Design skills.

RPG Maker - Creating the basic lobby:

For this type of project, it felt that having a main hub/lobby which could lead to the different mini games was the best layout option. This would allow the doors to transition to unique areas with their own puzzles and challenges for the player to face. Additionally, one of the key aspects that was desired was to keep the player unknown of what to expect next upon playing the game.

Each door way would eventually lead to each mini game designed, which the player would have to overcome in order to win and get a 'true ending'. This true ending was still under development but as this project was more simplified compared to using Unity, it felt like a wise decision to try and implement a goal the player could work towards. 

Designing the the secret area's mechanic first before working towards the first mini game was an effective approach.  It would allow a better understanding of how doors worked inside of RPG Maker. This would be achieved by adding Events;

- Such as a Set movement route (to adjust how a player or event will move),

- A Play sound Event,

- A few other basic Events/actions for the Self Switch so it could be activated (self switch is the event that tracks if all other switches were activated, and if so would open the secret area).

These were added to a few switches located around the lobby, each containing a list that would check if the switches flipped were required to open a secret door, that would be hidden from the player. Unlike the flower game, the priority for these were set to Same as character. This would set the Event to the same level as the player character.

Doing this would potentially allow this secret objective to this hidden room, to only appear to the player when the switches in the lobby were pulled in the correct order. If done correctly, a Text Event would display on the players screen to signal that 'Something activated'. 

From this, if the player was to then interact with this new hatch that appears, it could transition them from the lobby to this new secret area. This is done through the Transfer Player event. 

RPG Maker - Secret room design:

As the mechanics were being implemented towards the secret ending, having a basic design for this hidden area would be required. Mainly so that when the objectives needed to achieve the secret ending were met, that this room could correspond from the players actions towards that goal. 

Nothing in the room would work as of yet, this was just so a placeholder was in place for later when it would be useful for the player. Without the mini games functional, this room served no purpose at this stage, so the next task was to allow the player to transition to the first mini game and develop it.

RPG Maker - Door transition scripts:

For the doors to load into the unique zones for the mini games/mechanics, having a simple script that could not only transfer them to this area (using the Set Movement Route Event for the door and player), but also for when they won the mini game that the player could not return to this area.

Firstly, setting the values for the Set Movement Route for both the player and door was required so that the the doors opening animation would run and the player could be moved from their current location, to the new one. Next, having the Play SE (sound effect) Event using one that was pre-built inside of the engine itself for when the door opened. This would further show the players interaction with the door and give an audio cue displaying that this action had occurred. 
 

The trigger for the door would need to be set to a 'Player Touch' otherwise interacting with the door would not run this simple script. Additionally, if it had been set to something like 'Parallel'; then even though it could run with other events simultaneously, this is not what was required for the door to function. 

As Parallel is a type of trigger that can run multiple Events simultaneously with no interference. The door is just used to enter a room and not do any other actions, meaning it would not need a complex trigger type.

Here is the example shown:

What it should look like once the mini game is won:

RPG Maker - Graveyard mini game:

As the horror genre was still the main area to pursue, the previous example (the flower game) was used to create a new mini game that was set in a Graveyard setting. The mechanic of this mini game was simple;
 

The player would need to interact with the correct statues in order to successfully open the exit and leave the area. It was sort of a memory game which required the player to pay close attention to a sound cue and if the correct statue was selected, the player made progress. 

Creating a unique Event for the Control Switch A and variables so that this could be added to multiple objects and only the correct statues that were interacted with the associated variables/Control Switch scripts could advance the players progress. The custom Events for Control variables and the Control Switch A were assigned to each statue.  

If it was correct, the list would increase by +1:

If it was incorrect, the progress went down by -1:

The win state was the statues needed to equal 3, meaning if you activate 2 correct ones and then a negative, the progress was then set back to 1. Unless the player re-selected the statue to deactivate it, you could not win until the correct 3 statues had been selected. 

If all 3 correct statues were selected, then a 'clicking' sound would play through the Play SE Event and signal to the player that they did something right and should re-check the gate.

If the player tried to leave through the exit without completing the puzzle correctly, it would inform the player that "the gate is locked". The script for the gate that locks the player in only needed a Text Event, as the main code that checks for the players actions was out of the map boundary.

This was so that there was no physical means for the player to interact with the object in the game and potentially break out of bounds or somehow get through without completing the puzzle as intended. 

How it currently looks:

RPG Maker - Building aesthetics for the graveyard mini game:

With the basic mini game in place, the next steps was to set the theme for the scene by adding aesthetics such as weather and a unique track that plays within this mini game. Still sticking towards horror, darkening the scene would help build on the aesthetics of the level. 

The first screenshot (above) shows how the white flashing effect was designed for lightning. Choosing the Flash Screen Event that was built inside of the engine, would allow an easier method to implement the weather mechanic. The flashing occurrence was mixed between several different frames per second to help build variety to the pattern, making it feel more randomized. 

Making sure to set this to be Parallel so that it could work alongside the rest of the other weather mechanic scripts. 

The second script was also Parallel, however this script was slightly different. It not only contained the sounds of the weather but also the sound for the music you could hear in the level. Additionally, if the player successfully exited through the gate, the event would end so it would not repeat the music/sounds in the main lobby.

Here's a short video showing this:

After doing some playtesting, it was clear that what the player was expected to do within the game scene would not make sense if the person playing had minimal puzzle knowledge. To help assist with this, a new script was created to display a message on a small notice board to give a vague hint as what is being asked.

Allowing this new message to appear would help the player get a more better clue as to what they needed to do to accomplish the task and win the game. Additionally, having it be still vague meant that the hint provided would not offer a straight solution, but more of a reference point. 

Now that this mini game had been developed, the next step was to start developing a simple second mini game/mechanic. As this mini game could be advanced further later. 

RPG Maker - Mini game 2 development:

For the next mini game inside of RPG Maker, some research went into exploring tile/pressure plate puzzles and how various games (both indie and triple A titles) incorporated these. This was a mechanic that had never been explored before as a Game Designer, so this felt like a good area to look into.

Several examples of tile mechanics were explored in games, such as; from activating traps to unlocking doors. Continuing, games like RuneScape (specifically for dungeoneering puzzles) used their own methods of pressure plate puzzles to restrict the players navigation in order to press them and advance. In games like Skyrim, tiles/pressure plates were used to activate a hidden trap that could hurt the player if they stepped on top.

Here are some examples that were studied:

For this mini game in particular, having the player activate (or step onto) the wrong tile, would send a message to an enemy to chase the player. Because of this, looking at other games that did similar mechanics such as Five Nights at Freddy's and their fan games. Though the Ai in those games would not necessarily trigger based on a players incorrect input, as most of the enemies in those games would either;
- Chase the player upon being seen,
- Could get the player if they left themselves exposed.

As the aesthetics of the Five Nights at Freddy's was very appealing, this sort of direction was taken to create the environment the player would roam inside of. This was because it felt the most suitable for this type of mini game, because the checkered floor sprite could be used for this example. 

With this simple level layout drafted, the next steps for the mini game could be developed. 

RPG Maker - Mini Game 2 scripting:

Learning from the Graveyard mini game, it felt appropriate to design the players hint on what to do first rather than working towards the puzzle mechanics. This would not only help aid the players understanding of the task, but make the layout for correct/incorrect tiles easier. 

Using tools inside of Photoshop, 2 simple images were designed to give a rough floor plan for both sides of the playable map. On top of the checkered boxes, a red drawn line would show the player the correct route to take, based on the side they chose to walk on. So long as the player followed the line from the prompt, they would not accidentally step onto the wrong tile.

Next, to get the image to display inside of the level, the scripts trigger was set to Action Button to make sure only the player could interact with the prompt. From here, using the Show Picture Event to display the corresponding image based on the side that was taken. 

After a few seconds, this image would then be removed off the screen using the Erase Picture Event. This was similar to how Unity used the Destroy Object function. 

Here is an example video to show this:

Now that the basic hint designed and was useable for the player, the next step would be to get the tiles functionality to work. The tiles were the core mechanic for this mini game and making sure they functioned as intended was essential before progressing onto the Ai. 

RPG Maker - Creating the tiles and enemy for Mini Game 2:

To utilize the tiles to act like pressure plates, the script would start a Play SE Event on that current location to give the sound of a weighted plate being stood on. From here, the players movement would then be delayed through a Wait Event for around half a second. 

Then, the monster/Ai inside of the level would hear that the incorrect plate was stepped on, and would cause them to move towards the players position. Ensuring this movement was to be repeated so that once the player had triggered the Ai, it would chase them until the player was either caught, or somehow managed to escape the level. 

If the Ai managed to catch up to the player, a simple Text Event would display to signal the player had been caught. Eventually, leading to the game over. 

As all the enemy needed was to catch the player, the script would just include; 

- Text to show that the player had been caught (as mentioned above with the Text Event), 

- And would then initiate the Game Over event. 

Here is an example of how this currently looks:

The final basics for this mini game was to have a win mechanic. The point of this mini game initially was to have the Ai move randomly around but would only seek interest in the player if they went on the wrong tile. This could be potentially expanded on later, but for now the win state needed to be implemented so that the player could beat the game. 

RPG Maker - Mini game 2 win mechanic:

The simplest way to have the win mechanic for a game like this, was to reach the other side of the room where the exit would be located. Therefore, this was the route chosen. It meant that more time could be spent focusing on the other areas that would need more development work.

Using a Player Touch trigger, the script would run the Play SE Event for when the player reached the exit. Displaying an audio cue to inform the player that they had left the area. Additionally, some other Events were used such as the Control Switches, Control Variables and the Transfer Player Events.

The Control Switches and Control Variables Event was tied to the secret ending that was to be developed once the core games were made. If the player had beaten this mini game without stepping onto an incorrect tile, then they would make progress towards this objective. If not, then they would have to restart the game to get this to count. 

RPG Maker - Mini game 3:

This mini game would take a few known elements that were explored before, but with a new twist. There would be 6 switches for the player to interact with using the Action Button trigger. These switches needed to be flipped in a set order to win the game, if just one switch was not flipped in the correct order then they would all be deactivated and the puzzle would reset.

Before developing the switches, designing the Ai first would be the most suitable task at this stage. 

RPG Maker - Mini Game 3 enemy:

The Ai in this mini game would be chasing after the player constantly upon the game starting. This would add challenge to the player and make them feel slightly more punished when they flipped the incorrect switch. As this engine had a built in Autonomous Movement function, it meant that the Ai's script would just need the same Events from the previous mini game.

Provided the Autonomous Movement was set to Approach, the Ai would always be going towards the player. If the Ai had reached the player, then it would then cause a Game Over Event to run.

Having this Autonomous Movement available, meant more time could be focused towards expanding the switches mechanics for the game. 

RPG Maker - Mini Game 3 switches:

For the switches, other games that used a similar design for different types of puzzles were explored, getting a further understanding of how this could be incorporated into other projects in the future. Games such as;

- In Undertale, there is a puzzle where the player must step onto correct tiles to be able to progress forward, 

- Black Ops 6 has a keypad puzzle where you must guess the 5 correct digits to enter a door/room,

- As well as classic puzzles such as the water pipe puzzle, where the player must link the right pipe parts to flow the water from one direction to the next.

These examples helped build a further understand of how this concept could be taken, to a simple flip the switch mechanic that; if done in the right order could win the game. 

This was achieved by creating a variable known as Switches. This variable would check how many switches had been flipped in the correct order to keep progressing. If the switch the player interacted with was the next one in the sequence, the progress was saved and the player would then need to guess the next switch to keep progressing until they were all flipped. To further signal that the player had activated a switch, the Play SE Event would occur each time a flip had been flipped and if the incorrect one was pressed, another Play SE Event to also signal this action.

Then, using the Set Movement Route Event would run to change the position of the switch to make it go up or down based on the players actions. This would wait a few seconds before initializing this animation to make sure the correct switch was flipped, it would stay down. If the incorrect switch was flipped, the Text Event would display to the player, further signalling that they made an error and had to start over.

Here is a short example to show this:

With the basic switch mechanic in place, creating the script to check for the win mechanic was required to allow the player to return back to the main lobby/hub. Additionally, to also continue progressing towards the secret ending. 

RPG Maker - Mini Game 3 Exit/win mechanic:

Designing an exit mechanic was accomplished by ensuring the script would not be accessible unless the requirements were met, as well as setting the scripts functionality as Parallel. This meant that it could run alongside other events whilst a Parallel is active. This would allow this script to run at the same time as others without prioritizing it above essential mechanics (such as the Switches script).

This Event would run once all 6 switches had been flipped in order. It would display through the Text Event; "You solved the puzzle" on screen to signal that the player had beaten the game. Then, it would begin teleporting the player back to the lobby by showing a simple animation that is available within the engine. Doing this through the Show Animation Event, before then doing the Transfer Player Event, that would take the player back to the lobby/main hub. 

Having this animation felt suitable as it clearly showed the action of moving the player from the current game scene and back to the main level selector. Additionally, if the game had been won, the player would then advance towards the 'true' ending.

Here is another short video to show this all in action:

Now with the basics of the third mini game designed for RPG Maker, all of the core features needed were designed and working as intended. All of these mini games could now be expanded further based on feedback that could be received for their current state and based on time limitations.

RPG Maker - Feedback and next decisions: