[HN Gopher] Godot Editor running in a web browser
___________________________________________________________________
Godot Editor running in a web browser
Author : SquareWheel
Score : 182 points
Date : 2020-05-29 19:13 UTC (3 hours ago)
(HTM) web link (godotengine.org)
(TXT) w3m dump (godotengine.org)
| anderspitman wrote:
| 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?
|
| [0]: https://news.ycombinator.com/item?id=10213657
| stakkur wrote:
| I've been waiting for this.
| skybrian wrote:
| I'm not a game developer but it seems like syncing with a
| standard git repo would be ideal. Is that possible with games or
| do the assets prevent it?
| anderspitman wrote:
| Your intuition is correct. git alone isn't going to cut it for
| the assets.
| slezyr wrote:
| git lfs plugin should help with that one. IIRC Godot's editor
| has some support for creation of git repositories
|
| https://git-lfs.github.com/
| t0astbread wrote:
| 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?
| gjkood wrote:
| I guess its all relative.
|
| 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.
| nightowl_games wrote:
| A lot of the godot size is the images it packs in itself.
|
| 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.
| gnulinux wrote:
| > A lot of the godot size is the images it packs in itself.
|
| For comparison, emacs's installed size is 76K [1].
|
| [1] https://packages.debian.org/sid/emacs
| yepguy wrote:
| That's the installed size of the metapackage containing
| no emacs executable, no elisp files, and no
| documentation.
|
| On my system the emacs executable is 39M and the entire
| installed package is 128M. (Additionally, my Doom Emacs
| folder takes up another 840M.)
| tetris11 wrote:
| > Additionally, my Doom Emacs folder takes up another
| 840M.
|
| HOW?
| gnulinux wrote:
| Ah so sorry about that. I should have checked.
| xigency wrote:
| 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.
| snazz wrote:
| 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.
| kick wrote:
| The Chromium package on Arch Linux is actually just a bit
| under 200MB when installed. Are you looking at the
| download size?
| gnulinux wrote:
| 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.
| kroltan wrote:
| Visual Studio is probably way more than 25GB, and it's 2020
| still.
| leddt wrote:
| Depends on what packages you install, but my VS 2019
| install folder is 2.5GB.
| kroltan wrote:
| My VS folder itself is 4.1GB, but there are tons of other
| stuff that gets installed too. I know I downloaded about
| 28GB on my first install.
| kencausey wrote:
| Defining an 'order of magnitude' as 1024 seems a little odd
| to me. I would consider this to be closer to 3 orders of
| magnitued.
| eggy wrote:
| 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?).
| rowanG077 wrote:
| Having a little bit of discipline is all that's needed.
| TeaDude wrote:
| 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!
| z3t4 wrote:
| 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.
| nightowl_games wrote:
| What do you mean by native browser app? Like JS + WebGL?
| z3t4 wrote:
| 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.
| snazz wrote:
| 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.
| antoineMoPa wrote:
| I wonder when firefox will re enable SharedArrayBuffer.
| jszymborski wrote:
| Seeing as it's available in Firefox Nightly, it'd imagine it'd
| be in the next release provided it doesn't present any problems
| from then and now.
| msie wrote:
| Godot is such an amazing/polished game engine. I like it a lot
| more than Unity (at least for 2D).
| xrd wrote:
| 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?
| truncate wrote:
| 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]
|
| [1] https://www.humblebundle.com/software/learning-game-
| coding-a...
| jszymborski wrote:
| The step by step docs have been very useful for me: https://d
| ocs.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_.
| ..
| xrd wrote:
| That's great. And, I love that the examples all specify
| /home/ubuntu as the home directory, so the author is
| clearly using Linux. This is really cool.
| IshKebab wrote:
| 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!
| clarkrinker wrote:
| 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.
| nightowl_games wrote:
| Ya way fewer.
|
| The scene file is actually _readable_!!!!
|
| 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)
|
| Godot is the future. I promise you this.
| ImprobableTruth wrote:
| 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.
| nightowl_games wrote:
| 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.
|
| Languages dont matter as much as system design.
| SquareWheel wrote:
| Seems lambdas are coming in 4.0.
|
| https://github.com/godotengine/godot/issues/2684#issuecom
| men...
| arminiusreturns wrote:
| 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.
| ASVVVAD wrote:
| It's a common fact that Godot's 3.x[0] renderer is
| lacking but if it can achieve these[1][2] then 4.0 will
| be a game changer
|
| As a side note I like your comment ^^
|
| [0] didn't say current because master branch to be the
| current branch and it already migrated to Vulkan [1]
| https://www.youtube.com/watch?v=HQYZBZybP9M [2]
| https://www.youtube.com/watch?v=cKtwW9yU6QU
| iFire wrote:
| 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.
|
| Three.js is also able to import standard glTF2. There is
| an amusing chart of failures on Github.
| https://github.com/KhronosGroup/glTF-Sample-
| Models/pull/243#...
|
| 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 your review of the
| glTF2 work.
|
| I hope for future success in Godot Engine projects.
| skocznymroczny wrote:
| 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.
| turova wrote:
| 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.
| lux wrote:
| As long as it doesn't follow Unity's approach (asset
| bundles). Unity's favourite thing to do is break asset bundle
| compatibility between versions.
| nightowl_games wrote:
| I'm not sure what you mean. Godot has asset formats that
| translate from project to project.
| turova wrote:
| 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.
| nightowl_games wrote:
| There are some issues with the 3D importing pipeline,
| GLTF is the best supported file format, but they recently
| added .fbx support so thats good.
|
| I agree that there could be further improvements made
| there but I've had good luck with .gltf.
|
| Additionally, I've had problems with materials or
| animations importing into Unity as well. Seems like its a
| big, common problem.
|
| Unity imports started getting smoother in recent years
| because marketplaces and artists started specifically
| targeting unity.
| the_other_b wrote:
| 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).
| nightowl_games wrote:
| > I've been working with it for a couple years now and it has
| some bugs that really hinder development speed.
|
| 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.
| jay_kyburz wrote:
| 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.
|
| Update: Here are the bugs I logged.
|
| https://github.com/godotengine/godot/issues/31758
| https://github.com/godotengine/godot/issues/32383
| xnxn wrote:
| If we're thinking of the same dangling Variant bug, a fix
| was backported to 3.2.2 (releasing soon):
| https://godotengine.org/article/dev-snapshot-
| godot-3-2-2-bet...
| jay_kyburz wrote:
| Good news!
| boterock wrote:
| I think although it is missing that layer of polish, the
| underlying foundation layer is so much better built.
| robotnikman wrote:
| Would you recommend Godot for making a 2D bullet hell type
| game?
| logicprog wrote:
| 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.
| bkanber wrote:
| Yes, Godot would handle that very well.
___________________________________________________________________
(page generated 2020-05-29 23:00 UTC)