Like a lot of issues in gamedev, pausing the game is a surprisingly difficult problem to solve.
It's especially difficult to provide a one size fits all solution which would obviously be desirable for the popular modern engines that try to be a general solution.
I see a lot of comments here saying something along the lines of "isn't it just a state in the state machine?" which isn't wrong, but is an extremely simplistic way of thinking about it.
In, say, 1983, you could get away with something like that:
- pause the game: write "PAUSED" to the tilemap
- paused main loop: check input to unpause
- unpause the game: erase the "PAUSED" / restore the previous tiles
But at that time you could already see the same sort of issues as today.
Something somewhat common in Famicom/NES games is the sprites disappearing when the game is paused.
Perhaps deliberate/desirable in some cases (e.g. Tetris) but a lot of the time, probably just a result of the 'is paused' conditional branch in the main loop skipping the sprite building code[0].
There's an extremely large problem space and ultimately, each game has its own way to define what "paused" actually means.
You might be interested in the features Godot provides[1] for this. Particularly, the thing that makes it interesting is the 'process mode' that each node in the scene tree has.
This gives the developer quite a lot of control over what pausing actually means for a given game.
It's not a complete solution, but a useful tool to help solve the various problems.
[0] Simplified description of course. Also, the sprite building code often ended up distributed throughout the various gameplay logic routines, which you don't want to run in the paused state.
[ed] Just adding that Tetris is only an example of a game where you might want that behaviour, not a comment about how any of the Tetris games were actually made.
I read your comment and the article and I’m still not really clear on why this isn’t as simple as saving the current state or pausing the render or time loop.
The short answer is: because of all the complexity that you're not seeing. I'll try to explain:
My '1983' example above is a simple way to implement a pause state -- when the game is paused, don't run the game logic.
The sprites disappearing that I described (a real quirk, if not a bug, of games of that era) is a side effect of that.
The sprites disappear because the set of objects to draw each frame is determined by the game logic, which is being skipped in order to pause the action.
Is it wrong that the game logic submits the drawables? I would say that it's inflexible, but not wrong.
After all, the sprites are representing the state of the game, so they must be derived from it in some way.
You can do more engineering to support a more robust & elegant pausing system. You can build that system such that pausing the game feels like simply "pausing the loop". But that's more code, more complexity, less simple.
I'm not exactly sure what "pausing the render loop" means to you, but let me ask you this: how do you render the pause menu? When there is no time passing, how does the little bouncy cursor in the menu continue to bounce?
You'd want sound effects to pause while the game is paused, and ideally resume from where they were when the game is unpaused. But does the pause menu make sounds? Is there music? Does the pause menu play different music or continue the in-game music?
And this is the most obvious, simplistic idea of what pausing the game is -- to show a pause menu. What about in-game cutscenes: do the NPCs in the background keep running around while you're talking to another one? Inventory management: the items the player has are a gameplay system but you access it while the game is paused?
This pattern applies to every system in the game.
You can't just cut out the xyz altogether, you need a sufficiently complicated xyz system in order to simply pause what you want to pause.
Saving the current state? What does that even mean? You don't save transient things like visual particle positions but it's something you expect to persist between pauses.
Pausing the render? But not the physics so you keep falling? You need to pause many systems. At the very least you'd want to pause gameplay, and sound and physics. You'd want to keep input and some of the UI unpaused. If you have a fancy UI with VFX, you need to make sure those are not using the paused game time. etc etc
And if you pause sound in Unity using AudioListener.pause = true, which is supposed to make life easier, but ends up being useless if changing settings/clicking buttons has audio feedback, or changing the volume has audible feedback to tell you how loud, or you allow to change voice style, and on and on.
Repeat that for every system - all those edge cases for each system can waste a lot of time and energy.
I'm not sure if you're saying that your suspicions were valid or not.
Suspicious of what, exactly?
Like, yes, the most likely people to respond to such a call for "stuff to put in an article on Kotaku" are probably developers that want some publicity.
But this is hardly surprising.
Yep, this comment does a good job of illustrating the (surprising) complexity of this.
I'll add that the notion of the "time scale" variable as mentioned in the article is something that's only solidified/codified since Unity and the like came about.
And at the same time, the way Unity et al. works[0] doesn't really encourage thinking about what I'd call "main loop logic" in the bottom-up way that's required to build a really robust system for managing states.
You can do it, of course, (you can write as much code as you want) but by default, everything in the scene is "active" and somewhat independent from everything else, and you don't have direct control over the various major systems.
[0] I guess I should say "worked" -- I mostly used 3.x and a little bit of early version 4 -- I'm sure it's improved but I wouldn't expect anything drastically different.
You would expect it to do that, and I'd say that's a desirable behaviour, but it's not really that simple and you certainly don't get that for free.
Typically any of the common modern engines with a "time scale" variable like that are not at all optimising anything in that way.
It's likely that the physics engine won't be stepped with a zero delta time, which will reduce the time spent on physics, but that's more of a byproduct of how physics engines work[0] than an optimisation.
You would have to go out of your way to capture the scene and display it "under the pause menu" in that way.
Not saying nobody does that, just that it's not something the engine is giving you for free nor is it related to the time scale variable.
Further, doing that won't necessarily reduce resource usage.
For example, if there isn't some sleep time inserted in the main loop when in a menu, or v-sync[1] to limit the framerate, the result of the simplified scene (just the menu and the quad with the captured scene) is an extremely high framerate, which may or may not cook the hardware more than the in-game load.
[0] Typical rigidbody physics engines are only (what I'll call) predictably stable with a constant delta time (same dt every tick). And a common way to manage this is with a time accumulator main loop, that only steps physics for whole units of dt.
[1] And v-sync isn't a silver bullet. consider refresh rates, different hardware, different drivers, driver overrides.
First off, I'm of course interested to see what the future infrastructure of software building next looks like.
> The hard problem is not generating change, it’s organizing, reviewing, and integrating change without creating chaos.
Sure, writing some code isn't the bottleneck. Glossed over is the part where the developer determines what changes to make, which in my experience is the most significant cost during development and it dwarfs anything to do with version control. You can spend a lot of energy on the organising, reviewing, patching, etc. stuff -- and you should be doing some amount of this, in most situations -- but if you're spending more of your development budget on metaprojects than you think you should be, I don't think optimising the metatooling is going to magically resolve that. Address the organisational issues first.
> This is what we’re doing at GitButler, this is why we’ve raised the funding to help build all of this, faster.
The time constraint ("faster") is, of course, entirely self-imposed for business reasons. There's no reason to expect that 'high cost + high speed' is the best or even a good way to build this sort of tooling, or anything else, for that matter.
Git's UI has become increasingly friendly over a very long time of gradual improvements.
Yes, Mercurial was pretty much ideal out of the gate, but the development process in that case was (AFAIK) a world away from burning money and rushing to the finish.
Yes, as I understand it, the ~700 MiB "standard" was derived from the capacity of a CD. A rip is definitionally a copy that lacks some of the original data of the source media.
"box with a hole in it" resulted in a number of boxes and most of these did obviously have holes in them. some did not appear to, but being that they were largely enclosures for some sort of device (as opposed to storage or transport) I'll assume there was some hidden fastener clearance holes or something.
I really only wanted one hole in my box though, so I adjusted the query to "box with a single hole in it". the results looked indentical. except for one that stood out. I would link to the particular model, but there was no way to do that. this model appears to be a rectangular bathroom basin, on its side. I'd describe it as perhaps a ~currently fashionable porcelain design, but it could be a concrete 'getting shit done' sink, or a model from The Sims (the first one). so box-like perhaps, but not many people would describe it as a box. I guess my search continues (elsewhere)...
(actually interesting bit about natural language: I know that a box with two (or more) holes in it has a single hole in it, but most English natural language parsers (humans) will notice that specifying 'single' would be redundant if I wanted any number more than zero, so it's extremely unlikely that I was looking for a multi-hole box.)
where did you steal the models from, by the way? just curious. the original context in which they were found would actually be helpful if someone was for some reason trying to actually use this as a tool. [ed: saw the OP's comment down the page -- you can include a comment with the submission IIRC]
also if you don't have the 3D model spinning incessantly, having the page open won't be obnoxious and it won't (have to) waste power
the recent google report claimed that less than 0.1% of users have javascript disabled ... like for every website, or just some, or?
your PNG/GIF thing is nonsense (false equivalence, at least) and seems like deliberate attempt to insult
> I'm marginally sympathetic
you say that as if they've done some harm to you or anyone else. outside of these three words, you actually seem to see anyone doing this as completely invalid and that the correct course of action is to act like they don't exist.
It would be literally impossible to know whether a user disabled JavaScript on another site, so I'm going to say that they meant that for their own sites.
> you say that as if they've done some harm to you or anyone else.
I was literally responding to someone referring to themselves as "collateral damage" and saying I'm playing into "Big Adtech's playbook". I explained why they're wrong.
> the correct course of action is to act like they don't exist.
Unless someone is making a site that explicitly targets users unwilling or unable to execute JavaScript, like an alternative browser that disables it by default or such, mathematically, yes, that's the correct course of action.
If you're reading past the first sentence this time -- it is obvious, yes. So why use such language to describe the software? Your deliberate choice to use misleading language is not only obviously incorrect, but harmful.
There has never been a qualification required to be allowed to build software for yourself. This is unlike building a house, which most jurisdictions recognise as something that should not be undertaken by someone without the ability to demonstrate a basic understanding of the process.
So, sure, once there's some bare minimum qualification that one must attain to be an "owner-builder" of software, do that. Until then, vibe-coding perfectly describes what vibe-coders do -- except for the vibes, which aren't (obviously).
I see a lot of comments here saying something along the lines of "isn't it just a state in the state machine?" which isn't wrong, but is an extremely simplistic way of thinking about it. In, say, 1983, you could get away with something like that:
- pause the game: write "PAUSED" to the tilemap
- paused main loop: check input to unpause
- unpause the game: erase the "PAUSED" / restore the previous tiles
But at that time you could already see the same sort of issues as today. Something somewhat common in Famicom/NES games is the sprites disappearing when the game is paused. Perhaps deliberate/desirable in some cases (e.g. Tetris) but a lot of the time, probably just a result of the 'is paused' conditional branch in the main loop skipping the sprite building code[0].
There's an extremely large problem space and ultimately, each game has its own way to define what "paused" actually means.
You might be interested in the features Godot provides[1] for this. Particularly, the thing that makes it interesting is the 'process mode' that each node in the scene tree has. This gives the developer quite a lot of control over what pausing actually means for a given game. It's not a complete solution, but a useful tool to help solve the various problems.
[0] Simplified description of course. Also, the sprite building code often ended up distributed throughout the various gameplay logic routines, which you don't want to run in the paused state.
[1] https://docs.godotengine.org/en/stable/tutorials/scripting/p...
[ed] Just adding that Tetris is only an example of a game where you might want that behaviour, not a comment about how any of the Tetris games were actually made.
reply