I think that is an horrible piece of advice.

"The Case of the Golden Idol", "ΔV: Rings of Saturn" and "Lumencraft", to limit myself to some games that are released here, are all games that were made with Godot and have been well rated and successful.

The gaming industry, particularly indie and AA game devs, need to gradually move away from proprietary solutions like Unity as a building block and instead help foster a more open ecosystem to create games in.

Proprietary solutions like Unity have more tooling currently, but at least a handful of open source game engines currently out there are perfectly viable to create good games in, particularly if you are an indie dev.

Not Tetris; try something simpler like minesweeper. Tetris requires knowing grid collision and matrices.

Godot?
https://www.youtube.com/watch?v=wdeto5kXd40

I would run away in fear. If devs are mentally that "stuck" and with lack of heart, this leads to nothing good.

A game developer I know posted that, given how the Redot fork started, it's unlikely that it will be continued to be maintained.

Therefore, you should stick to Godot, and not use the recent fork.

From what I understand, forks tend to only be successful if at least one of the following statements is true:
* The original project is no longer maintained.
* Many of the prominent original developers have moved to the fork.
* The fork exists to fill a technical niche that the original project does not.

As for Godot versus Redot:
* Godot is still maintained. In fact, just last month they released 4.4 dev 2. (Note that I recommend sticking to 4.3 for new if you're just learning the engine.)
* From what I understand, there hasn't been an exodus of the main people behind the project (though I'm less familiar with this now).
* There;s no mention, anywhere, of any technical niche that the fork fills.
.

just a reminder: Manjaro forked from Arch in the similar way. and is alive and healthy. so let's not bury Redot prematurely.

I went through a game design course and this basically sums it up. We were all capable of making something but a small percentage of us were gifted or committed enough to make something seriously impressive.

Tbh, it didn't help that creativity was also limited by campus politics. It's not the topic so I won't waste my breath but if anyone was wondering why so many young developers seem to lack edge: let me introduce college/university.

Here's the important thing: Manjaro has made technical decisions that separate it from Arch. In particular, this includes having a real installer (as opposed to it being done manually via shell commands) and including more software in the default installation. Hence, there's some actual technical reasons to prefer Manjaro to Arch.

