itch.io

If the crashes happen after a somewhat consistent amount of time, it may be your computer running out of memory. This could be easily checked by running a monitoring program (or just task manager) while playing the game.

RPG Maker is not what I would call memory-efficient and a plugin could be leaking memory.

I have seen probably only 10% of the game so I can’t speak personally on any other bugs, but after fixing all the filenames in img/layers/ I’ve had no other gameplay-affecting issues with what I’ve played.

The filenames are the only problem here, if you fix that first you should have zero problems with other platforms.

A little bit of foresight saves you a massive amount of work later, so getting it right the first time is worthwhile.

At the very least, try to be consistent with filenames moving forward to reduce the potential amount of work in the future.

This problem could be fixed with a simple script that rewrites all the paths but I really shouldn’t have to patch your game for you, especially for a problem so easily avoided.

If you have any questions, I’m happy to answer them. I just hate to see people walking into easily avoided pitfalls.

I don’t know if this issue is fixed in the in-development version, but you should normalize all your filenames to lower-case.

Any RPG Maker MV/MZ game can be easily ported Mac/Linux/Android by simply swapping out the NW.js runtime for one built for the desired OS, EXCEPT that unlike Windows, other operating systems give a shit about case in filesystem paths.

This demo functions perfectly fine on Linux (and likely other platforms) but fails to properly load several assets because of case mismatches.

For example, the game trys to load www/img/layers/31_Лока_Фон.rpgmvp but fails because the real name of the file on disk www/img/layers/31_лока_фон.rpgmvp.

This works properly on Windows because it has a case-insensitive filesystem for some reason so those paths are identical as far as it’s concerned.

This is easily avoided by just always using lower-case letters in filenames, or at least enforcing some kind of consistent naming for files.

For those who want to bother, this game should work on other platforms if you have the patience to rename all the files to the case the engine expects.

The proper way to fix it however would be to normalize the filenames and release a new build so the game doesn’t ask for the wrong path in the first place.

I have a bajillion things I could say about this game so sorry if an essay manifests below or in the following week/days but the short version is I am very intrigued.

I love solving problems by eating everything in front of me and I love a diablo-style loot hunt, so the core concept hits me right in the dopamine centers.

I’ll try to avoid too much obvious stuff and address what I assume are intentional design choices (or at least intentional compromises).

I’m going to be pretty critical but understand that I like this game enough that even with what I’m about to say I’m considering starting a new character to try a different build because the core concept is just that strong for me.

My principle criticisms are:

Camera

The range of couple late game enemies mean they can attack you from off screen and we are way too zoomed in in general. The (I’m guessing) easiest thing would be to just make the resolution higher. I don’t mean scale the game up, just literally make the viewport larger. At 1:1 scale the game uses like 50% of my 1080p monitor.

Also, whatever scaling method you use when the window is maximized is so horrendous it actually hurts my eyes. Probably could be fixed by just tweaking a setting in the game engine.

Combat

The combat just isn’t done. I don’t play a huge amount of platformers but I’ve played Hollow Knight so I know what a good melee-focused platformer feels like.

The most frustrating thing to me personally is how low the acceleration of gravity is. Jump timing is really important against a lot of enemies and it’s frustrating to have a literal metric ton of enemies in my gut and be floating around like a hot air balloon. (Not that your fullness should affect your acceleration, that would probably also feel terrible)

Contact damage that stuns you in a game with this many enemies (and very large, very mobile enemies- i’m looking at you fucking Alaska bull worms) feels awful. Most of your moves are very close range so the most effective strategy for enemies that you don’t outlevel is to just spam the airborne special which both has the longest range and keeps you in the air where you are less likely to be hit.

I’m fine with contact damage but it absolutely should not stun imo, i think combat would feel way better if it was more about juggling enemies than poking them with your feet.

I shouldn’t be afraid to get close, I wanna punch shit.

You could still have a stun on special attacks to make maneuvering and parries important, but every single trash mob stopping me in my tracks feels awful.

It’s REALLY IMPORTANT to make combat and movement work first, because you don’t wanna spend the time making a bajillion sprites before you know if the moveset you are animating actually works.

Quantity > Quality

