Game Developers of Kiwi Farms

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
if you have reasons to hate unity you probably gonna hate godot too. and not to look like a hater, there's a lot of shit in unreal too, no engine is perfect.
My issues with Unity are more about how the business is run, leading to:
(a) the endless tower of cruft and bullshit in the engine thanks to chasing new features for marketing reasons and immediately no longer caring about the old stuff or folding it elegantly into the new, so the jank stays forever and there's six different unrelated systems for doing anything.
(b) the historical focus on selling it as a super ez beginner engine means both the documentation and community are retarded. They actively encouraged the "unity way" of doing things early on that was so ass-bafflingly crap for performance that some of those ez baby features aren't even in the engine anymore (which is super rare, see above). The long-term effect of this culture and dumb shit like having two versions of the docs so babies don't have to look at scary nerd words--neither of which is informationally complete, so you need to cross-reference both as well as possibly archived versions and random marketing pages for a crucial nugget of compatibility info, every goddamn time--means that if you dip out of Unity for a couple years and come back, you'll have no fucking clue which of those six competing systems for doing what you want are the current/supported/actually fully implemented/appropriate to your use case. It's like forensic archaeology.
(c) spitting in the face of the 'indie' userbase their success was built on back in 2015(?) when they announced they were "Democratising Unity"... by launching a closed Microsoft Pajeet-style accreditaton-based developer ecosystem. Yeah, you probably would benefit from an official course to navigate their official bullshit, but the long-term effects of that idea are obviously going to be awful and it actively incentivises them to make things shittier.
That was when I learned they were fucking evil and had to ditch it, tried to warn people and dipped. I've just been doing other things than active game development in most of the decade since. Ironically it was everyone else learning how garbage Unity Corp is that reminded me I'm a genius and that I should get back into games.

Godot has gay drama I don't care about and Unreal is obviously a massive corp too, but neither of them appear to be building their systems on the idea of being shitty on purpose.

I don't make the best stuff, but at least it's something. And while there's a lot of shit-talking of Godot in this thread (some of it for good reason) it reminds me of the same attitude people had back then.
I'd agree but most of the 'standard' stuff you listed absolutely were/are still in use, or their users basically did a natural transition over to other prestige premium pro software that's in parallel to our peasant open/indie stuff. But it is just more about making stuff, through the path of least resistance if necessary, so you can keep making more stuff. Those traditional pipeline guys are geared by schools more towards big studio work and maybe aren't equipped to do a lot on their own, but even then your portfolio is king in games so it's probably mostly about their attitudes, yeah.

But the other half is turbo nerds who want to write the engine themselves. That's a good instinct, we need those guys and I lean that way myself sometimes (mostly for graphics), but I doubt most of them who say that stuff have actually gone through the whole process all the way to launch themselves, or they wouldn't be so prescriptive with it. The hyper-autists I've met who can commit to that are also the highly-valued guys who spend most of their time on other people's engines.
Like, you should learn how everything works, because it makes you better at evaluating your tools, and removes the conceptual limits on doing something completely novel. But you should also pick the best tool for the job, even if it isn't an exactly perfect fit--the process of development is really the real project in game dev, not the game itself, but it's always specific to the specific game you're making and who's making it. Even if that's really open-ended (as a lot of classic genre-defining games were), which is something using an existing engine facilitates well.
If you're alone or working with other turbo-nerds, especially in a room together, and engine work really excites you, go where the heat is obviously. If that doesn't turn you on and you don't need some super bespoke rendering system or deterministic physics or mega specific performance benchmarks, then why? Make a toy project so you can say you've done it if that's all it is.



Anyway, I think I'm just gonna focus on Unreal. I do a bit of production/VFX stuff sometimes and it's been bugging me not having it on my resume. Godot was just gonna be a side thing for fun anyway. but as the thing I'm making looks cooler it's making me want to make it bigger than it was intended to be so I'm probably better off ditching it before I get too deep.
 
Autism incoming.
They actively encouraged the "unity way" of doing things early on that was so ass-bafflingly crap for performance
This is why I keep putting "as intended" in quotation marks, because for my games, I've been able to brute force a crappy looking UI. I just use labels, anchor them to the nearest corner, and have a global script that prints the hud when it changes.

There was a guy I knew that used to obsess over "data driven programming". He made games in a way that Godot didn't intend, but he made it work. I never understood the specifics, but it seemed to be dumping all the data in a bunch of globals and nodes just reference that stuff.

The whole "object oriented programming" debate is not one that interests me, but I think it's fair to say that it's reached a point of dogma where they try to apply it even when it's not working. In Godot terms, the idea of keeping nodes and objects completely self contained is a fools errand. eg. If I shoot an enemy with a gun, how does the enemy know how much health to lose without being passed the damage of the shot? So far, I've yet to receive a true object oriented answer.


