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.
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.
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.
:) 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.
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).
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?
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.
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.
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.
Readit News
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.
When I cloned the godot repo, I could understand the architecture just by the file names.
I started falling in love with it as the easily understandable file names started streaming down from the cloud.
It's truly a public good.
https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)
http://texteditors.org/cgi-bin/wiki.pl?Ted
https://books.google.com/books?id=yFs-_3jT-5kC&pg=PA281
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.
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.
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 :)
PS. GoDot looks great :)
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.
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.
The outcome isn't not going to be same though.
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.
https://docs.godotengine.org/en/stable/tutorials/misc/runnin...
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.
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 ;)
They even have a blog article on why it's the future (like JPEG for images) and how many big companies have started supporting it.
Versioning is the nightmare of Unity. So many assets and plug ins only work with certain versions.
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.
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).
What bugs do you think hinder dev speed?
I am vastly more productive in Godot than in Unity.
Currently I think the only criticisms I have are the 3D renderer is bad (whoop 4.0 lets go!), and there is not a strong community/asset marketplace.
I _love_ the workflow, though.
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.
[0] https://docs.godotengine.org/en/stable/getting_started/step_...
If you're a "work bacwards from a finished project" kind of person, this tutorial is quite great as well
https://docs.godotengine.org/en/stable/getting_started/step_...
There is also a Humble Bundle out there right now where you can get some basic lessons as low as $1[1]
[1] https://www.humblebundle.com/software/learning-game-coding-a...
Deleted Comment
Also, are there any off-the-shelf WebDAV client libraries for browsers?
[0]: https://news.ycombinator.com/item?id=10213657
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.
https://git-lfs.github.com/