Hacker Newsnew | past | comments | ask | show | jobs | submit | livrem's commentslogin

I have always liked gamebooks with interesting game mechanics (not so much the traditional CYOA or Fighting Fantasy) and one great source for that in the past was the annual Windhammer Prize for Short Gamebook Fiction that ran from 2008-2015. I believe all the books are still available for download. Many interesting experiments there and I really enjoyed some books (but it was a while ago and I can't name any of my favorites now).

https://www.arborell.com/windhammer_prize.html

The Lindenbaum Compatition is a newer attempt to do something similar and it has also resulted in some books that I enjoyed reading/playing several of the books from the first year (have not taken the time to look into the entries this year):

https://www.lloydofgamebooks.com/p/voting-is-open-for-202420...


As much as I dislike AI slop, one of the first things I did when I first saw Chat GPT was to generate some gamebooks to use as test input-data for my gamebook-generator script. Description with a graph showing one of the stories: https://intfiction.org/t/pangamebook/52856/17

It was useful for making those test gamebooks. I also thought (too much) about how it would be possible to use a LLM to generate gamebooks, but probably best to first randomly generate some kind of structure (directed graph) for the story and then make many smaller prompts to ask for the book to be written one branch at a time. However even if I ever get around to experiment with that I will certainly not release any code (or slop) because AI-generated gamebooks seems like the last thing the world needs.


There is this collection of 1980's internal design documents from Flying Buffalo that you can buy:

https://www.drivethrurpg.com/en/product/296847/t-t-solo-desi...

It is old, but I do not know of any other books really on this topic. I enjoyed reading it anyway. One of the documents in it describes a simple manual algorithm for how to number the sections in a reasonable way (just randomly assigning numbers is not very reasonable, as anyone will learn from reading a book where the author did that). I implemented that in a simple pandoc filter:

https://github.com/lifelike/pangamebook


He also makes some (non-free) tools that are fun (says me, not a real game dev or artist).

Asset Forge is for combining 3D models into bigger models. Fun to quickly bash his various free models together to make something more complex. Also comes with a bunch of sets of building blocks. I believe he used this tool to make many of the free assets.

Kenney Shape is like a simple pixel editor, except you also set the height of each pixel and then export the result to a 3D model. Can't explain it well, but it is fun.

https://kenney.nl/tools


I have learned it (somewhat) by playing around in TIC-80 and Löve2D (including LoveDOS).

Both Lua and Fennel are tiny languages. You can skim all the documentation in a short evening. Fennel does not even have its own standard library, so keep the Lua documentation close at hand.

I appreciate the simplicity of both Lua and Fennel. There are some ugly parts, but all languages have those.

Janet (later project by Fennel's creator) is a nicer language that is also portable and embeddable, and has a nice standard library, but Fennel runs anywhere Lua runs. Janet is great just on its own for scripting and not sure I would want to use Fennel for that anywhere Janet is available. But as a way to script games in e.g. Löve2D it seems like an excellent choice.


I looked at the documentation, saw it looked like a lot of stuff to learn, and went back to my plain org-mode files. Not sure what it is I miss out on?


I've always had the same problem - could never figure out why I'd want backlinks and endless templates all that. Seems like a lot of complexity for little gain. I put similar items in the same directory/note and never have trouble finding anything. It's possible that I have so much stuff and so many things coming at me that a simpler system is needed to operate at that scale. I've still got an old Roam Research account from when they were free, watched videos, listened to podcasts, read blog posts, and could never find an advantage of going the complex route.


I think it just depends on how you're able to access and use your notes. For me, backlinks were a life-saver because it's important to model relationships between individual notes. It's really helpful for synthesizing knowledge and creating output, or just exploration to find related ideas, etc. Backlinks also help with breadcrumbs, so if my memory fails (frequently) or my search fails (more often than I'd like), I can usually find what I was looking for by navigating backlinks or using hierarchical breadcrumbs (all generated automatically with backlinks in a defined property). So I get a bunch of bottom-up organization for free with minimal effort, and for me it's pretty helpful. Plain textfiles I have trouble resurfacing knowledge very quickly, but YMMV, it's really personal.


The nice thing about obsidian is that you can start off really simple. It can be as minimal as linked markdowns documents if you like. Which is pretty much most of the core plugins disabled up to all the bells whistles.

I've never used org-mode so can't really comment on whether you'll actually be gaining anything


Oh, I use Obsidian too. It's org-roam and related software like Roam Research that inspired it that adds a bunch of complexity. My primary system is to dump similar items in notes in folders in Obsidian.


> text-only apps

What? Is that a common problem? And where are those text-only apps anyway? I have installed Termux and some vim app and a few interactive fiction games that are all text. Are those somehow causing trouble by not having enough graphics to look high quality enough for Google?


The longer description of this from Google's policy page [1] is:

> Apps that are static without app-specific functionalities, for example, text only or PDF file apps

Apps where the user can interact with text in some way (like IF games or terminals) don't seem like they'd be affected.

[1]: https://support.google.com/googleplay/android-developer/answ...


Is this part of the long-term plan for zig to get rid of the dependency on clang/llvm?

https://github.com/ziglang/zig/issues/16270


No. Or rather, only the preprocessor.


Yes.


Does Zig already compile without LLVM, even if not by default?

Also, do you know when the changes Andrew mentioned in his "Data Oriented Design" are going to be released in the zig compiler?

I would expect that when both of the above are done, compiling Zig will be really, really fast compared to anything we currently have.


The Zig compiler has used Data Oriented Design for a long time, so any recent version has that, yes. The most substantial part of running the compiler right now is LLVM, hence the focus to provide an alternative. The other big focus right now is incremental compilation, which will make recompilations very fast.


The talk I am referring to is from 2024 and shows some metrics improving by 30% or more. And Andrew said that's not yet shipped:

https://www.youtube.com/watch?v=IroPQ150F6c

So, are you sure about that??

EDIT: ok, the talk was uploaded just last week, but someone in the comments clarified that:

> The original talk is from 2021.. Thank you for reuploading.

I feel stupid now :/


Recently Andrew posted that the compiler can compile itself without LLVM in under 10 seconds: https://mastodon.social/@andrewrk/112752924367683101


Don’t


It's the major area of focus right now. You can track the issues with this tag/link if you'd like:

https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...


It passed the type checker!


This killed FreeDOS (and presumably all the other *DOS as well) on modern hardware unfortunately. It was fun as long as it lasted. I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.


> I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.

Not sure why would you want a single-process OS on modern hardware, but there are some alternatives that run much less things on the background than regular Linux: Haiku, FreeBSD, NetBSD, OpenBSD, or some lightweight non-glibc, non-systemd Linux-based like Adelie or Alpine.


Or, you know, just booting the Linux kernel with init=/bin/sh with /bin/sh being a statically linked binary. You're overthinking things.


What's the reason why FreeDOS can't use the CSM (the BIOS compatibility mode of UEFI)?


AFAIK it can. I believe some UEFI implementations don't have CSM.


a Type 3 UEFI implementation has no CSM, Type 2 has CSM available, Type 1 enforces booting into CSM (what many "BIOS"es actually was in later days)


Thanks for that. That sent me down an enjoyable rabbit hole. I got started with PCs back in the 80s and became fairly familiar with how boot worked back then. UEFI happened while I was paying attention to other things and I've never become as familiar with it as I should be. This was a good excuse to do some reading.


Just for clarification's sake, the proper terminology is "UEFI class" not "type".

Otherwise, this is accurate.


> the next-best single-user, single-process, non-bloated OS

is UEFI.


Linux in single user mode


That's still multi-process though, there's an awful lot of background tasks running in pretty much every non-fossil kernel version, not to mention userspace daemons (udev, dbus, dhcp) without which most normal userspace stuff doesn't even work.


None of that exists in single user. When you say init=/bin/foo, then that's it, the only process is /bin/foo.


/bin/foo is the initial process. It can fork and/or exec other processes, right?


Sure the facility to fork still exists. So what? Observing that the kernel still provides fork() is like observing that the cpu still provides JMP.

It won't fork random processes you don't explicitly tell it to. I thought it was obvious that if you don't want unsolicited processes, then don't specify /bin/init as /bin/foo. The practical example is /bin/sh, but it could be any other executable.

Up to you to specify a binary that does what you want, and doesn't require a bunch of other processes like gdbus to function itself.

init=/bin/sh is more or less like ms-dos loading command.com


It's obvious but many people here seem to be confusing the Linux kernel with kernel+systemd and complaining Linux has many processes like it's not customizable.


As much as DOS allowed multiple processes, even if only one was executed at the time and there was no multitasking outside of ill-fated MS-DOS 4.0 and various Concurrent DOS products.


You were not there. Multitasking? Xenix. Multitasking DOS? DOS Merge. Pre-emptive multitasking? AmigaOS. DOS 4.0M was task switching. OS/2 2.0? I'm being extremely facetious.

Give me a date, and I will tell you what existed.

Nothing mainstream existed until windows 3.1. at least on x86/32

There also was OLEC on windows 2, that did run in real mode, but the only thing that took advantage of it was the demos, and samples: no commercial product used it.


DOS still allowed you to run child processes, and TSRs were a thing that sometimes caused funny behaviours.

My point was that running your own chosen process as PID1 (or, to be more practical, a minimal init or maybe system v init with single entry for process to run) matches the requirements of running small set of processes just as well as DOS (if you need more, it's IMO more worthwhile to start getting a build of some RTOS for your platform)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: