Godot Engine Web Editor | Hacker News Reader

Godot Engine Web Editor

editor.godotengine.org

274 pointstodsacerdoti98 comments

(Disclosure, am founder of Construct 3, we made a browser based game engine: https://editor.construct.net)

Interesting to see this progress, and unlike the myriad of other web based software looks like they've done a pretty good job of making it feel native like in the browser. I don't feel too threatened by Godot's progress here, fortunately our engine occupies a fairly specific niche that doesn't overlap too much with Godot's market and would allow them to co-exist.

It does look a little heavy (12.5mb transferred/77mb resources to load cold) and is slower to load than I would expect. Doesn't appear like HTTP2 is supported which would probably speed things up nicely.

For anyone wondering what's the point of this, browser based software is incredibly beneficial to educational institutes especially in the Covid environment - we for example are getting educational institutes who typically use Unity and other software moving to us because it's far easier to get remote classrooms set up with their wide variety of devices students have at home.

I do think the future of software is in the browser. There are just so many advantages. Not to everyone's liking of course but I do feel it's inevitable. We went web only as it has the huge advantage of one code base to maintain, I would assume a large risk on Godot's part here is having to maintain multiple code bases.

I am not sure why you would feel threatened even if there was overlap. Godot is MIT licensed, so if your customers started asking for features from Godot or for compatibility with Godot, you could just copy the code straight from them without any hassle.

Sadly, software is not (usually) that composable. If godot is a better engine all around, it would mean that competitors could offer a better service by just running godot in the cloud and charge per access, which they may be able to do for a cheaper price as they had very low initial investment.

Well, of course it would take work to compose them together, but then the pay off is that you might be able to say customers are getting the "best of both worlds."

If their customers are also asking them for hosted Godot, maybe they should also offer that as another product offering, at a competitive price, and then use that as a sales funnel into their other products? That is usually the way it goes with these open source bits.

They may be able to respond positively to a threat, but it can still be a threat. It may pay off to try to compose godot's code into theirs, but it may very well be cheaper to just rewrite things within their own framework.

Anyway, I'm just saying that free software can be a competitor and that you can lose to it even if you can, technically, embed their source code. Even if software was perfectly composable that would be true, but it's even more possible given that you can't always just plug in any new features godot releases. They may even be implemented in different languages, for all we know.

I don't see how it is a threat. Assuming Godot obsoleted all their code entirely, that would still be a boon -- that's now code they don't have to spend time maintaining anymore, and they can just reuse that and focus on their core competency. (Maybe it's hosting, I don't know enough about this business)

Different languages actually isn't as bad an issue with this type of thing, as the idea with running it in the browser is that it all compiles down to Javascript or WASM.

You are not taking the whole market into consideration. Maybe they are good at writing the game engine and then hosting, but others may be better at just hosting. So, they could be outcompeted by people who don't want to pay the cost/risk of building an engine. Others may be better at hosting godot than they ever will, although those people would not be there if there was no godot or if godot was not free. Free software (copyleft licenses in special) can be a threat for commercial software in two ways: a. users may just jump to the free alternative and leave yours b. it levels the field so new competitors can come in without paying the initial investment you made.

Just to be clear, I'm not saying that they are incorrect in assessing that godot is not a threat. They seem to consider they have other features beyond godot's scope which is what differentiate them in the market. What I am saying is that free software can certainly be a threat to a business. In fact, it can be even a larger threat than a single competitor, because it can turn your product into a commodity.

I still don't see what you mean. It sounds like you are saying the real threat would be if they had no other features that could let them stand out in the market, at which point a competitor would be able to beat them by lowering the price, possibly to zero. That can be done by any competitor and has very to do with the license -- my point is that the open source license on that "competing product" actually helps them, by allowing them to make use of the same thing without having to pay that initial investment again. And the first initial investment you made isn't lost as long as you keep a path to retaining those customers.

To put it another way, if the actual problem to the business is that they are falling behind on feature velocity and don't have the head count to keep up, re-using some features from open source code could actually help there.

If you can't keep up on feature velocity, you're fighting a losing game.

Yes -- so if the company falls behind, maybe using some open source code could help you keep up. At least that's what I've felt looking at things on github/gitlab/etc has helped with, if done the right way :)

Let me try to draw a picture. Say you have a web based game engine. It is the only game engine as a service in the market which also runs in a browser. Then, a popular open source game engine becomes web based too. Before, you had no competitors, now you have to compete against a product that's free.

