It's a maybe. I'd like to avoid repeating existing puzzles in this genre and from this game, but if I can't think of enough stuff to warrant a sequel, then I think I'd just update this game instead.
Yunyanite
Creator of
Recent community posts
Hey, sorry to hear that the game isn't performing too well on your device. I've been making note of all the Android-related issues so far, but until I can replicate these issues on my end, I'm afraid I don't have the knowledge necessary to further optimize this game or blindly fix any underlying causes.
All I can really say is that this game has been tested to run smoothly on Android devices manufactured since 2022. Older, lower-end devices will probably struggle to handle the game's physics stress, but unfortunately I've already exhausted most of the common optimization tricks by the book, and I've been rather limited in finding any new ones right now. Sorry for the inconvenience.
A star is awarded whenever you get a score of at least 500 in a level, which usually means having:
- a clear time of under 32 seconds
- all donuts collected
- a continuous, max-inflow stream of jelly being piped in during the 4 seconds between clearing the level and the results screen
Having an earlier clear time gives you some leeway on the 3rd criteria, but generally the scoring is supposed to be pretty strict for the trickier levels.
It's a challenge system I put in place since I personally enjoyed figuring out strategies and routes for these levels. For world 1 - level 5, my strategy is to wait and let the jelly pool up at the bowl-like peanut butter formation to buffer enough jelly for continuous feeding, and then I'd try to dig in a way so that the jelly doesn't fly above the last stream to avoid bunching it up in the air.
As for the automatic cutoff system, it's there to prevent having to wait too long before pulling up the results, but I'm definitely thinking about some possibilities to make it slightly more forgiving for the scoring.
I actually originally had it so that food capacity would grow regardless of nutrition, but that ended up being difficult to control (you could eat everything on floor 1 and steamroll the rest of the game), so limiting it to nutrition intake just felt like the most natural way to curb it.
I do agree that the mechanic itself is a bit obtuse, so I'm thinking about putting an in-game blurb somewhere to help explain that in a later patch.
The nutrition-to-weight growth is supposed to be linear, but the actual calculation is a bit funky since I used integers for a lot of the weight stuff.
Basically, for every 3 nutrition, 1 lb is distributed to the belly, 1 lb to the thighs, and 3/4 lb is distributed to the chest (rounded down after sum).
This results in stuff like:
10 nutrition -> 8 lbs
11 nutrition -> 8 lbs
12 nutrition -> 11 lbs
I actually hadn't noticed any of this until you pointed it out, so good catch btw
I don't have any recommendations for books or videos tbh, but if you're looking to make a game for the first time, then I'd try out Godot.
There's a lot of starter tutorial videos for making games in Godot, and the engine itself is reasonably beginner-friendly. I also found Godot to be the best for making my games so far.
No matter what you use to make games though, it's all about starting small and making simple things like Pongs or platformers before moving on to bigger game ideas. Experiment, learn stuff, and try to have fun.
So, I mentioned before in the latest update log that I've paused content development updates following the closing of the jam to work on other things before returning to this game, and I'd like to clarify that those plans are still ongoing. I'm currently working on a different weight game project so I have the experience of fully completing a mid-sized game in order to comfortably manage a bigger scope project like RogueWeight. In the meantime, I've been keeping a list of user suggested ideas to play around with later, and I will be making note of yours as well.
Regrettably, I've been working as slow as a snail for the past month. The game jam period was when I had the convenience to fully focus on getting stuff done, and I was hoping to maintain a slower but respectable pace for what I'm doing now. However, this past month has been rather taxing on my personal life outside of this, so unfortunately my dev schedule has been awfully sporadic.
I understand your concerns about abortive development. I'm aware I haven't made any announcements or posts to showcase anything else recently, and that's partially because I'm conscious about keeping things under wraps until I feel ready to talk about them. However, I would like to reassure you that I don't intend to keep RogueWeight in stasis forever. There's a world I do want to build with this specific player character that I can only do with this game. Moreover, the amount of support and engagement this jam version has received still continues to defy my expectations even today, and I would be a fool to let that go to waste. That's why I've put aside pursuing further game ideas so that once I finish my other game project, I'll be resuming content development for RogueWeight.
One particular mechanic I would like to play around with later is being able to encounter a really washed-up version of your character from a previously failed run (akin to a bones file from Nethack), so I suppose having sex isn't off the table.
That being said, I don't intend to develop big, overarching features like owning a house, completing daily missions, or building a city. To me, these features sound like objectives for significant long-term meta-progression, but I'd like to keep that down to a minimum for a roguelike. I want to design RogueWeight to have value in how a player experiences a run, and not necessarily what a player expects to gain from trying to complete one.
I've only tested out the cheat code on my computer and my phone, so I'm not too sure how to troubleshoot that. Sorry.
The pinch and konami code are the only two ways to active the cheat in-game, but the cheat toggle is saved as a boolean value under "NO_MILK_RESET" in the options.ini file (same directory as the save file), so if you're willing to do a bit more digging, I guess you could try flipping a 0 to a 1 somewhere.
This is a very nice write up! I actually didn't know how the save files were internally structured by Godot, so I enjoyed reading about your technical dive into save editing.
I definitely would like to figure out a satisfying way to incorporate size effects. Not too sure what'll come out of it, but I'm thinking about experimenting with some of the stuff you've mentioned as a starting point.




