Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard source for entropy #534

Open
MaxGraey opened this issue Aug 24, 2022 · 8 comments
Open

Standard source for entropy #534

MaxGraey opened this issue Aug 24, 2022 · 8 comments

Comments

@MaxGraey
Copy link
Contributor

Given that wasm4 is a rather very discrete system, it may not need access to a proper timer as suggested here:
#365

Instead of a timer, the vast majority of time user can simply use a game loop counter. In addition, on some systems (e.g. on some Arduino) the timer is simply not available.

But what is really needed is a seed to randomize the initial random state from run to run. Of course, you can use entropy harvesting tricks from user's input, but that's a waste of resources (time & wasm size) IMHO. While this could be delegated to the host via adding according API.

@hazeycode
Copy link
Contributor

It would be neat to have a w4.RANDOM_SEED.

But I'd really like a system clock or timer. There's many cases where this is useful and one doesn't want to assume that the game loop is called at a constant frequency. But I hadn't considered that this would limit compatible devices.

@ibillingsley
Copy link
Contributor

I just use a frame counter to seed the PRNG when the user starts the game from the menu screen.
In theory you can restart the cart and press start with precise timing to get the same seed, but in practice it's good enough for most games in my opinion.

@MaxGraey
Copy link
Contributor Author

I just use a frame counter to seed the PRNG when the user starts the game from the menu screen.

It's a good trick, but what if the developer decides not to do the menu at all, and immediately start the gameplay? And only during it bring the player to context (prehistory, control keys, etc.). Or another story, the developer would like that at each new start menu or splash screen would look different every time?

@ibillingsley
Copy link
Contributor

Fair enough, it would be a nice thing to have.

@desttinghim
Copy link
Contributor

I just use a frame counter to seed the PRNG when the user starts the game from the menu screen.

It's a good trick, but what if the developer decides not to do the menu at all, and immediately start the gameplay? And only during it bring the player to context (prehistory, control keys, etc.). Or another story, the developer would like that at each new start menu or splash screen would look different every time?

You could save the random bits to the disk to allow one player to get a different experience each time.

@MaxGraey
Copy link
Contributor Author

MaxGraey commented Aug 24, 2022

You could save the random bits to the disk to allow one player to get a different experience each time.

The problem is that it is not clear exactly when to do it. And in a way that is nondeterministic. And the user can close the tab / close app at any time. In addition, it looks very unobvious and hacky.

@desttinghim
Copy link
Contributor

The problem is that it is not clear exactly when to do it. And in a way that is nondeterministic. And the user can close the tab / close app at any time. In addition, it looks very unobvious and hacky.

I would save the random state every frame. The point is to maintain the entropy. It's not non deterministic, but it will make the randomness more varied.

I'm approaching this more from a "how can we work around this limitation" point of view though.

@TheRektafire
Copy link

Yeah I'd personally save the time since initial game start to disk every frame, it's about as good as having a timer since it could persist between game loads but doesn't require a hardware timer so it's more compatible I would assume

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants