I get a black screen and the JS error "Atomics is not defined." Did we overload it?
Atomics is part of the threading APIs, I'm guessing your browser doesn't support it. Although I feel like you should get a better error message...
Godot Editor running in a web browser
101–110 of 128 posts
Re: Godot Editor running in a web browser
#102Kinda strange but Godot kinda feels like a game dev oriented smalltalk to me
Re: Godot Editor running in a web browser
#103Honest 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…
Hey software engineer/gamedev here.
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.
Re: Godot Editor running in a web browser
#104Honest 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…
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.
Re: Godot Editor running in a web browser
#105Honest 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…
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.
Re: Godot Editor running in a web browser
#106I'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?
Or is a better question, what the hell is going on in other programs to cause them to be so gigantic?
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.
Re: Godot Editor running in a web browser
#107Honest 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…
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.
The outcome isn't not going to be same though.
Re: Godot Editor running in a web browser
#108Earlier quoted context omitted.
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.
Re: Godot Editor running in a web browser
#109Honest 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…
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.
Godot is particularly good at extending the editor.
https://docs.godotengine.org/en/stable/tutorials/misc/runnin...
Re: Godot Editor running in a web browser
#110Honest 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…
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++ co…
Gotcha !