Re: Earwax
@92
I don't have an article. And it's not, exactly, that they're bad. But suppose I do:
def enemy():
target = figure_out_target()
yield sleep(5)
kill(target)What happens if target died while it was sleeping? In general the problem with continuations is that after every suspend point, you have to assume that the entire state of the world changed out from under you, because it very well might have, and make extra sure to check. The only difference between this and a thread is that you get to control where it suspends, which can be nice because it avoids mutexes and things, but you still have the "other threads might have done something" problem. They can be used effectively, but you have to be careful about how. For example, this:
def create_player():
name = yield name_dialog()
class = yield class_dialog()
starting_eq = yield_starting_eq_dialog()
create_player(...)is good: you don't care about the state of the world until you're at the end, and you own everything you care about in a way that another thread isn't going to come in and smash. Also, yes, you can assign values as the result of yield statements. But irregardless, the key thing is: you have to think about these like threads, and all those concerns apply. You can't just go apply them to everything and be happy.
In networking land, they're great because in networking land there's not that much shared global state, so you get faster context switches and things and there's no real issue. They're definitely not slower. It's just that once you have lots of shared state, you have to do a lot of thinking. If you do it as finite state machines and stuff instead, the parent game loop can control the order: run all the stuff for physics, run all the stuff for player input, run all the stuff for AI. But if there's just some coroutine soup, which is what you're proposing I think, it can all just run in some jumbled order and you don't know. Maybe you unsuspended halfway through a physics update.
It works out well for Moo because Moo is about room-local state that isn't shared, 99% of the time you just do messages with delays or whatever and then do something at the end. But in general I wouldn't go "This worked for Moo, therefore..." If you look around at Moos where someone tried to build a game with them, as opposed to a shared social thing like Lambdamoo, they're even less stable than the C codebases. It's the perfect example of someone writing something, and then other people taking it waaaaay beyond where it was ever intended to go. Plus it was done in the 80s, before threads were even really a thing, and before anyone had experience with the things that it chose to do (i.e. I don't think version control was even a thing yet, so "we'll just edit in realtime" seemed amazing).
For docs, you need to figure out how to get Synthizer not importing on Linux or something: I doubt readthedocs or whatever will let you apt install stuff, so even if I fix that story you're likely to still be kind of stuck. As I said manylinux1 will probably happen eventually but key word on eventually; even once it's building on Linux, manylinux1 is kind of special. There has to be some Python way to deal with this, I just don't know what it is.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
