[HN Gopher] Godot Engine Web Editor
___________________________________________________________________
Godot Engine Web Editor
Author : todsacerdoti
Score : 246 points
Date : 2021-03-21 07:51 UTC (15 hours ago)
(HTM) web link (editor.godotengine.org)
(TXT) w3m dump (editor.godotengine.org)
| isodev wrote:
| I tried to preview the example but apparently it doesn't work
| with my browser. The web needs to do better.
| adventured wrote:
| Which browser?
| isodev wrote:
| Safari
| Darmody wrote:
| What's the point of this?
|
| While I think it's cool shouldn't they spend their resources on
| the desktop engine?
| carwyn wrote:
| 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.
| swebs wrote:
| It was probably easier to do this than port the editor to
| iPad/Android.
| nixarn wrote:
| 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...
| madacol wrote:
| A more recent post https://godotengine.org/article/godot-web-
| progress-report-6
| captn3m0 wrote:
| 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?
| johnyzee wrote:
| 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).
| onion2k wrote:
| _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.
| slezyr wrote:
| > 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.
| andybak wrote:
| 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.
| slezyr wrote:
| So, can you provide "good enough" games with "good
| implementations" that are somewhat popular?
| kroltan wrote:
| https://krunker.io/
|
| Runs at a couple hundred FPS if left uncapped, and has
| very good netcode.
| TheSisb2 wrote:
| Venge.io
| slezyr wrote:
| It looks even worse that Quake3 to me and it's gameplay
| is just dull.
| andybak wrote:
| Aren't you just moving the goalposts now?
| felipellrocha wrote:
| 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.
| athrowaway3z wrote:
| agar.io
| slezyr wrote:
| It lags even more that slither
| modeless wrote:
| 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.
| isodev wrote:
| 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.
| crocodiletears wrote:
| 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.
| isodev wrote:
| It's so frustrating to constantly switch between my
| favourite browser and whatever the developers had in
| mind.
| andybak wrote:
| 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.
| isodev wrote:
| 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...".
| andybak wrote:
| 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.
| isodev wrote:
| 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.
| andybak wrote:
| 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.
| onion2k wrote:
| 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.
| sfjailbird wrote:
| Most importantly, nobody wants to pay for anything on the
| web. Sad but true.
| TazeTSchnitzel wrote:
| There are free-to-play web games making a killing off
| microtransactions.
| UnpossibleJim wrote:
| 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 =)
| jan_Inkepa wrote:
| 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.
| liveoneggs wrote:
| 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.
| learc83 wrote:
| 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".
| StavrosK wrote:
| 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.
| jayd16 wrote:
| 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.
| sfjailbird wrote:
| Not to mention text input.
| jan_Inkepa wrote:
| Sound stuff is still pretty unstable.
| marcosdumay wrote:
| 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.
| techlaw wrote:
| 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.
| kroltan wrote:
| Godot already exports games to the web, this is about the
| engine itself running on web.
| sempron64 wrote:
| 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.
| techlaw wrote:
| Was responding to parent: "Unfortunately, the web is not
| a viable platform for games."
| pjmlp wrote:
| 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.
| thejosh wrote:
| 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.
| techlaw wrote:
| 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.
| hiccuphippo wrote:
| Not everything has a business perspective. Sometimes people
| build things for fun or to learn something.
| nohr wrote:
| 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.
| eoo wrote:
| 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.
| TheMagicHorsey wrote:
| 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.
| Qwertious wrote:
| >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.
| pjmlp wrote:
| Other than browsers blocking 3D hardware acceleration.
| sfjailbird wrote:
| 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.
| pjmlp wrote:
| 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.
| Applejinx wrote:
| 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.
| flohofwoe wrote:
| AFAIK this _is_ the desktop version compiled to WASM, not a
| completely separate project.
| thinkingemote wrote:
| 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"
| TomGullen wrote:
| (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.
| fartcannon wrote:
| 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.
| lukasbuenger wrote:
| 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
| chme wrote:
| I think vendor-lock-in is something that should probably be
| made illegal by consumer protection laws.
| [deleted]
| cycloptic wrote:
| 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.
| vvanders wrote:
| 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.
| cycloptic wrote:
| 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.
| aflag wrote:
| 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.
| cycloptic wrote:
| 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.
| aflag wrote:
| 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.
| cycloptic wrote:
| 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.
| aflag wrote:
| 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.
| cycloptic wrote:
| 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.
| marcodiego wrote:
| Hope this turns into the prodigal open source flash replacement.
| CharlesW wrote:
| 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...
| marcodiego wrote:
| 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.
| tauist wrote:
| Do you mean like https://rive.app but FOSS?
| [deleted]
| JamesBaxter wrote:
| 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.
___________________________________________________________________
(page generated 2021-03-21 23:01 UTC)