While you absolutely can use Godot to export to web, I found the exports themselves to be pretty lacking. For one, the export size is much larger compared to other game engines and frameworks. Because we're targeting web and not desktop, small size is a must-have as many people who play web games are more likely to leave and never come back if they're waiting for the game to load.
Export size is very important. We got our Godot export (assets + wasm) down to < 10mb after brotli compression for
https://goobershot.winterpixel.io/
I believe the wasm is about 5mb and the .pck is about 5mb.
You can shrink the wasm by disabling unused modules in your Godot compilation and not compile stuff you don't need. You can remove debug symbols, and enable link time optimization as well. We could push our export size even smaller, but I have higher priorities.
I don't feel like it's too complex. I started working with it about two years back and was productive within the first hour.
You definitely don't have to use everything. The only "requirement" you need - I use the term very loosely - is knowing how to use sigils ($,@,%,&) and understanding when to use which, which is easier than it looks. The rest of the knowledge comes naturally if you're inclined to refactoring.
For me, that means I'd write the most verbose solution first, then slowly work my way down to fewer SLoC. A recent programming problem took about 20 lines in Python but was a one-liner in Raku. I know SLoC isn't everything but it provides the dopamine this lizard brain craves, haha.
Not yet, but I have it on my watchlist. I wait for wider (rust-like) adoption of Nim, because most of my programming tasks are heavily dependent on the ecosystem and requires a fair amount of libraries.
Do you have any specific libraries that you are missing? The packages list [1] has almost 1600 packages.
Also, the FFI in Nim is basically just declaring some C function as a `proc`. So, wrapping existing C libraries is as easy as Cython for Python. You can even jump start things by running `c2nim` on a header file.
We use the Neo4j graph database quite extensively, so a Neo4j driver / client SDK would be nice. And for intra service messaging we need a google cloud pubsub client library.
Not sure how well it works (and I have no setup to test), but there is this [1]. It's pretty old and Nim has evolved quite a bit in the last 4 years. It probably doesn't compile, but it might not be hard to spruce it up (not that this would be a great "intro project"). { EDIT: Open source is often pretty thankless. It might be that if you asked nicely of that repo owner that he would do the sprucing! :-) }
I know there are a few different protobuf impls floating around. Not sure how much google pubsub needs beyond that. It's probably not so far away. Maybe you can be the one to do the pubsub wrapper. :-) (I'm only trying to encourage, not enlist/conscript.)
I appreciate your effort, I also have a hacker spirit / hands on mentality for my own hobby projects. But in this case I simply cannot "sell" it to my team. We really need something already production ready with community support behind it.
I would give it another shot. I was a Vim zealot that converted over with Spacemacs, but I ditched Spacemacs once I knew the names of the packages I used the most. The package `evil` is enough to satisfy your modal editing needs (perhaps you already knew about it). Anything that doesn't fit your workflow can be changed to fit into that same modal editing paradigm. It just takes time but it's worth it in my humble opinion.
Just remember: Emacs' main strength comes from how malleable and extensible it can be. Give it time; don't jump ship after a few bumps. Patch it up with some Elisp and keep sailing.
Emacs is malleable, but it shows that it comes from a pre-CUA era. IMO, they should just drop the existing UI preset into a "legacy UX" package that old-timers can keep, and come up with a new preset that will be familiar to users of post-Win95 machines.
IntelliJ does this right. You are dropped into a brand-new, complicated editor, but the basics like the arrow keys, Ctrl+C/Ctrl+V, ctrl+arrow key movements, menus and lots of other bits are already familiar to you. You may remap the editor in any way you want, but you are likely to override a few presets and get on with your day, than rewire the entire thing.
That's really gonna come down to your workflow and use cases. For me, the Lisp is a bit more welcoming than VimScript for me. It's much easier to test out a small snippet of something in-buffer which might grow into something else.
But, putting Lisp aside, going through the growing pains was worth it for me because of org-mode. I'm certain Vim might have something similar but the proper `org` package is definitely on my list of benefits. I have an org-file that tracks my time and generates invoices with a click of a button. Another one documents all the API calls in another project with interactive areas, thanks to org-babel. I think being able to craft documents like this is invaluable but again, it's gonna come down to how you do work and what makes you happy/efficient.
> It's much easier to test out a small snippet of something in-buffer which might grow into something else.
Ok, here you got me and I'm about to try it another time. But then again I remember the slow loading times, the weaker ecosystem (is the lsp implementation as good and fast as coc-vim?) but whatever, maybe I should give it a try with evil mode. But there are so many other cool things waiting to be learned...
I can't reply to your deepest comment in this thread, but I'm following up on that:
* Try spacemacs. Though I'm a Doom user, spacemacs is much more approachable out of the box. You can just uncomment things and have it work well.
* Use Emacs 27.1 or later because it has faster JSON parsing -> crucial for good LSP performance
A few ways to get started are learning how to search for things within Emacs:
* C-h f: find documentation for any function by name
* C-k k: find the documentation for any keystroke function
* If you want to see what commands are going on: install command-log-mode. it will give you a buffer to see what commands you run with every keystroke
* I don't remember if spacemacs has it or not, but the following two packages are crucial when you want to learn more: which-key (to show the keys available when you press something like C-x) and helpful mode [0]. I'm pretty sure spacemacs has these by default, but if not they're golden!
To me, the physicality of one of the "fantasy consoles" mixed with a bit more power might make for some interesting games and projects. The only thing I would wonder is if they could tilt that screen up a bit like an AlphaSmart.
Every time I hear a glowing testimony like this, I get a little hopeful but then I remember the current state of the JavaScript ecosystem. Perhaps you could shed some light on this?
Is it possible to make externs or definitions of library functions? How much time does it take to take a fresh library and write those externs to access them in Parenscript land? And what limitations did you run into?
Parenscript is nice because you don’t need complicated externs: it has a pretty straightforward mapping to JS symbols and no runtime. However, the downside is that it feels more like “JavaScript with a new syntax” than like Common Lisp or another lisp. I personally find the trade-offs acceptable because it’s fees fairly natural to right JS in a lispy style, but it’s not the “pure” experience of something like Clojurescript.
Sounds like you got an amalgam of bad first impressions. Sorry to hear that!
So, something that helped me get pass that inertia was learning where init.el resided and how it is loaded. After I read about that, installing a package manager that's not constrained to the minibuffer was a 3-4 line endeavour (use-package). Save, reload. After that, you might get a notification of Emacs warning you about trusting an unknown source. (I always accept here.) After that, it was a matter of using M-x use-package and installing packages that I remembered from Spacemacs: which-key, restart-emacs, swiper/counsel/ivy, and hydra were enough to get me up and running.
Regarding the overly complicated commands, I agree that they're a bit lengthy but you are able to change the ergonomics of your keybindings at will. My config is heavily inspired by evil-leader and I put a lot of functionality behind "C-;". So, "C-; f p f" will open a search dialog for all of the files in the current VCS repo. This might be lengthy for some but it feels right to me. I like that about Emacs.
Sorry for the rambling! If you ever decide to try it out again, feel free to message me and I'll help where I can.
