It's time for the monthly progress report!
A lot of what I am going to cover today was actually covered in my last dev stream. Honestly, you'd probably get all the information faster by reading this, rather than watching it; but watching it might include some additional insights and thought processes behind my decision making if that is something that interests you.
The video is here:
FAST TRAVEL & FAST TRAVERSAL
First, I want to talk about my new fast travel system. I believe it was Mr.
@RCXGaming who talked about the importance of fast travel systems in modern games. He helped motivate me to think about traversal, and after letting
@TESTOSTERONE , Wind Ryder himself, get special access to an extremely busted build of the game, he pretty much set in stone the importance of reworking traversal in my game; mainly within the Cave level (the level that the beta test from last year took place in).
Redoing fast travel event
So it's funny to me, that I clearly was aware how important quick traversal was in the first level I built, the Seas, because from its inception it had both a key item that could be used to create a short-cut and a teleportation system to jump around to specific points on the map.
However, I had tunnel vision (ha) on how I wanted my Cave to be formatted. I felt like these tools could not be used in the level. But thanks to RCX and Wind Ryder, I folded on this.
So in my efforts to improve traversal, firstly, I remastered my teleportation system so I could implement it into the Cave.
The new teleportation system looks like this:
This video was made mostly to show off some of the sound design work I had done (Including positional audio), but it also shows off how it works.
Basically; the player will unlock new fast travel points as they explore the level. Once unlocked, they can jump to it at any point in time - pretty standard fast travel system.
However, what you don't see in the video is the "Restore Fidel's Position" function.
RESTORE POINTS, QUICKLY GET BACK TO THE ACTION!
Restore Fidel's Position
At its absolute basic functionality, it is just a checkpoint system. Whenever you change map or reach certain trigger zones, your position will be saved to a checkpoint.
In my game, whenever you die, you are brought back to town. This checkpoint system means that after you are done fiddling around in town, you can go to the teleporter and jump back to the last checkpoint before you died.
What is unique about this is functionality that had to be built into it because of the way players are able to play the game.
It's a nonlinear game, so players can take on any level they want at any time they want whenever they want. So it is very much possible for a player to go to one level (let's say the cave) and then die (or save and quit - we'll talk about this later), and then decide that they'd rather make some progress in a different level (let's say the Seas.)
With a typical checkpoint system, you are just constantly overwriting your checkpoint with the most recent checkpoint. Well if that's how I did it, then if the player decided to go to the Seas, then when they return to the Cave and use "Restore Fidel's Position", Fidel would be brought back to the Seas. Oh dear. Now poor Fidel would have to trek all the way back to where she left off in her Cave Adventure because she dared to take a break and adventure around the Seas.
So, the checkpoints are unique to each level. When you select "Restore Fidel's Position", Fidel will be restored back to the most recent check point within that specific level!
That pretty much covers the fast travel system so far. So in a nutshell,
Players can unlock dedicated fast travel points as they explore and use those points to quickly jump to different portions of the level.
Players have checkpoints independent to each level of the game, and when returning to the level, they can use the fast travel system to jump back to their most recent checkpoint.
Next is traversing specifically the Cave...
REVOLUTIONARY DESIGN: GOING UP AND DOWN
One-way design is gone.
The cave was designed with this idea of "one way forward." The fish mechanic - allowing the player to catch a fish then throw said fish into lava to create a temporary platform across (yes it's silly) - is designed to facilitate the one way direction of the cave. Once you jump across your temporary fish platform, there may not be a fish to catch on the other side to go back.
The cave being split into what I called a "right ribbon" and "left ribbon" (called ribbons because it's a thin, long, linear path that loops back around on itself), the right ribbon puzzle gimmick is that the player could only test the results of their puzzling later. With the actual elements that control aspects of the puzzle on the lower part of the ribbon, and the ability to complete the puzzle on the upper part of the ribbon, the player needed to observe carefully what the puzzle elements are doing, and have the foresight for how those puzzle elements should be set up for the future.
If the puzzle elements were not set up properly: bad news: It's a one way trip back down the cliff face for you to adjust the puzzle elements, then have to shamefully walk all the way back around to the upper ribbon again. (And sometimes that could be a really long walk).
This is really unfairly punishing to the player. So to alleviate this unnecessary back-tracking, I have changed all of the one-way jump-down points to points where the player can place a ladder to climb down or up.
While both of these updates break the original philosophy of the Caves design, I feel like these improvements both improve the overall experience (making it less stressful) and better aligns with the overall philosophy of the entire game which is to play however you want.
Next up is Parallaxing! Let's make those maps beautiful!
MAKING MAGNIFICENT MAPS
I have been struggling with the flat look of my game. It's hard to put into words other than "flat" to describe my game, but it's just this feeling that things aren't really popping out. I talked about this in my previous update post on the game, so we'll just gloss over this. (You can read more about it in this post here:
LINK TO POST # )
I started by doing a few tests on the on-going Forest level, then decided to test to see if this could be applied to The Seas level (which has the largest map in the game). As mentioned, this was talked about in the previous update, so let's move on:
The Results (featuring images!)
Looking Ahead
Red Juice & The Fox
Currently I am working on improving the logic on a few aspects of the Forest. It's better to do it now than to have to do it later after all of the events have been placed. This is also mostly coming in the way of how to handle certain aspects (such as all the Red Juice resources) after the level is complete. Do I want the player to still gather those resources? Thematically it wouldn't make sense (your goal is to cure the forest of it's Red Juice ailment), but it would serve a game play purpose.
The item you unlock in the Forest (as previously discussed in this update:
LINK TO POST # ) allows Fidel to change into a fox:

However, this form requires Red Juice. After the forest is complete, the readily available Red Juice resource would be depleted, obviously making it tough to stay in the fox form if you can't get the resources to sustain it.
On the one hand, I considered adding a quest that would allow you to permanently switch between Fidel and the Fox without the requirement of resources, but that is additional scope. Maybe in the future this can be added.
In the mean time, I decided that one Red Vine tree will get planted in the town center (bye-bye fountain!) after the player completes the Forest level. Therefore, the player will be able to interact with this tree at any time and extract some Red Juice for the adventure ahead.
Load game, Return Home
This is still something that is in the
"I'm thinking…" stage, but I am thinking of changing how the whole save system works in my game.
Anti-save scum, philosophy matching save & load!
I have already partially achieved this by creating a call-able autosave event that will overwrite your existing save. This is to prevent save scumming by just aggressively and constantly overwriting your existing save to prevent you from "rewinding time".
However, the new part of this is how to handle loading the game there after.
I am thinking that whenever the player loads their game, they will be returned to the town. Easy enough to execute at it's most basic form; I already have a plugin to run a on-game-load common event. However, there are many situations where I DON'T want the player to be returned to town otherwise it might break things.
The pros:
It encourages one of the main pillars of my game: interacting with the town. It's just another way to encourage players to not ignore it if the game is constantly gravitating Fidel back to town.
It hopefully encourages players to consider their quit points; both discouraging quitting mid-level, while encouraging quitting when back in town ("Well, I'm already in town, so might as well quit now.")
The Cons:
Both of those pros can also be cons, being brought back to town means the tedious trek back to where you left off.
It will probably take a lot of tedious work searching and accounting for the edge cases where I would want to disable the on-game-load common event. Missing even 1 spot where the common event should be disabled could potentially result in soft-locks and completely destroying a save file.
As of now this has not been implemented (if that wasn't obvious already), however I will continue to think about it.
Fidel & The Maker's Trial
(The OG, the prototype)
At
@TRIDIUM 's request, and because
@hiddenone is kind enough to play my jank old game, I'm going to link it here and make this more obviously public. This is the prototype to Fidel & The Pauper's Paradox and was a game I developed in a month just to help me come to grips with RPG Maker.
Fidel & The Maker's Trial by NolanAlighieri
To be absolutely clear: This game has nothing to do with the current Fidel & The Pauper's Paradox project other than in name.
It's pretty jank, here's some info about it...
It's about 2 hours long (depending on your RPG-ing/Puzzling abilities) and I think has some cool ideas that were obviously not well executed. Some of the foundation of Pauper's Paradox is there, but I can promise you that Pauper's Paradox has refined...uh...most everything you see in this OG prototype. Those who play Maker's Trial now are likely playing the best version of it due to the number of updates I have done since it's launch. I still support the game, if not a bit irregularly.
It is filled with some jank, I don't intend on fixing it, however I do still enjoy the project for what it is, so if there are major errors such as critical bugs (such as softlocks or crashes), balancing problems, or minor grammatical issues then I can issue an update. (I might only issue an update for grammatical issues if there are other issues to fix too. No reason to push a full update for a typo)
Any feedback you do provide, however, will help me consider design choices for Fidel & The Pauper's Paradox or future projects, so while I don't intend on changing much of the OG, the feedback will still be valuable.
If you leave feedback on the OG game, it would be appreciated if you title your post or include bold text to indicate that it is feedback for the prototype/OG. This will reduce possible confusion as to which game is getting feedback
And that's it for this month's update! Thank you everyone for your continued support and interest in Fidel & The Pauper's Paradox's development!