For what it's worth, I don't know what kind of programming I do. I've heard it called "functional", but I don't know if that's an insult. I also remember a lot of fuss about "agile" while doing research on the topic years ago, but I never understood that either.


the endless tower of cruft and bullshit in the engine thanks to chasing new features for marketing reasons and immediately no longer caring about the old stuff
One thing I like about Gobot is that the jump from 3 to 4 came with a lot of quality of life features and core system improvements. Improving the 2D tilemap level creation tool being a big one.
 
The whole "object oriented programming" debate is not one that interests me, but I think it's fair to say that it's reached a point of dogma where they try to apply it even when it's not working.
that whole clusterfuck is just cringe to me
on the one side you have a legion of people who treat OOP like religious dogma, repeat impressive sounding terms like ~liskov substitution principle~ and ~dependency inversion~ as if they were magic incantations, and enjoy scrum sessions (ugh)
and on the other side you have obsessed turbonerds who take the polar opposite approach, denounce OOP as satan incarnate, autistically obsess over functional programming because writing haskell makes them feel smart, and throw a tantrum if they see a variable that's not immutable.
shit's fucked
 
There was a guy I knew that used to obsess over "data driven programming".
Ah, a kindred spirit. The best program is one that has as little code as possible. Everything that can be represented as data should be.
If I shoot an enemy with a gun, how does the enemy know how much health to lose without being passed the damage of the shot? So far, I've yet to receive a true object oriented answer.
The shot enemy should get a message indicating what hit it and where. To get the damage of the shot itself, the enemy should ask it, and then use it as part of the formula based on where it hit.
on the one side you have a legion of people who treat OOP like religious dogma, repeat impressive sounding terms like ~liskov substitution principle~ and ~dependency inversion~ as if they were magic incantations, and enjoy scrum sessions (ugh)
Real Object-Oriented programming is about message passing. Of course what the C++ and Java niggers call 00 doesn't work.
 
that whole clusterfuck is just cringe to me
on the one side you have a legion of people who treat OOP like religious dogma, repeat impressive sounding terms like ~liskov substitution principle~ and ~dependency inversion~ as if they were magic incantations, and enjoy scrum sessions (ugh)
and on the other side you have obsessed turbonerds who take the polar opposite approach, denounce OOP as satan incarnate, autistically obsess over functional programming because writing haskell makes them feel smart, and throw a tantrum if they see a variable that's not immutable.
shit's fucked
I miss the days when programmers wrote code to solve actual problems. These days, it feels like a snake eating it's own tail. The sheer amount of unnecessary complexity that plagues everything is completely insane. The worst programmers are the ones that make up bullshit to self inflate their own egos. They try to make everything more difficult than it needs to be. I feel sorry for new programmers that have to deal with this mess.
 
I miss the days when programmers wrote code to solve actual problems. These days, it feels like a snake eating it's own tail. The sheer amount of unnecessary complexity that plagues everything is completely insane.
I can see the logic in it. If I'm programming something, why solve a problem that's already been solved many times before, and better, why reinvent the wheel? In practice it doesn't really work since without those basics, you become dependant on inefficient plug ins.

At the same time, the opposite is true. Most of my game dev experience being trying to find the "correct" or "proper" way of doing something since my way of doing things tends to be "dumb" or "inefficient", but as explained, the "correct" way to do it is never explained.

eg. A pause system. I have a simple system like. If paused == false, do game_logic(). Sometimes even a switch of different game states like gameplay, paused, game over, inventory, etc. This gets eyerolls as a dumb way of doing things. What's the real way? They're too busy to explain fundamentals to a scrub. But even Godot's official documentation does it this way. A simple bool that, if set to true, halts the game logic and timing nodes.
 
Last edited:
  • Like
Reactions: Ibanez RG 350EX
I can see the logic in it. If I'm programming something, why solve a problem that's already been solved many times before, and better, why reinvent the wheel? In practice it doesn't really work since without those basics, you become dependant on inefficient plug ins.

At the same time, the opposite is true. Most of my game dev experience being trying to find the "correct" or "proper" way of doing something since my way of doing things tends to be "dumb" or "inefficient", but as explained, the "correct" way to do it is never explained.

eg. A pause system. I have a simple system like. If paused == false, do game_logic(). Sometimes even a switch of different game states like gameplay, paused, game over, inventory, etc. This gets eyerolls as a dumb way of doing things. What's the real way? They're too busy to explain fundamentals to a scrub. But even Godot's official documentation does it this way. A simple bool that, if set to true, halts the game logic and timing nodes.
Now, as previously stated, I have not made a game nor am I a particularly skilled programmer, but I think the reason they don't like it is that you've added an extra (albeit very simple) operation to every single iteration of the game loop. I suspect there's a way to just switch over to the paused state without requiring that check every single time, but heck if I know how you'd do it. Or they might just complaining about nothing.
 
