Game Developers of Kiwi Farms

[Tiggie_Tiger]

Honest question.
What do you guys dislike about the Godot UI famework? Seems like a pretty good system to make scalable GUI but idk.
What do other engines do better?

Also, the Cyclops Level Builder is a huge boon to Godot users. Hopefully Vincent Kalle won't have to awkwardly import BSP maps anymore.

I think Godot is a pretty horrible engine for a few reasons. I've used a handful of engines (even written my own projects in C/C++ directly with OpenGL and shitty Vulkan), and Godot by far is the most annoying to work with. The only good thing I can say about Godot is that it's smaller and more compact and its ok for prototyping. It has lowered the barrier for newer game devs but this comes at a cost (I'll get to that later).

I've ran into nasty bugs with Godot, some which have taken me weeks to solve, such as the infamous yield bug which can lead to unpredictable crashes while printing little to no errors back, which makes back tracing extremely difficult . Some bugs remain unfixed for months to years, devs randomly removing and renaming or changing parts of the API (seemingly for no reason), which have worked fine, but now you have to refactor everything because they've completely changed how you interact with those functions (in some cases they're worse compared to older versions). Godot also has a lot of missing functionality which is standard in most engines, for instance, getting a face index from a raycast hit. They've only just added such functionality with Godot 4 (which is a complete disaster of an engine imo). Godot's physics are riddled with bugs and some lead to annoying issues which are very difficult to create workarounds for.

The biggest one for me is performance and stability. Godot is pretty slow, and its prone to bloating and fragmenting memory. There are tricks you can do to better manage this, but they're pretty hacky. Godot's GDNative is absolutely dogshit and it's incredibly hacky to work with. C# support still hasn't improved much even after the Unity Debacle. It's still shit.

TL;DR Do not use Godot for more sophisticated or serious long term projects.

Godot has made game development easier for less experienced and skilled individuals, and I can't really say this is a good thing. Foremost, even for game development, you still need to understand software architecture, algorithms, and how computers ACTUALLY run your code etc. I've noticed a severe lack of skills with newer game developers, and this was greatly exposed during the Unity shitstorm. One of the worst issues is the fact they're completely dependent on these game engines. They can't take their existing codebase and move it somewhere else if shit hits the fan. They've integrated their entire project with it and now they're stuck with it. Sure, they're are tools which can move a project to a completely different engine, but they're shit and it'll just be another abandoned project. The result of such a move is unpredictable and the project will likely not work correctly or at all, and you may as well rebuild the entire project from scratch again anyway. These devs build their entire project around someone else's idea of how a game should be made.

I get why these engines exist, but the cost is just too high imo. The lack of freedom and control you have is just insane to me.

Anyways sorry for the large wall of text.

 

[Squawking Macaw]

Make a game that YOU want to play, and then likely someone else will appreciate it.

This is fine if you're making games for fun, but if your goal is money this isn't great advice. You may end up making a game only you want to play.

There's also the tutorial problem where using Unity or Unreal to make a game only works until the minute you want to do something that isn't covered by a tutorial or a bloated plug in.

The dreaded tutorial hell. I'm trying to learn 3D modelling and if there isn't a tutorial for a specific thing I want to do, I simply can't do it.

I’ve wanted to develop video games for a long time. I can’t code for shit though and quite honestly learning seems like a hassle. Also budget, because the game I would love to make most is a DMC-like, but I don’t think I would have the budget.

This is my problem as well. I've got a couple of notes laying around for games I'd like to make, but actually taking the first step and learning to code is too daunting. There's so much conflicting information, and when you're a newcomer it's hard to separate the good advice from the bad. What tutorials should I follow? Which language should I learn? How much math should I know? Which engine is best? No one can agree on an answer it seems.

 

[Dysnomia]

Honestly, I wish I could program my way out of a paperbag so I could try to do my own project. I've had repeated attempts at trying to learn how to program over the years, but never could get it once it came to actual bits that are more relevant to a game, shit like menus, state machines, saving and loading and such.

Even just a simple shooting game or sliding block puzzle would be cool just to say "I made that".

I used to make pixel art. But I stopped for awhile and never started up again. I had to mobilefag it for awhile and when I got a laptop I didn't bother starting back up.

One of my struggles as an indie dev has been a perpetual loop of people going "I don't care about graphics, I only care about gameplay. I'm not playing that, the graphics are shit." What's more, the styles themselves are considered a problem. Low poly, pixel art, stock assets, all of it gets slammed with the label of "bad graphics" or worse "lazy".

Some people just don't know what they want. Modern "retro" games seldom look like actual retro games because they were played on CRTs. Do younger developers actually think the those old games looked like groups of colored squares because of emulators? I actually prefer the 8 and 16 bit look. But that might be nostalgia.

You can't please everyone. Even if you were able to make a game with groundbreaking graphics you'd still have some sperg claiming they and you sucked your mom's balls. Don't take it to heart too much.

 

[Kung Pow]

When it comes to graphics, in general it is more important to focus not making your game look bad, as opposed to making it look good on the get go. And the reason for that is that making something not look bad is easier than making something that looks good, and something looking bad has more of an impact on the player than something that looks beautiful.

The problem with games is that it can have all, and often needs, the major artistic disciplines in it depending on the project, and if one fails the rest starts to suffer. Imagine if CS looked like Cruelty Squad or Dark Souls having the Crazy Bus soundtrack, very few people would play those games. I think it is better to see the design of a good game as a pyramid, where the base is the technicalities (you can't play if it doesn't run), above it would be the gameplay, and so on. They are all dependent on one another, but there are some that are more important than the others, that is assuming that you want to make a traditional video game and not something like chess or checkers.

 

[TheAmbiguousLurker]

I've made three games (Clickteam Fusion, Unity and Unreal 4), all of them sucked, but... You know, they got 'finished' technically.

Fourth game I'm putting a lot more thought and effort into, wrote down my whole plan, but I'm in that in-between where I'm just good at programming enough to get confident and put stuff together, but still shit enough that I'm getting stumped short of the finish line of getting what I want to actually be realized.

Game went from a shitty horror-lite shooter to a shitty horror-lite JRPG over the course of months because trying to make an AI that incorporated acting in real time within a 3D space broke my tiny brain.

 

[Pepe Cortisona]

Don't blame the tools, blame the low effort people put on the projects.

Hotline Miami was made in Game Maker, Lisa the Painful was RPG maker, Catherine used Gamebryo, Freedom Planet was Clickteam Fusion.

Sadly, for every one of these examples, there is a sea of crap, but I am a believer that, as long as you have passion and care for your project, any game engine can deliver quality games.

 

[ZMOT]

When it comes to graphics, in general it is more important to focus not making your game look bad, as opposed to making it look good on the get go. And the reason for that is that making something not look bad is easier than making something that looks good, and something looking bad has more of an impact on the player than something that looks beautiful.

there's also the first impression, you can't "sell" your game with gameplay (unless you call it another soulslike). similar to having a great personality doesn't help you if you look like a goblin. you need to get people interest first, the rest comes later.
people also need to understand that "gamers" as a group are fucking retarded. but that's the same for most groups. it's like the george carlin joke about average IQ. people saying "graphics don't matter" simply says they don't know their own process of selecting games, or are literally such niggercattle to only buy the marketed FOTM that their opinion is worthless anyway (don't get me wrong you can make a very minimal game, but something like an atari 2600 game obviously is gonna have lesser appeal than 8-bit).

It's a good line of thinking, but one I struggle with. "Make a game that you want to play" only works as long as you want to play something that isn't weird, autistic, and esoteric. It's the game dev equivalent of those people that tell single people to "just be yourself". Sure, it makes sense, but it assumes "yourself" is a normie.

the idea is you are happy with the result, even if the result is having no sale or get no pussy. otoh if the result is to be the next phil fish or get mad pussy, that obviously isn't the solution (or make you happy).
however, and I think that's the most important aspect (and often gets said but always overlooked): if the goal is the latter, you'll likely gonna fail. it's a process, making a game for yourself means you understand what works and what not, in the end you learned something (same way not to be a sperg when talking to women unless you're loaded).

to some degree I think people underestimate the effort and time it takes to get somewhere, and it doesn't mean all that hard work is gonna get rewarded inevitably. the world sucks, it is what it is.

There's also the tutorial problem where using Unity or Unreal to make a game only works until the minute you want to do something that isn't covered by a tutorial or a bloated plug in.

it's not really a problem, it's just that that people learned wrong. it's basically like "I know the vocabulary but still can't speak it because I know fuck all about grammar". if someone never learned the problem solving and figuring out the implementation, which is a large part of it, of course he won't get anywhere on it's own. blindly copypasting code from a tutorial only gets you so far.

 

[Anti Snigger]

I do some stuff, but the niche is pretty small so I can't be too specific. Lots of fun though, I don't have much of a mind for game design, but the group of buddies I do it with do so I've been learning

 

[Coolio55]

Since we're all bringing up engines, I just want to whip out my big hateboner for how much Clickteam sucks my spider balls.
(This is the killer one) Extremely hard to make multiple levels unless you copy and paste code (that doesn't update when you change any other instances).
Integer numbers only.
The programming system is very confused on whether an object refers to a single specific instance or every instance of that object.

@Tiggie_Tiger
Haven't used Godot in a while and just came back so I can believe the API weirdness. It even seems like we're going back to the old days where the older branch has some killer features that the newer doesn't.
(IIRC 1.1 had dictionary inspectors long before the 2.0 branch got them. Now the 3.0 branch is getting shit like mesh merging and LOD.)

I can believe the memory fragmentation issues. I remember in one of the devlogs for version 4 they mentioned the changing of a lot of internal structures to modernize everything and make it more cache efficient.
Some of them probably made sense but what really rubbed me the wrong way was the removal of all the packed arrays. I can't remember if it was Juan or Ariel but they said that modern 64-bit allocators handled fragmentation much better.
Ironically, packed arrays have actually come back to en vogue in the meantime.

As for the yield issue, do you have any tickets for it? Not doubting you, just interested.

 

[Gender: Xenomorph]

My take on game engines:
* UE looks bland, and is bloated
* Unity is versatile, but the monetization is ass
* Godot is a buggy mess
* Gamemaker is primitive

 

[Pepe Cortisona]

It seems that there is talent here in the forum. How come you haven't banded together an give it another shot other than the Yandere Simulator clone?

 

[Geddy Lee's Fee and See]

Random question: How many of you have made your own game engines, for what project, in what language (probably C/C++, but still curious) and how long did it take? I'm curious to see if there really is a use case for building your own game engines anymore.

 

[Tiggie_Tiger]

Since we're all bringing up engines, I just want to whip out my big hateboner for how much Clickteam sucks my spider balls.
(This is the killer one) Extremely hard to make multiple levels unless you copy and paste code (that doesn't update when you change any other instances).
Integer numbers only.
The programming system is very confused on whether an object refers to a single specific instance or every instance of that object.

@Tiggie_Tiger
Haven't used Godot in a while and just came back so I can believe the API weirdness. It even seems like we're going back to the old days where the older branch has some killer features that the newer doesn't.
(IIRC 1.1 had dictionary inspectors long before the 2.0 branch got them. Now the 3.0 branch is getting shit like mesh merging and LOD.)

I can believe the memory fragmentation issues. I remember in one of the devlogs for version 4 they mentioned the changing of a lot of internal structures to modernize everything and make it more cache efficient.
Some of them probably made sense but what really rubbed me the wrong way was the removal of all the packed arrays. I can't remember if it was Juan or Ariel but they said that modern 64-bit allocators handled fragmentation much better.
Ironically, packed arrays have actually come back to en vogue in the meantime.

As for the yield issue, do you have any tickets for it? Not doubting you, just interested.

Godot has a history of poor management. I don't remember who but there was some disagreements between one of the main contributors and the lead developer (Juan Linietsky) over the direction and development of Godot. I don't remember what exactly happened since it was so long ago, but I think they were booted off the team. What I see is that Godot doesn't really have a main goal, it's just slapped together bullshit without any focus for quality and blatant disregard for performance.

that modern 64-bit allocators handled fragmentation much better.

Sound like they've based this on an assumption rather than direct testing in real a case scenario. But I personally wouldn't remove Pack[some type]Array's on this alone. It should be an optional feature that developers can use if they want to.

As for the yield issue, do you have any tickets for it? Not doubting you, just interested.

I don't have any direct examples to show you, and this issue has probably been fixed by now (I've not touched Godot for a while now). In some cases when using yield with get_tree().create_timer will generate a unique bug which will cause random unexpected crashes. Sometimes things ran fine, other times you'd get the crash. Due to the lack of errors printed back and the scenario of the bug, tracing it back was impossible. I've only found the issue by guessing. That wasn't a very pleasant experience, I'll tell you that.

 

[foobar]

My take on game engines:
* UE looks bland, and is bloated
* Unity is versatile, but the monetization is ass
* Godot is a buggy mess
* Gamemaker is primitive

All lower the entry bar by abstracting away core engine functionality and cucking developers into going through hooks to execute any logic, with little to no control over program execution. Now we have an influx of soydevs who are too dumb to look under the hood and will write inefficient/shitty code with no understanding of what it is actually doing.

 

[DumbDude43]

So yeah, I'm pretty blackpilled on the idea of developing games to make money especially if you wanna go the "just make what you yourself want to play" route.

Random question: How many of you have made your own game engines, for what project, in what language (probably C/C++, but still curious) and how long did it take? I'm curious to see if there really is a use case for building your own game engines anymore.

if you count really primitive games like snake and tetris that i made as practice projects while learning new languages, then yes i have made engines from scratch.
i also once made a generic 2d game where you could control a character and move around a 2D grid, interact with other entities (combat or dialog) and have basic inventory management, that was technically a game engine too i guess but again i was doing it mostly to familiarize myself with the language and abandoned the project long before it was anywhere near playable.

but real talk, even for serious games enginedev is not as impossibly difficult as it is often made out to be. you can find youtube videos where people shit out a minecraft style 3D voxel world engine from scratch in a few hours, for 2d games it's much easier and faster than that.
the general purpose engines on the market (unity unreal godot etc) are ultra huge and complicated because they have to be generic and work with every possible game idea a dev could possibly have. but your own homebrew engine only has to work for your one specific game, so you are allowed to build everything for a specific purpose and ignore everything else, so your engine gets to be much smaller and simpler (and easier to make)

you do have to make some compromises (you will probably not be making a renderer that looks as good as what unreal can do) and you need better programming skills than someone who just plugs things into unity, but in my opinion it's worth it.

 

[Tiggie_Tiger]

Random question: How many of you have made your own game engines, for what project, in what language (probably C/C++, but still curious) and how long did it take? I'm curious to see if there really is a use case for building your own game engines anymore.

I've never built a general purpose engine for a variety of games, I have however created games written in C with OpenGL. The time it takes to build a game from scratch depends on the project. A few months to years.

Yes, there is plenty of reasons to build your own engine. Foremost, you have complete control over how the project is developed, you can quickly fix issues directly without having to create workarounds with an existing engine. You are also building the required functionality for the game, which can lead to a simpler and smaller and more efficient codebase, and I have complete control over how the various systems should work. A big one for me is that I have a complete understanding of what's going on. Non of that blackbox bullshit.

I've noticed that writing a game without an engine or an overarching framework ends up being more efficient in a lot of ways. Though this is hard to convey to those who don't have this kind of experience.

Sometimes I will use other game engines to mess around with, but I'll never use one for any major project.

Edit: Just wanted to be clear that I don't hate game engines inherently. There are some valid reasons to use one. Recently, I've grown to avoid them.

 

[Mr. Bobby Brown]

I just dick around with rpg maker alot. I tried to remake other games like FF4 and Wizardry for fun, but I always struggled with actually trying to make my own games.
For the past few days now, ive been trying to make an RPG for a game jam, but i honestly don't think i'll finish it in time.

 

[DiggieSmalls]

I started doing a passion project in Godot. Like making my own assets, concept art, OST. Just getting into art. I get making art and putting importance into people enjoying it, but it really hinders exploring what ideas you have. Anything and everyone on the internet gets shit on. Tons of great stuff gets ignored. I think the hardest thing I had to realize as an artist is that I need to make art for myself, not for other people. That said, there's always a group, no matter how small that will enjoy your work.

 

[and and and and]

You don't need high quality graphics, what you need is well stylized graphics. People can tell if something looks generic and that doesn't matter if you put nothing or everything into fidelity. Graphics are like the cover of a book, it really doesn't have any impact on the actual contents of the game but it'll definitely go a long way in determining peoples first impressions

 

[Individualism Incarnate]

Fuck it, I'm downloading UE. Probably going to give up learning it in a couple weeks but it's something to do at least.