There are way too many levels on each planet for the unique ideas each planet has. Like honestly I’d prefer there was 1/5 the levels but they focused on replayablity (random events, poi’s, etc). Most levels of the same “tier” feel largely identical anyways.

MORE EVENTS

The little text-adventure-stye encounters are great. They break up the combat, flesh out the world/level, and provide ample opportunity for kink shenanigans. I think the levels should be built around them, acting as primary & optional mission objectives driving the path the player takes through the level.

Personally the way I’d develop the levels is

1. Devise a setting (planet)
2. Determine the stories you want to tell in that setting
3. Build level geometry and encounters around those stories

MORE PROGRESSION

Just grinding for loot is already a pretty fun core loop, but I feel like the game could use at least one more avenue of progression. I’ll expand a bit on this is the following sections.

Mission Rewards

It feels pretty anticlimactic to reach the end teleporter and just be done. There should be some kind of reward for actually finishing a mission.

An obvious choice would be making finishing missions grant a large XP bonus or perhaps special loot that can only be dropped at mission end.

Inventory

The most rewarding part of the gameplay imo is grinding for loot, so the game desperately needs a real inventory UI. The inventory and stat screen should be one and the same IMO and you shouldn’t have to drop stuff to equip/compare it.

Late Game

A loot grind game can keep you going for a long time as long as you have something to be grinding for, but this game doesn’t really have anything to strive for after you reach the final area.

A very easy way to give the lategame some extra spice is to have a rare loot drop that lets you permanently increase one of your stats. It should be very easy to implement and nothing quite hits like a permanent stat boost.

Non-Conclusion

This is probably only 25% of what I have to say about this game but I’m loosing focus so I’ll leave it here for now. Excited to see what you do with this. :)

No worries, just trying to save you pain in the future. In traditional software development, you have something called a “feature freeze” where basically everyone agrees to stop adding new things to a codebase and focus on bug testing.

Alternating between feature development and bug fixing like this means public releases are as stable as possible which is of course nice for the players, but also provides you as the developer a stable foundation you can be confident of building on top of.

Giving it’s been a month it would probably be a good idea to release a version that has the disappearance bug fixed while continuing to develop the new content.

In general I would prioritize fixing bugs in the existing public release before developing new content, as the new content will often contain it’s own bugs that also need to be fixed, meaning there will only ever be broken public releases basically.

This way the prior build serves as a stable, reliable experience for us to play while you work on the new stuff.

Controller support seems borked in the Linux version, I have an xbox compatible controller that is more or less plug and play with a vast majority of modern-ish games but all I can get to work is basic navigation in the menus (using the Y button as select for some reason).

Also a big frustration I recall from the last time I played (on the Windows version, where the controller did work) is that menus couldn’t be backed out of via B, and you rather had to select a “back” option.

I recall this behavior specifically resulting in me buying upgrades I didn’t want multiple times (which to be fair, is mostly my own clumsiness) but having to manipulate the cursor just to back out of a menu feels Evil after playing so many games that make it a simple process of mashing B until I’m playing the game again.

This project is easily one of the more intriguing of the genre, excited to see it develop.

Love to see a developer bothering to compress their assets properly instead of shipping a 3GB game for no reason. 👍👍👍

Please give the files descriptive filenames including a version number, help keep everyone’s download folder a little more comprehensible. :)

Also, given that Vukan-related issues are apparently significant enough for you to release a second version, I would significantly consolidate and simplify the language regarding this.

I get this is the internet and some people will just never read the description, but for those who do you spend too many words on technical details that mean nothing to 90% of the people passing by who just wanna run the game.

Instead of naming the release after a technical term link opengl, it should be named “Fallback” or something similarly descriptive. Then, right at the top of the description, have a bold “Please try the fallback version if the normal version doesn’t work” disclaimer, instead of having it buried at the bottom with misc. troubleshooting information.

Anything particularly technical should be saved for a “Troubleshooting” section and be exclusively found there. I’m sure some freak into marketing could give you numbers on this but I’d say it’s safe to assume most people are only going to read the first 2 or so paragraphs of your description so make sure the most important stuff is there.

Walks into sushi restaurant

“Man, I fucking HATE fish.”

