I should have included a disclaimer -- I agree that textures and sprites are excellent, but they come from asset packs (for this same reason I cannot redistribute them in the source release). Only the crossbow placeholder is self-made.
I don't have any issue with paid asset packs, I would gladly build the entire game with third-party art, but there is only so much of it in the necessary style, resolution and quality.
It might look much better if you picked a palette with a mood (https://lospec.com/palette-list). The resolution mismatch between the foreground crossbow and the sprites and background textures could be made less apparent too by reducing the resolution. For the monster sprites there's always scaling and palette flips. But yeah, with those sprites (and sound) defining the game's identity it's a bottomless pit.
> Over the years I have been frustrated by binary and XML formats that make data only accessible via a single program (or by me wasting time manually converting each file, or by me writing a file format conversion program).
For me, the frustration is version control. Native spreadsheet formats (xlsx/ods) are binary, so un-diffable. Plaintext formats like CSV/TSV play nice with Git, but come at a high cost in ergonomics: there is no way to preserve formatting such as column widths and formulas are usually discarded on save. Moreover, Excel/Calc don't really like it when you overwrite an open file from another program.
MtCellEdit seems to be a step in the right direction, but still leaves a good part of the itch unscratched.
I've never understood why retro computer enthusiasts go through such effort to replace their floppy drives with CF cards, when Sony had a solution almost 25 years ago.
My DSC-30 came with a metal floppy disk that has no moving parts. But you could insert a Memory Stick into it, and then stick it in any 3.5" floppy drive and read the stick as FAT.
Every time I see someone on the VCF forums struggling with the latest floppy drive replacement board I wonder what ever happened to that technology.
Simple: a real 3.5" floppy disk drive has moving parts and various things that age and eventually break. For example I have an old device with a broken floppy disk drive which can't even read a real floppy anymore. With the metal floppy "emulator disk" you mentioned, the FDD itself still has to be fully functional in order to read this "emulator disk".
A floppy emulator board which reads SD/CF cards or USB sticks doesn't have that problem at all since it's purely solid state electronics and directly connected to the electronic interface of the FDD instead of the real FDD, and usually you can put thousands of floppy disk images onto such a memory card/stick and select which disk image is to be put into the emulated floppy disk drive ⇒ there is simply no need for the "emulator disk" technology you mentioned anymore.
Those floppy disk emulators require special drivers to prevent the drive head moving off the transducer. It isn't worth the hassle to get them working on non-PCs.
I would agree that the flying has become "unreasonably" cheap given the negative externalities, but if we are talking about traveling over distances of >500 km, the alternatives are rarely compelling -- unless you are lucky enough have a direct high-speed-rail connection to your destination.
I would like to make the observation that as Hy matured over the years, instead of accumulating syntactic sugar and special cases to grow more Lispy, less Pythony, it seems to have generally gone the opposite way. That is, becoming a thinner syntactic abstraction of Python's feature set, focusing on the essentials that cannot be emulated in any other way (macros)
A few examples from recent releases:
- "match" is just native Python "match" -- it doesn't even polyfill for pre-3.10 Python versions (in the TypeScript world this would be unthinkable)
- "foo?" used to mangle to "is_foo" as a special case, but this has been removed
- "hy.eval" has been overhauled to be more like Python's "eval"
- nice-to-have but non-essential utilities ("unless") get often pushed out into the Hyrule package
For me this direction was counter-intuitive at first, but it has some very nice outcomes; for one, it simplifies the learning curve when coming over to Hy from Python, and it makes it easier to consistently interact with Python packages (arguably the main reason to use Python in the first place!)
Or maybe it's just a matter of simplyfing maintenance of the language; IIRC, "let" took like 4 attempts to get right :)
In any case, congratulations on this great milestone!
Yeah, at a certain point I realized that both the maintenance and the use of the language became much slicker if unnecessary deviations from Python were minimized. After all, when I'm writing Hy code, I'm usually spending a lot more time referring to the documentation of Python or third-party Python libraries than the documentation of Hy. I felt there were a number of ways Python could be improved upon, but e.g. the old feature that let you spell `True` as `true` in deference to Clojure was just a needless complication.
It is true that Hy really shines in those cases where it adopts an existing Python feature and adds meaningful quality-of-life improvements: anonymous functions without limitations; multiple iteration in for-loops; relaxed character set for identifiers. Things that seem completely obvious, once you have them.
It also demonstrates that elegance in a Lisp-on-Python is reached in a very different way than elegance in a stand-alone language, since it becomes an art of making the best out of what is already there.
Not to discourage you from building your own, but Joplin seems to already tick all or at least most of your boxes -- in fact, I was surprised that it was was not addressed in the first article.
Thank you for your suggestion. In fact, some people have already recommended Joplin to me, but it seems that it was a bit late. Where I am, not many people seem to be familiar with this tool. After being suggested, I tried using Joplin and it turned out to be a good tool. However, you know, I had already started developing Notas a few weeks before, and abandoning it is the saddest part. That's why I initiated this discussion, and you contributed to it.
