crispweed

I'm working on a collection of networked games, around the central theme of a lockstep deterministic network model with 'delay frames' (between acting directly on user input and progressing actual shared network state).

You can try this here: https://locksteparcade.com/Client

Games included in the arcade, currently:

- Neon Swarm, a take on the classic lemmings game, with multiplayer versus and coop modes

- Serpents, a snake game (where you eat food, grow a tail and need to avoid this growing tail), with inertial movement and multiplayer

- Spirits, an homage to N++, where you work together to get someone to the exit, while avoiding enemies, figuring out how to open doors, and so on

- Pilots, a multiplayer asteroids battle with homing missiles

Each game solves the network delay problem (the problem of providing immediate feedback to user input and hiding the fact that actual changes to shared state are delayed) differently, and it has been very interesting to work through a bunch of different approaches to this.

If anyone else here is working on multiplayer network games, I'm very interested in setting up a regular "play each other's games" session.

The idea is that regularly playing with other game developers will help develop a kind of 'scene' (where you get a group of people together who make work in public but really aimed at each other, pushing and unblocking one another to become bolder and better at an accelerating rate, as described here: https://www.henrikkarlsson.xyz/p/scene-creation-engines ).

If you are interested, let me know!

I'm working on a game arcade thing as a hobby project, themed around lockstep networking.

There's a website for this here: https://locksteparcade.com/

It's still very much a work in progress, with just two games. One is a version of the classic game "Lemmings". The other is a very minimal asteroids style inertial ship duel.

The games both use deterministic execution in lockstep across network participants, and provide interactive gameplay and smooth execution even if situations with up to quarter or half second lag times, and the methods used for this are then perhaps one interesting aspect of the project.

In each game, the local player sees their own controlled entities at current positions, and other player entities at historical positions.

In the lemmings game, the complication is that lemmings depend on their own world changes (e.g. they need to stand on a bridge piece they just built). So there is a kind of fork and merge mechanism that enables local and remote world changes to be eventually consistent.

In the inertial duel game, homing missiles have a deploy phase in which they transition between different update time frames, with exactly the same sequence of updates applied on each machine, but with these updates accelerated or slowed down to achieve the time frame synchronisation.

There is an offline part with a tutorial to go through for the lemmings clone, which gives a flavour of the thing. The networking part uses a dedicated server and is currently invite only, but if anyone is interested in trying this then please shout and I can send out server credentials..

Recent discussions about artificial intelligence safety have focused heavily on ensuring AI systems remain under human control. While this goal seems laudable on its surface, we should carefully examine whether some proposed safety measures could paradoxically enable rather than prevent dangerous concentrations of power.

The text you get when you click share should indicate which puzzle you solved, in some way (e.g. like the number in "Wordle 247 3/6").

Having some kind of graphic in this sharing text would feel nicer, I think, as well, somehow. (Could be just sequences of green blocks for each word, basically just showing how long the words you made are.)

Right, this seems like an interesting subject, but not a lot of information there. Can anyone suggest better sources?

Any comments on the following: https://news.ycombinator.com/item?id=22662071

How about something like this: https://www.asailorslifeforme.org/educator/primary/PS-Plan-o... ?

The concept of diminishing returns, perhaps, together with the corollary, by which I mean the fact that you can often get easier profits or make progress a lot more easily by switching to some less explored avenue.

When considering selling points, everyone seems to be focusing on the advantages of being able to run traditional games without console hardware or delays for installation, but no-one seems to be talking about how something like this could fundamentally change the constraints on multiplayer game design. I wonder what the server side looks like, and whether anyone is working on MMO type products that are designed specifically for this setup..

How do you think the unthinkable?

..

With a great big itheberg.

I don't know exactly how that bug bounty program works, but it feels like there may be some fundamental issues with bug bounties in the context of open source projects.

For example, what is there to prevent someone from introducing a bug into an open source project, first of all, and then subsequently claiming a bounty for identifying and/fixing it?

(Maybe this can end up by forcing more careful pull request auditing for security critical projects, but that seems like a big ask..)

As other posters have said, it seems like it can be tricky to incentivise cattle owners to add algae to their feed, check this has actually been added, in proportions that have the desired effect, and so on.

But how about if governments provide subsidised feed centrally, instead, with the algae added?

Perhaps that is not a performance, in the same sense as other stuff. e.g. do you get a bit of adrenaline kick in, are you motivated to impress them with your keyboard skills, etc?

What makes the attacker different? If there was a possibility to subsidize mining by being paid to do science, why would other miners not take advantage of this also?

The trick is to detect obstacles that are likely to have minimal affect on the global result of pathfinding search, e.g. convex obstacles that are in the middle of open spaces, or, more specifically in the case of PathEngine, obstacles that don't combine with other nearby obstacles to form larger blockages.

After the initial graph search, the path is modified to avoid these obstacles locally (by pushing the path around the obstacles, essentially), before it's returned from the pathfinding query.

So the way it's set up in PathEngine this optimisation is largely hidden from application code (code that calls into the pathfinding API).

Leaving this to be handled later on, by agent local obstacle avoidance, could also work..

Yes, a lot of people are doing this, and it's not a bad approach.

There's another approach you can take for continuous space pathfinding, however, which is to use visibility graphs.

See http://www.cs.kent.edu/~dragan/ST-Spring2016/visibility%20gr..., for example, for some explanation and diagrams.

This is the approach I used in PathEngine (www.pathengine.com).

A lot of people are put off by the possibility for graph explosion in situations where there are a lot of obstacles in an open environment, but PathEngine works around this quite effectively by detecting these kinds of obstacles and pulling them out of the visibility graph (and pathfinding search).

Maybe the solution is to reuse or share content a bit more? Seems wasteful, for example, that the huge worlds created for some of todays AAA open world games are used only for those games.

Just saw this on the french wikipedia page for iodised salt, not included on the english language version:

> Toxicologie : en 2012, l'Autorité européenne de sécurité des aliments (AESA)7 fait remarquer que alors que la plupart des aliments ont un taux de plomb qui a régulièrement diminué, parmi 734 catégories d'aliments consommés en Europe et analysés (145 000 analyses au total), 87 présentent encore des taux de plomb préoccupants. Le sel iodé est l'un de ces 87 aliments, il serait source - pour un consommateur moyen - de 2,4 % des apports alimentaires quotidiens en plomb. Le rapport de l'AESA ne pose pas d'hypothèse sur l'origine de ce contaminant toxique et indésirable, source de saturnisme.

So that is saying that there are some concerns, reported by 'AESA', with iodised salt containing lead.

Couldn't find any original source for that, though, so far (looking here: http://www.efsa.europa.eu/).

> The computation [...] is multiplying two 64-bit unsigned integers, giving a 128-bit product. Some machines have an instruction for that.

And compilers often let you call these instructions fairly directly, with compiler intrinsics.

With Visual Studio on Windows x64, for example, you can implement the mulul64() function with _umul128: https://docs.microsoft.com/en-us/cpp/intrinsics/umul128 (and expect quite a good speedup)

Randomly remove some tiles each game, without revealing which were removed?

> Currently used blood pumps have many disadvantages: their mechanical parts are susceptible to complications while the patient lacks a physiological pulse, which is assumed to have some consequences for the patient.

Kind of weird, but apparently people with artificial hearts that don't give a pulse don't really suffer any obvious consequences:

https://www.popsci.com/science/article/2012-02/no-pulse-how-...

The text I quoted seemed to suggest that the reference going out of scope could trigger deallocation.

> The most important thing about Rust (and the thing that makes programming in Rust confusing) is that it needs to decide at compile time when all the memory in the program needs to be freed.

> ...

> When the function blah returns, x goes out of scope, and we need to figure out what to do with its my_cool_pointer member. But how can Rust know what kind of reference my_cool_pointer is? Is it on the heap?

> ...

> If we knew that my_cool_pointer was allocated on the heap, then we would know what to do when it goes out of scope: free it!

The way this is written kind of seems to suggest that Rust will sometimes free heap memory when a reference to that memory goes out of scope, which I think is misleading.

As I understand it, this is not the case, and the point is just that Rust needs to be able to prove that nothing else freed the referenced heap memory at any point where the reference may be used.

I guess tooling can help here?

It seems like this information is all collected together for the docs, for example.

Look at the page for std::vec::Vec, for example (https://doc.rust-lang.org/std/vec/struct.Vec.html).

Here, you have sections for: 'Methods', 'Methods from Deref<Target=[T]>' and 'Trait Implementations', and then it seems that if you look through all these sections, you can see everything that can be called on this type, highlighted in the same light brown colour.

It would be quite nice to get an alphabetically ordered list of just these method names, also..

obligatory sci-hub link:

http://sci-hub.io/10.1098/rspb.2017.1380

It can't be as simple as this appears to make out, right? Otherwise, it seems like you could just close one eye while reading..

Yes, but I've seen other people go through the same chain of reasoning, and make the same mistake (and this is what led me to write the article).

Personally (ignoring sugars) the 'MONO AND DIGLYCERIDES' is the bit I try to avoid, not worrying so much about the gums.

Mono- and diglycerides of fatty acids: https://en.wikipedia.org/wiki/Mono-_and_diglycerides_of_fatt...

Seems like this replaces hydrogenated oils across a whole range of products, and I'm suspicious that it's just a way to avoid public concerns about hydrogenated oils by replacing them with something similar just without the same stigma.

Quick search found this article, which states some more specific concerns, if in a rather extreme way: https://foodbabe.com/2015/07/31/theres-no-safe-level-ingredi... (but of course you can search and find similar concerns about many things, doesn't make them true).

I guess the ideal would be the possibility to see both.

One big reason to make compiler warnings fatal (not mentioned here, as far as I can see) is the fact that otherwise, unless you do a full rebuild, you won't see warnings for any source files that don't need to be rebuilt.

So there were attempts to make the calculations more useful, but that's not the only way to avoid this 'wasted energy'.

One alternative idea is 'proof of stake'.

And then it always seemed to me, also, that some kind of strategic partial centralisation could help make cryptocurrencies much more efficient..