Interesting experiment.

Would love to see a multiplayer version of this game!

https://store.steampowered.com/app/2410820/Too_Many_Sheep/ both cooperative and competitive

Also, https://store.steampowered.com/app/3006280/Sheepherds/

> A cozy co-op party game where you and your sheepdog buddies guide colorful flocks through beautiful landscapes [...]

It has a free demo but no release date yet

Maybe you are interested in slipshow: https://github.com/panglesd/slipshow/

Good question :) Many reasons, I could make a blog post about it!

First, let me start with the biggest drawback of using OCaml: it might prevent potential contributors from making contributions. That is very sad!

However, OCaml is the language I know the most. I use it at work and I'm very very satisfied with it. It's main strengths for me are its type system for maintainability, the tools around it (the lsp server, the build system dune, the autoformatter ocamlformat, ...) and the fact that it can compiles to Javascript! It also has some libraries of very high quality.

With a "single" codebase, leveraging the javascript ecosystem, I could make the compiler work as a statically linked binary, as a node script published on npm, inside a Tauri app, and inside a VSCode plugin. ("single" codebase in quote since I needed some specific code for each application, but the core logic is shared.)

For sure, the same could have been made with another language, but I knew OCaml, and knew I would have a pleasant experience using it for that.

(I even plan to rewrite the engine in OCaml. The engine was written in javascript quite quickly, at a time when I had no experience with largish projects. It is now very difficult to maintain and extend.)

Markdeep seems great!

Having modifiable source inside the html is a great idea. I'll still need to have a compile workflow to add image while keeping a standalone produced html file (and some other feature such as live-preview), but I'll definitely add this as a possible workflow.

Yes, that is exactly right!

This is one important thing for me: the produced file must be self contained. Even if images are included, they are embedded in the html file.

Thanks for the link, and the idea! Definitely a github action to automatically publish your Slipshow presentation on push would be a great workflow! (I'll open an issue for that!)

Yes, clearly this is not for every usecase.

I think math lectures often need quite some text support, they are the reason I created Slipshow.

The timing is super important. Writing on a chalk/whiteboard or overhead takes time, which is required to absorb the content. Hitting the right timing and cues with this approach seems like it would take a lot of practice, which isn't a deal breaker, though I believe the 2 biggest problems with most presentations is too much/too fast content, and not enough practice and this approach might make those both harder, not easier.

Very cool! I had never seen something like that!

Sometimes, I used the analogy of a big papyrus roll (like this one: https://pgi-shop.de/en/papyrus-roll-20-x-80-double/) to explain what is Slipshow. But your analogy is much better!

I don't know Miro or Figjam very well, but I would say that:

- You can write a Slipshow presentation in Markdown, which can be more convenient than in those collaborative whiteboards (depending on the person): the source file is plain text. - Slipshow is made for presentations, so it is themed for that: the usual ratio for the screen, blocks such as example/theorem/definition, titles, ... - It is easy in Slipshow to reveal new content/go to a new position by simply pressing the "right arrow" key. - The output from Slipshow is a single file that you can view offline, send to your audience, ...

There might be more differences. For sure, those tools are different and adapted to a purpose, or a style of presenting. For some kind of presentations, Miro and Figjam might be much better than Slipshow!