eg. A pause system. I have a simple system like. If paused == false, do game_logic(). Sometimes even a switch of different game states like gameplay, paused, game over, inventory, etc. This gets eyerolls as a dumb way of doing things. What's the real way? They're too busy to explain fundamentals to a scrub. But even Godot's official documentation does it this way. A simple bool that, if set to true, halts the game logic and timing nodes.
it's not a 'dumb' way, there are just more elegant solutions
@Lurking no more one if/else statement per game loop is effectively nothing in terms of performance, but having a thread on infinite loop doing nothing while the game is paused can be seen as a bit of a code smell.

you could for example do it by having your pause hotkey set a "pause_requested" boolean, and at the end of your game loop you put a bit of code that goes
Code:
if (pause_requested) {
    enterPauseState();
    pause_requested = false;
}
where your enterPauseState() function opens your pause/inventory/map/whatever screen and only returns after the player exits that screen again. this way your game loop is actually paused and doesn't loop infinitely in the background during pause mode. whether this is beneficial at all depends on your game. like, maybe you are counting ticks for some purpose, then this could actually makes a difference.
 
Last edited:
That's a great suggestion. I never thought of that. Thanks.

In Godot terms, that might be something like the "await" (formally "yield") command. Though as mentioned, in Godot the built in pause feature halts the game loop functions anyway, so might be a bit redundant.

Kind of related. I remember an article gushing over yield/await, saying that it allowed "coroutines" and that it was extremely powerful, allowing you to make entire games with just a dozen lines of code. It has it's uses, but I don't see it as the be all end all of game development, but I'll get to that.

having a thread on infinite loop doing nothing while the game is paused can be seen as a bit of a code smell.
Even AAA games have done this. I remember StarCraft 2 getting a reputation for melting graphics cards if you idle on the menus for too long, since it maxed out the draw calls, drawing as many frames as the GPU could push.

they might just complaining about nothing.
Sorry for the rant and power level. As you might have guessed, I have a bit of disdain for devs that went to university or those that preach so called "pro" techniques. I also ranted about how they keep talking about the "proper" way of doing things but never make anything themselves. How they end up in entry level jobs forever while always waiting for that phone call from Gaben or Miyamoto that's going to come any day now, or even lie about working for some AAA studio.

These pretenders frustrate me. Sometimes they throw out jargon that will impress normies but doesn't make sense in context, or will tell people to do things that make no sense because that's the way they were taught. It makes me assume they know little or nothing about the subject. Again, thanks to @DumbDude43 who has, in just a few sentences, explained what I was doing wrong and why, instead of just offering eye rolls, condescendtion, and excuses for why they can't just tell me.


Anyway, part of this little rant is that a lot of so called "game dev" complaining rings hollow. I've known real game devs. I had one complain that, even though he's a freelancer who works for AAA studios, he mostly works on shit tier shovelware. It makes sense. You get into the business with dreams of working on the next Halo, but instead end up drawing barrels for some shitty phone tie in game.

It's possible I'm jealous and just coping, but it could also be jealousy on the part of the pretenders. Since the criticism is rarely constructive. It's not what I've done, but how I've done it. I used a free tool that isn't "industry standard", or an engine that isn't a "real engine", etc. They don't offer a reason why they're bad, they just are. Sometimes there's good advice that gets way overblown. "UX" and "juice" being two that spring to mind. They're good, but focusing just on those things is how you get flashy AAA garbage that doesn't trust the player to figure out anything on their own.
 
  • Like
Reactions: CircuSphere
I've been thinking about those fantasy consoles. Is there one that simulate old hardware limitations and oddities? I'm mean stuff like sprite flicker, garbage tiles on the edges or something like that.
@Judge Dredd, do you know?
 
  • Thunk-Provoking
Reactions: Judge Dredd
My issues with Unity are more about how the business is run, leading to:
(a) the endless tower of cruft and bullshit in the engine thanks to chasing new features for marketing reasons and immediately no longer caring about the old stuff or folding it elegantly into the new, so the jank stays forever and there's six different unrelated systems for doing anything.
(b) the historical focus on selling it as a super ez beginner engine means both the documentation and community are retarded. They actively encouraged the "unity way" of doing things early on that was so ass-bafflingly crap for performance that some of those ez baby features aren't even in the engine anymore (which is super rare, see above). The long-term effect of this culture and dumb shit like having two versions of the docs so babies don't have to look at scary nerd words--neither of which is informationally complete, so you need to cross-reference both as well as possibly archived versions and random marketing pages for a crucial nugget of compatibility info, every goddamn time--means that if you dip out of Unity for a couple years and come back, you'll have no fucking clue which of those six competing systems for doing what you want are the current/supported/actually fully implemented/appropriate to your use case. It's like forensic archaeology.
How is that different than Unreal tho? Also, UE tries to sell itself as this super high-detail, ultrarealistic "BIG BOY GAMES" engine, ugh.

