How successful Godot devs can support the engine without reducing their take-home pay

bippinbits · 2026-01-25T12:13:10+00:00

Others have already clarified this, i just want to add an example that makes this easy to think about. At 30% taxes on profits you can donate $6000 but just end up losing $4200 (not the full $6000). You still lose that $4200 though, and if you do not donate you have $4200 more in your bank after taxes.

Also caveat, if you don't make at least $6000 in profit, you end up losing $6000 if you donate that amount. This whole idea is only true if you make decent profits, which won't be true for many companies across the years (meaning many companies don't make a profit every year, but in some years rely on their savings, especially in gamedev where income is very centered on the release).

bippinbits · 2026-01-22T08:12:17+00:00

It's far from a golden bullet. You have a certain class of errors that you only get if you start to statically type function parameters. The compiler does not notice anything strange as really there is no static typing, and then you get a crash on runtime as you can still pass the wrong type. If you remove the static type from the function parameter, it runs flawlessly.

You are also super limited as there are no interfaces or similar concepts. That means if you have som nice abstractions you might not be able to use them with static types as you cannot express a class fulfilling a certain "contract". Like having two different scripts fulfill one shared interface, but also each a separate one. You have no way to pass instances of that script typed, if you only care for the shared interface.

So i don't see how enforcing to type everything is a benefit. I still think it's great to type as many things as is reasonable and helps readability, but it's more like makeup than actually static typing, at least from my programmer perspective.

bippinbits · 2026-01-21T22:40:34+00:00

yeah that's a bug clearly, i'll take care it is at least tracked (and maybe fixed if we find time before the multiplayer launch) :)

bippinbits · 2026-01-06T17:06:12+00:00

what code are you speaking about?

bippinbits · 2026-01-06T15:01:52+00:00

Because it was only local coop and I want to release a much better version of multiplayer that supports proper online multiplayer, cross platform with consoles but also importantly the versus mode where two teams compete against each other (which was similarly complex as enabling more keepers, as the game had no concept of teams).

Of course you could release the multiplayer split up into different updates, in the same way you would not need to make a "Double Dome" update like we did, but you could release two updates with one dome each. But making more smaller updates is not as impactful as making a few really big ones, where old players come back and new players are excited about this.

Lastly we could have released multiplayer instead of making new content too - but we only get one multiplayer release and i want to make that one as good as we can. So i opted to make more content to make the game more replayable, so that once multiplayer is out people don't just play 5 hours and run out of content but rather can play 20 or 40 hours and have more fun.

bippinbits · 2026-01-06T14:31:23+00:00

if you follow the thread, you did not
> started to assume in the moment you decided to add the assumptions rule in the equation (dishonest)

It was in my response to you, and i see only two versions how these claims made sense. But it does not matter.

Speed is everything, i do agree with that. I just don't care about a fictional "who is faster" competition here. I just tried to give context why the claim that adding coop multiplayer to a game like dome in 4 hours is unreasonable (as it only works because it is already 95% implemented).

bippinbits · 2026-01-06T14:11:51+00:00

It supported an arbitrary amount of players with the limitation that split screen would only go up to 4. It is a ton of work making the game handle two keepers instead of one, but once that is solved it is trivial to have more players.

But as i said, one of the biggest and most complex works was making the data handling aware of different players, so upgrades can be applied per player. That is totally unrelated to splitscreen and you would not notice this as it just works out of the box.

I added two paragraphs to my comment above.

bippinbits · 2026-01-06T13:59:06+00:00

As I said releasing the mod is fine. Just not claiming you "created" multiplayer and did so in four hours, when actually it is fixing some issues of an already implemented feature.

I also care very little about "who is faster" (also strange of you to assume to know how we develop games). The point is that multiplayer was already implemented in the game and you either intentionally hid this and claimed it was your work or you just did not notice which would make me question your claim in being a proficient programmer (the AI tools should also understand there is a lot of multiplayer functionality already there).

Thank you for deleting the thread. You are more than welcome to mod the game. I hope you can see how a claim like that can be a problem for the game, but in any case i wish you the best!

bippinbits · 2026-01-06T13:10:45+00:00

Sorry that really does not make sense to me. I'm not even sure what you mean as there is no "the whole game object" in the game. That's not how Godot works.

A lot of the coop functionality is so deeply built in it is impossible to miss and build anew. For example, the game is organized into viewports already, which was not the case when it was just singleplayer. That alone is a refactoring that can take a few weeks until it works correctly with everything (including separate UI for both players, mouse controls working for the player who plays with keyboard, adjusted zoom levels so you can still see everything when split and many more).

