I do not know about government work, of which government, and which laws...
We can be sure there won't be an issue with not passing
- You know the hardware you are targeting, it has predictible performance, and a standard refresh rate.
- You can identify when a frame is taking too long and have a commitment to fix it before release.
Or from the opposite point of view, not passing
delta has these possible drawbacks:
- If you decide to change the frame rate (e.g. porting to a different hardware, or if you want to make it match the refresh rate of the display) your code won't be able to adapt to that.
- When a frame is taking too long (either because the update code is a bottleneck, or because the OS/CPU/Other apps degrading performance), your code could not adapt to that. Arguably you might want this.
We can also argue that not using
delta has a benefit: update code is simpler (e.g. we assume a constant
delta, or hardcode values as if already multiplied by
delta), and since it would be doing less (less multiplying by
delta) it would perform better (if this improvement in performance is significant is a different matter).
Thus, not passing
delta is a good option on limited hardware with fixed specifications, in particular when the game is the only thing running on the system (which is the case of old consoles).
I see that in the code you post you call
draw every loop, thus the concerns about refresh rate might be mitigated already (I'm assuming
draw hides logic for swapping buffers, checking for VSync, or similar). Consider if you can save time in redundant draws by using a similar structure to the one you use for updates.
And about the updates, as I mentioned above, perhaps what you want is that updates to not adapt to the timing between updates. For example, if a particular frame takes longer, you won't see entities doing a big step afterwards to compensate.
You could pick some minimum hardware specifications below which your game is not expected to perform well anyway, so you can take that as your target hardware, and if you can assure that your updates stay within their allocated time on that target hardware (barring OS/CPU/Other apps)… Then if there are performance degradations, at least your game is not to blame.
Doing that might require (depending on your game and the target hardware) techniques such as:
- Limit the number of entities in the game at any given time.
- If you allow more entities that can be updated then each frame a different subset gets updated.
- Or you might have some have a simple update (e.g. keep going the direction they were) and some have a complex update (e.g. do path finding).
- Speaking of complex updates, you might want to write it a way that can be halted and resumed on the next update.
Notice that these and similar techniques depends on the game, and as such a general purpose game engine cannot make promises about them, so it makes sense that game engines give you
delta (another reason for engines giving you
delta is that they might allow to export your game to different hardware and operating systems).
I cannot tell you if that is OK for your game. And your government.
And I remind you to test.