Entropy Engine producing seeds for procedural game mechanics — feedback wanted

If this is meant to be commercial proprietary middleware, I personally would never commit to such a thing. What I've observed over the very long haul of commercial game maintenance, lasting multiple decades, is that proprietary solutions derail anyone's ability to use and modify the IP.

For instance an example in Sid Meier's Alpha Centauri: they availed themselves of a proprietary voxel rendering engine for their unit artwork. Might have seemed like a good idea in 1999, when 3d graphics hardware wasn't as widespread as it is now. Well the company folded, and nobody's ever managed to reverse engineer the voxel format. Someone partially figured out a way to modify the texture maps that the artwork uses, but that's it.

So basically I regard this kind of proprietary "convenience" library, as a bomb waiting to go off decades later. Not everyone may have the same long term development sensibilities though.

I'm also not sure, why sharing random seeds would be hard for anyone to do? Maybe I'm just a very technical guy, but it seems like something I'd put in a save file, if I wanted it. Doesn't seem to rise to the level of a 3rd party solution.

My engine just groups together open Quantum Computer hardware portals like IBM, Amazon, etc to so software/game developers can use the engine to get their seeds from a truly quantum source and I'm setting up a game/app marketplace next week on my site where users can post or download apps or games using quantum backends.

The apps like a quantum dice app are simple and just a fun way to experiment with quantum hardware in games and app designs for consumers and the code and seed is self contained so it should still work in 20 years if IBM goes kaput!

Why would I as a game developer need quantum randomness, as opposed to a robust pseudorandom number generation algorithm like https://en.wikipedia.org/wiki/Mersenne_Twister ?

Fair points, and I’ll concede both: for the RNG stream, Mersenne Twister (or PCG) is the right call, and for seeding, /dev/urandom is unpredictable, free, and local. I’m not claiming a game needs quantum bits to be “random enough” — a CSPRNG off the OS is fine for basically any game.

The pitch isn’t better randomness. It’s verifiability. urandom is unpredictable to me, the operator — but a player can’t check I didn’t cherry-pick the seed afterward. For provably-fair draws or a shared daily seed everyone must agree on, the value is an external, auditable source neither the house nor the player controls. That’s a trust property, not a quality one.

Solo game? You’re right, urandom → MT and quantum adds nothing. It earns its place only when “trust me, the seed was fair” isn’t good enough. (And no, it’s not fully trustless either — a hash-commit scheme or on-chain VRF goes further; this aims at the “external shared seed” tier, not full crypto commitment.)

artphorm wrote:

the value is an external, auditable source neither the house nor the player controls.

If it's a gambling game for real world money or equivalents, and laws are involved, maybe there are rigors of verifiability I'm not anticipating.

If it's just a competitive game, perhaps Player vs. Environment and the "house" is handling the latter, it seems as the developer, they have numerous ways to cheat anyways. If you think the devs running the servers are scummy, why or how would you trust them? For a legally limited gambling game with rather severe constraints on what randomness can do, yeah sure, perhaps you could audit that. But what if it's how badly a torpedo is gonna damage your warship? I the dev might just rubberband you, in the interest of drama. Oh you're doing too well, I think your randomly generated explosion will be bigger. All kinds of ways to fudge. What as the player could you do about it, other than quit the game and play something else?

What if you're doing a military sim and you want an audit of every... single... phenomenon... in... the... sim. Well maybe a defense contractor might be willing to spend those kinds of computational resources, who knows. But just a game for consumers? I'm not seeing it. Verifiability takes a back seat to performance, lobbying, all kinds of other considerations.

If players are complaining about aimbots, surely an external RNG verifier isn't needed to detect that.

totally fair points im havent reinvented the wheel just thought itd be fun to try and start playing around with connecting games back ends to real quantum hardware and honestly an entropy engine with a dashboard showing feeds from Amazon, IBM, etc just seemed fun and cool and next week on my website i'm launching a free app/game marketplace where im hoping people will use quantum hardware portals i can hook up to the site to try and build weird fun apps and games as an umbrella for opening up some of this fascinating tech in a fun accessible way.

You know you're stuff obviously and I'd love to see what someone with your background comes up with for social media or gaming using quantum hardware - get weird with it like MTV was when it first started playing music videos.

Be Quantum Devo and blow some minds! i'm not looking to get rich just weird with software.

artphorm wrote:

Be Quantum Devo and blow some minds!

Reading through some of the RNG stuff about Mersenne Twister etc., I found the tests used to prove bias in the RNGs interesting. Seems you could come up with something pretty lopsided if you started with a small amount of data. Didn't quite understand the formalisms but there was a stark contrast between MT and "better" more recent algorithms in this regard. Having a bunch of different RNG algorithms available side-by-side to feed some artwork generation, might be mildly interesting.