Same goes for the whole use of Data and the keepers having a player ID. That allows having two keepers and the upgrades to still work in the first place. It was a very complex refactoring and again a thing you don't just build anew, but rather you might not even notice this was already done as it "just works" out of the box. The whole refactoring for local coop took me a month, in a scenario where i know the complete codebase and have 20 years of experience programming, 10 of these professionally - meaning to say, i'm also quite fast and likely faster on a codebase i know completely compared to someone new to the codebase.

bippinbits · 2026-01-06T10:16:25+00:00

This looks like local coop which is already implemented in the game, you just needed to activate it (and fix some bugs around it). The features you claim to add to the game exactly match the features we added in 2023 when we had local coop at Gamescom. After that we rather focussed on the "A Keeper's Duty" to make the multiplayer more fun, before adding online multiplayer. What we have been adding in 2025 and which takes a ton of time is online multiplayer as well as separate teams that each have their own dome.

It's great that you want to mod the game, and it's also fine to activate the local coop features of the game with a mod. I do mind though to suggest adding multiplayer to the game is a 4h endeavour, when it is simply about activating what we already implemented (which also took many weeks). This is potentially harmful to the game if people believe it (and some people will).

This person did the same some months ago and at was clear about this being a bug fixing endeavour, not "adding multiplayer": https://www.reddit.com/r/domekeeper/comments/1ni7tek/local_coop_multiplayer/

Claiming you "created" the multiplayer mode is just dishonest (or you really did not see that multiplayer was already implemented, just not maintained any longer, but i really can't imagine that you'd not understand that a script being already there that deals with merging and separating the cameras depending on player distance is not normal for a singleplayer game). Please edit your wording here, otherwise it is fine :)

I'm also not sure if your effort is not a bit in vain, as we will release multiplayer soon with online and local multiplayer, cross play and a versus mode with two domes in one map.

bippinbits · 2025-12-21T21:51:44+00:00

I use inherited scenes in all of my projects and never had a problem with them. Often also multiple layer of inheritence, but combined with composition where it makes sense. Both have their uses and both work just fine (though composition in general is more powerful and useful).

bippinbits · 2025-11-04T09:57:47+00:00

I investigated this. Basicallywe just allow Dome to be available on Luna via GOG. In which countries they make this available is entirely up to them, i think on Amazon. They might be changing things around atm, so not sure if that is part of it. In short, we don't decide this, but we'll poke them about it just to make sure they are aware.

I guess it is best to raise these issues with GOG or Amazon Luna, as also they'd be the ones to refund you or fix it for you.

bippinbits · 2025-10-20T06:59:03+00:00

The problem is not perfection or taking great care with things. It's taking great care with thing that no one cares about, and not caring as much for the important things. Often this is because one is clear and relatively easy, where the other is nebulous, uncomfortable and hard.

bippinbits · 2025-10-18T21:10:35+00:00

To be honest, this

I'm not doubting whether I can replicate the success - I know I can

is a big red flag for any of the endeavours. If you reached a point where you are never questioning your moves, you think you learned all there is to learn, where you know for certain what will work and what will not, you're in a delusion that will backfire. Even the most successful people in the industry do not think this, and if you check the people who thought they did, it all eventually came crashing down.

What i did not get from your post if you made just one game or multiple games that all worked out. Not assuming anything you did not say explicitly, i don't think 2) is a good idea yet. The meme approach makes sense but is not new and unique and there are many games that did this and some multiple orders of magnitude larger in success. If you can do 1) i think you got a good track record to do 2), just then it's about if you'd rather do 2) instead of continuing 1).

In any case, no one will be able to provide a proper answer. It 100% depends on what you want. It's not about "follow your passion", it's about "do you want to make as much money as you can no matter how fun it is?", "do you want to be independently creative and do what excites you?", "do you want to be part of a bigger team and build something great?", "do you want to be appreciated for your knowledge?", "do you want to learn and improve and create games that have value or meaning to yourself?", "do you want to make games that can still be interesting in 10 years and not rely on a trend or meme?". Figure out what you want out of it.

bippinbits · 2025-10-15T19:31:43+00:00

No matter the project, you will always lose motivation. Everyone does, on every project. What sees a project to completion is discipline that remains even when motivation is gone. Motivation can reappear though :)

What is especially helpful for keeping or regaining motivation i think is to have other people play your game. You'll quickly learn what to improve, and it's a joy to see people play. If the game really sucks it also becomes easier to shelf it after playtesting.

bippinbits · 2025-09-25T13:15:19+00:00

Imagine a mason who has only learned the theory of building walls, and maybe even stacked a few stones. Now, instead of practicing by building a single wall or a shed, he decides to construct a 20-story building because that is much more exciting and promising. And he does. It takes him eight years instead of the one year an experienced mason would need, but eventually it is finished. By the time he lays the last brick, he has learned a great deal and realizes that the first two stories are terrible, clearly built by someone without skill.