You may lose some costumers that only cared about it being web based and who are willing to learn another engine. Not only that, a single guy decides to host the game engine in the cloud and charge really cheap for it. Now, if you want to compete in price, you probably have to fire all your game engine devs and significantly downsize. Either that or have vastly superiour features to justify your higher price in the eyes of the costumers. All that threats your company's existence.

I'm not saying it's impossible to compete, but the more overlap between your product and a free software product, the bigger the threat will be.

As someone who's worked in AAA game engines this is like saying because C# is now open source it will be easy to just copy code into Swift without any hassle.

The part that makes game engines both interesting and difficult is they made a series of discrete trade-offs to support the use cases of the types of games they ship. This is true from tooling workflows to rendering stacks to core engine layout like if they do heavy arena allocation or more open world dynamic entities.

We extended the engine we licensed with some fairly reasonable features and even doing the uplevel was a brutal, 4-6 month process to reconsile those changes.

I am not saying it would be easy, it would definitely be work that someone would have to do. I'm more saying that the Godot authors would not try to threaten you or consider you a threat, it's more likely they would want to help you. Of course as a business you would not do it if your customers weren't going to pay the cost to make it worth it.

I don't know enough about the implementation of C# and Swift to say for sure, but it does seem like the open sourcing of that would making it easier to do things like port some standard library component or algorithm over from one to the other, or perhaps do something like building a Swift implementation for the CLR.

Let me try to be a bit more to the point, game engine features are not just "drop-in", by adding a feature to one part of the engine there's a high probability that you make another part of the engine worse.

There's a reason that they say performance is the most leaky abstraction.

Then that sounds like you would want it to be an optional plugin, or a compile time flag that could be enabled for customers who want it? Why not do it, if that's what the customers asked for?

I get what you are saying and it definitely applies to the core architecture of the product, but if you have a large number of customers each with their own needs then I would be surprised if there were zero parts of the product that were modular or interchangeable.

> then I would be surprised if there were zero parts of the product that were modular or interchangeable.

You'd be surprised. Game engines are extremely monolithic.

There are some modular components and techniques (eg pathfinding, rendering, physics engine), but most of the effort that goes into an engine like Godot is integrating these components to their specific architecture. While the component is transferable (eg you can always use the Bullet engine in your own project), the integration work isn't.

Isn't the future of applications on the browser only possible because the current browser leader (Google) isn't actively fighting cross OS support? Because what's a browser if not a universal front end for widgets. We could have had cross platform widgets but that would have made it too hard to monopolize one platform. Google have simply abstracted the previous platform leader (Microsoft) advantage away from them.

It's interesting, but depressing that we keep letting these greedy humans lock us into things. We keep wasting time fighting them and each other.

I think vendor-lock-in is something that should probably be made illegal by consumer protection laws.

While technically somewhat a valid concern, vendor lock in on an OS level has never been Googles MO. Quite the opposite actually: The more the merrier. Every Google service (Maps, Docs, Mail, Drive, Calendar, Analytics Admin etc ppt) works in all major browsers. You might get the best out-of-the-box UX with their offerings in Chrome because authentication/authorisation is handled on an app level, but other than that there's really nothing stopping you from using, say, their spreadsheets in Safari. The fact that they kind of own TC39 while also actually owning the browser with the largest market share is not optimal on many, many levels, but, frankly, the risk of them pushing a hard lock in on any level, to me, is negligible. They're monetising telemetry and ultimately don't care where that's coming from.

Edit: Typo and Grammar

Yeah, they're not going to prevent browsers running on multiple OSes, but they do abuse their position to prevent competing browsers. The OS doesn't matter now, the browser does. They can leverage their position to move the goal posts faster than the competition can run. So, it's still bad, it's just a different abstraction.

Anything that helps the web export progress sounds like a good idea to me, I think there’s a lot of potential in that feature.

Being able to play game demos in the browser before installing the full version if you like it would be nice.

But for developers themselves I think it would be really cool to see the output of the tutorial you’re following before you start. It would be pretty motivating to see what’s coming and I think it could help get across some of the concepts which can be difficult in game dev.

Agreed, there's a lot of potential for Web export across all engines. This was one thing Flash did really well back in the day but now JS + Webgl can surpass that as long as creatives are given a nice tool to create with it.

Unity's WebGL export is a good start too but the bundle size is huge (they did release a leaner, pared down version but it's still got a ways to go in terms of load speed).

Hope this turns into the prodigal open source flash replacement.

There's a good open source Flash runtime called ruffle.rs, used by Internet Archive.[1]

(Wasn't sure what "prodigal" means in this context. Any chance you means "canonical"?)

[1] http://blog.archive.org/2020/11/22/flash-back-further-though...

By flash replacement, I do not mean simply something that can play flash; I mean also an editor simple enough to be used by artists.

By prodigal, I mean that this is something FLOSS enthusiasts have been waiting for literally decades.

Do you mean like https://rive.app but FOSS?

What's the point of this?

While I think it's cool shouldn't they spend their resources on the desktop engine?

Well, I suspect it's done because it's almost "free" and it's good PR for an engine I hope will become a great alternative to Unity. Here's more on the topic https://godotengine.org/article/godot-editor-running-web-bro...

It's also sponsored by Mozilla, as the link mentions.

I like the idea of a web-based Godot - reduces barrier to entry, and makes for lots of interesting possibilities - collaborative game jams?

A more recent post https://godotengine.org/article/godot-web-progress-report-6

There is no one who knows the projects time/financial budgets better than the team. I'm sure their free product is plenty well planned to accommodate for side utilities like this. This might even be from a contributor that has less work than the rest of the team.

I met aome of the creators back in the day. The RedHat model is working well for them: open source and sell consultancy. It doesn't scale exponentially but as long as their OSS product is good they won't have a shortage of incoming deals.

>While I think it's cool shouldn't they spend their resources on the desktop engine?

Browser-based games are a perfectly legitimate platform, and tend to have fewer clicks than desktop package distributions. Namely, one click.

Hell, there's nothing stopping this from replacing HTML5/flash games.

Other than browsers blocking 3D hardware acceleration.

How recent is your experience? It definitely was a thing for a while (especially from Microsoft), but my impression is that this particular issue has been resolved in the last couple of years.

It is a common experience on GNU/Linux, even on a netbook I own, I have force enabled it, something that most users aren't aware of.

One of the targets is webassembly, and the engine is written in the Godot engine. I'm not surprised that they could do this: it's a completely natural outcome from how Godot already works. I doubt it took unusual commitment of resources to do.

Two main things:

1) Allows godot in schools etc where installing binaries can be problematic.

2) Provides more focus on improving the html5 target.

From what I understand the editor is a "game". Both the desktop editor and web editor are created in the engine, so improving the engine will improve the web editor too. The web editor is the html5 export of the editor "game"

Your question is unpopular because everyone here likes the web and want to see it thrive as a platform. So do I, but still, I agree with you. Unfortunately, the web is not a viable platform for games. It had its moment for casual games some years ago, but mobile devices have taken that over. Thats why all the web game portals (the bargain bin bottom of the games space) are languishing, even Facebook Games, with its captive audience, is slowly dwindling away.

To put the actual game editor on the web makes even less sense. It's a cool technical feat, and the author may have thought of it as 'free', as some commenters have alluded to, given that there is already a web export, but anyone with a bit of experience knows that nothing is free, and certainly not a project like this. At the very least it's a months long effort (the author himself stated as much in the blog post), even before factoring in continued maintenance.