On the more gamey side, a combat resolution for a wargame with units and so forth, might be interesting to see if different RNGs give different results.

Nice!

What role does entropy play when you’re sharing a seed based on day, instead of second (like with C++’s time())?

On the 1st day of Christmas my true love gave to me

A bugbear in a pear tree!

On the 2nd day of Christmas my true love gave to me

Two doppelgangers and a bugbear in a pear tree!

Nice!

LorenzoGatti wrote:

To the nonrepudiation challenge — this is the strongest critique in the thread, and he’s largely right, so concede and narrow:

Fair, and mostly right. A central server signing a pre-committed seed is the standard nonrepudiation move, and for most games it’s the correct one — I’m not claiming otherwise. Two honest distinctions: (1) A signature proves the server didn’t change the seed after publishing, but not that it didn’t grind the seed beforehand — generate thousands, sign the one that favors the house. An external source the operator doesn’t control removes that pre-selection freedom, which a self-signed seed doesn’t. (2) You’re right that no third party is fully collusion-proof — that’s why I don’t pitch this as trustless. It’s a “reduce how much you have to trust the operator” tier, sitting below a full commit-reveal or on-chain VRF. And your parenthetical is correct: a plain date-hash seed is previewable, which is exactly why I don’t use a bare date hash. Quantum for the seed, PRNG for the stream.

Why can't the house just submit 10 billion requests to your service, then cherry pick whatever results it likes? It could justify the number of requests by saying they're a high capacity server with many players. Once they've got all those requests from you, they can just sort them for what they want to pass on to the players.

If you are going to directly provide requests to players, so that the house can't do that, why would anyone trust that you as a company are capable of doing so at scale? Why would anyone want to entangle themselves with the performance needs of all games that use your service? If it gains substantial adoption, then everyone wonders how you're going to build out your service. Starts to sound like an enterprise class service, and you're just 1 guy.

Do you even want to spend your life becoming the kingpen of randomness verification on the internet? Most people would expect you to get bored in a few years, especially if you "weren't trying to get rich". Then that's that, it doesn't work anymore.

taby wrote:

What role does entropy play when you’re sharing a seed based on day, instead of second (like with C++’s time())?

The switch from per-second to per-day isn’t about entropy quality — it’s about making the seed shared and stable. C++‘s time() gives a new seed every second so each player/session diverges; a per-day seed means everyone gets the same daily value and the same procedural result, which is the point for a daily puzzle. The entropy source (quantum or otherwise) only decides which value that day lands on and whether it’s predictable in advance. So: per-day = shared determinism, entropy = unpredictability of the pick. Two independent knobs.

Both of these land, so let me take them straight.

The cherry-pick attack is real — and it’s why “the house pulls a seed from an API” was never meant to be the trust mechanism on its own. If the operator can request 10 billion and pick one, verifiability is zero. The fix isn’t the source, it’s the protocol: the house commits publicly to a specific seed reference before the round (a hash, a timestamped draw ID), then reveals it after. Grinding dies because they’re locked to one value in advance, in the open. An external timestamped source just makes that commitment harder to fake than a self-signed one. Without commit-reveal, you’re right — quantum or not, it proves nothing.

The scale/business point is fair too, and I’m not going to pretend I’m an enterprise. I’m not trying to be the RNG backbone for “all games” — that would be a doomed solo endeavor. The realistic scope is small: hobby projects, jam games, provably-fair indie experiments, daily puzzles — cases where a shared, auditable seed is a nice-to-have, not a five-nines dependency. If something needs guaranteed uptime at scale, they should self-host a commit-reveal or use an on-chain VRF, and I’ll say so in the docs.

And “do you even want to be the kingpen of randomness verification” — honestly, I thought I was already the king of random i do incredible improv comedy and the engine’s a seed layer under an app ecosystem I’m building; the verification angle is one property, not my life’s mission. If it stays small and useful, great. If it doesn’t, the games still work. Appreciate you actually pressure-testing it instead of shrugging. You are officially hired as the VP of randomness verification.

I have a job now? Lol. Anyone ever bothers me about it again, that's what I'm gonna tell 'em.

So basically, you’re using the word entropy because it’s a difficult to understand concept… because it’s the cool thing to do.

You can create synchronized shared experiences by using a hash of the date as the seed. No distribution mechanism required.

alvaro wrote:

You can create synchronized shared experiences by using a hash of the date as the seed. No distribution mechanism required.

Is it acceptable for 3rd parties to be able to know the hashed value in advance? A binary hacker could extract the hash function from the game code. A non-hacker could make an educated guess about the hashing algorithm used and match the game's output with their own implementation of the algorithm.