Since there hasn’t been a reply to this I’ll just put it on the record that the monastery isn’t complete. Curing amelie’s curse isn’t in the game yet. After you get access to the inside that’s basically it story-wise.

You don’t. You must play on a computer or an android phone (the apk).

Blame Apple, they don’t allow 3rd party software on their mobile devices.

Just a heads up, this sounds like an encoding issue, and even if you change this filename it’s likely to cause future issues.

What’s almost 100% going on here is that the filenames are getting mangled on decompression, as unicode support/implementation in ZIP is kind of a shitshow.

Basically, by default ZIP assumes the encoding of the system you’re extracting to is the same as the encoding on the system that made the archive so when you open it on Linux (an OS that’s bothered to properly implement unicode) stuff gets screwy.

Rather than renaming the file I strongly suggest using software that encodes in UTF-8 by default (PeaZip does this.

7-Zip doesn’t seem to and requires a special option set that would probably be too annoying to figure out if you aren’t the kind of nerd I am.

This shouldn’t cause any issues for computers that are newer than Y2K lol.

This should fix the issue this person is having but do a test with the default windows extractor.

Create your archive with PeaZip, extract it with windows, and make sure the filename is correct. If everything looks good you should then always use PeaZip (or other software known to probably encode in UTF-8) to create your archives and never have this issue again.

I see SO MANY troubleshooting threads caused by this EXACT problem and unfortunately the only solution is using better software.

I’m sorry I couldn’t resist. With any UI elements that display text, you’ll want to make sure that text has good contrast so you don’t give people eyestrain in a game that largely involves reading.

The easiest way to do this is to create a solid background in a color that highly contrasts the text and set it to a high opacity. (Probably at least 80% but whatever looks decent.) This way it should always be readable regardless of the background while still letting a bit of it show through.

Edit: oh, unrelated, but the executable installer is already compressed so putting it in a rar archive does nothing to reduce the size and mandates 3rd party software to get it out in most cases.

If it’s an attempt to work around Windows Defender false-positives, it doesn’t do that either. Just adds an extra step before the AV flips out at you.

This is a rough outline of what the process would look like:

1. Convert the story to the Twee2 format
2. Import the story into source control (git)
3. Sign up with a third party localization service and import the english strings (there’s a few of these, could probably help you pick one if you wanted to go through with this)
4. Integrate the localization service with your repository host (GitHub/GitLab/etc.)
5. Profit

This sounds like a lot, but I’d wager 90% of the process could be automated if you’re good at computer-wrangling (hi).

The hardest part would be moving away from the Twine GUI, as while there’s no technical reason it couldn’t support all of this, it doesn’t seem to be a design goal of the GUI despite the massive benefits source control brings to projects that are 99% text.

Once this is set up, filling in the blanks with machine translations for languages that don’t have proper translations yet would be pretty straightforward.

lol no it isnt. (Poor) quality of the machine translations aside, integrating them into the game without an automated build process would likely take longer than writing the original text did.

This game has a lot of soul and I’m excited to see where things go! If you need more eyes looking over the project I’d be interested in helping too.

I’m pretty good with the technical side of things and with solo(ish) projects it’s important to automate as much of the development side as possible so you aren’t spending your free time computer-wrangling.

I haven’t exhausted the contents of the demo yet, but this is looking quite well done. The aesthetic feels well thought out and the combat is far beyond just reskins of RPGmakers base mechanics.

Can’t say I’m a huge fan of how much of the genre is jRPGs (which I understand is largely due to RPGM’s accessibility) but I can’t deny this is a good one of those.

My main gripe currently is the jump to chapter 7 feels very disorientating because it plops you half way between the town and the fairy portal, making the path forward in what has so far been a linear game unclear.

I spent a good 2 hours wondering if I was going the right direction because I fought my way to the portal first before finding the town.

To me it would make more sense to drop you into the town after the timeskip and introduce the party management/social features there before the player dives back into combat with their new companions.

And this is probably more of a personal taste thing, but I think most combat animations should be at least 30% faster. Turning them off completely is a shame when so much work has been put into them and some really overstay their welcome for how often you see them.

1-2 seconds is generally the sweet spot where you can process what happens but things still feel like they are moving along.