WOW! I had no idea there would be so much interest so quickly given the amorphous blob of an idea I was poking up at 1 AM local. I"m most amazed that I figured out how to render Liz speechless (Eben, I will reveal the recipe for the secret sauce for the princely sum of one mmmbillion dollars in small, unmarked bills … or a pallet of R-Pi boards – your choice ). I greatly appreciate all of the comments, and here are some quick thoughts in an interim response.
All code is not created equal and, as some have pointed out, the artistic elements are an absolutely vital part of the equation for any game. I don"t expect noobs to be able to jump into Open GL ES on Day One (although there is an amazing number of young teenagers doing some wonderful apps on iOS in Objective C, especially games using Open GL ES), or any other complicated parts of the code, especially the lower-level, critical-section stuff like network comms. However, I don"t envision needing to do much more than adaptation and building upon libraries of existing functionality.
As for the development language, for those who may not know, Python isn"t interpreted directly from source like your grandfather"s BASIC, it"s compiled to byte-codes that are then executed in a virtual machine, like Java, Pascal, Modula (IIRC), etc. A good virtual machine can have about 90 – 99% of the performance of the equivalent C/C++ code and, in most cases, the architecture of the software can have much more of an effect on performance than the language implementation (e.g., data structure design, network comms efficiency, execution path choices, etc.).
Also, Python can be extended using modules developed in C or C++ (and other languages, I believe), so, in those relatively few places where maximum performance is needed, that can always be done. The existing Python libraries already contain code written in optimized C/C++, and I strongly suspect that we won"t need to do a whole lot of low-level development, if any, unless we really go crazy (hmmm, with this group, we may already be waaaay past that point ).
As for verifying that an R-Pi is participating in a game, I believe there are a number of choices, and while MAC spoofing is possible under some circumstances, I seem to recall that there are ways to prevent it. That may require encryption, and I think IPv6 can be used as part of a solution (most network hardware made in the last 6 ~ 10 years works fine with IPv6, especially routers, switches, etc. – v6 wouldn"t be needed for actual routing of packets, just the verification part, with interrogation results encoded in the v4 packets. Perhaps it would only be done randomly on an infrequent basis (relative to network speeds).
Another approach may be interrogating the CPU/GPU for some unique attribute – we already know the Foundation has designed in interrogatable special registers (for lack of the correct term I"m too lazy to look up now) that can record whether the clock speed and thermal operating limits have been exceeded. I"m betting that there are some other unique read-only attribute bits that can be evaluated. Yes, there may be efforts made to modify the code to subvert these measures, but, with enough hashing and other countermeasures, we can make it not worth the while. It"s not like there are 10,000,000 credit card numbers waiting at the end of the rainbow (yet ). The R-Pi validation would be one of the last things to be implemented – it would allow people not using an R-Pi to play until they get hooked, then, "Gotcha! – now you have to go get an R-Pi board/box!" Oh, yes, Dr. Evil has his ways … MUUU-HA-HA-HA-HA-HAAAAAA!!!
The multiple worlds/solar-systems concept is very much in line with what I"m thinking, although we might need parallel universes if we"re going to have anything rated more than G (I"ve kinda grown accustomed to my clean criminal record, and I don"t want my first offense to be for distribution of porn to kiddies or, even worse, kiddie porn). The multi-world/galaxy concept will allow parallel development of mostly content, although perhaps we would want to have variations in the laws of physics and chemistry that would help kids understand how things work here in the Sol system and Milky Way galaxy, and what kinds of possibilities may exist elsewhere. It would certainly create all sorts of possibilities for game behavior and expertise gained in one area might be completely useless in others. The variations could be code-based (more educational for the kids to figure out how to program behaviors, not to mention noob adults), but, we can start out with attribute value editing of a baseline of universal constants and behaviors (e.g., what happens when you start mucking about with the gravitational constant, friction equations, electromagnetic relationships, etc.). Different worlds/galaxies could even feature different kinds of games built up from a core of gaming elements and tools.
I realize the peer-to-peer concept is so novel as to potentially being unworkable, but, I"m working off a hunch that it could be feasible with some careful planning. Think of a mesh of meshes of R-Pi systems such that the code and data automagically distributes among higher-level meshes such that it"s always completely replicated within a given mesh, but only pieces are contained on any given R-Pi node, and updates flow only among the super meshes where needed, and remain within a local mesh, normally. It would be similar to how proxy servers in clouds work now, but, I want to avoid the "C" word, as it can mean a lot of different things to various groups, and this wouldn"t be quite the same thing, as it"s not just files of mostly content being moved around. Consider how DNS data is distributed at various levels – there are something like only 15 ~ 20 master servers that are never queried directly by individual node computers. Requests for IP addresses are only forwarded up the DNS hierarchy until matching data is found, and updates are only propagated down the hierarchy when specifically requested from below. Yes, I know it"s more complex than that, with expiration tags, lookup rules, etc. I"m still heavily in hand-waving mode, right now.
This will be more of a system of systems, rather than a homogeneous collection of identical nodes. There will be distributed replication for redundancy, just not across even a majority of systems. A mechanism for how that distribution will occur will need to be developed, with some kind of statistical model, possibly combined with hashing to ensure completeness of redundancy.
There will definitely be solid APIs established early on, and I"m considering monotonic expansion, where older versions of APIs remain available as newer ones are introduced, so that, in the event of a failure, fallback can occur, albeit with potentially less functionality (e.g., values only used in a newer version of the API are ignored). I know various programming languages have different mechanisms of varying capability for this, but, I"ve spent a fair amount of time making code written in more archaic languages behave as if it were developed in more modern languages or dialects (object-oriented FORTAN, anyone? ).
As for tools, they don"t have to all run on the R-Pi boards (and, for now, _none_ of them _can_ run on the boards ), so, it"s perfectly OK to develop on the latest-and-greatest systems we each have, for both software development and content creation, then port when needed. Since many of us have the R-Pi running in emulation, we"ve already got targets that should provide 99.9% of the fidelity of the actual boards, modulo performance differentials. The GPU is probably at least as capable as those in any of my systems, and only one of those is rigged with HDMI out – I"m not even sure it can do native 1080p30fps without occasional glitches (I"ve spent way too much of my career wringing every last bit and cycle out of already blazingly-fast hardware to be able to enjoy mucking around with the resulting video output ).
My coding style tends to be verbose with comments and meaningful code and data structure naming. My prolific posts should provide some hints about my ability to document until well past when the cows come home, are resting comfortably in the barn, have something interesting tuned in on the large-screen TV, and are munching on tasty snacks … oh, it"s dinnertime, no wonder it feels like my blood sugar is sagging and my mind is going, Dave, I can feel it … I generally try to be cheerful and give others the benefit of the doubt, but, sometimes my wry/sarcastic humor isn"t received as intended. I can be a sergeant-major of a taskmaster, but, I really don"t like it at all, and would much rather work with other self-motivated folks who know how to play well with others. I like to think I can do the "vision thing" somewhat better than average, but, I know when to hold "em, know when to fold "em, know when to walk away, and know when to run, when a better idea enters the room.
There was mention of centralized servers being necessary for the code repository, at a minimum, with the implication that we might as well just also use them for the games, too, but, I"m not sure either of those assumptions is true. I"ve had this idea rolling around in my head for years that code and data can automagically distribute themselves sufficiently to ensure multiple redundancy across some percentage of supermesh systems, without everything needing to be replicated at all nodes, all the time. The latter has been the reason for failure of a number of very high-profile, very large network-distributed systems, where all of the network resources wound up oversubscribed with updates continuously flying all over the place. Careful study of how the TCP/IP packet-switched architecture works is fascinating, particularly distribution schemes where a packet has multiple destinations and duplicate path transmissions need to be collapsed down to just one.
This hasn"t addressed everyone"s comments, it"s too long already, there are lots more very interesting ideas buzzing around in my head, now, and I need to follow the links you"ve provided as examples/candidates. So, I"ll start building up some wiki pages where we can begin capturing ideas and organizing them in order to have some glimmer of hope of ever later finding any of the actually useful ideas that may find their way here before they sink into forum Oblivion.
Thanks again for your thoughts – "To Pi-finity and Beyond!", indeed. Hmmmm, I think we have at least an interim working name for the game system … "Pi-finity!"
The best things in life aren't things ... but, a Pi comes pretty darned close!
"Education is not the filling of a pail, but the lighting of a fire." -- W.B. Yeats
In theory, theory & practice are the same - in practice, they aren't!!!