Create a First-Person Shooter In Godot | Hacker News Reader

Create a First-Person Shooter In Godot

godottutorials.pro

302 pointsstudentLS72 comments

We play with this at home before my 5 year old goes to bed. I create little 2d scenes that we draw together on tuxpaint such as him going to school or riding a space rocket. It's good family fun. We used to do this with pygame, but I had to hand-craft a lot of the animation and scene building, and the code screen was a bit boring to look at for 15 minutes while I figure things out.

Sony's Dreams (https://www.playstation.com/en-us/games/dreams-ps4/) is absolutely worth looking at if you want to play with a game engine that children can use. It also incorporates the ability to remix anyone else's creation and automatically attributes the creator in your project.

They also bake in a pretty fascinating way to play those games inside of Dreams itself, making it a YouTube of video games.

Nice! I was wondering if would try something like this, but in the end, I takes me too long to create something entertaining even with a nice game-engine such as Unity.

So far I opted to play with Scratch Junior, as that

a) runs on my tablet

b) is simple enough for my kid to do most of the scene-building/programming herself :)

c) the block-language is simmilar to the one used with Lego Boost that we have as well :)

On the other hand, it is kinda limited, and we are only able to do simple point and clicks, so I might try Godot now, and see what can we make of it :)

You could also try normal Scratch now that it works on iPads in the web browser. Still limited compared to something like Godot, but it is more like a "real" programming language and would probably be a good stepping stone from Scratch Jr to something else.

I think we try Scratch once she learns to read :-)

That's pretty awesome, I really feel like I need to up my Dad game.

Do you mind sharing a game or screenshot so I can see what's possible?

My four year old is really struggling with the alphabet, I'd like to make a Shooter for him called "Destroy Z", where he would have to identify letters and then go kill them.

Godot's download size is pretty small, and there's a small demo included, along with a few other demos that are similarly pretty small files that you can download directly from the client, mostly MIT-licensed, including a first-person shooter demo, I think.

Grab some freely-licensed assets (there are a bunch of them, they're pretty easy to find with the obvious search queries, mostly CC-licensed), then the code for what you want should be pretty easy to hack up in a couple hours. GDScript, while not very elegant, is simple enough to where you should be able to learn it pretty quickly (it's aimed at non-technical people), and if you don't want to use it, you can use other languages, too.

Some of the ways it does things is a bit confusing, but if you keep docs and a search engine close-by, you'll figure it out; good luck, it's always nice to see parents who care so much!

This would be super easy and fun to do in Scratch. For sure someone has done a similar game you could borrow to start.

Also: don't worry about a 4YO struggling with letters. It's OK. But do make the game anyway.

I feel like there's room in the typing game genre for an easy mode meant to teach kids the alphabet.

Something like https://zty.pe/ or Type to Learn mashed up with Reader Rabbit.

I know there's a lot of disdain for them but I credit a lot of my early development to edutainment games. Difficult to pin down their actual effect of course.

As someone used to living in my editor, I have a hard time grasping the workflow that combines configuring lots of stuff via UI, and then having code in some files in addition. When making "real" games (something bigger than a demo/prototype) in Godot , Unity etc., is the UI used much? Seems constraining, or how does it play together with lots of code?

Asking because I'm interested in learning, but when experimenting myself I end up with the worst from both somehow.

Making games is very visual. So yes, you do a lot in the editor. And as someone who also uses code to give initial positions and rotations: it is easier to get an idea how things look in a visual editor than with code.

We tend to make visuals, visually. See Photoshop, Illustrator, Blender. There are others such as Substance and Houdini that use visual programming. Also visual, but also coding (much like UE4 blueprints) but you can see results throughout the code which is something that coding has a harder time with.

Most "real" games (Not what I'd call it, I'd say larger/complex games) are made by teams of different disciplines, not just programmers. The UI of Godot/Unity/Unreal, and most other engines is catered towards that, teams with all different specialties collaborating.

Yes, using the UI is very important.

In Unity, having a good UI in your inspector will let you, the programmer, empower the other team member to use what you've created. Designer, artists, etc. will be able to tune, tweak and modify a lot of things without dealing with the code, or having you deal with the code.

Yeah, my problem may be I'm used to working with frameworks and not engines, so I try to do everything in code. Which means reinventing some stuff or doing grunt work (placing tiles manually), and not being able to use the UI properly (attaching behaviour to entities).

But it's hard figuring out what should be done where, and how to utilize the strengths of both parts. Would be happy if someone had nice tips / readings to share.

I think ideally you should start with the editor and only move to code once you have a need the editor can't provide.

Think of Photoshop. You'd never want to code your own effects or workflows if they're already there. In the case of an game editor you'll eventually need to code some behaviours or interactions between entities, and even then you might be able to do those with a visual editor which a few engines come with.

In a way, code should almost be your last resource when making a game.

Also think that making a game is a heavily iterative process, you want to reduce the friction between iterations as much as possible. So even code should be targeted at exposing options that you can edit on the fly within the editor. The benefit of a good editor is that it is WYSIWYG. So if say, an object is not lining up, has the wrong colour, particle effects are staying for too long, etc you can quickly pause and adjust the values in the editor and see the result immediately, no need to be tweaking values in a file.

Do what works for you. Make things data-driven through the editor when it suits you more. Do it in code when it suits you more in code. Only in teams do you really have to worry about where something is beyond personal preference. Example: You can use Node.GetChild(index) in Godot to get a node in the code, or you can expose a nodepath variable in the editor to hook the node to. The first method is code-based, the second one is data-based and more accessible for users. I doubt the performance difference is very significant (and its only done once, anyway).

Other than that, avoid using volatile structures when things need to be solid (above examples easily break when the structure of the children changes, the name changes, etc. whereas a more sophisticated, code-based construction wouldn't), and avoid rigid implementations when you need flexibility.

UE4 has a really nice balance here; you can create your own C++ classes, either by inheriting from UObject (lowest common denominator class), or higher level classes like UActor, UPawn, UCharacter, UTexture etc. There are component classes that can then be attached to these to give you a composition based approach, rather than just pure inheritance.

With C++ you have a very fine grained control over everything, however the compile/link/dynamic reloading cycle can be quite slow and you don't get much in the way of instant visual feedback.

This is where Blueprint classes come in; they can inherit from both C++/Blueprint classes, and can be extended very quickly in the editor using a node editor similar to what you'd find in the UE4 Material Editor and Animation Graphs, Blender, Substance Designer, Nuke etc. The feedback loop is much tighter and you can see the results on screen much more quickly. Downside is that not all API's are exposed to Blueprint, and they are a little slower than C++ classes. This can be mitigated somewhat by compiling Blueprint classes to C++ in recent versions.

I am more into the managed languages side of game engines, but as far I know from UE presentations, dynamic re-loading of C++ should be quite ok nowadays.

As I think we have discussed before, it had difficulties at least as recently as 4.18 or 4.19 when you added or removed variables/members into classes or structs other than at the end, which is not totally unexpected. It does mean you have to restart the UE4 editor which can be slow. Also compiling UE4 C++ code in general can be extremely slow. Is is extremely tempting sometimes to prototype some new feature in Blueprint because of this, as a result you can end up with a lot of unwieldly Blueprint code that you never rewrite in C++.

Use the UI for level design, use code is for features. So placement of opponents, spawn location and configuration of opponents is all in the UI as its primarily artistic and subjective. You can judge what it looks like from the editor, unlike code. Code is used to create the infrastructure to support the level design.

I'm with you, 20+ years of staring at an editor is hard to overcome :)

I could see how a scene editor would be useful for a game like super mario bros, but how do I use it when my levels are procedurally generated?

Unity lets you execute scripts in the editor, so I usually execute level generation scripts on the editor and player/effects scripts when the game is playing.

Scenes aren't just levels. Let's say you're making a bomb item for your game, in Godot you would probably make a bomb scene with a particle emitter and a model and a collider. You could then use the scene editor to configure these components instead of having then all in code. Tweaking certain parameters is much faster with the UI than using code and a debugger. Imagine trying to line up a sphere collider with a model using code and a debugger, vs just dragging the handles around.

The scene editor also works as an inspector, so you can fly around your scene and inspect properties and the scene graph while the game is running.

Exactly, it's those kind of questions nagging at me :)

>>When making "real" games (something bigger than a demo/prototype) in Godot , Unity etc., is the UI used much? Seems constraining, or how does it play together with lots of code?

Well, I work at a AAA studio where we use different engines, and at least some of the workforce is not actually familiar with programming, or has only very basic understanding of it(think level designers, gfx people etc). Being able to build most of the game in the editor without touching any code is very beneficial to this. Usually the flow looks like this: level designers request feature X, then programmers provide feature X using the built-in code editor, if that is impossible for any reason then it goes down to engine programmers who add the required feature directly into the editor.

Which engine(s) are you using? I thought only Snowdrop was this way.

Well, you do know it's Snowdrop ;-) But we use other internal engines too, the flow is pretty much the same as far as I can tell. Not when people are using Unity/UE for obvious reasons.

Artists and designers are accustomed to Maya-style GUIs.

As a counter-example however, I worked at a game studio where we made our own engine. We didn’t have the time to make GUI-based tools. So, instead we focused on text-based configuration, Lua scripting, fast asset baking and hot-reloading of everything mid-game. When we switched to Unity for business reasons most people thought it was a productivity reduction.

Even if you're primarily making a game and not a general purpose engine it's really helpful to get some things out of text and into a visual medium. Usually in that case the tools are built into the game or a specific game editor. Examples are level editing, putting together animation, setting up assets for example transforms for character customisation and the biggie I've never not seen in a game runtime inspection of the game in progress.

All of this can be edited as text but it becomes laborious and error prone. Even setting up stats for something like an RPG is often better done in a spreadsheet where the results can be modeled.

I never managed to like unity or godot because they remove freedom from the developer. Your code becomes a second class citizen.

Apparently level design people and artists like it, which makes sense, of course, since indie gamedevs and small teams who are full of ideas and content, want to work as quickly as possible.

But as a developer, I just loathe those tools. They sort of make sense for non-developers who want to make a prototype game and "tweak" things by writing as little code as possible while getting bleeding edge graphics. In reality it just enables unambitious projects so that "anybody can make games". It's like comparing LEGO to mechanical engineering. Of course, if you're pedantic, a LEGO car fits the definition of a car. You can sell a lego car, and then you realize how twisted the indie video game market is right now.

But if you want to make a game, those WYSIWYG things are horrible. They're viable, but if you have some issue or limitation with the tool, you're really stuck. If there's a performance problem, it becomes more difficult. If you want to release on console, there are additional steps and work to do. You cannot "use what you want", because it's a huge generic blob of things that you cannot really understand how it's made.

I watched a video about the internals of godot and was not convinced at all. Of course it's open source but it's a giant mess. Unity is not even open source.

I will always show this video each time those WYSIWYG tools are talked about: https://www.youtube.com/watch?v=tInaI3pU19Y

It's the 40 years old debate "should I use this feature rich framework to make the website of my grandma?". The answer is "you either care about your ability to write code, or you don't.". Simple as that.

Another result is a large bubble in the video game market. There are just too many games. In a way, it helps people gaining experience, but even many of the great games are often very short lived. I think it will give a bad reputation to platforms like Steam etc.

These visual editors are a godsend when developing a videogame. Even with ThreeJS, which is still an abstraction of OpenGL, I've had a lot of issues with really simple visual problems, like getting my models placed at correct locations at correct scales with the correct rotation. Trigger box placement. Enemy spawn locations. Their visual fields. I ended up having to essentially script my own visual editor to debug these issues. God forbid I have to implement any sort of networked multiplayer.

And yes, there are a _lot_ of games. Steam is already suffering from the lack of quality assurance. But allowing creativity to flourish like this is good for society in the end.

Personally, I think UE4 has the right idea. You can have your first-class citizen code (C++ components) which you can hand off to be used by the more design-oriented team members (Blueprint scripting + visual editor).

Honest question: What does the dev process actually look like for AAA games?

- Do they create levels/scenes without a visual tool to set the positions of everything?

- Or, if AAA studios tend to use some kind of visual tool, is it not a WYSIWYG tool? How does it differ?

I'm not a game developer, but I've tried gamedev as a regular developer, trying to do everything in code. Laying out the positions of objects in code, rather than visually, is a huge time sink. So I'm really curious how this could be done quickly at a large scale without some kind of visual tool.

Professional game teams use visual tools. Visual tools allow non-programmers to do work / prep files / iterate on ideas / create animations without an engineer being involved.

An individual indie dev doesn't care about that, so having hardcoded data may be a faster workflow.

In the studios I've worked UI artists work on the UI files and then pass them off to engineers to connect to the code. Tuning data comes from spreadsheets, and art/animation comes from artists, and they generally have a one-button import process that doesn't involve an engineer.

Visual tools are used all the time, take a look at UE4 or Unity, most AAA engines look pretty much like that. Not all engines are as polished as these two (since those are products by themselves so they have to look shiny and do a lot of stuff to cater to a large demographic) and not all engines use the monolithic approach where the editor and the engine are one and the same (AFAIK Sony released a framework of theirs a few years ago for C#/WinForms that they used for internal tools which were completely separate from the engines - a programmer i know who has worked on something similar also told me that the tools even had their own separate renderer). But visual tools are involved in one way or another, especially when it comes to inherently visual stuff (e.g. like you wouldn't manually put pixels in an image and use an image editor instead, you wouldn't put the objects manually but use a scene editor).

How much they go towards visual vs non-visual is largely a matter of engine and tool design. In UE4 everything is done visually, including scripting. In Unity most behavior and scripting is done via C# but the rest are done visually (though there are addons for visual coding and/or behavior too). In a company i worked at some years ago everything outside of scripting was done visually using a combination of in-engine and external (but still custom) tools. In a company i worked more recently almost everything outside of level design was done via text files and there was no scripting at all, all game logic was in C++ and driven via text files (however the editor had a very flexible parametric prefab system which allowed a lot of modularity so you could still have some simple form of logic through reusable components).

In my own engine and editor (you can see both in action here[0]) i have them totally separated - in fact i started wroting the editor three years before the engine and i used it for different stuff (e.g. this little creepy[1] game i made for an old Ludum Dare in Java/LWJGL which i lated used as a base for this Descent-like demo[2] and later in this[3] demo i made to learn C#/XNA). Outside of world editing, everything else is handled via scripts (actually even inside the editor you can 'attach' script code to entities, it is just that the editor doesn't know about them, they are just passed as strings to the engine which handles them as scripts). These scripts are mostly edited by hand[4] or generated by other tools (e.g. the model editor generates scripts that define animation details through scripts) or scripts.

Though recently i'm thinking on scrapping everything and making a more unified monolithic engine. Architecturally i believe it is better to have everything separate (especially the engine from the tools, but also the tools individually) but in practice it is much more convenient when i can reuse existing code - as things are right now, even though i do share code between the tools, i still have to reimplement a lot of stuff that a more monolithic approach wouldn't require. Nobody else except me is going to use that code anyway :-P.

In any case, if you are curious about how tools are used in a game, even if a tiny game made in two days for a gamejam, you can see the two-days-compressed-to-one-hour video i made for the She Loves you game in [5].

[0] https://www.youtube.com/watch?v=8gnDdM_PC54

[1] https://www.youtube.com/watch?v=LeIIt5Wydyw

[2] https://www.youtube.com/watch?v=5WrV4By94pQ

[3] https://www.youtube.com/watch?v=GP9kTbYxIqY

[4] https://i.imgur.com/tCd64Wh.png

[5] https://www.youtube.com/watch?v=YXIDzwUMnIg

> They sort of make sense for non-developers who want to make a prototype game and "tweak" things by writing as little code as possible

I'm a programmer for life and I am always looking for opportunities to turn code into data. The editor is just a way to edit some of that data.

You can take this take this too far though. The inner platform effect is real and I'm not personally a fan of visual scripting languages most of the time. But even that has nuance, because writing shaders visually in Unreal where you get an image preview at each step of the transformation is incredible.

Note that I'm not a game developer by day and when I do dip into Unity/Unreal I tend to also avoid the editor, but looking at it as a spectrum from developer to illiterate is a fallacy.

On professional games, your code is a second class citizen, is is only a tool to bring the level design, the game story to life and that is not made by programmers.

Programmers on game studios are akin to SFX and film processing processing on movie industry, that is not what a movie is all about.

In many studios they are even writing game engine plugins for several games ongoing at the same time.

One of the main benefits to opening up development of games to the slightly less tech savvy is the gems that come out of it.

The fact everyman and his dog tries to sell their first hobby game and stores do nothing to differentiate between quality products and crapware isn’t the fault of modern game engines. Rather blame the commercial culture around game development and the storefronts themselves.

Also if you think Unity etc. are bad you should see the rock bottom quality of internal tools people used to put up with!

I had a similar experience going through the Godot "Your first game" tutorial [1]. I have little experience with game engines, but attaching signals in GDScript seemed like it required GUI interaction, then it was difficult for me to understand when the signal code actually was run.

[1] https://docs.godotengine.org/en/3.1/getting_started/step_by_...

https://docs.godotengine.org/en/3.1/classes/class_object.htm...

Each Node has access to add_user_signal() for creating signals in code, connect() and disconnect() for subscribing to the signals, and emit() to emit a signal outside of Godot's predefined framework (along with other methods). Generally, anything you can do in Godot's editor can be done in code.

Your comment reminds me of when I started OSX/iOS client development. It frankly gave me some sort of anxiety how much a single checkbox on some UI pane with some element selected in Xcode could change everything.

It at least would show up in your git diffs as a change in the generated XML, but I always felt like I was credentializing in a bunch of trivia knowledge as I leveled up in the Xcode's controls.

Much like managing your database in phpmyadmin instead of maintaining a simple schema.sql file.

Unreal is the worst here because their C++ API documentation is unusable, and all their official, fleshed out docs are for a visual node-based scripting system called blueprints. Those blueprints seem to be their main focus and I just hate programming via click and drag.

In unity/Godot, at least you can still write a program mostly in code

Blueprints aren't for programming, they are for scripting and the material editor. As soon as you want a data structure more complicated than a map, or to do for loops inside the blueprints, it gets unpleasant.

Unreal is designed to integrate with a hot reloading visual studio setup in c++. Extending and sharing code is a breeze with plugins and many people fork the whole engine itself to make significant changes. One team reimplemented source style movement in their fork and shared it.

Thanks! Good to see a proper textual tutorial. Videos are sometimes hard to follow (pause-play-rewind..)

If you don't know, just like me, what Godot is, it is a 2D/3D opensource game engine. [1]

[1] https://godotengine.org/

It is open source alternative to Unity3D and UnrealEngine that bundles 3D engine, scene editor, code editor and debugger. The editor is much more lightweight and faster than competition so you can use it even on older laptops. Supported languages are GDScript (python-like), C# and visual programming with routing nodes. There is also support for native code execution which allows community to hook up their own favorite language.

The engine targets all major platforms including mobile and VR. Consoles are not supported due to necessary NDAs, but there are still some Godot games deployed.

Some things lack polish (API documentation mostly), but the development and community around it is very active and positive. Works best with Blender as modeler. Currently the Vulkan support is in works and planned for next major version.

As for engine quality, you can judge from last year's showcase: https://www.youtube.com/watch?v=NlKEO1N8wMM

They just got $250k from Epic https://godotengine.org/article/godot-engine-was-awarded-epi...

Its current big downside (which I hope they address in an upcoming version) is that it lacks occlusion culling. So while it does have half decent VR support, for example, the performance in anything but very simple scenes is quite poor.

Seems they've got pretty good funding and traction for a FOSS game engine.

https://www.phoronix.com/forums/forum/software/linux-gaming/...

Does anyone know the state of C# support and documentation? I played around with Godot in the early days of C# support, and I found I had to translate from its documented API calls in GDScript which was quite cumbersome.

i spent aprox 160hrs learning the newest version of godot (3.2) using c#.

It's pretty well featured for hobby projects and experimenting. You can translate any GDScript example into C# on nearly a 1:1 basis. So honestly "C# docs" are not needed.

The big turn off for me, which I only came to the realization after my 160hrs, is that there is no easy way to performance analyze/tune your code. You have to manually instrument with Timers and even that is of limited utility when you have unknown 15ms+ spikes every couple seconds (and that's not even GC related).

My desire getting into Godot was to build a job/ecs system similar to unity (because I did this 10yrs before with my own xna based engine) but sadly, until there is better perf tools this is a futile task.

Wow, thanks for the insight! I've really only ever used Godot to play around with so I haven't hit any performance issues.

Would your XNA based engine work with MonoGame and/or FNA?

yes, it's a C# system, though it's written for the .net framework 2.1, and assumes a desktop so care isn't taken to reduce GC pressure very much. The unity job system is based on structs and unmanaged memory to avoid GC pressure, which in hindsight is a good idea for targeting broader platforms (phones, embedded)

Thank you so much for creating a web page tutorial, instead of a Video tutorial.

I can't upvote this enough seeing as doing an FPS is my main godot project. I've been collected fps projects in godot and comparing different methods and really like the simplicity of this one. Cool stuff.

  var x : float = 5.0

What a stupid fucking language. Everything else is great.

It has other options, like GDNative: https://godotengine.org/article/dlscript-here

See for example: https://github.com/GodotNativeTools/godot-rust

It just sounds like another glue language. The reason UnrealScript halted development was because they found that its whole purpose is to call C++ code. So they put their focus into making Unreal a more reusable framework instead of confusing developers with some zainy little toy programming language project that serve as an interface.

This allows using any language really, as long as you can produce a shared library that matches the ABI/API. Which should be good enough for those who have some issue with a particular scripting language.

What is wrong with that example?

We already know by its value it's a float. It's literally easier to type that in C as float x = 5.0;

GDScript can infer the type by writing it as var x := 5.0. I'm guessing it's just the authors preferred style to include the type.

Godot is an awesome engine and I recommend everyone still using the ancient ones like Unreal and Unity to switch to it, at least on new projects. You can script it in pretty much whatever language you want.

Godot still has a lot of issues for which workarounds don't exist, doubly so when working in a team. Issues we've run into:

The way references are handled in scene files makes it easy to get conflicts when working on the same scene. In Unity, solving these conflicts is a lot easier (from personal experience, only an issue working in teams).

Animation files sometimes empty themselves when using a composition-based approach. If the object you reference no longer exists (e.g. you programmatically decide what weapon a player uses and don't instantiate anything preemptively) the animation player will opt to rewrite the animation as if that component never existed, resulting in loss of work.

Low level oddities: drawing lines using the drawing system doesn't work if the point is outside view of the screen. You can't specify whether to draw the segment that would be visible if possible.

There still isn't a whole lot of support to release on some specific platforms, and some popular programs don't have a support plugin yet (e.g. Live2D).

The object-oriented structure of each node type can be severely limiting towards a composition-based approach. Minor gripe as it is possible to work around this or implement your own entity-component-system framework or Unity-like GetComponent/AddComponent structure.

It is definitely a great engine and regarding 2D, I'd say it is at least on par with Unity. For 3D and general-purpose, it is still subpar to Unity and definitely subpar to Unreal. Of course, the easy solution to each of my problems is "why not write it yourself?", but that requires time saved when using Unity. On the other hand, I do find Unity to be particularly cumbersome on the final 20% of the project, whereas Godot is much easier to finish a project with.

Downvoted for "ancient". There's quite a lot of competition between those engines and people have different reasons for choosing each of them. You can find quite a few "why I chose X for my game" videos on YouTube, all with very good reasoning regarding features, payments, available resources, available positions in the industry, etc. Fanboy-style recommendations are not enough.

>I recommend everyone still using the ancient ones like Unreal and Unity to switch to it, at least on new projects.

The last reason you'd want to switch to a new game engine or framework is because it's newer.

And, while I like Godot, the implication that it can replace Unity (much less Unreal) at this point is just ludicrous for anything but bare minimal toy projects.

>You can script it in pretty much whatever language you want.

Yes, no and maybe?

Someone has to write the interface for each language and be willing to update it with each version of Godot, and all existing documentation and tutorials reference GDScript and maybe C#. There are language forks out there but I'm unaware of any projects being completed with them, so their stability and viability is questionable.

> And, while I like Godot, the implication that it can replace Unity (much less Unreal) at this point is just ludicrous for anything but bare minimal toy projects.

That's going way too far in other direction. IMO Godot can support any kind of 2D project and deliver polished and performant product. In 3D medium the competition is too far ahead with ready-made assets and robust tooling, but complex projects still seem doable.

Currently Godot is used mostly by open-source gamedev enthusiasts and not professional teams with art talent and funding. The editor and engine was not really pushed to its limits.

I agree with your other points though.

Fair enough in the case of 2D, but the most common use case for Unity and especially Unreal is 3D games. Godot still lacks features like occlusion culling and compute shaders that would even make it competitive with the other engines in that regard. I think Godot's still a couple of major versions away from that, at least.

I agree that so far no one's really tried pushing Godot to the limit as far as I've seen. But when all you have to go by is the content on /r/godot it doesn't make a compelling argument for Godot as a viable replacement for existing engines yet.

C is even more ancient and it is used by more developers than all the game engines added together. When people use "ancient" tools they tend to have good reasons for it.

Back in 2016 I made a comment[1] about Unity being impressive because of how easy it is to use and a great option for simple indie game. I noted, however, that it didn't yet seem to be a good enough option for AAA development.

Since then, Unity has grown into a serious contender and while my experience with Unreal is limited to hobby projects I can definitely say I prefer Unity over Frostbite for AAA development.

At this point, I'd like to say that what I said back then now seems to be true for Godot instead.

[1]: https://news.ycombinator.com/item?id=13151354

How are Unreal and Unity ancient?

They might be not ancient, but they still didn't manage to produce a good quality parallelized Vulkan renderer. Unreal made something (and marked the whole effort "archived"¹), but it's not really parallelized and performance is bad. I bet Godot will beat them to it, because they are focusing on Vulkan as their primary API.

1. https://trello.com/c/lzLwtb5P/124-vulkan-for-pc-and-linux

As nice as Godot might be, it still as a lot of growing up to do before it can match "ancient" engines.

Reply on news.ycombinator.com