(Arch still exists because there's still technical reasons to prefer it over Manjaro, like if you prefer the control the manual installation gives you, if you don't like the "bloat" that's installed by default (and you consider it bloat, of course), or if you want the more up-to-date (and sometimes breaking) software that Arch provides. Plus, I believe Manjaro still uses upstream packages from Arch.)

As is, there's no real technical reason to choose Redot over Godot.

Splitting your community because you start peddling politics around a game engine of all things, generally doesn't seem like a good thing. Nothing positive will ever come out of that other than division and they just intentionally made more unnecessary holes into their own ship.

Just my opinion. Feel free to believe whatever you want of course. Your mind seems pretty made up.

Some interesting reading on the subject of Godot as a whole from one of the former Godot maintainers:
https://waiting-for-blue-robot.gitlab.io/index.html
Should be mandatory reading for anyone thinking about Godot.

Several hours long, but quite eye-opening and a lot of things start making sense. Downplay it all you want, but the way they are handling the current "situation" is nothing short of terrible.

If you want to read it (definitely recommend), read it in its entirety. Don't just jump around chapters, or you are not really going to be able to piece together a full picture.

Having read the book in the link I posted above in its entirety: https://waiting-for-blue-robot.gitlab.io/index.html
I do agree. The latest "happening" is honestly just the cherry on top.

the. reason. to. fork. was. the. same. period.
I didn't say anything abt diffs now.

https://www.gog.com/en/game/city_game_studio_a_tycoon_about_game_dev
https://www.gog.com/en/game/dome_keeper

and i think all the Devcats games

Yes. Making games is hard.

Though, making your own games, is probably easier today, than it has ever been before (in some regards at least).

Because nowaday we have all these "game engines" available, which enable even people with zero programming knowledge, to create games per "drag and drop", etc.

But "making games" still requires a lot of creative work.
And what that really means, is: "you need to be creative" and "you need to put the necessary work in".

Ask yourself: "what do I need to create a game?"

Hint: your first answer to that question shouldn't be: "game engine A" or "game engine B".

Instead, the first and most important thing you need is:

- an idea

Because, without an idea, you have nothing to work with.

Then that idea needs to be fleshed out.
Because your first flash of an idea is probably not (good) enough to get you a game in the end.

I kid you not: "fleshing out the idea" to a point, where it becomes even worth to switch on your PC, to do the "programming" part and to create all the art, music and sound FX, is probably the most important and the most time consuming part of the whole "game making" process.

The good thing about that process is: to fulfill this first requirement on the way to a new game, all you really need is a notepad and a pencil.

Now, what is ist exactly, that you need to work out?
- the story (even if it's not a "story game" - it still helps to have some sort of background story for every game you create)
- What features do you want your game to have (MP, (online) Highscore list, several difficulty levels, the ability to save/load, etc)
These two points are the most important for now.

If you want, you can also spend some thoughts on:
- the kind of graphics you need (one word of advice, though: don't waste too much time on imagining the "perfect" graphics this early in the process...placeholder graphics are good enough at this point. And yes - I highly advise to start with a 2D game. Leave that fancy 3D for after you earned your 2D spurs)

If you really want, to can even think about:
- the sound FX that you need (if your game needs them)
- the music that you need (if your game has use for music)

After that is done, ask yourself: "how much of this can I do myself? Where do I need help? Do I know someone who can help me (e.g.: with the music/soundFX)? If I don't know someone - where can I find someone?"

In regard to all of the above (with exception of the story), you might get away with using stuff, that is offered online for free.
There are many sites, where graphic artists, musicians, etc. offer their output either for free or for a mention in the credits of your game.

Good thing about going down that route: you can basically find everything you might ever need for free.

Bad thing about going down that route: your game probably shares a ton of graphics, sound FX and maybe even music with dozens of other games - which means, it won't "stick out" in the mass.

Now we come to the "game engine" part.

Which one you use, is entirely up to you, but - as I said already - for your first few games, I'd advise to go with one that's good (and easy to use) for 2D.

It should go without saying that, if you never worked with a game engine, you'll have to find your way around its features, first.

Much is done today be "drag and drop", but game engines often come with their own "scripting language", which you may need for some of the more sophisticated tasks.

After your first (successful) attempts with such a script language, maybe your appetite gets whet, and you want to dabble in some programming language (preferably one that gets supported by the engine of your choosing), like: Python, Lua, C#, etc.

Once you reached that point, the "handiwork" may be easier for you, when it comes to making games...but - having a worthwile idea (and working that out to become a game) will still always be the #1 requirement.

So, as you can see: making games is hard.

To close this: I absolutely support what some others have said - start with something small and simple.

Don't try to re-invent the wheel - re-create a few already existing ones, first - and while you're at it: maybe give them your personal spin.

Edit: typo
Edit 2: wrong word used

It's easier than making your own graphics card, that's for sure.

I would say not even that. I think you need to start with the narrative core of your game. What would make the game appealing for a player to play in any capacity? And it is not an easy question to answer.

From there, your exact needs (ex: multiplayer, difficulty settings, state persistence, etc) will emerge during the development process.

Don't ship your game with that, but so far, I found AI to be great for placeholder graphics to quickly iterate. However, if you have animations, AI might suck for that, because so far I've found it is really bad at creating subtle variation of the game picture.

You need to think about it I think (I think music & sound is an invaluable tool in any game to establish mood), but unless your game is a musical, you don't need to think about it too early in the development process.

You can do a do-over once the game nears completion. It helps limit context-switching I find.

Also, you can buy a lot of music and sound effects for very cheap (Humble store often have bundles for that). You do need to pay special attention to the license (always double-check the terms) and you need to keep in mind that you don't own that music and it is possible that at a later point in time, if your game does really well, you might want to change the score, but that's a rich person's problem once you have a game that is out there and doing reasonably well. Your immediate concern is just getting your game out there and that is a struggle in itself.

Otherwise, for potentially having the same music/sounds as some other games, not a huge amount of games in the lower budget range (higher budget games tend to have music created for them anyways) are very successful, so the likelihood that another game a lot of people have played will have the same music score as you is not that high, particularly once you consider that the music that is appropriate for a game is very dependant on context (you can't just copy the music from another game and expect it to be a good fit even if you can legally do so).

I like to pay some money for it, because it gives some degree of insurance that they won't completely pull the rug out from under you. It is not that expensive.

If you have a reputable merchant selling reusable music and they rip you off, then they have something to lose: Their reputation.

See my statement above.

Here's the thing: Manjuro was forked for more than dumb, petty, completely selfish social reasons.



It was one donator (in the range of 100€) who got upset. AsmondGold and other wingnut grifters are makinng a complete circus over a 100$ donator.

If people aren't emotionally mature enough to handle a difference of opinion like this, they shouldn't be working on anything but personal projects. I'm sick and tired of this idiotic chest beating, grandstanding over the assumed right to be uncultured.

The mistake that Godot PR made was making a tweet, instead of throwing away their twitter account months ago and keeping to BlueSky or Mastodon, or other members of the fediverse. They should have known better than to go to the platform where intelligence goes to die.

Addendum: I'm sure that person feels proud to have helped indirectly contribute over 1000 Euro to Godot via their little tantrum.