First of all, congratulations on getting THE idea, I think user content is essential too, but I see why commercial games shy away from it 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 fashion. p.s. I'm not an expert on pypy yet On 9 January 2011 21:24, Nathanael D. Jones <[email protected]> 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. > HogwartsLive.com and lotgd.net 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 > http://nathanaeljones.com/ > > > > _______________________________________________ > [email protected] > http://codespeak.net/mailman/listinfo/pypy-dev > _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
