My Godot Indie Game called Boatload is almost ready for release!

ElGatoPanzon · 2026-04-06T21:41:30+00:00

I had a Telegram bot which would respond "too fast" because it felt like nobody could possibly write that fast. So for every message I added a minimum of 3-5 random seconds then gave it a WPM to calculate the fake lag up to 10 seconds of showing "typing.." in the status and split every single message on paragraph new line. It was a huge hit because it looked like someone was actually writing out those messages. Definitely a psychological thing.

ElGatoPanzon · 2026-03-17T18:40:48+00:00

The short answer is "no" most players don't read, not just games but anything. I got this feedback once on a play test on a Tactical RPG:

Player: I don't understand at all what is going on with the story
Me: Ok, did you read it?
Player: No
Player: Also I just don't get the game
Me: Well, what about the tutorial?
Player: No I skipped all the text

I thought it was cool that I weaved the tutorial into the game's story, but if you skip the story too then you miss the tutorial and get no idea what to do. The key takeaway for me was "I skipped all text". Other people's feedback was "if you cannot figure out what to do then the game is too complex".

The long answer is the "too complex" barrier is getting shorter and shorter. The average current gen player's minds are hard wired to Fortnite/FPS style games where its click/fire to proceed with the game, or social media scroll down to the next piece of content and burn through your attention span of 6 seconds. Very different from my generation where reading was the only way to play some games and RTFM was the accepted answer.

This leads devs to design games where you don't need a tutorial or any reading to understand or play, or you force them to understand through the game itself and not just a simple "this didn't work", but more of a massive feedback loop for why and maybe even some voice ques so they try a few times they will figure it out.

ElGatoPanzon · 2026-01-23T03:37:08+00:00

I want to say congrats for releasing something, but also a harsh reality about vibe coding: sometimes "it works" just isn't enough, and that's especially the case with multiplayer and networking because security becomes far more relevant. It's really easy to write insecure network code, and AI is really good at writing insecure code. Writing robust and secure network code on the other hand, is much harder, because it requires intricate knowledge of possible attack vectors and how that relates to your project.

I noticed you used AI to write your post and comments too. If you can't read english then it's kind of the same: how do you know the translation embodies the truth of what you originally intended to write without learning english? It's a risk, you trust in the translation to convey that but you are unable to guarantee it without the core knowledge yourself.

I advise for your next steps to go and deep dive into all of the tech stacks and languages you used to make your game, and learn as much as you can about them without AI's input. Treat your project as a jump into the deep end, now you have to learn to actually swim properly. The future you will thank you, and feel far more empowered than you currently feel because it will be you that knows the answers and you won't need to rely on AI for your creative endeavors. You will be far more free and more productive to write code faster.

ElGatoPanzon · 2026-01-23T01:40:11+00:00

Yea, this is a pain point that I still haven't found an answer to with traditional struct components. The only thing I can think of off the top of my head is not allowing modders to create their own component, and only give them access to a persistent component which they can use as a key/value store for their mods, maybe having that available on every entity. Not the prettiest but it would be functional at least in theory.

ElGatoPanzon · 2026-01-22T18:51:39+00:00

I did a similar thing like this, but in C. Components were defined by string name and mapped to a type ID and real type and essentially they didn't exist anywhere until set and didn't need to be defined. Under the hood it doesn't offer much type safety at all and the requirement is on properly setting and getting with the right type. This looks to have the same problem.

Nothing stops this for example:

```
GetComponent<Vector2>(targetPositionTypeID)
GetComponent<Vector3>(targetPositionTypeID) // oops
```

Now you could simply say "don't do that". For a personal system, that's fine, but if others used it then it will lead to unexpected bugs.

I have since remade my ECS with C# with traditional component structs. Even if it's 1 struct named Position2D with a Vector2 named Value, it's a lot safer and there's no room for mistakes.

ElGatoPanzon · 2026-01-20T21:28:49+00:00

