First of all, congratulations on getting THE idea, I think user
content is essential too, but I see why commercial games shy away from
 An open source game could do really well!

1, yes, but not in a way you want (you want many boxes that can't
touch each other, right?)
2, yes, stackless is the name/misnomer
3a, I doubt is relevant, you have to show that your workload has a
substantial number of tail calls; stack depth is not that important
with stackless.
3b, I imagine this is impossible in general case, how do you see this
done in any language?
3 again, yes of course, and I bet you knew this already.
4 indeed, unloading old code is a bit harder as you have to make sure
all references to module or function or class are lost in timely

p.s. I'm not an expert on pypy yet

On 9 January 2011 21:24, Nathanael D. Jones <> wrote:
> Hi folks,
> I've got a challenging set of requirements that I think PyPy may be able to
> meet, but I'd like to get some feedback before I jump in.
> I'm developing a collaboratively edited game. It's not a MUD, but similar in
> concept, and also text based in nature.
> and are examples of the genre I'm going for.
> I believe if a game of that genre makes user modification simple and
> rewarding enough, it could be self-sustaining and grow quickly enough to
> keep users interested perpetually, like Wikipedia.
> It's also a fascinating computer science challenge, because it requires a
> LOT from a computer language.
> 1) Sandboxing. To allow users to make changes to the game without being able
> to "cheat" at it or escalate privileges.
> 2) Serializeable continuations. With gameplay being based on good plot and
> story flow, continuations are critical to allow straightforward
> implementation of 'workflows' that depend on user choice at every turn.
> 3) Tail-call elimination.  By nature, players will accumulate a very large
> call stack. While this isn't terribly bad a first glance, the following
> issue combines with it to cause a very big problem:
> When code changes underneath a continuation, we need to determine how to
> resume flow. One option is annotating a checkpoint method in each code
> 'file'. However, if a user's call stack includes every file in the system,
> each change will cause them to restart.
> Tail-call elimination would help eliminate unneeded stack frames and
> minimize re-spawning.
> 3) Dynamic, strong typing and metaprogramming are key for keeping the API
> simple.
> 4) Dynamic code loading. Users will be able to 'branch' their own version of
> the world and share it with others. There may be thousands of versions of a
> class, and they need to be able to execute in separate sandboxes at the same
> time. Source code will be pulled from a Git repository or some kind of
> versioning database.
> I'm interested in knowing which of these PyPy already does, and which of
> them I can make it do.
> I appreciate your help!
> Nathanael Jones
> _______________________________________________

Reply via email to