I love it as a technical feat, but I'll agree it doesn't make sense from a 'business' perspective (for lack of a better term, given it's an open source project).

Unfortunately, the web is not a viable platform for games.

Why not?

The usual answer is "performance", but that's a non-answer. Not all games need cutting edge levels of performance, web performance for accelerated graphics is actually pretty good as once a shader is on the GPU there's very little practical difference between web and native, and most importantly nothing pushes performance to improve quite like developers trying to maximize performance. If we don't try to make web games (or any other performant apps) then there's no reason for browser vendors to work on improving the situations where things are slow.

If Godot's devs think web is an interesting and fun thing to target then they absolutely should be making tools like this.

> The usual answer is "performance", but that's a non-answer.

Try to play https://slither.io

The performance is horrible even in simple games.

Surely that's a poor implementation? The parent post's point still stands. Browsers are "good enough" a very broad range of games. There's ample evidence of this if you wanted to look.

So, can you provide "good enough" games with "good implementations" that are somewhat popular?

agar.io

It lags even more that slither

Venge.io

It looks even worse that Quake3 to me and it's gameplay is just dull.

Aren't you just moving the goalposts now?

Yeah, they did. Goalpost went from "is it even feasible" to "did the devs implement a compelling game" as if it was impossible to create a compelling game over the web.

https://krunker.io/

Runs at a couple hundred FPS if left uncapped, and has very good netcode.

https://poki.com has 30 million monthly active users. That's more than e.g. DOTA 2, CS:GO, or any other single Steam game. Yes there is a lot of trash, but there is also some decent stuff on there.

It doesn't work in Safari or mobile browsers. It's quite far from the expectations of a versatile web platform. WebAssembly has a lot of potential, so one day... perhaps.

Working pretty well for me on Chromium and Firefox mobile.

iOS and everything on it using Webkit though, I'm sure there're some issues.

It's so frustrating to constantly switch between my favourite browser and whatever the developers had in mind.

If your favourite browser is Safari then there's a good reason developers might have targeted another browser - Safari is consistently slow in adopting the kind of features that enable more cutting edge web applications.

That's not neccesarily a bad thing but you can't complain if you're trying to run cutting-edge apps on a conservative browser.

I am happy they are experimenting with something fresh and cool. My complaint is that it can't possibly be anywhere near ready without being more inclusive.

This comment goes beyond browsers - it's such a bummer when I try to play a game I like or one that someone recommended and then "oops, we don't support your device/browser...".

But doesn't that mean Apple gets to choose the pace of advancement and be the gatekeeper of features?

At least on Desktop - it's not that much of a burden to have a second browser installed for certain apps, is it?

I use Firefox for daily browsing but I've got Chrome and Edge for those times I want to run something that Firefox doesn't support (which is fairly rare). I imagine it's much less rare with Safari.

Not Apple... I think it's really the developer's responsibility.

Like you say, you like Firefox but say if you want to video chat in Microsoft Teams, they'd tell you "video is not available in your browser".

Some games are only available on Android, others only on iOS. Or you are on a Mac but you can't play because someone opted for the easy way out saying "Macs are not for games" even though I am certain what I want would run just fine, if it was available.

These as examples of gatekeeping and the fix is definitely in the hands of developers to make their stuff portable and working everywhere.

I don't understand you properly.

Apple is famously slow or simply refusing to implement features that Chrome, Edge and Firefox have adopted. Many of these features are critical for certain applications. Gaming being one of them.

How is this a developer's fault?

1. I need feature x - either to implement an aspect of my app at all - or at least to do it in a way that doesn't require a large amount of extra work and cost. 2. Feature x exists in every major browser except Safari 3. I choose to exclude Safari.

My only options as a developer are to spend a ton more time or cash (assuming it's even possible at all) or to build something different.

And this might be a solo project or a project with no realistic hope of paying for my time.

As a game developer that's done a bunch of web games, thank you. Parent is trying to shame game developers for not making choices that would destroy their businesses. It's quite strange to read.

I think it's unfortunate that you can't have rock solid cross browser gaming yet (and Safari is not the only offender, but it's by far the largest). But that's not a reason to just shut it all down for the next decade until that's possible.

That definitely lags when there's more than one or two 'snakes' on the screen. The performance sucks. I'd argue that shows that specific game is poorly coded more than it shows web browsers can't handle performant games. If you look at something like https://beta.unity3d.com/jonas/AngryBots/ you'll see that browsers can, technically, cope with at least PS2 level graphics in a decent game running at a solid 60fps.

the web is not viable for games because browsers are unstable targets that change things constantly, breaking the games. Back when there was a stable deployment target (flash) games were everywhere.

This is very true. I built a game to go along with our wedding invitations. I’ve been maintaining it for the past 6 months, and it has stopped working on one browser or the other multiple times. This is despite the fact that I’m using a popular actively maintained JavaScript engine.

It noticed just a few days ago that is wasn’t working on my iPhone because mobileSafari decided to stop reporting itself as safari and only as “mobile safari”.

Why do things break? The underlying primitives are as simple as a canvas element, no? I'd think it would be hard to break an array of literal pixels.

Well for starters even getting a canvas based UI working that supports all DPIs, all aspect ratios, live resize, clicks, and multi-touches is non-trivial.

Not to mention text input.

And unless we do some strange CSS tricks to force acceleration, there isn't even the guarantee that canvas is doing hardware acceleratd drawings.

Sound stuff is still pretty unstable.

Audio is what was breaking. Also WebGL outperforms canvas, and it’s more complex than drawing a bitmap to the screen.

It noticed just a few days ago that is wasn’t working on my iPhone because mobileSafari decided to stop reporting itself as safari and only as “mobile safari”.

That points to your code doing browser agent sniffing. There are much better approaches to feature detection these days, precisely because of the issue you've encountered. I can recommend https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes... as a good place to start.

It wasn’t my code, it was engine code, and it was a problem where Safari reports that it doesn’t support a feature that it actually does.

Web assembly looks quite stable.

It is hard to interoperate with the page, and it will keep changing on that point for a while, but that's not something that games do. For games it's all drawing on some element, what is very well defined already.

Yeah, but then you need cavas and WebGL to draw and there isn't any way to know if they are actually being hardware accelerated, or if the browser vendor decided to blacklist the users hardware.

Most importantly, nobody wants to pay for anything on the web. Sad but true.

Advertisers were willing to pay quite a bit back in the days! While privacy is good, the advertising industry supported a p. large cottage industry of cool online game developers back in the days. A lot of people I know got their first buck that way in a way that's harder to do nowadays.

I hate to admit it (and it truly does pain me), but anything casual will be on a mobile platform. Anything on the web should just be ported to the mobile space.

The rise of web games, way back when, was to blow off some steam at work. With the rise of monitoring software, that niche has been filled with mobile games that can waste time at work, on the bus, on the toilet, at the dinner table and while watching the television.

Flash games are where I started making graphics and learning programming, so this is a wonderful introduction for younger people to programming (Godot doesn't come with a suite of drawing programs like the stolen version of the Adobe Suite that I "liberated" as a script kiddy a thousand years ago). They can readily host them for cheap or free and show them to their friends, but as for business viability, you're very right.

Apologies for the length of this.... it kind of got away from me =)

There are free-to-play web games making a killing off microtransactions.

People played browser games before because it was a way to play games without installing them. This is a use case that existed because of locked down computers in schools, universities and workplaces.

Now everyone has phones.

I've seen a lot of people comment that they would love these for students, as their computers are locked down and they can't do much. Even trying to get the latest versions of the software installed is a burden if they DO manage to get the software installed.

This unlocks so much, in terms of being able to build games via the web browser without students needing to download software is pretty amazing.

Yes -- our non-profit publishes nearly all of our games to the web because they run reliably on browsers in schools and public libraries without plug-ins. We've deliberately gone in this direction to make games available to educators without risking the ire of network admins.

Not everything has a business perspective. Sometimes people build things for fun or to learn something.

The web is reliably the best platform for the games our nonprofit produces. And we've produced dozens of them played by young people around the world for the past 15 years. (Yes, we've had setbacks with deprecation of Flash and Unity Web Player but webGL has been fantastic.)

Although the games are also available through the appstores or for direct download, those channels are not as accessible for many people, especially those on the other side of the digital-divide. No smartphone, tablet, or home PC? Then turn to the web instead: our evidence-based and award-winning games are used by educators in classrooms, by parents at home, and by young people who access them via public libraries.

The web is the best outlet for these games because it is by far the most accessible of platforms. These games are also much safer from a privacy perspective via the web than installing an always-on & always-tracking game from Google Play.

And though these are not AAA games and they don't include microtransactions or advertisements that merely means nobody is getting rich from them. But that isn't our goal. Our goal is to drive positive change in the most efficient way possible.

Genuinely free video games via the web is how to safely reach and empower hundreds of thousands of young people around the world about issues important to them.

Godot already exports games to the web, this is about the engine itself running on web.

The editor UI is mostly implemented in the game engine, so dogfooding the web version of the engine for the editor will bring improvements in engine functionality and probably performance to all games.

Was responding to parent: "Unfortunately, the web is not a viable platform for games."

My experience with WebGL has been hit and miss, because many people are blocked to use it properly, whereas native 3D APIs just work on the same system.

All due to how browsers block access to drivers or specific cards.

This is something I'm always on the lookout for, for my growing daughter - relevant, up-to-date and age-appropriate games.

Could you share some more info?

It was probably easier to do this than port the editor to iPad/Android.

It means the developers are dogfooding their WASM support as Godot runs on top of its own engine.

Also excellent for ease of adoption with beginners due to zero install overhead.

AFAIK this is the desktop version compiled to WASM, not a completely separate project.

Its much easier to have educational content about an engine if you can run tutorials directly in the web browser. Don't underestimate the importance of this for producing accessible educational content about an engine at scale.

I love this! Not sure why you would need this, as the desktop app seems to be a lot more performant, but am a big fan of offering everything as a webapp.

I tried to preview the example but apparently it doesn't work with my browser. The web needs to do better.

Which browser?

Safari

Safari doesn't have shared memory yet because it hasn't solved Spectre issues like Firefox has

It also did not work on FF.

Well the UI started, but it failed to load any sample.

I was confused by this too, but you have to load the sample zip before opening the UI - the "filesystem" in the editor isn't a real one (as far as I can see) but a virtual one in the browse that's saved in some kind of persistent storage.

Reply on news.ycombinator.com