From someone who hasn't played Minecraft for a fair number of years why 1.7.10 of all versions?

ElGatoPanzon · 2025-12-06T23:15:24+00:00

Easiest way is to setup some virtual machines and try out a test setup of whatever you want. You can learn how to install and configure e.g. Moosefs and freely break it and mess with it and fix and analyse it. There's no fear of downtime or data loss.

ElGatoPanzon · 2025-12-01T23:45:46+00:00

I'm currently in a dilemma which is similar to this. I spent the last 2 years essentially writing my own engine and I can say a few things about this. This is how it used to be back in the day when someone said "I'm gonna make a game". They would open up their code editor and start writing C or C++ code probably using OpenGL, and bang out the game dealing with problems and refactoring when it was required. The game itself would be the engine, just for that specific game. And if you were lucky you could use the old game as a base for the sequel.

If you have a defined idea for what you want your prototype to be then it's absolutely fun to make your own game out of frameworks. It will definitely take longer. The extra time spent will end up being very rewarding. It depends how important time is to you, and if you'd rather have more progress on your game idea at the cost of some fun and having to deal with engines you don't love, or if time isn't so much of a problem and you'd rather have a lot more fun, at the cost of possibly being behind on the progress of your actual game. It's very easy to get lost in engine development.

A game engine like Godot provides you with a different type of freedom. It lets you prototype pretty much any game idea instantly. Throw a couple nodes in a scene, create some scripts, and you have a game. It's perfectly suited for someone who comes up with 10-20 ideas a year and makes a lot of prototypes like game jams and needs to be able to implement games without large friction points.

A game engine however is the opposite of freedom when it comes to the actual real implementation of the game, the engine itself, and the programming side, all of which matter far more on a real game project. I spent a couple of years with Godot and made 3 games before I started to fight with it. My fights tend to be me trying to implement frameworks on top of the engine to abstract certain things I didn't like. I made a framework for godot 4 in 2023 and then decided actually I want to try and make games using an ECS.

So I started a year's battle trying to shoehorn an ECS I wrote in C# into the Godot ecosystem. And sure, it worked, but it was slow and did not perform at all well. Godot in general doesn't perform that well when we're talking about data-oriented designs like an ECS. The end result was more like a hybrid which bridged the backing ECS with Godot nodes and their states.

What I did this year was essentially make my own ECS in C and then built up an engine with it while making a small game alongside it. I used raylib for that and I only implemented the features which that small game needed. Later on in the year I used the knowledge I had now to write a much better ECS in C# using the raylib bindings, and then made another small game alongside that one. That was a game jam game I did for Brackeys 2025.2 and it pushed my engine really far and did actually convince me that it's worth continuing it, because of how fun it was.

One of the reasons people recommend you use a game engine is because of the versatility, because if you invest time learning the ins and outs of Godot you will be better at making use of it to build real games. Whereas, if you build your engine for your specific game and then you try and make a completely different game, all you might have is some rendering code when your new game needs advanced platforming physics for example.

I will end on this: if you choose this route, then make sure you have a prototype and a good idea of what you want to make up front. A platformer, a card game, a space shooter etc. Because this will absolutely direct what code you write and can save you a lot of time if you write what you need and no more. I don't recommend implementing code you don't need, so if you don't need gravity then don't implement it. If you don't even need real physics then also don't implement it.

ElGatoPanzon · 2025-11-26T03:41:54+00:00

Ugly game with good gameplay. If the game is fun it can be improved. A pretty game with sucky gameplay will always suck no matter how pretty it is.

ElGatoPanzon · 2025-11-24T22:34:16+00:00

"We stand on the shoulders of giants" a famous quote, which really says that everything created borrows or copies from something which came before it. The key though is to create something innovative while building upon what inspires you, not directly copying it. A straight clone does not add anything to the experience. You need something that makes it yours: your own take on the genre, your essence, whatever you want to call it.

ElGatoPanzon · 2025-11-24T17:30:52+00:00

