HN user
There was research on this published by Activision [1]. Spawning fake enemies behind the users back, inside walls, etc.
The players who react to fake enemies self-identify as cheaters.
For a very simple API, warp [1].
If you're into horror comedy movies, be sure to check out Rare Exports [1]. It combines some of the folklore with the commercial father christmas.
[1] https://en.m.wikipedia.org/wiki/Rare_Exports:_A_Christmas_Ta...
Really fun!
I have been experimenting with similar idea myself. I was curious on how you handle instantiating the terminal state for new clients. Seems like you're storing a buffer [0] of past output, and replaying that?
[0] https://github.com/ekzhang/sshx/blob/91c82d46cde4d1ffa0ae34e...
https://web.archive.org/web/https://rework.withgoogle.com/bl...
Seems the source is overloaded or down.
Hi HN.
ScaleSocket is a command line tool that lets you to wrap any STDIO capable script or binary, and serve it over websockets. Clients then connect to rooms (channels) which have an unique URL (wss://example.com/exampleroom). Connecting to a room spawns a new process of the wrapped script. Subsequent websocket connections to the same room share the process.
I built ScaleSocket in order to be able to build multiplayer back-ends quickly. In the past, I have been experimenting with websocketd [1] to stream a command line application to the browser. It seemed to me that using that approach, i.e. spawning a process and streaming it over websockets, would make a nifty back-end for browser based multiplayer games. ScaleSocket takes that one step further, by supporting shared backend processes.
It's a pleasant approach to get started with, since no lobby server or netcode is required for making a multiplayer backend. ScaleSocket has been my prototyping tool for multiplayer games for some time now.
It's similar to running netcat in server mode, wrapping a script. It's even closer to doing that using websocat [1], whereby one does not have to do the websocket header juggling.
The main difference is that while netcat or websocat will spawn a new process for each connecting client, ScaleSocket has a concept of rooms (channels). For a room, a process is spawned once only. All clients connecting to the same room are routed to the same process. This is not straight forward to do using the forementioned tools.
There's a small comparison page [2] where I have mentioned some alternative tools.
I've been developing a websocket server that lets multiple users connect to the same command-line app.
I wrote a short example [1] that exposes a TUI game on the web. In theory, hot-seat terminal games should be playable over the web with this.
My current challenge has been around refreshing the screen for late joiners. I need to save some of the ANSI escape history and replay it to clients, or ask the application to redraw itself. If anyone has ideas on how to approach this i'm all ears.
We've used dbmate[1] outside of the Django/alembic ecosystem.
I was eager to try this. The screenshots had me convinced the workflow would resemble Alfred/Spotlight. Be careful of guessing your users workflows - there are a lot of ways using git. It seems opening the commit window stages all changes. I'm used to working with patches (`-p`), so in in it's current form it wont suit my workflow.
Another useful Google search trick not mentioned in the article is numeric range queries.
You can use two numbers separated by two dots to represent all numbers in the range.
For example, a search for
taki 100..200
This is useful when you can't remember an exact year or number.
Consider a sentence like "We will finish project x next week with 75% probability".
I'm not sure it is any more clear than "It is probable that we will finish project x next week".
The point estimate is of little value unless we know how it was made. In this case "Jim just came up with a number".
Instead of talking of probability, an estimate of the number of days/hours/tasks would seem more grounded and easier to come up with.
In this case I'd go for, "We will finish project x after we have completed four days worth of work".
Shameless plug for Doctave [0], which offers a solid way to combine markdown and OpenAPI specs into a documentation site.
It's a hosted SaaS, so it's technically not a static-site generator, but it's an alternative to the above.
Facebook's ad platform famously uses the Vickrey–Clarke–Groves auction [0]. In theory it rewards advertisers for bidding for ads using their true valuation, or rather, the lifetime value of a customer.
In practice, it's a lot more convoluted, but the basic principle is fascinating.
[0] https://en.m.wikipedia.org/wiki/Vickrey%E2%80%93Clarke%E2%80...
Combining Swagger (OpenAPI) with Markdown prose was what prompted us to build Doctave [0]. Jekyll does a good job, but breaks down once you need more bells and whistles, such as search and versioning.
It's early, but worth checking out.
Now this is the "headphones for my eyes" I have been waiting for.
I wonder if combining an ebook with a contextual audio track (does this exist?), would work as well as combining an audiobook with visuals (a movie).
They should have branded it as "headphones for your eyes". To me, this seems like the closest analogy of what the value of the product is.
There's Dokku [0] which supports buildpacks (and containers). Would love to hear more from anyone runnkng a business on it.
See also Weyl sequences for generating samples from a discrete uniform distribution.
So first, alter server state before transmission by spawning hallucinations (human-like bots) in places not visible to human players (inside walls, unusual angles, far in the horizon). To the client, they all look like human players. At least in memory.
The players who react or interact with these hallucinations are likely cheating.
This flips the roles, and the hard task of correctly determining "human like" behaviour is now on the cheaters.
One more tool to accomplish this is lmt [0] which, despite minimal documentation, is quite pleasing to use.
For smaller applications, an acceptable middle ground is using the TS language server[0] and JSDoc[1] comments.
Writing
// @ts-check
/** @type {number} */
let x;
[0] https://www.typescriptlang.org/docs/handbook/intro-to-js-ts.... [1]: https://jsdoc.app/
I built a small websocket server [0] that helps me write simple multiplayer backends. It spawns a process for the first client in a room, and routes subsequent clients to the same process.
Also, run your tests in watch mode using entr or pytest-watch [0] for faster feedback.
Seems to be Redis/Memcached API-compatible. Can I use it as a drop-in replacement?
An inspiring collection of thoughts. The section on feedback loops had me thinking: Would it be possible to program without feedback (or with minimal feedback). How would that look?
Pen and paper still has some feedback as one can see more than can be held in working memory.
edit: typo
Recently had a good experience with Typesense [0] for implementing ecommerce search. We solved the "blue shirts" problem by grouping a products color variants together using `group_by` and ranking by text match. The best "matching" shirts are then likely blue. This is a bit simplified, and not exactly the same case, but it worked surprisingly well.
Really excited by projects in this space! I'm working on a similar project myself [1], intended mainly for collaborative web-apps and browser games. It's more of a light-weight approach with processes instead of containers. Pop in a binary or script and let multiple users connect to a shared process via websockets. Process-based architecture limits its use to simpler cases, but these kinds of apps are at-best delightful to spin up and develop.
The effects of sentient AI may wash over society even before we would have such a machine.
A thought provoking "fake scifi wiki article" can be read about simulating a human brain dump called MMAcevedo [1]. It is a highly entertaining read.
I'll add the Innovators by Walter Isaacson to the list as a general take on persons involved in the history of computing. It was well written and the stories within were exciting to read.