I'm still amazed how small the Godot editor is (last time I checked it was ~25MB). Just how are they able to pack this much functionality into such little space?
In the late 80s I was impressed by a full Wordstar compatible text editor for Turbo Pascal which only occupied 25K (including the compiler). Times have indeed changed.
I'm sorry if this sounds like I'm making fun of your Emacs install (I don't mean to) but how does this happen? Like, what is that when does it load all of that and how much memory/time does it take? I'm genuinely curious.
Well, we should be impressed with 25MB for a decent game editor since the other players like Unity and Unreal Engine are probably around 25GB. It's also a fraction of Slack or Chrome or even the Rust compiler I believe.
The Chromium package on Arch Linux is around 68MB. The Electron runtime is a surprisingly reasonable size. Interestingly, the Go package is over 110MB. Rust is larger.
1 order of magnitude in 40 years? Doesn't seem a lot, but if applies exponentially would mean we will have some IDE in 2060 that's 25GB and someone will find it impressive. That's a lot of bytes for an editor.
1024 (2^10) is ~10^3 (I know switching bases!) vs say 10 (10^1), so two orders of magnitude larger in general. A gig 10^9 would be many orders of magnitude. An order of magnitude is generally a jump to the next power of 10. So 10 (10^1) is an order of magnitude larger than 1 (10^0) as 100 (10^2) is to 10 (10^1), and so on. People frequently misuse the term when speaking in technical terms. When the average person uses it to denote a big jump, I let it go - usually ;)
If you stick with base 2 I guess you could say many orders of magnitude (2^32 = 4,294,967,296 vs 2^8 = 256, or 24 orders of magnitude?).
Why? The common base is 10, and "orders of magnitude" is normally based on 10X between orders here. Ten fingers, decimal system, etc. Don't bring up metric vs. Imperial ;)
I work at an engineering firm, and that's how most engineers understand it.
:) Before I read the link, I was thinking about a text editor I would keep on my rescue floppy disks. The method of distribution was typing the assembly out of the November 15, 1988 edition of PC Magazine.
She's not as small as she used to be (Currently sitting at 61.1MB and has been over 30MB since 3.0) but to put that in perspective, that's smaller than the binaries for Half-Life 2 and even Half-Life 1.
The release binary is even smaller at 33.5MB!
Because some developers and project managers like, tolerate or even encourage complexity. I've read this comment on hackernews once about it, and it seems to be true.
There is Wirth's law ("software is getting slower more rapidly than hardware is becoming faster").
Generally, developers don't like performance, for some weird reason. The 97% Knuth quote might have played a major role, unfortunately it doesn't apply to game development at all. It's always a compromise between speed and code size.
For the rest, too many developers are not educated about electronics or physics, and often disregard important topics like memory management and data structures. But computer science always is complex. The generalization of garbage collected languages is also a big problem (see Minecraft)
Another problem is the lack of discipline and OSHA-like regulations in software development. The software industry is too anarchic and liberal-minded (Silicon Valley-style venture capitalism has a lot to do with this). It results in a lot of work being easily thrown away.
Well, if you had massive dependencies you'd probably look at consuming them as shared libraries making your binary smaller than if you rolled your own solution, right?
The fact that the Godot editor includes the Godot runtime along with its own UI- and graphics stack (if I'm not mistaken?) in such a small bundle makes this even more impressive to me.
Honest question.. Is this "just" the way modern gamedev is being done. With these "Editors For Scenes" ?
Like the Unity and Unreal Editors ? Not hating just asking last time I "checked in" on gamedev was prob one or two decades ago and had a lot of fun with IrrLicht and Ogre.
Does this "editor approach" not get in the way ? Just looking in as an outsider with almost zero gamedev experience.. don't you end up fighting the editor to just get things done ?
Again don't flame me I have no idea what I'm talking about :)
I use Godot daily to make games for small businesses, usually around GPS-based games. What I really found is that the editor based approach of Godot actually doesn't get in the way, but is actually way closer to the DSL of a game designer.
Also the way of making nodes/scenes with signals in Godot promotes making systems that are very loosely coupled, so I haven't ran into any big problems with the engine when it comes to maintainability of projects.
And when I want to extend the engine with some native features like Android camera feed (which I'm preparing a PR for somewhere in the future), I can just dig into the code, no need to wait for something like Unity support or something.
Honestly, whether you're using this for hobby purposes or if you're dabbling in professional gamedev, this engine is worth a try.
That has been the way that AAA game development has worked the last 25 years.
Professional games are like movies, programmers are a tiny percentage of people on the set.
They are the ones caring for the lights, that all cables are working properly and special effects go off as they should.
The main role, what dictates what a game is all about, belongs to game designers, producers, artists, those aren't writing C++ code, rather using visual tools.
Naturally you can make a game old style, just like on the 8 and 16 bit days, just like there are people doing movies just with an handy-cam.
These editors provide instant feedback on the materials, lighting, effects and animations. It’s like live reload for GUI apps.
I was very impressed when I got back into the field by how easy it is now to create and run a nearly-photorealistic scene with Unreal by only using built-in tools and the (now free) collection of assets from Quixel.
Partly it depends on the game but I think both Unity and Unreal, and I assume Godot, expect that the editor is just a framework and you're expected to extend them to whatever special needs your game has.
Having recently decided to bite the bullet and get back to Unreal Engine after not touching it for more than a decade, here's my impression:
1) You can essentially treat these editors as visual REPLs to your game engine. Which is useful in part because almost all gamedev is done in languages that have not seen a proper REPL (and Python doesn't count).
2) Most games these days have high art demands, these editors allow artists and designers without programming background to work on the game directly, in a more comfortable environment.
> don't you end up fighting the editor to just get things done ?
That is often a problem, yes, but not just for the editor but the whole product.
By using such an integrated "game development framework" you basically also buy into all the tradeoffs. You get a lot of stability, robustness, WYSIWYG-editing and ready-to-use features, but you also need to align your whole way of thinking and your workflows to the design principles of the framework.
I like to compare game creation in Unity or UE4 to Photoshop. Sometimes ImageMagick or even MS Paint are the better choice, but if you only know how to use a hammer, every problem looks like a nail ;)
One thing that I think would hugely shift godot's market share is a standardized asset format, similar to what Unity and Unreal have, so asset developers could offer assets in Godot-compatible format. It would be even more amazing if there was an easy way to import Unity resources. Maybe I just needed to do more research, but last time I tried, I had to pull out individual files, mess around with them in Blender, then import the model and the mesh into Godot separately, where I needed to arrange them together afterward. I think if the asset management was as simple as Unity's, Godot would be a no-brainer in many projects, especially smaller ones.
Maybe, but let me question that. What standardized asset bundles also do is create a market for asset bundles, which is good for the company they support. They also let new people buy a package of assets. Those aren't big issues for me, but I have never tried to make a commercial scale game in Godot.
Versioning is the nightmare of Unity. So many assets and plug ins only work with certain versions.
A friend of mine is developing a commercial game with unity, and that's been a big issue. It's either don't get big fixes or rework parts to upgrade unity
I've used both Unity and Godot at a hobby level and what I found was that with Unity, I spent almost all my time playing around with game mechanics. With Godot, I always spent a considerable amount of time importing resources and fiddling with them before being able to do anything useful other than add basic shapes to the screen. I think it's probably a problem of being the underdog with a much smaller asset market, but that's literally the one thing that made Unity worth checking out for me. I've downloaded most releases of Godot to play around with them as they come out though, so I'm really excited about it growing further.
Wow. I just downloaded and installed it (on Linux).
Hands down the best install experience of any similar tool.
* Unzip one binary and run it.
* The app auto-detects everything you need, and uses the best version it finds
* Its project layout requirements are "open an empty directory"
* The example projects install and work!
Seriously, the biggest difficulty I had was finding the "run project" button.
It took me a little bit of hunting.
It's getting there, I think it's missing the top layer of polish. I've been working with it for a couple years now and it has some bugs that really hinder development speed.
That being said, once those issues are fixed I think it'll be a hard choice to not use Godot (for what I do, more 2D work).
I'm a full time game dev and started a fairly large 3d project in Gotdot last September, I worked in it for about 2 months full time before moving to another project with another team.
The bugs that hindered my productivity were mostly "land mines" that I discovered along the way.
1. I thought having my scripts as internal scripts sounded good for a week until I realized there are all kinds of undocumented problems with storing your scripts that way. I had to refactor.
2. There is no selection outline around mesh in the editor window. Makes it impossible to build a 3D scene in Godot. My guess is that the developers expect you to build the scene in Blender then import it as one big FBX. (But that's not ideal for some things)
3. Then I hit the dangling reference bug and that was a heavy blow to my enthusiasm. The fact you can save a reference to an object in a variable, and that the engine can then change what object your variable is pointing to under the hood. It's such a fundamental bug it makes me wonder what other massive issues are there waiting for me to run into. My work around was to listen for signals for when object references were removed from the scene and manually clearing them, but its a real drag.
There were a few other things, but those ones stand out in my memory as examples of why I don't think I can work in it yet.
The reference bug won't be fixed until 4.0, so have another look at Godot then.
I have never used a built in script and agree it should be removed.
I have never hit the dangling reference bug, and I agree it is critical. Good thing its fixed now.
I have been laying out scenes in 3D without the selection outline. It seems like a good feature to add. What I truly love about Godot is that you or I can actually add that feature. I know that turns some people off, but it actually is very attractive to me.
I actually built a fairly functional combination of bullet hell and tower defense game in Godot about two years ago. Beware, though: the 2D lighting system for Godot is extremely slow, so if you want a buttery smooth FPS, don't do any crazy lighting.
Godot will do the job quite well, although there are plenty of alternatives that may also be worth a look (some open source, some source available): Defold, Solar2D, Heaps.io, etc. There are many good choices nowadays, although Godot gets the most love on HN.
I played with it about 2 years ago (even contributed some code to godot-cpp!) and it was pretty good, but it did have some gotchas and issues. Many are likely fixed now. You should just give it a try, its easy to get started and then you can judge for yourself.
Yes I downloaded it last week. I got bored doing a Unity tutorial (how to best explain ... what I was doing all felt a bit disconnected from the games I guess?).
I dived right into the Godot tutorial "Your first game"[0] and had something basic running really quickly and I understood most of it without any further reading.
I clicked on the doc link from within the native editor. It is less of a tutorial than I had hoped. Do you have a suggestion for getting started with it?
Yes "Your First Game" is a fine place to start even if it tells you to read some other things first. I'm a big fan of diving in to get something running, then searching or backtracking to learn the fundamentals if you need to.
There were a couple of typos in there that I ran into, it shouldn't be too hard with a little programming experience to notice these. I didn't download the finished files because I think typing it out is a much richer learning experience.
I recently got started by following couple videos on YouTube which are not hard to find. I've just followed very basic lessons, mainly to get familiar with non-programming aspects (scripting part is very easy if you already know programming).
There is also a Humble Bundle out there right now where you can get some basic lessons as low as $1[1]
How does it compared to Unreal? I've been using it a little to try and make a VR game and it's generally quite good I'm finding there are loads of bugs, or at least weird behaviours with materials and the OpenGL ES3 mode. And every time you change a setting it compiles like 3000 shaders which takes half an hour. Quite frustrating!
Check out my game https://vrworkout.at for a VR game made with Godot.
I am not a graphics designer so the models are bad which means that the rendering capabilities do not matter that much, but you have to stick to GL ES2 for the moment. Here is a video https://www.youtube.com/watch?v=mknXbyVJm3c
One of my favorite parts about Godot is that it gets away from those crazy load times / lockup you experience in Unity/Unreal. The .import file it associates with your asset is plaintext. Definitely running into fewer merge conflicts.
The node and resource systems are vastly more accessible than Unity IMO.
Workflow feels so much better in Godot than Unity.
Godot's problems are in it's 3D renderer. It's not very performant nor good looking and has some shadow bugs...
Godot 4.0 should fix all that stuff.
The renderer is fine for my indie/low poly style, but is pretty limiting for advanced post processing and realistic designs.
The particle system isnt very good in godot 3.x so far either.
Godot has some a noticable lag spike when shaders compile as well.
So, there's lots of issues related to rendering and advanced stuff, but for my purposes, godot is way more productive than Unity for me. And thats because:
- the scene hierarchy has a superior design
- the keyboard hotkeys are better
- compilation time is non existant
- hot reloading works
- gdscript is faster to write than C#
- scene & resource files are more git friendly
- documentation is local and in-editor
- gdscript has opinionated & accessible apis for things that other languages make hard (string manipulation, encryption, file system access)
Hi! I work on Godot Engine closely, improving the 3d asset pipeline.
Things move slowly in any large project.
Changes that were made for Godot Engine to make glTF2 import acceptable were done in October 2019.
However, a feature request to make the official glTF2 importer (Blender) import standard glTF2 properly will take until Blender 2.83 (LTS) to arrive in the next few weeks.
FBX 3d asset import support in Godot Engine is the same struggle.
Supporting standard FBX is the goal because of the focus on open source ecosystems. Even when the current Godot Engine fully supports FBX (Godot Engine does not currently), it will take significant time to get Blender's incompatible variation of FBX to be patched in stable releases of both Blender and Godot Engine.
Other people are working on Godot Engine rendering for the next version, but I am joyed at reviews of the glTF2 work.
I hope for future success in Godot Engine projects.
I don't know, to me the choice of their own NotPython as the main language seems like an incredible misstep to me. It's lacking in features (last time I checked they didn't even support basic things like lambdas), tooling and libraries.
There's a reason why both Unreal and Unity moved away from providing their own language.
I thought it was a massive misstep until I started using it heavily.
Now I really like it.
As to lack of lambdas, yes there are no lambdas, but coroutines are a first class citizen in gdscript, and network libraries, like Nakama for instance, use coroutines heavily. I prefer coroutines to lambdas anyways, and I think the industry is moving towards coroutines.
There are a ton of good things about gdscript. I was a hater on it until I started using it, and then I realised how quickly it allows me to do stuff.
Besides, I'm staring at the worlds worst Unity project right now.
Coroutines and lambdas are orthogonal features. if the language supports it, a lambda can be a coroutine. Arguing that one will replace the other strikes me as nonsensical.
And I don't hate gdscript, I just think it's incredibly half-baked and feels very immature. It's understandable that they only have limited resources, but that doesn't make my experience with it better.
Languages matter an incredible amount because of how heavily they influence system design. You can design an awful system in any language, but if you have to treat everything like a nail because you only have a hammer, you're bound to make a lot of awful decisions.
Edit: also, good IDE support really is incredibly helpful for working on larger projects
Im thinking of both lambdas and coroutines as techniques for asynchronous programming - like the 'complete' callback for a network call, for instance.
For functional programming, yeah there's no equivalent to a lambda in gdscript, but again, I think it's exceptionally well suited for the kinds of things you do in typical, run of the mill, game dev.
All these things. GLTF and godot have been amazing to me, though I do sometimes struggle with the asset flow but I'm getting better.
I've been using 4.0a and havent found anything with major breaks so far, and Vulkan really shines compared to opengl3.
It makes me so happy that I can have a game editor that aligns with my RMS-esque views (pro gpl). Now if I can just get my friends on board, many of them have invested so much time in unity or ue they don't want to switch. My goal is to have a prototype cool enough to draw them in eventually.
Have you tried it on a package of similar size? Yes I hate the Unity/Unreal start up issues. On the other hand they are doing a ton of stuff for you. Compiling 100s or 1000s of shaders for for particular GPU, compiling all the code, processing all the assets for your particular platform. Those all get cached but the first open is painful. But I can't imagine Godot is any different. Those steps have to happen and they are all heavy steps. If Godot is faster it's more likely because it's doing less for you than because it's actually faster.
Godot seems to be a recommendation only for 2D projects. It's 3D support is lacking to the big engines. You can also see it in the showcase - it's 99% 2D projects.
Yes my understanding is 2D is first class while in the U engines you tend to turn a 3D scene sideways to get 2D and have to deal with vector mathematics rather than points in various functions. At least that's one reason a few people cited for the switch since they wanted to focus on 2D and it works without extra layers or abstraction.
My comment was more around tooling and complexity as seen by the programmer. You can have functions that look 2D but are really 3D behind the scenes, like glVertex2f in OpenGL. AFAIK Godot uses GPU acceleration still for 2D scenes like all games these days should.
This is awesome. Question: everything I've read[0] about WebDAV indicates tons of compatibility problems between implementations, even those built into operating systems. I wonder what the plan is to deal with that?
Also, are there any off-the-shelf WebDAV client libraries for browsers?
We use Git with LFS for our games-orientated projects, including some pretty massive projects, and have found it works really well.
We previously used SVN for similar projects, and made the switch to Git once LFS made it a feasible choice for projects with lots of large binary assets (games), and honestly never looked back, it's massively improved our workflow.
Smallish indie projects get by with git and or git lfs. git isn't really designed for binary assets and large games with terabytes of source assets usually don't use git. git's distributed nature is also an issue for non-mergable binary assets. The most common tool version control for bigger teams is perforce. It's significantly faster than git for binary files and it helps manage 2 or more people trying it edit the same binary file. There maybe be other bolt on solutions for that for git that I'm unaware of to help with that.
A feature introduced in e.g. Nightly 78 might stay out of stable until say version 86. That is features make it to stable by becoming stable not because it first landed in a certain nightly and so everything was held up until all features in that nightly became stable. Releases happen on a fixed 4 week calendar cycle instead.
At the moment, I think only Chromium enables SAB by default for devices that have "Site Isolation" enabled (avoids spectre attacks by using process isolation). That's a browser feature specific to Chromium, and is disable for some low-memory devices, so it's not universal.
I'm not familiar with how far along Chromium or Firefox are. If you're interested in using SAB, start reading up on COOP and COEP.
How is Godots performance these days? I heard they are adding a ton of c# support after a lot of people have struggled with frame rates in gdscript (source: various youtubers who use Godot)
I just switched from unity to unreal because of sketchy retroactive licensing changes from unity and the performance in unreal is really making me happy so far
I wrote a large scale fluid sim (like Cities Skylines' water sim) with Godot and Rust. I think the biggest bottle neck is the gdscript honestly. I had a prototype working in GDScript and after I ported it to rust I had like a 20x speed up
It's amazing that a native Windows/Mac app can be compiled to run in a web browser. However Web-assembly does not mean better performance. A native browser app would most likely be faster.
I'm guessing that an app written for WebAssembly in the first place would be faster than an app written for the desktop when they're both running in the browser.
JS is usually not the bottleneck in web apps. The bottleneck is most of the time rendering. Rewriting the app in JS would make it faster then the Webassembly version. It's a common misconception that Webassembly is faster then JS. Although theoretically possible, the compiler wouldn't be able to beat a skilled JS developer's hand written JS specific for the web platform. A turtle is faster then a rabbit - in water.
Is this true? I was under the impression that webassembly was capable of faster performance than JS, and thinking about learning a compiled languages to make my web applications faster. Would that be a waste of time?
It would not be a waste of time if you learned something. Here's a quick exercise: Write an "hello world" app and compile it to WebAssembly. Then open browser dev tools to inspect the app. You will see that a middle layer is needed to put that "hello world" on the screen. Just like JS, WebAssembly can't talk directly to the hardware and need to use the same browser API's as JS.
Besides obfuscating and being able to compile desktop apps to the web platform, one use-case for WebAssembly that might bring an performance improvement is to use it for something you currently use a Web Worker for. For example sending a bit buffer to the worker, have it do some work on it, and send it back. There is however a penalty to sending the data back and forth, although there are work being done that allows shared memory, which will make both JS and Web-assembly faster.
JavaScript is compiled to optimized native code. So you will get away with really stupid code - the optimizer will make it fast. But the more you learn, you will be able to write even faster apps. It really doesn't matter what programming language you use, it's more important to have experience and tribal knowledge of the platform you are targeting.
A funny thing about performance is that the more you know, the slower your app could become. If you for example use highly sophisticated abstractions, make use of frameworks and preprocessors, together with an orchestra of cloud functions and services with IPC message across oceans - then it will be slow. If you want performance - just keep it simple.
