[HN Gopher] Show HN: GodotOS - Fake operating system interface m...
___________________________________________________________________
Show HN: GodotOS - Fake operating system interface made in the
Godot engine
GodotOS, an operating system interface created entirely in Godot!
Browse folders, edit text files, view images, play games, and more
in one cohesive polished interface that can even be used on the
web. Note that GodotOS is more of a toy than a serious project.
It's meant to push the limits on UI design in Godot while creating
a desktop that is minimalist, distraction-free, and aesthetically
pleasing. Any feedback is greatly appreciated! Apologies for
posting again, but I forgot to include "Show HN" in the title, and
when I did post yesterday Hackernews almost immediately went down
for over an hour, which is unfortunate.
Author : popcar2
Score : 414 points
Date : 2024-01-11 12:09 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mysterydip wrote:
| Reminds me of all the "OSes"/GUIs that got made back in the
| QBasic days: http://qbasicgui.datacomponents.net/
|
| Always a fun project to do. Thanks for carrying the torch forward
| in something modern!
|
| ps, my favorite of the QBasic ones is probably M-GUI:
| http://qbasicgui.datacomponents.net/95_mgui.html which even
| included its own programming language to make apps in!
| VMG wrote:
| Fascinating. I wish I could run them in a browser VM - it would
| probably be pretty fast as well.
| Retr0id wrote:
| >Because this site still gets a lot of traffic, I'll be
| redesigning the site with more of a modern look and feel. [...]
| I'll try to keep you posted and hopefully won't get
| sidetracked.
|
| Looks like they did get sidetracked, and I'm glad! If the
| author is reading this, I think it's a great time capsule
| that's probably best left as-is.
| chalst wrote:
| Another time capsule, this time in the form of an endolink:
| https://news.ycombinator.com/item?id=38938998
| anticorporate wrote:
| That was how I learned to program, back in the 90s when I was a
| teenager.
|
| But it was never what I meant to do. I was quite sure I was
| going to be a game developer. Knowing absolutely nothing about
| designing a game, managing a project, et cetera, I just
| starting writing games at the beginning, with a splash screen
| or animation, and then started writing the start GUI for the
| game.
|
| For a 13 year old pushing the boundary of what you could do
| with QBasic and mode 13h graphics, I never quite got past
| designing the GUI, but I made a heck of a lot of them.
| luismedel wrote:
| DOS-based GUIs were the rage in its days.
|
| In 1999 I coded a graphical environment for DOS using Borland's
| BGI in Turbo Pascal. I even used it in one of my uni
| assignments[0].
|
| I still remember some afternoons in the library, helping pals
| with linked lists basics and finetuning my textbox scroll code.
| Good times.
|
| [0] https://github.com/luismedel/jugadores
|
| edit: Forgot to add that I wrote a lot of code in paper :-)
| franzb wrote:
| This is absolutely amazing! It brings back great memories of my
| childhood when I was doing similar mock UIs in QBasic, then
| QuickBasic, Turbo Pascal and Turbo C. Thanks for sharing!
| TonyTrapp wrote:
| GIMI was quite impressive as well, also including its own
| programming language, but also getting some heavy-lifting
| weight from a handful of tools written in other languages:
| https://sourceforge.net/projects/gimi/
| cl3misch wrote:
| From the screenshot:
|
| > GodotOS is a fake operating system
|
| Is it fake, though? Does the term "operating system" imply the
| level of hardware it's running on? Otherwise, even if it's
| running on top of another OS, it's still an OS.
| internetter wrote:
| I feel like operating system implies the existence of a kernel
| bluetomcat wrote:
| An application that spawns processes/apps/modules, controls
| them and lets them communicate back to the application for
| some service is also, in a loose sense, an operating system.
| trealira wrote:
| That seems a bit too loose.
|
| Doesn't that apply to IDEs that implement the language
| server protocol, since they spawn language servers and
| communicate with them?
|
| And servers like Apache that spawn child processes to
| handle requests?
| chuckadams wrote:
| Apache supervises tasks in the form of threads and
| subprocesses, including managing memory in the form of
| pools, so yes, it's doing some of what an OS would do. It
| isn't, on the other hand, providing abstractions to
| hardware, and that's what I think of when I hear "OS".
| It's not really a cut-and-dried thing though: modern web
| browsers are like 90% of the way to being full-blown
| OS's, even down to abstracting hardware in the case of
| things like WebGPU, but they still rely on a host OS to
| bridge the connection and do the actual bit-banging
| required to make it work.
| mikepurvis wrote:
| Robot Operating System (ROS) is also an operating system, but
| it runs on top of computer operating systems like Linux and
| MacOS, and is focused on supplying the services, build
| toolchain, and communication standards/paradigms that are
| useful for implementing a robotics system, much as Linux (and
| its distros) are focused on providing that for a general
| computing environment.
|
| In any case, it's clear that the project under discussion
| here isn't really any of these things is rather a system
| shell/GUI/launcher. But calling it an "OS" falls under the
| fun tradition many of us enjoyed in our youth of trying to
| recreate our own Windows in whatever was our programming
| platform of choice, and thinking that was what an OS was.
| popcar2 wrote:
| It's a fake OS in the sense that it's actually an application,
| not something that can be ran as an operating system like Linux
| or Windows. I've been a bit careful with my wording when
| advertising this, I wouldn't want to give the wrong impression.
| xeonmc wrote:
| Would "desktop environment" be a more appropriate
| description?
| lpointal wrote:
| Yes
| popcar2 wrote:
| Absolutely, but I feel like it's a technical term that
| might be hard to understand or advertise. When I explained
| the project to my non-technical friends before showing
| them, I told them "Ah, it's like an operating system" and
| they generally understood what I'm going for.
| bee_rider wrote:
| Is it a desktop environment in the Gnome or KDE sense? I
| didn't see any third party programs in your trailer video
| so I guess you can only run your built-in "programs,"
| right? So I would say it is not really a desktop
| environment... I'm not sure what the technical definition
| is, but I must have something to do with acting as an
| environment to draw other programs.
|
| Calling it a fake OS was, IMO, s great choice for
| avoiding confusion. Maybe something like Concept-OS or
| Desktop Environment Mockup could be good names if you
| want to be fancy.
|
| How hard would it be to include a terminal emulator?
| You'd get a lot of functionality for free, there!
| bee_rider wrote:
| Desktop Environment is already taken by systems like Gnome
| and KDE. This is more like a mockup. The "concept car" of
| desktop environments. It is quite neat.
| im3w1l wrote:
| Sounds like a shell https://en.wikipedia.org/wiki/Shell_%28co
| mputing%29#Graphica...
| z3phyr wrote:
| Is Pharo/SmallTalk/Interlisp a fake OS?
| iosonofuturista wrote:
| Popcar2 , a note on your disclaimer that you are not affiliated
| with the Godot foundation. Is that usual in projects using an
| engine? Or is it because of your , IMHO, poor naming choice.
|
| Think of this way, if the tagline of the project was "EstragonOS,
| a fake os made in godot", would the disclaimer be so proeminent
| in the page?
|
| I think you know you are playing with fire, to make the
| disclaimer a larger font. It's not too late, consider a rename.
| popcar2 wrote:
| Thank you for the concern, I did indeed add it preemptively
| because of the project's name. The reason I chose "GodotOS" is
| because the project was initially intended to be a sort of tech
| demo for Godot's UI systems, and I spent most of my time in the
| official Godot Discord showcasing its development and getting
| lots of feedback. One of the contributors of the engine itself
| gave me the thumbs up.
|
| Of course, if anyone officially from Godot wants me to change
| the name and general branding I'll do so quickly. Right now, I
| think it should be fine.
| ranting-moth wrote:
| It's OK, I'll name my project Popcar2-OS.
| nightowl_games wrote:
| "playing with fire"
|
| I don't think the Godot Foundation would be against this.
| ahoka wrote:
| As a heard they are quite toxic, so who knows?
| jermaustin1 wrote:
| From where?
| mog_dev wrote:
| Please add a disclaimer that you are not affiliated to IOS
| SquareWheel wrote:
| It's a fair point, but I don't think Cisco has too much to
| worry about in this case!
| mentos wrote:
| Would be fun if game engine editor environments took on the UI
| paradigm of an operating system like windows. So that instead of
| going to the File menu at the top of unreal engine to open the
| blueprint debugger, you navigated the start menu to find the
| program.
|
| I've reflected to myself so many times that UE4 feels like an
| operating system, would be fun if in the future it actually was
| ha
| thinkingemote wrote:
| I think that the Godot UI editor is written with Godot, so it
| should be possible!
| gumballindie wrote:
| Just the other day I was wondering - what would it take to
| develop a Linux WM in Godot?
| arminiusreturns wrote:
| Not that much actually if you don't mean as a full WM/DE
| replacement and instead as an on top layer; Godot 4.2 window
| management on linux is working quite smoothly for me, including
| multi-window support. From there what you do within the windows
| is where the magic happens. (see my other post)
| gumballindie wrote:
| What I mean is a full WM/DE replacement. I mean godot already
| handles graphics quite nicely. Imagine a desktop that you can
| control with shaders and runs on Vulkan. That'd be pretty
| neat.
| arminiusreturns wrote:
| I've thought about it but it seems daunting so I punted
| this idea for myself, but it depends on if you mean as an
| xorg/wayland replacement or if you mean to build on one of
| those, and even between those two they have a vastly
| different approach, but there are some minimal foundations
| that could be built on...
|
| For example, wlroots: "Pluggable, composable, unopinionated
| modules for building a Wayland compositor; or about 60,000
| lines of code you were going to write anyway." So it would
| also depend on if you mean raw WM or if you want
| compositing also etc.
| tmpdbejdhejd wrote:
| > Just the other day I was wondering - what would it take to
| develop a Linux WM in Godot?
|
| It bas been done :
|
| https://github.com/SimulaVR/gdwlroots
|
| But it is not up to date with Godot 4. You can have your
| Firefox or Blender window be a regular texture inside a full
| Godot game, pretty crazy...
| scoopr wrote:
| Heh, back when, I used to do (Q/Turbo)Basic stuff like:
| PRINT "Welcome!" INPUT "Password: ", pw$
|
| and so on, with very little actual functionality. I guess some
| themes of toy projects are evergreen, even if the sophistication
| is on another level :)
| xyproto wrote:
| It's a game launcher that uses Godot, but neither an OS nor
| connected with the Godot project.
|
| It's a bit like writing a game launcher in Rust and calling it
| RustOS.
| bbkane wrote:
| I think it's a fun name
| palata wrote:
| Isn't it a bit like making an app that uses Qt and start its
| name with a Q? Without giving any real name, I can invent
| "Qnotepad" which would be a notepad implemented with Qt.
|
| I know real projects that follow this pattern, and it never
| really bothered me that it was not connected to the Qt project
| (other than by using Qt).
| davidy123 wrote:
| I guess that "a desktop that is minimalist, distraction-free, and
| aesthetically pleasing" means Windows 2000 with transparent
| backgrounds.
| baq wrote:
| super bit boy made me instantly younger by about 15 years.
| thanks!
| gcr wrote:
| Godot is a great sketchpad for these things. One time I was at
| the airport for a flight, so I wrote a quick-and-dirty notepad
| for the Russian pencil-and-paper game Virus War ("Voina virusov")
| for my eInk tablet that my partner and I could play. It was just
| a grid with tappable buttons in varying states, but I was able to
| get a playable prototype ready for our flight.
| omgmajk wrote:
| This is great, actually thinking of building something similar
| for a game I'm working on, but other way around really. OS in
| game instead of game in OS. :)
| emmanueloga_ wrote:
| Looks great! I know there are a bunch of games that use this kind
| of setting (fake OS) as the main mechanic. Her Story comes to
| mind [1].
|
| 1: https://store.steampowered.com/app/368370/Her_Story/
| koromak wrote:
| Hypnospace Outlaw is the absolute MVP of this category. That
| game is a trip.
| rubymamis wrote:
| We at a stage where desktop environments become faster than the
| OS they run on (ahem... Windows).
| felideon wrote:
| This is great. Would you recommend Godot for prototyping UIs, in
| general, over HTML/JavaScript?
| chalst wrote:
| I guess you are aware, but Godot can be compiled to JavaScript:
| https://docs.godotengine.org/en/stable/tutorials/export/expo...
| popcar2 wrote:
| Short answer: Yes!
|
| Long answer: I recommend Godot for rapid prototyping and
| creating desktop applications, but not necessarily for web app
| development. The biggest blocker is that Godot 4's export size
| is quite big compared to web standards, roughly 35MB
| uncompressed and 7.5MB compressed. The web version of GodotOS
| is 7.8MB, which may be too big for professional use.
|
| Godot is fantastic for making quick prototypes though. The
| editor is very quick & intuitive once you understand the core
| concepts. It's also a fantastic tool for creating cross-
| platform desktop & mobile applications, some professional apps
| have been designed with it.[0]
|
| [0]: https://alfredbaudisch.com/blog/gamedev/godot-
| engine/standal...
| bitwize wrote:
| This might still be useful in the real world. Think movie
| industry, where having a mock OS for showing characters doing
| computer things is practically a trope in its own right. I was
| recently in a discussion with some fans of the movie Hackers, in
| which one of them asked what OS they used in the movie. My reply
| was to the effect of, what every movie in the 90s used, which was
| basically Mac OS with fake UI elements cobbled together in
| Macromedia Director (or Flash in later films).
|
| With film studios increasingly turning to game engines for
| applications like providing real-time on-set CG as a reference
| for a shoot, something like this may well be the modern version
| of that.
| larschdk wrote:
| Related: Grey Hack is a fake OS, Network, Internet in a
| multiplayer game where the objective is to hack (including each
| other). It simulates many basic functions quite well (you can
| steal files, place files on other computers, install software,
| run commands from a command line, including imitations of many
| tools). You can also write your own programs.
| actionfromafar wrote:
| When will someone go all in and release a hack game with
| hundreds of emulated real little servers of various operating
| systems and vulnerabilities?
| aa6ll wrote:
| Isn't hack the box already itching this?
| mikepurvis wrote:
| At a certain point on the realism continuum, just get rid of
| the gamey parts and deliver someone a set of VM images that
| they have to boot up and break into.
|
| (Maybe that's actually what Hack the Box is, mentioned in the
| sibling-- I hadn't heard of that and only looked briefly at
| the homepage for it.)
| cmeacham98 wrote:
| > Maybe that's actually what Hack the Box is, mentioned in
| the sibling
|
| Hack the Box hosts the VM for you on their servers (and you
| connect to a VPN to get access), but it's effectively that.
| They release a box every so often (roughly monthly?) and
| users compete to collect the user/root flags.
|
| They also have a rotating selection of past boxes (and I
| think you get access to all of them if you pay them), so
| it's kind of like an "on demand" CTF.
| bee_rider wrote:
| I've always thought it would be interesting to try something
| like that for a LARP.
|
| It would be fun to run in an "anything goes" type setup. Get
| a cheap raspberry pi and install some really old Linux kernel
| with plenty of well know holes. I'd worry about delineating
| between game-machines and real ones. It would have to be
| totally isolated from the real network I guess.
| fragmede wrote:
| That's what CTF at Defcon is like!
| t0astbread wrote:
| Yeah, my employer does that. We call it "infrastructure". /s
| depressedpanda wrote:
| Some time ago, I found a site that provided different
| variants of VMs you could download which contained exploits
| you could utilize to pwn the machines. There were also
| walkthroughs and guides available to teach you how to break
| in.
|
| Unfortunately I can no longer find the site, and my Google fu
| has failed me.
|
| Unlike Hack the Box, no signup was necessary, you could just
| download the VM and get started.
|
| Does anyone here know of any good alternatives they'd like to
| recommend?
| FpUser wrote:
| Very nice. I wish it would also work on mobile. The initial
| screen showed up but "clicking" on folders does not cause any
| action.
| netbioserror wrote:
| This just makes me yearn for a UI-centric minimal compilation
| mode for Godot. It's such an enticing target for GPU-rendered UI,
| and there are even some excellent libraries and plugins out there
| for making components that are useful in engineering or data
| analysis!
| 654wak654 wrote:
| You can disable a lot of Godot's features when building the
| engine from source [1]. Not sure how much you can save while
| keeping most of the 2d/3d components, but it should be
| possible.
|
| [1]:
| https://docs.godotengine.org/en/stable/contributing/developm...
| barbariangrunge wrote:
| Shouldn't use the godot name for this
| cjdell wrote:
| The Godot IDE itself is a "game" as in it is entirely built using
| Godot APIs. Makes me wonder if it would actually be a good
| environment to build portable business apps, sort of like a
| modern Visual Basic.
| jeremyjh wrote:
| It would have all the issues of Flutter (non-native widgets,
| accessibility, etc) without the focus on these specific kinds
| of use cases.
| IshKebab wrote:
| Only nerds care about non-native widgets.
| Gormo wrote:
| This is actually a great proof of concept for using Godot as a
| cross-platform framework for desktop applications. The
| distribution package is incredibly simple -- just a single
| executable and a data file -- and performance is excellent.
|
| This seems much superior to Flatpak and the like as a way to
| offer fully self-contained distro-agnostic binary packages, and
| _vastly_ superior to Electron in the performance department.
| Maybe desktop applications built with game engines are the next
| big trend.
| eru wrote:
| The Firefox people have some nice write-ups about how they want
| to / wanted to use techniques from games to make Firefox's UI
| faster.
| jadtl wrote:
| I was trying to think of arguments against it, so I thought
| about the fact immediate mode GUIs might not always be
| suitable, before I stumbled upon this post:
| https://stackoverflow.com/questions/47444189/what-are-the-pe...
| The only other downside I can think about is from a design
| standpoint, the application has to have the same design
| language across platforms, so it cannot have a native look for
| each. Any other cons?
| 654wak654 wrote:
| Some quick googling tells me Godot doesn't have native tray
| icons/notifications support or access to peripherals like
| webcams & printers. Buut if you're using Godot over
| electron/flutter/QT your app is probably focusing on 3D /
| physics topics. You can implement plugins for those other
| niche desktop features as you need them.
| tmpdbejdhejd wrote:
| There is some ongoing PR, so it might come at some point :
|
| https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Ao
| p...
| nucleogenesis wrote:
| I've been thinking about this a bit and the main concern I've
| had is around accessibility. The web has had a lot of
| iteration over time to make it relatively easy to build
| applications that are well suited for use with screen readers
| and other assistive technologies. Have you done any testing
| along those lines with the Godot UI tools?
| Narishma wrote:
| It requires a GPU.
| Gormo wrote:
| I'm not aware of any GUI stack that doesn't require a GPU,
| nor any desktop hardware released over the past 30 years
| that didn't have a GPU.
| Narishma wrote:
| Qt or Electron don't; they both have software renderers.
| The latest Godot needs a GLES 3 or Vulkan GPU. The older
| versions used to only need a GLES 2 GPU.
| Scramblejams wrote:
| I RDP or VNC into VMs that run without a GPU all day.
| It's very much optional for 2D, at least.
| ladberg wrote:
| This would be sooo much worse from a UI point of view. All nice
| OS features (good text rendering, uniform text editing
| interface, accessibility, transparency) would all get chucked
| out the window.
|
| I also don't think Godot is inherently more performant for any
| random UI than Electron is. It happens that most Godot apps are
| performant because they're made by the type of people who want
| to use videogame engines and thus care about performance.
| Electron can definitely have great performance when the
| developers care about performance (VSCode).
|
| I say all this as someone who's worked on game engines before.
| lolinder wrote:
| Exactly. People hate on Electron because they have bad
| experiences with many Electron apps, but that's not because
| Electron is inherently terrible, it's because most developers
| choose Electron because it requires the lowest amount of
| effort. When you start with that as your single reason for
| choosing a tech stack, it's unsurprising that optimizing
| performance never happens.
|
| VSCode works because they chose Electron for the advantages
| that web tech has when it comes to building a plugin
| ecosystem. They were then willing to put in the effort to
| make performance decent.
| integricho wrote:
| I think it's very subjective what is considered performant.
| I for one don't think about VSCode as a performant app, for
| me it is a resource hog, not at all that responsive app,
| there's always a slight delay / lag in input reaction,
| simply not a fast application.
| lolinder wrote:
| So that the rest of us can calibrate, what text editors
| do you use that you consider to be performant?
| allan_s wrote:
| Sublime text or neovim for me (even with all debugger,
| language server, tabnine etc installed so to be also a
| full 2024 ide )
| integricho wrote:
| SublimeText, Notepad++, CudaText and LiteXL have
| acceptable performance, memory footprint and
| responsiveness for my taste (but this is certainly not a
| benchmark, just another subjective viewpoint :) )
| trealira wrote:
| Lite XL, although I usually use Emacs
| z3phyr wrote:
| VSCode is slow as heck and a needless memory hog. Something
| like VS6.0 or Code Warrior with crisper fonts would be my
| first choice on a graphical interface.
| Gormo wrote:
| > People hate on Electron because they have bad experiences
| with many Electron apps, but that's not because Electron is
| inherently terrible, it's because most developers choose
| Electron because it requires the lowest amount of effort.
| When you start with that as your single reason for choosing
| a tech stack, it's unsurprising that optimizing performance
| never happens.
|
| Which amounts to a strong argument in favor of using a tech
| stack that has superior _default_ performance, and
| therefore requires less dev effort for optimization.
| whstl wrote:
| The problem is that Electron is superior to something
| like a Godot UI in absolutely everything else.
|
| Sure Godot can be ok for trivial apps, but extracting
| performance out of Electron is also not that difficult
| for trivial apps in the first place.
| forrestthewoods wrote:
| > The problem is that Electron is superior to something
| like a Godot UI in absolutely everything else.
|
| Why? What capabilities does Electron provide that Godot
| doesn't and can't? I'm genuinely asking. I don't know.
| homarp wrote:
| Electron allows you can do webdev stuff, so you don't
| need custom knowledge of anything special. That's the
| 'superiority'.
|
| Doing UI in Godot means either their pythonish custom
| language or C# (and via GDExtension technology, C and C++
| ).
| whstl wrote:
| Electron has literally thousands and thousands of very,
| very complex UI/UX features offered by the OS, plus
| thousands and thousands of very, very complex UI/UX
| features offered by a browser engine.
|
| Godot has barely nothing compared to that, as it's not an
| UI toolkit and never tried to be.
|
| Even basic things like "rendering text correctly in
| multiple languages, with emojis, while making it
| selectable with the mouse or with the keyboard" are super
| hard to get right, but it's a problem already solved by
| your OS, in a way that is not only better optimized and
| has less unseen bugs than a hypothetical bespoke
| implementation: it also looks and feels more familiar.
| Then there's the whole accessibility part, which has
| different native APIs depending on the OS.
|
| Some other people have written detailed answers:
|
| https://news.ycombinator.com/item?id=38953558
|
| https://news.ycombinator.com/item?id=38954455
|
| https://news.ycombinator.com/item?id=38954087
|
| EDIT: You asked "doesn't and can't". Here's something:
| there is no can't if you have a turing complete language.
| But you need a large team to re-do it from scratch, as
| you're throwing away 40 years of work.
| bluesroo wrote:
| I think that it instead amounts to a strong argument that
| many apps simply wouldn't exist if Electron didn't lower
| the barrier of entry.
| vcg3rd wrote:
| > All nice OS features (good text rendering, uniform text
| editing interface, accessibility, transparency) would all get
| chucked out the window.
|
| Could you explain this to someone who doesn't program and
| knows nothing about how os internals?
|
| My naive question is wouldn't the OS/DE/WM still take care of
| the above for an application?
| ladberg wrote:
| To give an example comparing a text field in a native OR
| webview-based macOS app with a hypothetical Godot-based
| one, the Godot version would need to reimplement (or likely
| just omit):
|
| - Copy/paste
|
| - Emacs/readline keybindings (Ctrl-A, Ctrl-E, etc.)
|
| - User's preferred text size and font as selected in System
| Preferences
|
| - Spellcheck
|
| - Nice features for non-latin text (e.g. built in pinyin
| keyboard)
|
| - Crisp text rendering
|
| - Dictation support
|
| - Screen reader support
|
| - Autofill
|
| - Automatically updated with OS updates (e.g. HiDPI, all
| Java UIs had looked almost-native but were now stuck
| looking pixelated)
|
| - And hundreds more features I'm forgetting...
|
| This is all possible to do in Godot (e.g. the Godot Editor
| does a lot of these) but with a lot of work required. It's
| completely built in to any native or web-based text field
| and doesn't need any additional work.
| rkangel wrote:
| From an "interfacing with the OS" point of view, a game
| engine interacts differently. Most desktop apps ask the OS
| "please render this text here, with this font" and the OS
| takes care of that. A game engine just asks the OS "here is
| a canvas I have drawn, please just put these pixels on the
| screen". The OS doesn't know that a chunk of pixels is
| text, so you can't select it, copy and paste it, or screen
| reader it by default.
|
| This is the same difference between an system like Flutter
| and native App toolkits (I'm going to talk about Flutter
| because I know more about it). It has massive advantages on
| portability - Flutter rendering is very predictable on
| different phones because the only thing that can vary is
| screen size. The subtle variations between OS versions and
| phone manufacturer UI skins don't screw things up.
|
| There are downsides: You need to implement all the common
| stuff that you'd normally get for free. This includes
| native look and feel - Flutter has to have all the Android
| and Apple widgets. It also includes text rendering
| accessibility, etc. etc.
| freedomben wrote:
| Think of it like the difference between building a bicycle
| by taking existing parts and assembling them, vs just
| starting with raw materials and fashining a bicycle. If you
| use the pre-built seat that has a spring (suspension) on
| it, then you get that "for free." If you're assembling from
| scratch, you either have to build a spring (not very easy)
| or go without one. For many bikes, it's going to be without
| and for the ones that do it, odds that the spring will be
| as good as or better are low.
|
| With a game engine the OS is basially handing you a blank
| canvas and telling you to draw what you want. With a GUI
| toolkit like GTK or Qt, the "OS" is handing you a bunch of
| pre-made parts and you get to arrange them on the page how
| you like.
|
| If you're writing a game, the former is obviously better.
| If you're writing a standard application, the latter is
| usually better. By "better" I mean higher quality output,
| and less work to construct.
| corethree wrote:
| No it's better for an os UI. A web page UI is better with
| electron where you click on a link an open a page. But
| floating windows with resizeable and highly dynamic UIs Godot
| is likely easier, better and much more well suited.
|
| HTML was never intended for dynamic interfaces. Whenever you
| diverge beyond what it does best which is hypertext, things
| become more and more hacky and awkward. If you wanted to
| design an os UI in electron, you would use a framework called
| react, and you would use a language called JavaScript that
| compiles down into typescript and you'd need a whole build
| ecosystem and connect everything together, then you might
| find HTML to awkward so you have to switch to webgl which is
| too low level or you might switch to svg... In both cases you
| miss the text rendering from HTML. If you stick with HTML
| then you'd be using css to move shit around and create
| windows which is also incredibly awkward.
|
| People use electron because it's easy. The reason why it's
| easy is because of familiarity not because of actual
| superiority.
|
| Web UI is one of the most hacked together technology stacks
| ever. Developers with nothing better to do keep coming up
| with new abstractions trying to build for a moving target.
| It's not unique in this regard but it doesn't change the
| reality. Godot has the benefit of a very specific design
| implementation for a target that is highly dynamic and likely
| will never change. Plus it's new so you don't have armies of
| developers trying to "abstract" shit on it over years and
| years of horizontal progress.
| arshxyz wrote:
| > HTML to awkward so you have to switch to webgl which is
| too low level or you might switch to svg
|
| HTML is replaceable by WebGL which is replaceable by SVG?
|
| > JavaScript that compiles down into typescript
|
| JS compiles down to TS?
|
| I am not sure if anything in this comment indicates you
| have any experience with developing for the web but that is
| not my primary issue with this comment. My gripe is
| claiming that things are "awkward" or can't be done without
| even looking around. None of the examples below use WebGL
|
| Here's a WinXP UI clone that runs in your browser with
| floating, resizable windows. - https://winxp.vercel.app/
|
| Here's one that mocks macOS - https://macos-web.app/
| corethree wrote:
| >JS compiles down to TS?
|
| It's called a typo.
|
| >I am not sure if anything in this comment indicates you
| have any experience with developing for the web but that
| is not my primary issue with this comment. My gripe is
| claiming that things are "awkward" or can't be done
| without even looking around. None of the examples below
| use WebGL
|
| I think you're smart enough to recognize it's a typo. The
| primary issue with your comment is hiliteing issues as if
| it weren't typos but actual lapses in experience. It's
| like saying someone misspelled a word and claiming they
| therefore have no experience with the English language.
| If someone did that, the intent is 100% malice, not a
| misunderstanding. Don't be malicious. Don't debate and
| use malice to prove a point. What you should do is Make a
| point and change your stance based off of evidence.
|
| Also I never said it can't be done. I said it's awkward.
| It certainly can be done.
|
| WebGL is low level. Same with WebGPU, it means you have
| to use shaders. Godot has a library for UI. Which makes
| it less awkward. I'm saying it's JUST as awkward to build
| these things with webGL then with other web front end
| technologies.
|
| >Here's a WinXP UI clone that runs in your browser with
| floating, resizable windows. - https://winxp.vercel.app/
| >Here's one that mocks macOS - https://macos-web.app/
|
| What do these examples prove? That it can be done? Did I
| say it can't be done? Again I didn't. It's obvious these
| examples exist, everyones seen them. Heck you can
| probably do the whole thing with CSS and no JS. The gist
| of my comment is that it's awkward to do, not that it
| can't be done. You can construct a house out of
| toothpicks and glue. I'm sure it CAN be done. But bricks
| are the less awkward tool.
| zogrodea wrote:
| I'm another person who read your comment who doesn't like
| Electron/web dev and, while reading your comment, I
| thought "does this guy even know what he's talking
| about?".
|
| So as someone aligned closer to your team (preferring
| other toolkits to Electron) I don't think the other user
| who replied to your comment previously was being
| malicious in interpretation.
| corethree wrote:
| So did you think i actually meant that Javascript
| compiles down into typescript?
|
| I'm sorry but that comment alone makes me think malice.
| It's too obvious. To each their own.
| zogrodea wrote:
| Yes, I did and I was confused (hence my thought it was
| someone focusing on things other than web dev that made
| the comment).
|
| It's not like I'm attributing ill intent now that you've
| clarified what you meant (I mentioned having the same
| anti-Electron inclination as you to demonstrate that) but
| I probably can't change your mind if you think two
| people's misinterpretation of the same comment came from
| malice.
| whstl wrote:
| _> Developers with nothing better to do keep coming up with
| new abstractions trying to build for a moving target_
|
| Bullshit. React is almost 11 years old, the only other two
| really popular competitors are 10 and 13 and use the same
| paradigm.
|
| Everything else in this area is very experimental and
| tentative, as it should be, but it is mostly celebrated by
| people who, surprise, complain that "the web is too
| complex".
|
| Even "new hotness" like Tailwind is based off quite old
| Atomic CSS ideas that started in the late 2000s and early
| 2010s at Yahoo.
| corethree wrote:
| >Bullshit. React is almost 11 years old, the only other
| two really popular competitors are 10 and 13 and use the
| same paradigm.
|
| React has been changing a lot. And before react it
| changed even more. There's all kinds of change in the
| front end world and you know it. Not even close to
| bullshit.
|
| >Everything else in this area is very experimental and
| tentative, as it should be, but it is mostly celebrated
| by people who, surprise, complain that "the web is too
| complex".
|
| Webgl and svg are experimental? I don't think so. Using
| CSS + HTML + Javascript to build an Windows like
| application is more experimental.
|
| >Even "new hotness" like Tailwind is based off quite old
| Atomic CSS ideas that started in the late 2000s and early
| 2010s at Yahoo.
|
| I never talked about whether something is based off of
| old technology. I'm just saying all the state of the art
| is always changing constantly as people build new things.
| Whether those new things are recycling old ideas is
| besides the point. The main problem is that each "new"
| thing is placed as this big ugly layer above something
| that was designed to be a high level interface anyways.
| whstl wrote:
| React had a single major _incremental_ change in the form
| of hooks. It was built upon existing established
| foundation: functional components. And even then, it
| still didn 't break backwards compatibility. That's far
| from "changing a lot" in 11 years.
|
| And _" before react it changed even more"_ is a terrible
| argument. We had a handful second-tier frameworks who
| _never_ gained enough traction compared to React
| /Vue/Angular even in their first months. _None_ of those
| temporary frameworks achieved more than a very small
| fraction of jQuery popularity in their heyday. jQuery was
| king since almost launch, and was never really
| threatened, until React came along.
|
| By "in this area" I obviously mean frameworks. And good
| call: WebGL is gonna be 13 years old this year and SVG
| will be astonishing 25 years.
|
| And no, the "state of the art" is not really changing,
| unless you're going for non-market-tested technology. But
| that's you, that's not the market, that's not what people
| are hiring for, and that's not even what's getting stars
| in Github. New experimental projects are not "change".
|
| The "state of the art" is still React/Vue/Angular,
| perhaps with SASS or CSS, which is from 2006. Even
| Webpack is 10 years old next February! And only now it is
| getting serious competition. Typescript is still 100%
| optional but is 11 years old.
|
| The meme that "Javascript changes too much" was already
| old and tired in 2015. In 2024 it's absurd.
| brucethemoose2 wrote:
| > I don't think Godot is inherently more performant for any
| random UI than Electron
|
| It probably depends on the app?
|
| Electron will obviously excel at things that resemble an
| oldschool web page, but one would think Godot would excel at
| more dynamic OS UIs? If something is already sluggish or GPU
| heavy in Electron, I would think its right up Godot's alley.
|
| Accessibility of course is a seperate and huge concern.
| bufio wrote:
| I have never encountered an Electron app that can even
| display the results of keystrokes in a timely manner, and
| that includes vscode. All Electron apps waste system
| resources to an obscene degree. Also, Electron apps have
| already thrown away OS conventions to the point that user
| interface consistency has become a thing of the past.
|
| I don't believe that either choice is ideal, but if Godot
| were ubiquitous instead of Electron, applications would
| probably at least be less laggy and more memory-efficient.
| skydhash wrote:
| Sublime Text and Blender (and I guess the majority of CAD
| applications) creates their own UI engine. That would be
| better than the current state of electron apps, but most UI
| engines I encounter have support for custom elements. The
| issue is more wanting access to lots of cheap developer
| resources than branding.
| then4p wrote:
| VS Code ID top laggy for you? Honestly asking because I
| think it performs adequately when compared to like
| IntelliJ.
| alpaca128 wrote:
| According to one benchmark intelliJ can reach an average
| latency of 3ms on an i5 3427U from 2012 [0]. In a 2022
| Github issue someone profiled VS Code which resulted in
| 12ms latency on an i7-12700KF released in 2021 [1].
|
| If those results are even remotely representative of
| real-world scenarios then VS Code can't come close to
| intelliJ performance.
|
| [0] https://pavelfatin.com/typing-with-pleasure/#windows
|
| [1] https://github.com/microsoft/vscode/issues/161622#iss
| uecomme...
| dekerta wrote:
| Are you running a 15 year old netbook or something? I've
| never noticed any input lag in VSCode or Slack (or any
| other Electron apps I can think of)
| fragmede wrote:
| they're a text editor and a chat client, and a 30 year
| old computer can run vim/emacs and irssi just fine.
| fkyoureadthedoc wrote:
| brb, just switching my 100k employee company from Teams
| to IRC, should be quick and easy, everyone is going to
| love it.
| alemanek wrote:
| If they are on MacOS they may make you their king. I
| still have PTSD from the last job that I had to use Teams
| on a Mac.
| KomoD wrote:
| Teams is awful on all platforms, I don't ever want to
| touch it again
| whstl wrote:
| They might indeed. There are some very nice native IRC
| clients for macOS that are fast and good...
| rubymamis wrote:
| I own a 2017 MacBook Air, and I don't see why a block
| editor like Notion should be so slow on my computer. This
| is why I'm building my own block editor in Qt C++ and
| QML[1].
|
| [1] https://www.get-plume.com/
| Capricorn2481 wrote:
| Because Notion is slow period. The web app is insane
| jshreder wrote:
| Just wanted to compliment your landing page and the intro
| gif. Great showcase of the app, if I wasn't hooked on
| LogSeq I'd give it a try!
| rubymamis wrote:
| Thanks a lot, I'm very happy to hear! Essentially, all
| notes are just markdown/plaintext, so it should be easy
| to move your data to/from LogSeq. I'm saying essentially
| tho cause, although the underlying data is plaintext,
| they are stored inside a local database rather than an
| arbitrary folder. But soon I'll change that.
| pests wrote:
| Looks good. I joined the waitlist.
|
| How does it compare to Obsidian? I didn't see it in any
| of the comparison graphs.
| oDot wrote:
| Nice landing page. Tip: make the speed comparison an
| agonizing animation, like esbuild's:
|
| https://esbuild.github.io/
|
| Edit: Tip 2: the screenplay looks nothing like a
| screenplay
| rubymamis wrote:
| Haha that's funny. I'll consider that.
|
| > Tip 2: the screenplay looks nothing like a screenplay
|
| Is it because the lack of middle alignment? I was
| thinking about that. At the end of the day it's all
| plaintext/markdown underneath, so I need to come up with
| the right syntax for that.
| oDot wrote:
| You can use Fountain
|
| https://fountain.io
| bufio wrote:
| You're probably used to high latency.
| squeaky-clean wrote:
| Something is very wrong with your system configuration if
| VS Code has issues showing keystrokes in realtime. It's not
| a VS Code or electron problem.
| gkbrk wrote:
| I've had this happen with VS code. When your system is
| under load, VS Code not only gets keystrokes in a laggy
| way, the characters arrive in the wrong order.
|
| Haven't had this problem with other text editors.
| haolez wrote:
| I've seen this too. With recent versions nonetheless.
| theferalrobot wrote:
| This happens to me pretty regularly when training ML
| models or running heavy simulations etc, the system is
| taxed and electron just gets swamped meanwhile more
| efficient apps can handle themselves just fine on the
| side.
| jcelerier wrote:
| People say this but then I look at them typing and I can
| literally see the lag compared to closer-to-the-metal
| toolkits.
| 0xdeadbeefbabe wrote:
| I have the same not-a-VS-Code-or-electron problem.
| dartharva wrote:
| You are overlooking a massive point that invalidates your
| concerns from a homebrew developer's POV: it is _easier_ on
| the mind to make apps using low-code graphical interfaces
| than with full-code.
| Gormo wrote:
| > This would be sooo much worse from a UI point of view. All
| nice OS features (good text rendering, uniform text editing
| interface, accessibility, transparency) would all get chucked
| out the window.
|
| This is what is already happening with people using
| sandboxed-runtime containers (like Flatpak) and webapp
| wrappers (like Electron). Desktop UX is becoming a hodgepodge
| of siloed runtimes and inconsistent interface paradigms.
|
| I don't think Godot would be a great alternative to
| developing a conventional desktop app, relying on the OS-
| provided runtime environment, but if you're already deviating
| away from that, it might still be much better than Flatpak or
| Electron.
|
| > Electron can definitely have great performance when the
| developers care about performance (VSCode).
|
| But most Electron applications do not have great performance
| because they're not being developed this way. Using Godot
| would provide an easy-to-learn frontend environment (with a
| scripting language that might even be simpler than using web-
| derived JS) while still providing the performance of a game
| engine under the hood. So non-Microsoft developers who would
| otherwise use Electron might still stand a chance of
| releasing decent software.
| wk_end wrote:
| > This is what is already happening with people using
| sandboxed-runtime containers (like Flatpak) and webapp
| wrappers (like Electron). Desktop UX is becoming a
| hodgepodge of siloed runtimes and inconsistent interface
| paradigms.
|
| Flatpak and Electron don't sabotage any of these things.
| Flatpak usage is entirely orthogonal, and Electron actually
| has best-in-class accessibility, i18n, text rendering,
| keyboard navigation, RTL support, hi-DPI support, etc.; its
| widgets feel by default as-or-more-native than anything Qt
| or GTK produce.
|
| Without massive engineering work, handcrafting your GUI in
| Godot is going to suck for anyone using a screen reader,
| anyone who reads Arabic, anyone who can't use a mouse, etc.
| alfalfasprout wrote:
| VSCode is super laggy even on a $4000 MBP. Compared to
| something like IntelliJ sure, but that's a super low bar on
| responsiveness.
| fauntle wrote:
| I keep seeing this complaint but I have never reproduced it
| locally. VSCode runs at a buttery smooth 120hz on my MBP.
| What are you doing that causes such poor performance?
| IshKebab wrote:
| It's extensions. Some of them can drag a machine to its
| knees, with unbounded CPU usage. The worst is the C++
| extensions. Gets stuck at 100% CPU if you open a file it
| doesn't like, which is most of them.
|
| VSCode _with no extensions_ is very fast and light.
| VSCode with 30 extensions you 've accumulated? Not so
| much.
|
| I think that's why you see such conflicting experiences -
| people have different extensions.
| bigstrat2003 wrote:
| Except VSCode most certainly does _not_ have great
| performance. I can open the same set of files in VSCode and
| Sublime, and Sublime will use a few hundred MB of memory
| while VSCode uses well over 1 GB. That 's not acceptable.
| popcar2 wrote:
| Completely agreed! I've been meaning to write a blog post on
| using Godot to professionally create cross-platform
| applications (and probably will soon). The short of it is that
| Godot is fantastic as a UI builder, and I think a lot of people
| are slowly realizing it. Many professional applications have
| been built with Godot[0] , and I also want to give a shoutout
| to Lorien[1] which is my favorite whiteboard application also
| made in Godot, and what partially inspired this whole project.
|
| Godot isn't perfect of course, and there are some things that
| many other UI creating tools do better, but I think there's a
| lot of untapped potential here.
|
| [0]: https://alfredbaudisch.com/blog/gamedev/godot-
| engine/standal...
|
| [1]: https://github.com/mbrlabs/Lorien
| zengid wrote:
| If you're making a certain class of desktop app (CAD, DAWs,
| Video Editor) this is worth exploring!
| LSRegression wrote:
| It's already being used for that! I use a program called
| Dungeondraft[1] for easily creating maps for TTRPGS and it's
| built on top of Godot (see the modding API page[2] where they
| mention Godot).
|
| [1]: https://dungeondraft.net/
|
| [2]: https://megasploot.github.io/DungeondraftModdingAPI/
| FinalDestiny wrote:
| To add to the list, Pixelorama[1] is a pixel art sprite
| editor built on Godot.
|
| [1]: https://godotengine.org/showcase/pixelorama/
| paulmd wrote:
| > This seems much superior to Flatpak and the like as a way to
| offer fully self-contained distro-agnostic binary packages, and
| vastly superior to Electron in the performance department.
|
| The children yearn for Swing Toolkit
| FireInsight wrote:
| I don't get why people in this thread are conflating Flatpak
| with different ways to do desktop UI. Even if your app is a
| single self-contained binary, it can benefit from Flatpak.
| Sandboxing, permissions management, separation from system
| (needed on 'immutable' and image-based distributions), unified
| package format (don't need to create deb, rpm, etc. for a
| simple GUI app), and many other Flatpak's features can benefit
| the devs and the users alike. That has not much to do with what
| you use to write UI. Flatpak can't be entirely replaced by
| self-contained binaries.
| themerone wrote:
| Electron apps work with screen readers and os accessibility
| feature.
|
| Unless accessibility becomes a first class concern, game
| engines are not going to be good choices for desktop
| applications.
| turtlebits wrote:
| Sounds like you're describing Flutter.
| zilti wrote:
| Have you heard of AppImage?
| dataangel wrote:
| This doesn't remotely solve the same problem Flatpak does, you
| are comparing apples and oranges.
| bentt wrote:
| Please consider calling it GodOS (pr: gud-os)
| popcar2 wrote:
| Trust me, you aren't the first to recommend the name. I love
| the idea of saying godos, but then I'd have to constantly
| explain that it has no relation to God or TempleOS haha
| bentt wrote:
| I trust you
| arminiusreturns wrote:
| Very nice! (and AGPLv3 too!!)
|
| I have been working on a similar project for actual filesystem/OS
| interaction (heavily abusing OS.execute
| (https://docs.godotengine.org/en/stable/classes/class_os.html))
| which is actually a sub-project of a much bigger project (only
| working part-time now so I can spend half my day on it as I near
| alpha). My favorite part so far has been in my attempts at using
| Godot to recreate fsv/fsn (3d filesystem representation).
|
| Is there any reason you haven't tried to turn it into a real
| desktop environment given that Godot provides the mechanisms to
| do so? I know I've been nervous that I might have a bug that does
| something destructive and that is why I've been working on my
| ci/cd pipeline and unit tests but am just curious.
|
| Either way, it has been awesome watching the explosion of
| creativity happening in Godot land. I compile daily and watch the
| commits and see such vast improvements being made all the time.
| It's a great engine with first class c++17 support with GDNative
| and modules, and I truly believe the future of gaming (and many
| other things) is FOSS. My only meta-wish is that the engine was
| GPL instead of MIT, but luckily that doesn't stop me from
| releasing my stuff built in it as GPL.
| popcar2 wrote:
| > Is there any reason you haven't tried to turn it into a real
| desktop environment given that Godot provides the mechanisms to
| do so?
|
| It's just too complicated to embed third party applications
| into a Godot game. I suppose it is _technically_ possible to do
| so since you can use GDExtension to glue C++ code, but I can 't
| even begin to imagine how that can work. Thanks for the
| feedback anyways :)
|
| As a side note, Godot can't be GPL because it would imply that
| you can't make closed source games in it (they'd all have to be
| GPL as well).
| arminiusreturns wrote:
| With OS. functions (including OS.execute) you don't need any
| third party things or GDExtensions from my point of view. You
| might check it out if you haven't. I am working on a real
| file browser in 3d and execution launches applications
| natively in linux for example. It's not launched "within
| Godot" per se.
|
| As for the GPL thing: that's exactly the point!
|
| Wish you the best in future Godot dev.
| strontian wrote:
| Thank you for making this! I've been dissatisfied with the
| options available for making local GUIs and curious about what
| could be done with game engines. What was it like working with
| the UI layer of Godot?
| popcar2 wrote:
| Quite fun. I find it a lot simpler and more intuitive than
| other UI frameworks I've worked with (especially front-end
| webdev), but I understand it's very opinionated. Once you get
| accustomed to using Control nodes in Godot (that's what they
| call UI components), it becomes super easy to rapidly prototype
| and design anything you'd like.
| tombert wrote:
| This is really neat!
|
| I almost wonder if this could be adapted into a "real" desktop
| environment, as in "competing alongside KDE or Gnome". I have no
| idea what's involved with doing that but it it would be cool if
| you could.
| dogtimeimmortal wrote:
| Dang! I just realized github no longer works on my old macbook
| running firefox 78.15.0esr (64-bit).
|
| BigTech wants me to buy a new macbook or switch to chrome.
|
| Edit: it's actually no laughing matter. I'm pretty devastated.
| :-(
| Dunedan wrote:
| ... or to just update to a newer version of Firefox.
| ziddoap wrote:
| The current FireFox ESR version is 115.6.0. Extended support
| for 78.15 ended in 2021.
|
| It's weird that your first inclination is a new computer or
| chrome. Those are two very different things, and neither is
| necessary.
| corethree wrote:
| I mean let's look at all the game menu screens in existence
| today.
|
| For what they are most of these screens are far better than HTML
| counterparts. UI is snappier and more special effects.
|
| Game UIs off the menu have always been better than web pages too.
| Look at say baldurs gate 3. I don't think such a UI is easily
| pulled off in web. Possible but awkward to build.
| jarboot wrote:
| I've been thinking about making a cross-platform mobile app but
| don't want to think about react native, touch javascript, or
| fiddle with xcode any more than I have to.
|
| Is it accurate to think that I could instead use godot to create
| a cross-platform app to eliminate complexity from react native
| while creating something that is performant/native across
| ios/android?
| ronyeh wrote:
| I've worked in both Godot and React Native. I wouldn't say you
| are eliminating any complexity.... You are just trading one UI
| system for another. UI by its nature is complex and requires a
| lot of "code". In the Godot case you might be doing less coding
| in the "typing letters on a keyboard" way, but you still need
| to figure out the UI controls and fiddle with the settings in
| the properties panel until you get it juuuust right. The final
| product is still saved as code, in tscn scene files.
| Rucadi wrote:
| The performance is really nice, I kinda love it.
| neonsunset wrote:
| >written in GDScript
|
| Quite unfortunate.
| koromak wrote:
| Until C# is first class, I still find GDScript more comfortable
| nirav72 wrote:
| This is neat. I always wondered if it was possible or if anyone
| has made a fancy UI for instrumentation / dashboard using a game
| engine.
| freshnode wrote:
| This reminds me of a time circa 2005 where "Sub OSes" were
| somewhat popular in the GameMaker community. Seems that given
| enough time someone will try to make an OS-like interface in a
| given game engine.
|
| It was a great way to understand UI and usability paradigms
| beyond building game mechanics.
|
| This definitely triggered some pleasant nostalgia for me.
| trigonated wrote:
| Nice to see someone else who also remembers those.
|
| I was the creator of Tiagix OS, AFAIK one of the first subOSes
| that actually had support for creating apps for it.
|
| Learned a lot about GUI toolkits making it, since I had to
| implement one from scratch for it.
| arjonagelhout wrote:
| Do you have any material online on Tiagix OS? I can't seem to
| find anything from a quick Google search.
| trigonated wrote:
| I think there's a build of an older version of it on the
| YoYoGames archive. The archive didn't save the screenshots
| that the original website had, sadly.
|
| I also spent a long time working on a very large update
| which I might have archived somewhere locally but never
| shared it online.
| chaosharmonic wrote:
| > silksong never.png
|
| Why do you have to hurt me like this
| swalsh wrote:
| I remember when Notch was playing with this space game with a
| slimed down assembly language he created. He stopped working on
| it unfortunately, but I still think there's a whole potential
| genre of hacking on a game. Not a "press F" to hack, but a legit
| log into this system, get/change whatever. Having a legit in-game
| OS seems like a good step forward.
| bragr wrote:
| It's more programming than hacking but you might enjoy TIS-100
|
| https://www.zachtronics.com/tis-100/
| posix86 wrote:
| Factorio has a mod where you can program electricity circuits
| using assembly, I forgot the name. You place a "computer
| facility", connect to the signal network, then open a terminal
| to start programming.
|
| It's pretty cool because factories can be very complex, giving
| it real utility. And you can communicate over the wire with
| fair sophistication using items as signal symbols. The clock
| speed of the devices was limited to a few instructions per game
| tick.
| fragmede wrote:
| At what point does it start looking too much like your real
| job? Zachatronics game Shenzen had that problem for some
| friends of mine that do chip design professionally.
| n_plus_1_acc wrote:
| https://store.steampowered.com/app/716490/EXAPUNKS/
| koromak wrote:
| Bitburners does a pretty good job. Its an idle game with fairly
| limited "OS" emulation, but the best solutions require real
| thought and programming knowledge.
|
| You'll be writing scripts to scan the net for open ports,
| automatically "hack" into them, then globally balance allocate
| memory between all of them according to certain parameters to
| make the hack the most "profitable". You'll be writing
| elementary socket communications, building scripts to feed
| analytics back to your home PC, even alogirthmic trading in a
| fake stock market. I had fun with it.
| grimgrin wrote:
| For the curious: https://en.wikipedia.org/wiki/0x10c
|
| https://web.archive.org/web/20130905082541/http://dcpu.com/d...
| koromak wrote:
| I would love a write up on design philosiphy. I'm currently
| learning Godot coming from web dev, and finding the distributed
| business logic impossible to organize. I just don't know who,
| what, or where business logic should be.
|
| My urge is to lift logic up to the parent of any group of
| interactions, and let nodes just be renderers. But I understand
| that is absolutely not the design philosiphy of Godot, and
| probably won't scale.
| keerthiko wrote:
| It's impossible to be sure without knowing your programming
| experience in general across sectors, but it sounds like you
| are unused to the paradigms of game programming in general,
| which is centered on logic executed per-frame rather than per-
| flow (like in business applications, which is where the concept
| of "business logic" comes from).
|
| The default approach in game engines is to bind data including
| state to an actor, then have define per actor, in a given
| state, how it modifies its own and other actors' data over a
| frame (usu. processing user input as necessary), and how it
| renders to the screen. This is what game engines are designed
| to make easy, by providing something like an "Update" and
| "OnDraw" virtual functions you fill in for every element in
| your world.
|
| Inevitably every application needs to have a few "directors"
| who need to take care of business that can't be isolated to an
| individual "actor" or per-frame state manipulation, and these
| are usually structured around async-awaits, callbacks, is a
| thread handler/dispatcher. But if you go overboard with
| directors, actors that operate like directors, or actor-
| director interactions, you're inviting trouble in game-engine-
| land.
|
| There are some alternate paradigms like "entity component
| system" and entirely callback-driven event-driven game
| architectures, but they tend to never exist in purity without
| the actor-update model.
| matt_s wrote:
| Ironically, early days Java Applets had you painting things
| on a canvas with a similar event loop. I think Flash also
| operated this way.
|
| I almost think if someone were to build applications with
| Godot (or another engine) that you would need to mentally
| translate from something like React components and their data
| to the actor/sprite+state in an event loop model.
|
| For example a todo list in Godot might have an actor that is
| the checkbox with some text next to it and the state of
| checked/unchecked, then allow the user to click something
| which generates more of these actors/sprites dynamically. I
| think where it really becomes cumbersome with a game engine
| is no real organization of a scene exists without you
| explicitly laying out x,y pixels. There are concepts of
| "relative" but common application concepts of pagination,
| etc. would be hard to pull off in a simple way in the code I
| would imagine.
| whywhywouldyou wrote:
| The fact that you're playing around with a game engine and
| using phrases like "distributed business logic" tells me you
| have a long road ahead of you.
| nucleogenesis wrote:
| Coming from web dev to Godot was a bit wonky for me and digging
| into some Godot dev patterns on YouTube and elsewhere went a
| long way to help me wrap my head around the question of like...
| "where does this logic/state/etc live and how do I access/use
| it where I need it?"
| ShadowBanThis01 wrote:
| This is a pretty cool prototype for something I'd considered
| Godot for: a GUI for a device running embedded Linux. In that
| environment, you want the least bloat but some decent development
| tools so you can iterate reasonably fast. That's not a widely-
| available combo.
___________________________________________________________________
(page generated 2024-01-11 23:00 UTC)