I thought making a small forest adventure would be the easy project

I want to post something here that isn’t just a link drop.

I’m a solo dev. Hobbyist, evenings and weekends. I’ve got four things up on my page now,
and the only reason any of them exist in public is that itch.io doesn’t do gatekeeping.
No pitch deck. No approval email. No “we’ll get back to you in six weeks.” You make
something, you upload a zip, and it’s live. When you’re doing this alone, that’s not a
small thing. That’s the whole thing.

The other part I actually appreciate is pay-what-you-want. My games are free. But PWYW
means if someone plays one and feels like tossing a couple of dollars at it, they can.
I don’t have to build a shop, or stuff ads into a platformer about a frog. It’s a decent
middle ground for a hobby project that isn’t a business and doesn’t want to become one.

So, what I put up most recently. Muscle Frog: Forest Quest. You’re a frog. You eat fruit,
you get bigger, you jump on platforms, you dodge spikes and fire, and eventually you fight
a pig who calls himself a king. Seven levels, about fifteen minutes. Free, runs in the
browser, works on phones with touch controls.

It’s short on purpose. No shop, no stamina bar, no daily login, no cutscene to skip. I kept
thinking about all the things games do to hold your attention and then I just didn’t build
any of them. You press right, you jump. That’s the whole game. And honestly, playing my own
thing was more fun than a lot of what I’ve played this year, which was a surprise.

There’s also a mahjong game and an RPG on the same page, if a frog isn’t your genre.
Different games, same one person.

If you try the frog one and something annoys you, tell me. I read everything and I do
actually fix things.

And a real question for everyone else posting here: what’s the thing itch does that other
platforms don’t, that you’d miss most if it went away? For me it’s the no-approval-process
part, but I’m curious what it is for everyone else.

4 Likes

Small update on this one — I found a fairly embarrassing Web export bug.

The browser version had technically had a save system for quite a while, except I was writing everything to res://. So on desktop it behaved normally, while in the browser nothing was actually being saved.

It’s on user:// now, which means IndexedDB on Web, and the leaderboard finally survives a refresh.

I also fixed a startup case where a bad saved resolution could end up calling window_set_size(0, 0). Windows doesn’t quite give you a 0×0 window, but the tiny sliver it creates is arguably worse because it looks like the game failed to launch.

Both were very simple bugs once found. Finding them took considerably longer than I’d like to admit.

1 Like

This makes me wonder why Godot even allows writes to res://. I guess it makes sense for tool scripts, but for the actual game? Is there a valid use for writing to res:// that I’m missing, or should res:// be mounted in read-only mode for actual games?

For the modest Projects that I create, ‘res://’ serves me very well, enabling complete and welcome automatic separation of my Projects. As I have no intention of exporting or commercialising my Projects, ‘user://’ has no purpose for me. If, punctually, I decide to render public any export of my Projects, it’s an easy enough matter to change to ‘user://’; until then, I am in favour of leaving the default as ‘res://’. I may be alone in this, but that’s not certain.
Peace.
Chum

I just learned about this from Godot’s documentation and other YouTube videos. While my understanding isn’t very deep, I’d still like to share my thoughts:

The difference lies in the project file system and the runtime file system. Simply put, res:// is the project root directory during development, making it writable and very useful for editor plugins, @tool scripts, importers, generators, build tools, etc. In this case, if Godot forces it to be read-only, it would be quite limiting.

However, for exported games, res:// should not be considered writable application storage. Depending on how the project is exported, resources may already be included in the PCK file (I haven’t looked into it closely), and Godot’s documentation treats the exported project file system as read-only.

Therefore, res:// = files included with the game, while user:// = files created or modified during game runtime, such as save files, settings, downloaded data, cache, screenshots, generated content, etc., are all placed under user://.

However, I still agree with your point. After all, for exported games, treating res:// as read-only is probably the safest and most secure approach. Hope this helps.

My friend, I never knew you had such in-depth knowledge in this area! You’re amazing, it really surprised me. I hope you’ll continue to support my work and offer more insightful comments in the future.:clinking_glasses:

1 Like

Two issues here:

1. The primary purpose of running games from the editor is to test how the game will run when exported. It should be possible to catch all bugs in the game by running in the editor, because debugging an exported game debugging tools that the Godot editor provides is painful bordering on impossible (depending on the bug). And writing to res:// is a bug, because it doesn’t work in exported games.

2. Godot should allow one to write portable applications that put user data in the same directory as the application itself. This would work by remapping where user:// points to, not by writing to res://, and it would affect both exported and un-exported games.

The simple solution, and the one I believe already adopted by Godot, is to inform those that wish to export their Projects that ‘user://’ needs to be used for any file saves or such. There is no issue really; it’s a simple enough notion for all to understand and implement, leaving everyone else to continue to have all of their Projects inside of ‘res://’, where it all works fine. There is no ‘bug’; it’s set up like this as a feature, of which I, for one, approve.

1 Like

That’s right, and your solution is also very correct.:blush:

1 Like

I’m on vacation for the next few days, so I’ll be going on a trip. Therefore, there will be a temporary update period of about 10 days. A better version will be released after 10 days, so please stay tuned.

2 Likes

Hard agree about itch.io being the place for solo/indie/hobbyist devs. Your page is gorgeous, btw. I also made my game free (and ad-free, no in-app purchases, etc.) and I plan to have more like that. I don’t have the PWYW enabled because I haven’t set up my tax stuff for that. Maybe one day if I feel like one of my games might be worth it. :0)

(I also need to merge my two itch pages - I have my dev one and then my original one I used to buy things - I want to see if I can combine them into the dev one so I am following people from just the one, but we’ll see)

1 Like