Please confirm you are at least 18 years old of age. Otherwise leave the website.
Sign up
Log in
18+
michaelpstanich
I work in various mediums and will be releasing content ranging from safe for work to R18+ content including Art, Video Game Mods, Video Games and Dev builds, Technical Articles, Game/Tech related videos, AI Work, and whatever else I fancy and Subscribers request!
[Game Prototype!] [Project] Idle Fox RPG Now Playable!
Ok, "Playable!" may be a bit of an overstatement given this is just a prototype to test out the backend I've built over the last week and to set-up a release workflow. But still, I'm super excited! Currently I handle game projects as more of a background kind of thing and don't say a whole lot about them before they're ready, simply had to many projects fall apart and not go anywhere, but I'm trying something new with this one! (Also worth mentioning, the title is very much a WIP title and just a placeholder! We'll have a fancy name soon enough! ^-^) Some quick things to mention about the current build, I wanted to just develop something over a week and see how much I could get done and set myself a (relatively) strict release timeline to get whatever I had done out by the end of said week. Technically I took a day longer than planned because I had some save-system issues and got too tired to release yesterday, but 1 day off isn't bad! This version is a very simple front-end and gameplay loop to test the backend systems that will power the actual game, but this does not represent the gameplay of future versions (I already have stuff in the works that will change things rather drastically ^-^). So consider this a test prototype purely designed for testing! (In-fact, a community member in the Discord, alphabetsoupdog123, already helped me find a logic error which I fixed earlier today! Thank you, alpha!~)
Although there are executable versions available for testing (I specifically need people to test on Linux just to make sure the export is working on different repos), I recommend checking out the web-version over on my site for easy and quick testing! (Future supporter-only versions won't release on web, sorry! >.<)
(Changelog will not be available for this version) Basically I implemented various back-end systems which probably are not worth documenting in a front-end sense, and since the gameplay of the proto-type doesn't match what will be the 'actual' gameplay it felt a bit unnecessary. X.x
Ok, so, what's the deal?
I felt I should introduce this game with a bit of an explainer, especially considering I've been already working on another project (Data:EnCryptic). There's a really common issue among creatives like myself where we tend to get really ambitious visions and projects tend to scope out of control rather easily. This is something I've been really working on over the last year and it was my goal for 2024 to release a game in some form or another. But there's a snag, I typically don't like releasing things that are unpolished or have issues, it's been a major struggle for me personally to release dev-builds for projects as frequently as I have, but honestly it's been a very positive experience overall I think and has been inspiring for many of our community members! So, I wanted a game project I could try this with while also having a bit of a simpler, non-scoped to hell and back, concept to help test-bed ideas and create assets that can then also be used in other projects.. hopefully. (if they don't suck too much X.x)
So ultimately, I decided a bit off-the cuff I was going to start a project and just release whatever I had after a week of development, see how much I could get done from scratch and for myself to break my habit of 'just one more thing!' That does mean this initial release is VERY underwhelming and I don't think it'll be of any interest to many, nor will the next few releases honestly, but there's the origins and why this is kind of out of no-where!
The Game Concept
Idle Fox RPG (WIP placeholder name) is an incremental RPG inspired by character-focused RPGs with diverse ways to level up and acquire skills, along with inspiration from other incremental titles. (Although many equate idle and incremental as the same game genre, Idle Fox RPG will have a more active play style and be much quicker in progression when actively played, but offer some AFK style options in the form of the auto-choice tree mechanic!) In Idle Fox RPG you play as a demon-born fox lady who's been freed from the void by a mysterious fairy with an attitude. After freed, this confused fox lady is able to explore the world and make decisions as she sees fit, she can go out hunting materials for new fancy outfits and gear, fight off the local bandits to raise some reputation, take in quests from tavern go-ers for some coin to buy more pillows, or just sleep the rest of this realm's short existence in the comfort of her new den! The choice is hers yours! Every activity is a skill, every action working toward your strength, every item holds value, and every choice determines your path!
Graphics
Since the current version in this posting is fairly simple and lacks any graphics, just a basic interface for testing values and systems, I thought it would be important to outline exactly what my goal here is. The goal is for Idle Fox RPG to be a fully 3D game with 3D character models and 3D environments, but with a bit of a confined scope. One of the main concepts behind Idle Fox RPG is cosmetics which will integrate with various systems and act as one of the driving factors for players (hopefully, anyways >.<). I'm most likely going to use a cell-shader and painterly textures as this is suppose to be a chance to build assets for Data:EnCryptic as well, locations will be small island like locations with simple randomized geometry with a few key locations having much more to it. The UI will most likely follow Data:EnCryptic's design language with simple but sharp UI elements (I know I haven't shown this off yet, it's not 'quite' ready), though I'll most likely aim for a brighter and lighter mood to the overall style. Animation wise I also want to try a more comical/whimsical approach than my previous works, so we'll see how that aspect goes!
Game Systems and Gameplay Loop
Exactly how things will link together isn't quite figured out completely yet, but there are various systems which I'd like to test and have already begun building and implementing into the game. The general gameplay loop has the player looking at their various objectives, both in-game and personal progression goals, then using in-game information to decide where to go and with what gear. Gearing up and selecting a class for the switching system is integral to the gameplay loop where before heading out the player can define different sets of equipment and class combos which will determine what they will have available for that journey. Once prepared, the player will choose on a hex map what region(s) to explore with each hex having different rates for certain activities such as combat with enemies, finding resources for harvesting, or treasure finding! While exploring the player will manage their inventory and can determine what actions the fox lady takes, optionally there's also the auto-choice system which acts like a command list of actions the fox lady will perform on her own through an if-then branching system. Actions run on an act and wait system, think turn-based but real-time by default.
The progression loop is a bit less defined at the moment as I'm still investigating what the best methods for handling different mechanics would be with this kind of gameplay loop. Ideally the player will have various choices in how they want to approach their goals, every activity the fox lady can take part in will have a level associated that will attribute to her base stats and improve her abilities in all other tasks, and every item will have some sort of base-value that can convert down to universal currencies. Currently, the plan is to have the player build up their skills through activities, build up resources to craft their own gear with gear having durability and a life-span. Since gear breaks eventually, the idea is to have upgrades to crafting be a central component where you slowly build-up minimum crafted qualities that make gear acquisition for your favorite sets easier. As the player progresses they'll unlock new cosmetics like outfits, tail/ear customization, apply-able colors, animations, along with your typical new gameplay locations. (how these unlock systems work is yet to be determined)
If you have any thoughts, ideas, suggestions, or are just curious on further discussion, we have a dedicated channel in our Discord that's well worth checking out!
What's Next?
If you try the version from this post you'll notice it's pretty bare-bones as just a very basic and default Godot user interface and some buttons! That's obviously not how the actual game will look, so the next step is getting some 3D models, implementing the proper stylized shaders, and then starting to implement the actual mechanics! Part of building the prototype was getting a lot of the back-end stuff set-up as well as planning the methods to accomplish it. I didn't quite get 'everything' I wanted done before this week was over, but with the systems I've built already, adding new systems should be a lot easier since the base-line types are in-place and what's already built could be extended pretty dang far. Building 3D assets, however, can be VERY time consuming, especially with how slow I am working in blender at the moment, but that's the next major step! Hopefully the next version upload looks completely different and resembles an actual game!
1 - Implement environment models and build transition systems. 2 - Introduce proper player model with clothing system. 3 - Build shader/visual system for the intended cel-shaded style. 4 - ???
EDIT : Uploaded a v2 versions which just allows you to set 'Max Wompage Count' to 0 which disables random Wompage. Someone on LoversLab mentioned they couldn't do a boss fight properly because there was too much Wompage! This allows you to disable Wompy Womp before entering such a serious situation!
People have been asking for a gamplay mod for SCake constantly, and, well, here's one that's reasonably usable! Is it great? No. Does it exist? YES! Wompy Womp - Random Sexy Edition is a quick mod I put together more-or-less to prove a point and show you can make a usable gameplay module for SCake in a very short period of time, and here's the result! Wompy Womp - Random Sexy Edition is a mod for Project Sugar Cake which periodically scans for characters and starts random erotic animation events with other characters nearby, making them Womp! The player is only considered for random events if they are above 200% Sex Heat, but if the player is in a solo animation then WompyWomp will scan for another character to add into the Wompage! There's a handful of other things, like there's a menu for customizing how often WompyWomp tries to start an event, how many events can run simultaneously, and how many attempts WompyWomp will make before waiting again. Matching is also done on a distance basis, first checking the closest character when matching so if you're doing a solo womp-session, make sure to be close to your favorite womper!~ =^.-=
Wompy Womp is an example mod and has Source available! You can either get it on Discord (for free) or in the restricted post on SubscribeStar for Subscribers! (I have an upcoming blog post covering why it's restricted within the next week)
This mod is the result of a conversation in our Discord, The Broken Chatbox! A shout-out to Shenova for suggesting this when I had nothing better to do (apparently), also a thank you for testing it! If you'd like to join in discussions like this, see live dev updates, or just hang out, please don't forget to join The Broken Chatbox!~ (https://discord.gg/h3vB7S4FEw)
Periodic (defaults to every 15 seconds) random scanning for matching random characters for animations, randomly chooses between 3 distance fields (Near/Mid/Far) and selects a random target in that distance to match with other characters nearby, matches are only considered valid if they are within a certain distance of each-other
Added a feature which adds the Player to the random scan if they are at 200% Sex Heat or higher (also adds summoned pal if they are at 200% sex heat, but I think they were already added in near scans anyways)
Added if the Player is in a solo animation then when a scan is performed it will try and match the player with another character nearby without doing any normal scans
Added all scans are done by distance first, so closest character is checked first then gets progressively farther as attempts fail or are considered invalid
A max animation handled count meaning only a certain number of random animations will be triggered at once (defaults to 1), more random animations won't trigger until these events have ended, player solo animation check is excluded from this value and will check regardless of how many animations are going
Added a simple menu to customize the frequency of random checks, the max number of random events going at once, and how many scan attempts are allowed per-check all with descriptions, does not persist between sessions and must be editted when loading into the game if desired
What's Next?
So this is a bit of an odd one, because this isn't really a long-term project or anything. Instead, Wompy Womp was just an off-the-cuff project that only took a few hours to put together and acts as an example of a simple gameplay mod for SCake. We've been struggling to get more people on the coding side of Palworld modding so the goal here is to show how quickly and easily you can get something up and running. It only took 15 minutes to post the first iteration, then I logged 4.5 hours on this project before having what we got here (sans some spelling corrections I just did last minute... I wish I could spell properly Q.Q). I'm also providing the source so other modders interested in making modules for SCake can see a simple example and use it as a reference or jumping off point for their own ideas. There are some complications with sharing source files with Unreal Engine I'll be covering in a future post so I won't go over it here, but I do need to be careful with where and how I share these source files so they won't be posted publicly and instead be restricted to Discord and a restricted SubscribeStar post for now until some concerns are addressed. (I am NOT trying to paywall the source, because of how unreal assets work it's just not safe to share the source as openly as other types of code projects unfortunately, however I will be using this method to distribute the code for all the modules I make and eventually SCake/Altermatic/UniPalUI as well)
Currently there are no plans to expand Wompy Womp - Random Sexy Edition, instead these features are going to be expanded upon and included inside the 'Palicious' gameplay module I've been working on.
Project Sugar Cake v0.5 DEV Available! [Palworld Mod]
(New Custom Objects!)
Hmm.. where do I even begin with this update.. It's been much longer than intended since the last update for Project Sugar Cake (sorry! >.<). From accidentally not releasing 4.3, to finding all new issues which required massive reworks, to requests for the API that wouldn't work with the current system, this update has been a bit of a mess internally! But either way, it's here and it's a massive change! (At least on the backend, more about that later!) Honestly, at this point, I can't even REMEMBER what the goals of 0.5 where, but I sure hope I hit those goals! This update featured some massive changes for the backend as well as integrates UniPalUI! (Note : UniPalUI is now a requirement for full functionality!) The first major change comes in the form of custom data objects, previously SCake used a lot of structs but we found that could cause issues with future compatibility when integrating with mods so I decided to move a ton of things to custom objects so they can be more easily accessible and simplify/speed-up some internal systems while also exposing those objects and their variables to the SDK, allowing more complex modules! I'll be expanding on this in the future, but other changes include the transition to UniPalUI for the UI and input, new debug controls that allow more than just 2 actors, a FreeCam mode while in animations (heavily requested!), and a TON of bug-fixes! There's also new detection methods for persistence which should help make it more reliable/performant!
This version comes with the all new detection methods for faster, more performant, and hopefully more reliable detections for tracking and stats! If you notice new issues with these detection methods, please let me know ASAP!
This version switched to UniPalUI for both input and UI handling, UniPalUI is now a hard requirement for SCake to have full functionality!
Do-to saving changes and fixes to the persistence, "SaveSystem" and "SavePal" files from older SCake versions have been invalidated and will reset when loading with the new version. If you wish to keep your old save data despite the changes you can change the save file's "SCake_ModVersion" to "5000" in the associated SCake_SavePal_WorldID.json file, however a lot of data may not load.
This version adds functional Altermatic integrations, requires Altermatic 0.4.0 DEV or newer to take advantage of them! If an older or no version is present then the integrations won't function. (Altermatic is not a requirement, just listens to calls made by SCake for certain functionality)
Adjustment profiles have been reset since the way they are tracked and saved has changed
Added :
__Create_Load_List__.bat will now try to scan .json files for UniqueAnimID and UniqueEventID to try and predict if the json config actually contains animation data (the ID is required for anims/events to register, so if they are excluded then it most likely isn't an anim config JSON)
Started transitioning to the new Unified UI system (May release as its own framework in the future)
Improved and re-enabled Async systems on the Register, this will drastically reduce the freeze-up on initial load but anims will take a short bit to register after the game starts up (Lock-ups can still happen depending on what anim packs you have installed and your hardware, packs with excessively large AnimJSON files will cause a lockup when loading in since the parsing of their data couldn't be fully asynced this update, solution is to create an async parser or have creators split up their json files into small chunks)
"SCake_GetAnimObj" API Function, this returns the AnimObj which stores the data for an animation
"SCake_GetEventObj" API Function, this returns the EventObj which stores the data for an animation
Register now also sends the "Report" to UE4SS's console when "Set_ReportRegFails" is enabled (Still sends an in-game notification)
Added new FreeCam mode which triggers while controlling an animation, use WASD for forward/horizontal and QE for vertical, mouse controls camera direction (Disables while the adjustment menu is open, no gamepad controls for now)
Animation switching in Animation Control menu will now show the Animation Event details in the description box similar to the Animation Event List
Aroused Morphs now apply to all mesh components on an character (enables replacers that use alternate replacer methods or for add-on mesh objects to have functional Aroused morphs)
SCake will now have integrations with SCake and be able to call certain functions when required (Only available on Altermatic 0.4.0 DEV and newer!)
"SCake_ED_SexEquipChanged" Dispatcher, this is called whenever the SexEquip for a Pal Character with an associated PalComp changes (should also trigger when a new comp is first created, however using SCake_ED_TrackPalEnabled is better for that kind of use case)
Added new randomized gender/sex equipment spawning system, now when characters are first detected they will be assigned a random gender based on the user's preference settings (on a technical level, the sex equip is now stored in the PalComp which is used for tracking)
Added Player gender as its own separate setting so it is no longer tied to the no-longer existing hard gender swap system
Added an all new detection system which is replacing the old 'forced' detection system, this new method hooks into game functions and is much more reliable but still needs testing to find edge cases (the old methods still run as a fallback but at a drastically reduced rate)
"Natural Sex Heat Rate" added to the menu, this configures how quickly Sex Heat changes naturally over time before any multipliers or additions
Changed :
Most defaults were changed from their initial 'debug convenient' settings to more gameplay focused settings
- Max Event Duration (90sec > 300sec)
- Base Pleasure Gain Rate (120 > 80)
- Pleasure Loss On Orgasm (80% > 95%)
Drastically reduce default Sex Heat Gain over time (Multiplier * 1.4 per hour > 0.4 per hour) (This should reduce how often characters get aroused and allow more dynamic systems in the future, this should cause heat to 'fill' after a couple in-game days)
Characters should no longer gain Sexual Pleasure or Sex Heat while orgasming (should freeze at the reduce value)
"SendReportMessage" aka Notifications now show through the Unified UI system (UniPalUI)
Most input is now handled by UniPalUI
Animations and Events are now stored as custom Objects (SCake_AnimObj and SCake_EventObj), this allows more flexibility, is more stable to expose to the SDK, easier to use for modules, and should be faster in more complex scenarios
Extended fail conditions for the Register to now fail when non-critical stuff is also invalid such as climax definitions (should help to ensure better compatibility, reduce confusion, and help modders debug their JSON files)
Changed some menu wording/titles
Completely transitioned to UniPalUI for all settings and configuration
Completely transitioned to UniPalUI for all input registers/handling
Changed all controls invalidating all previous keybinds
- Debug targetting changed, now you use the debug keys to select targets and hold a key to start an animation with all targets (This allows animations with more than 2 actors at a time to be triggered in debug animations, previous trace limitations still apply)
- Shift+K : Open Animation Control for Target (Hold for summon)
- J : Touch Self / J with Debug : Target Self for Animation (Hold to touch self)
- G with Debug : Target For Animation (Hold for summon)
- H with Debug : Clear Animation Targets (Hold to start animation)
- R in Anim : Open Adjust Menu
- Shift+[ with Debug : Increase Sex Heat of Targets (by 10)
- Shift+] with Debug : Decrease Sex Heat of Targets (by 10)
Extended distance all debug keys are able to function at
Sex Heat now caps at 1000
During Animation Control, pleasure bars now show at the bottom of the screen and have a different look to them
Increased the time orgasms add to animations without a climax animation to 8 seconds (was 5)
Slightly changed default gender assignments for NPCs (All NPCs should now assign as either Male or Female with Male being the 'default')
Re-organized the Preferences menu to show gender options first, separated Player Gender as its own option within this menu instead of a sub-menu, added appropriate menues for other additions
Preference Settings now contains the Player Gender on it rather than in a sub-menu (it's its own setting now)
Changed hard gender switch menus to "xxx Gender Spawn Rates" for the new dynamic gender spawning system, this menu allows you to set percentage chances for different gender spawns
Changed hard gender switch for human characters into a "base gender" menu where you define what in-game gender each NPC type should be recognized as by default (in-game NPCs have their gender set to 'None' however SCake no longer takes in none as a gender and instead defaults to Male, for female NPCs this setting should be changed to "Female" while the rest can be left as is)
SCake no longer uses "none" as a default gender type and instead assumes male for all undefined genders, none was removed from menu selections (Note : None is still used when defining requirements as a "no sex equip required" type setting, characters will just no longer have a 'none' option)
Requirements for pals to persist have been made more strict to prevent non-relevant pals/npcs from accidentally being tracked while also adding additional systems and checks to make catching when a pal should be persistent much more reliable
Adjustment profiles now account for all characters in the animation when determining a profile to use, this should prevent issues where animations are available for multiple sizes (this update resets old adjustment profiles with this change, uses scale factor which is mostly untested so hopefully it works but if not we'll have to try again with a different method)
Changed some key values in the SaveSystem JSON (since it was being reset this update anyways, figured I could simplify it a bit and remove unnecessary prefix')
Removed :
API Events "SCake_RegisterAnim" and "SCake_RegisterAnimEvent" have been removed to help streamline loading and removed some dependency on Structs (A future version of these functions will be made which allows you to directly create the necessary datamap which will work the same way JSON registration currently does, this allows more features to be utilized with BP anim registering and prevent breakage between versions)
API Function "SCake_AdjustAnimCamPos" has been removed along with the old camera system (Replaced by freecam)
Removed old menu and menu control (Menus are now handled by UniPalUI)
Removed "Game Settings" from SCake's menu since it had no options within (Will return if there's ever anything to add in there)
Removed cam position saving for animations and removed this param from the adjust profile (May be possible to add back in a new form but with the new free-cam the old system no longer functions)
"Use Global Cam Adjustment" has been removed (Made invalid by new FreeCam)
Hard gender switch settings and system completely removed (replaced by dynamic gender spawning system)
Fixed :
__Create_Load_List__.bat will now properly run in admin mode for all users regardless of your environment set up (while in windows at least)
__Create_Load_List__.bat now properly checks for the .json extension before adding to the list
Anim compatibility checker was sometimes checking SexEquips in reverse, making Futa/FullFuta/Andro types not always behave as expected
The __Create_Load_List__.bat file should now work in file paths with spaces in them
Debug Input for starting solo target anims should now report errors like other debug functions (should be easier to understand what's happening, the lack of a notification was just an oversight)
Registration no longer ends early when an AnimJSON used UniqueAnimID or UniqueEventID but included more than one register variable
Co-op skills should now be disabled during player involved animations
Andro should now proper register in compatibility for animations and not break the compat settings (was being skipped in the parser and messing up the compatibility map)
Optimized the JSON parser to save directly to the anim/event object which is a decent speedup
Minor optimization to JSON parser (new method is being investigated which could both save more memory and be much faster, however implementation is difficult)
Removed a lot of unused/unnecessary data which should improve memory usage (and potentially performance?)
Event Register should now properly compare compatibility across all animations and only register with compatible matches
Minor optimizations to save/load functions (switched some methods around for a theoretical 10-25% speed up with their use, but will most likely have no meaningful impact overall)
When calling "SCake_GetPalComp" with a valid pal but no associated PalComp exists, one will be created and properly initialized (This is how the internal function already worked but the API wasn't using it, now it is)
Fixed pals not always being set as persistent when loading from the persist file, causing their stats to reset randomly after a game load (the new load system uses a persist value within the tracker itself now instead of relying on live status read from the game, the original issue was caused when loading a persistent pal's data but it was invalid so it could not check if it should persist)
Fixed certain NPCs and Pals from events being accidentally marked as persistent (the game does not properly flag all NPCs/Pals which caused strange and hard to debug save bloat, stricter requirements and new manual persist methods work around this issue)
Added a delay to saving to help reduce potential stutter from saving at the same time as the game does (reduces processing on a single frame and splits it up a bit better)
New Custom Objects!
If you hadn't seen it, check out the previous update post for Altermatic which goes over a new custom save method which uses custom objects! That method isn't yet implemented into SCake (still need some internal changes before that is viable) but is something coming down the pipeline, but one thing I'd like to briefly touch on here is custom objects! Now it's fairly common in object oriented program to create your own custom objects, but a lot of people don't quite understand what that means, especially in regards to engines like Unreal Engine which have pretty much all the common objects built and ready to use by default. But further still, how does this related to modding? What's the benefit?
To quickly explain custom objects, in object oriented programming like C++ which Unreal Engine uses, you can define specific objects with different properties and you then can use copies or modified versions of these objects however you see fit through parent/child relationships. The specifics are complicated, but for those less technically incline just consider this like a custom basket you can make where you decide what goes inside, how you open/close it, where and how many handles there are, ect. Typically for mods you don't need these all that much since you're generally working on in-game objects, but if you want to implement your own systems it may become necessary depending how things are put together!
Originally SCake was designed to just use dynamic arrays and structs, structs allow you to have a set amount of 'data' in a specific structure which you can pass around like any other variable like a number but it has some major limitations. The first is that a structure has to be broken down and re-built when interacting with the contents, secondly you can't reference specific variables within it, and thrice they can be very tricky to work with and break between changes on them which would cause modules to need updates any time a struct changes. These things combined have honestly made me kind of hate working with Structs in Unreal Engine, especially since we're stuck to Blueprints where they can be even more trouble. The alternative was going through and making/using custom objects.
In contrast, objects are able to be referenced however you want, you can reference individual variables, and you can add/remove content without causing crashes from modules! Fixes all the problems, right? Well, mostly, because while custom objects do solve many problems they can also be tricky to work with in code. They must be created with a parent relationship, in this use case we parent directly to SCake's main actor which prevents the objects from being garbage collected. Objects also can't be passed as variables, instead you pass around references so this change required a complete sweep of the code to change how all these functions worked and how data is passed around. Other than that though? It's honestly been amazing and much easier to work with than structs! The major trade-offs we have to consider in the future however, is that Objects take slightly more memory and can only pass as reference so if we want to, say, clone data or use pointers instead of values we have to do all those calculations manually which could be a pain if ever required.
Generally though, I think this is a massively beneficial change and something I should have done from the start! Technically I was already using this method before with Actor Components, which are objects but with additional functionality like running OnTick and contain several other features a raw object type lacks. Stuff like the Animation Player runs inside it's own component called SCake_EventComp which each animation has its own instance to prevent accidental cross-talk, so it makes sense I'd also move things like Animation/Event data into custom objects as well!
What's Next?
Ok, we've been talking about multiplayer for quite a long while now, but I think it's actually going to happen. In the Discord we've been talking about it here and there and I plan to try and get a meet-up going in voice chat so we can get people together to test some various multiplayer stuffs! People seem really interested in getting it all going, so it's certainly the next major step! I'd also like to mess with getting audio (the next most requested feature) but right now there's some issues working with WWise that Palworld uses and isn't version safe so I may need to run with Unreal Engine's default systems and see how it goes. I haven't messed with audio for quite a few updates, not since I messed with subsystem injection, so that may be tricky. I also want to work on Palicious Lust, which is the Gameplay Module I said I'd work on and may release some early test version on Discord soon! (Also going to be trying to implement some animation related stuff, like getting mesh restrictions working and implementing the callbacks during animation systems implemented fully)
Current Road Map
1 ) Work on getting multiplayer working properly 2 ) Investigate audio integration 3 ) Work on Palicious Lust gameplay module 4 ) ???
Altermatic v0.4 DEV Available! [Palworld Mod] (Now With A 'Real' Save System!)
New detection methods are now live in Altermatic along with a new complex save system to help with performance and reliability! This update didn't really come with much front-end changes, but there's a good number of fixes and new backend stuff that is pretty transformative to how Altermatic works!
Worth keeping in mind, from this version forward UniPalUI will be required for the UI and input implementations, versions from this point on won't include the integrated version of UniPalUI to help with compatibility and reduce potential update confusion. This update comes with all new detection methods with the old method still available as a fallback that runs much less frequently. These new detection methods still need to be thoroughly tested to see what is/isn't caught, but overall the new methods should perform much faster and swap meshes 'generally' much faster with a few odd exceptions do-to pal initialization being inconsistent (for example, when taking a pal out of the Pal Box). The save system also got a complete overhaul with a much more complex system. This new save system performs much faster (a general theme of this update) and should be much more reliable but given the complexity is a lot greater it can also be much more error prone if done incorrectly, please report bugs if you find them! Thank you!
This version comes with the all new detection methods for faster, more performant, and hopefully more reliable detections for swaps! If you notice new issues with these detection methods, please let me know ASAP!
This version completely changed the internal structure (again) as well as the save system, all previous saves before this version will invalidate and swaps will re-roll as they re-appear
Added :
When SCake is also installed, Altermatic will attempt to re-roll characters if their Gender is switched through SCake's systems (functions through a dispatcher)
All new detection system which uses several in-game hooks to try and catch characters the frame they become visible, improving not only the visual experience but potentially performance as well (Still has the old method as a fallback but runs much less frequently which should result in a performance improvement)
All new save handler system has been added which should speed up save processing by using a custom object with less processing required while saving (stuff is saved into data-maps dynamically then converted into JSON when saving rather than working on validated/invalidated data when saving, should speed up the saving process drastically but is more error prone so requires much more testing/maintenance)
New menu using UniPalUI which shows the default keybind for re-rolling meshes and contains a new configuration menu
"InvalidID Attempts" config setting added, this changes how many times Altermatic will try and process an ID that's found but initially invalid
"Fallback Frequency" config setting added, determines how often Altermatic will use a fallback method for catching exceptions
"Reload Config JSON" setting to configuration menu which loads the current config JSON
Added config save JSON file called "_Altermatic_Config.json" which stores global Altermatic settings, this file should be created when editing the configuration settings and exiting the menu (If you edit this externally while the game is running you'll want to enter the menu and select the "Reload Config JSON" option to apply the changes, otherwise any changes you make won't take effect until you reload your save and if you change settings the config file may be overwritten)
Changed :
Changed the values for the Best Matching System so that PrefTrait matches now take precedent over no PrefTrait matches and also prevent 'IsRarePal' from being swapped with non-rare pal swaps (Behavior for "Rare" trait is unchanged)
ReqTrait match is now -25 degrade
PrefTrait match is now -5 degrade while a non-match remains +5 degrade
IsRarePal non-match is now -110 degrade
Rewrote the entire internal structure to use custom objects and expand the use of pointers rather than duplicating data, also required rewriting much of the swap logic as well (this includes a full re-write into the new save handler)
New save handler is much more aggressive in checking for characters that should persist (Player and Pals) however it is also much more strict in what it considers persistent (This should mean obvious pals that should persist like party summons should persist much more reliably but could also mean some edge cases may not meet the requirements of the new system, please let me know if you find things that should persist but do not!)
Removed :
No longer displays a message when SCake is detected (reduces notification spam, will move this info into the menu)
SkelMeshSwaps without a SkelMeshPath defined will now fail to validate (The null shortcut, "SkelMeshSwap":"", still functions but is highly discouraged as it causes many technical issues, especially with manual swaps)
Fixed :
Now properly sends notifications through UniPalUI instead of trying to run through SCake (Also fixed a potential crash when a JSON error was detected but SCake was not installed to send the error to the UI)
Integrations for SCake/UniPalUI now has proper guard-rails to prevent them running when they are not installed and causing errors/crashes (I think the only crash was the one mentioned just above, but now it should be much less likely to happen again)
Improved randomization for SkelMeshSwap by not relying on shuffle functions and allowing match pairings to search further
MatReplace should no longer accept null entries
Fixed certain NPCs and Pals from events being accidentally marked as persistent (the game does not properly flag all NPCs/Pals which caused strange and hard to debug save bloat, stricter requirements and new manual persist methods work around this issue)
Added a delay to saving to help reduce potential stutter from saving at the same time as the game does (reduces processing on a single frame and splits it up a bit better)
Building A 'Real' Save System
Strangely enough, this actually ties directly to my game development project Data:EnCryptic which recently I'd been working on revising the data structure for some new systems. One major component to an RPG (to which Data:EnCryptic is) relates to how the game stores and saves data. When creating a save system there's a few ways you can do it, but generally you have some sort of container which has the data that needs to be saved and is filled at some point then translate that container into a save format. In Data:EnCryptic's case, stuff has to save regularly and there's very little reliance on manual saving given the game has inspirations from idle games and potentially allows short play sessions.
What this ultimately lead to was investigating further ways to optimize the system to ensure it doesn't become a performance bottle neck, and that's mostly related to how we fill that container and translate to the save format. When modding we generally take the easiest route first, we need to just get something 'to work' and we often don't have to worry about any major issues arrived from doing things in a sub-optimal way. This means Altermatic (and SCake) ran its save system in very inefficient way. It's the first thing you would think of when building these systems, first you have the container, so when you save we just go pull all the data we need and put it into the container right? Then we just translate, so we just do it in 2 steps, easy-peazy! The problem? That's a LOT of work to do in a single process! When you're dealing with small amounts of data there isn't much of an issue, pulling a few swaps and storing it, then translating to a JSON string isn't too bad, but what about doing that while the game is already running logic and we start dealing with hundreds of swaps? It becomes a bottleneck quickly, especially on lower-end systems which is even more exaggerated by Palworld's already lacking optimizations!
So, what's the solution? Well, the solution in code and method is complicated, but in words it's quite simple. As the game plays and we start applying/storing swaps we then apply it to the save container we mentioned before, this fills the data so we don't need to pull the data when we want to save! Another addition is we can start translating any of that data which is immutable or won't change, and in Altermatic's case there's some optimizations I applied here. To get into specifics, Altermatic's save system now has a custom save object, this object stores various Data Maps for each different 'type' of data. When Altermatic applies a swap and notices it should persist between sessions it will then, at the time of the swap, process the swap and store it into these data maps. These Data Maps are actually already Strings as well since Altermatic has other storage systems for storing the actual data using pointers, though I won't get into the pointers system in this posting but know it basically speeds up the translation process to effectively nothing. This means when we save we actually just run a quick check to see if we've stored all the data we need using a quick id check, only processing what we'd missed, then we compile the data maps into a single JSON object and save to file! This DRASTICALLY improves the saving performance, and with the other optimizations I'm hoping this comes at zero cost in other areas (such as the pointers, which are also much faster than the duplicate data method I used previously).
Now, argue-ably this does have a minor trade-off of memory usage and some interface time when actually performing swaps which is why I had to also implement the pointers system. Previously data was stored multiple times depending on how often the data was used in swaps. Now, however, data is only stored once and everything else uses a pointer to the 'real' data. I won't cover the specifics given that's a whole'other topic to cover, but ultimately it means storing the data maps is fairly low on memory usage since the translated strings are just a list of pointers with splitters rather than full-form data! If you're curious, you can take a look at the save file to see what I mean! Each ID stores a pointer to a swap that then points to the appropriate data, though I do warn it's a bit difficult to read through without context. The real trade-off here however, is the loading and maintenance costs. Loading this pointer system requires some special logic which, while technically still faster than the old method isn't exactly 'optimal' given JSON still has to be parsed as a String, which is relatively slow (in Godot with Data:EnCryptic I use a binary file format by serializing the save data object which is much more efficient in all respects but also can't be externally edited without a specialized tool). For maintenance I'm referring to actually building and maintaining the system internally, a system like this can get very complex very quickly and given Altermatic now has several different detection methods and systems for applying swaps, I'd be lying if I said it didn't cause a few head scratches when something didn't quite work as expected. This means it'll take longer to debug any persistence issues, but overall the trade-off seems well worth it, and given Altermatic most likely won't see major additions in features for a while now it was a good time to do it... now I just have to also do this with SCake... Q.Q
What's Next?
Next I'd like to implement a menu for swapping skins on characters, preferably with some sort of selection state like maybe making the keybind Shift+O open a select menu for that specific character which shows different skins available to swap to. The only complicated part in that process would be creating a rendered texture to display in the menu, which is actually something I've never done in Unreal before! I am hopeful that research into that would pave the way toward reversing the in-game menu system and be able to reflect changes in the me paldex and various menus as well. After that I know some have wanted Altermatic to support player replacers in a much more dynamic way since there's not really a flexible framework that allows entire replacers and the like, so I'll most likely do some research in this regard while doing the menu stuff, if it's not too difficult I could implement it sooner rather than later but I have no idea what would actually be required here.
Current Road Map
1 ) Implement a menu for checking available swaps and swapping characters live using UniPalUI 2 ) Investigate menu replacement and player replacer method 3 ) ???
See something you like? Subscribe to see even more!
Subscribe Now
Creator Stats
163 subscribers
42 posts
Goals
$71 of $500
per month
(Monthly Goal) Would ensure part-time work on projects and ensure a constant flow of updates to content without worries of financial strain or burn-out.
$71 of $800
per month
(Monthly Goal) Would provide the potential to go full time, working on projects and producing content as seen fit by subscribers!
SubscribeStar and its trusted third parties collect browsing information as specified in the Privacy Policy and use cookies or similar technologies for analysis and technical purposes and, with your consent, for functionality, experience, and measurement as specified in the Cookies Policy.
Log in