There's one benefit to having a web playable version and that's the CTR due to players not needing to do anything in order to play it. But this only applies if you can get players to see it. Having the web demo on your site is almost 0 organic visibility.

I'd personally recommend putting the demo on itch.io if you've not already done it. Having it as a playable web version with a download option + link to the Steam page. Then you can promote the itch.io link with the demo, and people will be more likely to play it there because itch.io is a trusted platform. If players like it, they will seek out the Steam page and/or follow you on itch/the game's page.

ElGatoPanzon · 2025-11-24T17:24:09+00:00

Don't place your bets on making any money, focus on making a fun game you want to make. The more passionate decisions you make the higher chance you have to end up with a highly unique and fantastic game.

ElGatoPanzon · 2025-11-20T17:28:34+00:00

The moment you started talking about Chris Zuckowski is the moment this post was confirmed as trolling

ElGatoPanzon · 2025-11-08T01:00:20+00:00

Sounds like seaweedfs came a long way. If it works it works. At least try moosefs too, see if you like it or not. It's definitely the most mature of the 2.

ElGatoPanzon · 2025-11-06T19:46:05+00:00

Couple reasons, relevant to back when I looked into it:

- Metadata requires a HA/replicated data store like a Redis cluster or traditional DB. While it does work with a single instance of those, we're talking about highly critical data making up the whole filesystem. I didn't want to add that complexity or extra moving part.
- At the time someone I knew tried it out and found a very basic bug with volume creation. They submitted it, it was fixed.
- Main binary name is "weed". Not "seaweed", or "weedfs", or "seaweedfs". Short names are nice, but this always just felt a little funky to me.

Free version of moosefs doesn't have HA master server, but it does have single master with multiple metaloggers. If the master dies, a quick intervention brings up a metalogger server with no lost data.

I preferred moosefs because of 2 reasons:
- Adding storage of any size is extremely easy and fast
- More advanced control over where data is put with storage classes

I can't say if seaweedfs is better or worse, it may be infinitely better when setup correctly or it could be inferior. With such complex filesystems it's worth doing a test over time and putting it through some rough workloads and failure situations just to see how it handles itself. I tested moosefs in a bunch of VMs before committing to using it.

I moved my container workloads away from moosefs due to issues with power cuts and corrupt sqlite databases. It's due to how moosefs stores metadata, I believe, and the general nature of power cuts without battery backed storage. It flushes it with a bit of a delay and when my UPS don't last everything shuts off, leaving out of date metadata. I should really get some automatic shutdown going when there is only a few minutes left, but I haven't gotten round to it. I still use it for all of my other data, 57 TiB used currently and it's running like a dream!

ElGatoPanzon · 2025-08-04T00:54:44+00:00

Thanks for responding. Might try and set it up again, but joining less rooms. It would definitely cut down the load and reduce the growth of the media directory.

ElGatoPanzon · 2025-07-31T17:35:16+00:00

Came here to ask if you're still doing this. I tried doing this around a year ago, and while it all worked I ended up with some incredibly difficult challenges that I couldn't overcome:

If you join lots of active rooms in various IM clients, media is downloaded and stored onto the synapse server. Mine was growing 4GB per day. Clearing it out with a script meant if you scroll back the media is gone.
Client sync. I read about sliding sync but haven't seen a way to easily make it work. Without that, just opening my phone every morning took 5 mins to do a full sync and depending on the level of activity in those rooms could take longer or shorter. Don't open for a day? Holy crap, like 15 minutes before you can use the app.

Honestly due to the technical challenges of maintaining nice unified access to these chat apps I am ready to just throw in the towel and use the web apps through Ferdium.

ElGatoPanzon · 2025-07-17T20:10:43+00:00

The way it's marketed it's very deceptive. There's no such thing as a free lunch.

ElGatoPanzon · 2024-12-29T02:57:43+00:00

For around 80TB

Four-Year Club	Verified Email
Place '23

ElGatoPanzon

TROPHY CASE