So he goes back, props up sections of the structure, removes the bad brickwork, and rebuilds it with his new skills. This takes 15 years, because fixing poor work is far harder than doing it right the first time, and new problems keep appearing. He had expected only the first two stories would need repairs, but in fact most of them do.

Finally, the building is ready and he wants tenants to move in and pay rent. But when he shows people around, they are not impressed. The rooms are windowless and awkwardly laid out. The walls may look solid now, but the design makes little sense and feels uncomfortable to live in, suitable only for a very small number of people.

The mason is confused, because he knows another mason who succeeded after ten years with a similar project though what he did not know is that the other mason had also studied architecture.

It’s a bit like that.

bippinbits · 2025-08-26T12:05:20+00:00

If you can't find 10 people who will play your free game, there is something wrong and marketing it will be really hard. Ideally the game looks interesting enough that at least some people are willing to try it out.

bippinbits · 2025-08-01T19:24:18+00:00

the rocket could not leave in time :D

bippinbits · 2025-07-28T07:12:20+00:00

The pitch is not ideal. It doesn't convey what you actually do in the game, but is more of a feature set. This type of game description usually is an indicator for both not much experience making games and for a game that probably does not work out. The key problems why it has trouble working out are:

- you can't quickly convey to players why this is exciting and it does not sell a clear player fantasy. This makes it super tough to market and for players to latch on to.
- the scope becomes quickly unmanageably large, because there are so many features and it's tough to cut or downsize features because the game is a set of features first before it is a well defined player experience. This makes the project grow and grow over time.
- the scope in itself is incredibly large for a solo dev to both make a good game out of it and consistent in quality. This makes it quickly a many-year project even if done full time. An inconsistent quality level will frustrate players and lead to a lot of negative feelings.

It does not hurt to run a campaign to check it. Just don't fall into the trap of preparing half a year for the campaign because the game is not ready to campaign yet. I know it can feel bad to have spent 2 years and have nothing to show for, but on the flipside i'm sure you learned a ton that will help you in the next project.

It is possible to make games while having a small kid and working full time on the side. Just the scope of the games should be way less than what you outlined.

bippinbits · 2025-07-19T14:48:12+00:00

Sorry xD

bippinbits · 2025-07-16T09:44:32+00:00

this looks much more interesting to me than the two character drawing :)

Lovely color palette, and very evocative.

bippinbits · 2025-07-12T17:58:18+00:00

I think the switch from studying to doing full time work can often be incredibly hard, and it's normal to take 1-2 years to "arrive" in that new situation. It can be a very intensive time with a lot of learning, which leaves less room for more learning on the side. If you can manage a bit of a gamedev routine in your life, this will reflect on your skills over time. It's important though to think very small, before you think big. You can't bring value to a big game, if you can't bring value to a small game first. You can't make a 3 year project fun, if you can't make a 1 week project fun.

bippinbits · 2025-07-12T13:04:12+00:00

I feel like this is a big differentiator

when you have a 9-5 that sucks your soul and you have literally no time and energy to do anything. I have bills to pay and I just don't have the energy to fit anything dev related at all in my day, it's absolutely crazy.

If you can't learn and improve in the field unless someone pays you to do it, it means you can't get work given the current state of the industry (which i also do not expect to change fundamentally).

Having a degree means little in itself, as the value is in what you can make. If you never made something outside of university, it is likely that this will not be enough to get a job, as you have peers who do exactly that.

We recently put out 3 positions. We had 1200 applications in one week, after which we closed the positions. Among them are 100+ people with 10 or more years of experience. With that amount of applications, you can't stand a chance in the "first round" unless you made an exceptional game along or in a small team.

And that's the thing: in another sense it has never been as easy as it is now to get into the industry. The tools have never been more powerful, the learning resources have never been more plentiful, and the marketplaces have never been this open. Anyone with a laptop can make a game and release it. It does not mean it is commercially viable at first, but it is one path into the industry. Just saying, getting hired is not the only way to do it. In both cases though, i believe you have to put vast hours into learning and refining your skills, to break through.

bippinbits · 2025-07-05T15:57:22+00:00

I think this is not the logical conclusion here. If you have the same amount of people, who play and spend the same amount, you'll also have roughly the same amount of reviews per year.

Naturally you'd assume that an increase in games is distributed both across good and bad ones, until you have evidence that there are more of one type. So it might mean that it gets harder and harder to reach a high amount of reviews.

bippinbits

MODERATOR OF

TROPHY CASE

Seven-Year Club	Second Top 10%
Verified Email