Sorry for the rant and power level. As you might have guessed, I have a bit of disdain for devs that went to university or those that preach so called "pro" techniques. I also ranted about how they keep talking about the "proper" way of doing things but never make anything themselves. How they end up in entry level jobs forever while always waiting for that phone call from Gaben or Miyamoto that's going to come any day now, or even lie about working for some AAA studio.
If you're gonna try to get a job in the games industry you are gonna run into these kinda dorks. They don't even know anything they just asked chatGPT to generate 10 'programming' questions.



Does anyone have any publishing advice for indie devs? Approaching a publisher with a project that cannot promise to make 1 gorillion dollars from the start is a no-go. Was wondering if there are any tips and tricks to getting your game noticed?
 
How is that different than Unreal tho?
You tell me. I haven't been using Unreal for a decade.

Also, UE tries to sell itself as this super high-detail, ultrarealistic "BIG BOY GAMES" engine, ugh.
Well, the difference there is that it is. Like I said, half my reason is that I want it for doing VFX work. But it's the gold standard for universal games engines as well, I don't know how you can dispute that.
I'm not sure that they actually bother trying to sell themselves that way though, it's not like anyone needs to be told. Unlike Unity, who when they did their massive developer layoffs we found out they were spending almost a billion dollars on marketing, somehow. Which is some real my family is dying shit.

Approaching a publisher with a project that cannot promise to make 1 gorillion dollars from the start is a no-go.
Yeah it's not even that, if you want to go this route all "indie" publishers are basically leeches who want 99% finished games even though they always promote themselves as angels for games in early development. The other route is basically work-for-hire promotional games etc which are actually pretty easy to get, but you're not getting paid beyond the contract if it's a success.
 
Last edited:
Anyone here have any experience with Unreal?
I decided to try it and am coming from Godot.
I'm aware of the notorious loading times, but I have fans running simply by clicking in the viewport.
I know this might come across as stupid, and I meet the recommended specs. But I feel like I still might be under-powered.
Here are my specs:
memory: 64 GiB
processor: 13th Gen Intel core i9-13900H x 20
graphics card: Nvidia GeForce RTX 4060 Laptop GPU
Disk: 1tb
vram: 8 GiB
Is that good enough? Or am I still not at a point where I can dev in it. I'm also using the linux editor.
 
  • Horrifying
Reactions: agent_donkey
What do you actually need from a publisher? In the digital age it's mostly funding and marketing.
Yea pretty much.
Yeah it's not even that, if you want to go this route all "indie" publishers are basically leeches who want 99% finished games even though they always promote themselves as angels for games in early development. The other route is basically work-for-hire promotional games etc which are actually pretty easy to get, but you're not getting paid beyond the contract if it's a success.
Yea that's the impression that I got. They come on with $10000 in funding, and expect 90% of profits and the intellectual properties. Yea, no.
 
Yeah it's not even that, if you want to go this route all "indie" publishers are basically leeches who want 99% finished games even though they always promote themselves as angels for games in early development.
They come on with $10000 in funding, and expect 90% of profits and the intellectual properties. Yea, no.
Seems more like a 100% finished game for $0 funding and 100% of the profits in a lot of cases. I don't think the Cave Story guy has seen a dime in decades, and it's one of the biggest earners for the "owner" of the IP. Have to watch out when a dev outsources the console ports of a PC game to a 3rd party -- and an indie-indie developer is not going to have dev kits, so they kind of have to -- they might screw the dev with legalese, or go the simpler route of just not returning phone calls. They're absolute parasites, probably worse than the big dogs.
 
The Godot official discord server has basically been killed and rebooted. The official server was mired in controversy after controversy, mainly due to the tranny jannies. Using the engine updates channel to push political narratives, constantly fucking around with channels and roles to censor discussion they don't like, and even banning Pepes. As far as I can tell none of the development staff used it or cared. I remember the guy making the VR mod was active there, but no one else of note.

Well, they recently changed the server to "Godot Cafe", and started a new official discord. I've not joined it, because it looks like more of the same.
 
The Godot official discord server has basically been killed and rebooted. The official server was mired in controversy after controversy, mainly due to the tranny jannies. Using the engine updates channel to push political narratives, constantly fucking around with channels and roles to censor discussion they don't like, and even banning Pepes. As far as I can tell none of the development staff used it or cared. I remember the guy making the VR mod was active there, but no one else of note.

Well, they recently changed the server to "Godot Cafe", and started a new official discord. I've not joined it, because it looks like more of the same.
Can we have a thread on this?

I'd start it myself but I have no info on the Godot drama.
 
  • Feels
Reactions: Judge Dredd
Back