If I didn"t already type it out loud (some things that are clear to me in my head haven"t magically appeared in others" heads if I haven"t actually posted them, for some reason), I am planning on everything being located in Real Universe 3-D space, so, that could be our means of resolving conflicting world locations (stake yer claims, Klondikers!). Per Steve"s observation, there can be solar systems with planets, and there have been only a couple of thousand planets detected within a few thousand light years from Earth. There are an average of three planets per star detected so far, so, there are somewhere around 299,999,998,000 other potential undetected planets just in the Milky Way galaxy. How many bits do we have in a 32-bit address space – only ~4 billion? We"re gonna need a bigger address space, Cap"n Quint … declare type long long int of 64 bits just for each world"s unique ID. Yeah, I know, I like to think big, but, who would have thunk three months ago there might be a million people waiting to receive a Pi?
If we really are going to have so many worlds, we may need to come up with an automated planet surface modeler/renderer where players can select general characteristics and the planet"s location relative to its star would influence its structure. For example, inner planets tend to be smaller, rocky worlds with potential water in liquid/vapor form, while outer planets are gas/liquid giants with icy moons, or ice dwarfs. This is probably one of the things we can worry about later, but, part of the fun of working on this kind of project is being able to take a break from the hard-core code stuff and enjoy playing with the graphics.
Another inspiration for Pi-finity! visuals is the astronomical simulation/exploration software from CelestiaMotherlode.net, which features planet models with image maps as large as ~86,000 pixels in circumference derived from Hubble Space Telescope and interplanetary probe images such as Voyager, Magellan, Cassini, etc. (most planetary image maps only contain 1,024 pixels, such as my WebGL demo). Celestia has a plug-in architecture for add-ons that can be independently developed, and there are even 3-D models for actual satellites and probes, as well as fictional models inspired by "2001", "ArcBuilders", "Babylon 5", "Orion"s Arm", "Star Trek", "Star Wars", etc. (all work and no play makes Jack a dull astroNut
).
When a world is created, the data needs to be propagated to all of the nodes in the mesh (if a centralized server is not used), but, when we"re just starting out, how is a mesh formed? We would include the P2P code (based on, if not actually a standard torrent client) in the installation and one of the installed files shared would be the tracker file with all of the IP addresses of other nodes that have downloaded and run the installer. Then, the new node adds its address to the tracker file, and the updated file is shared with some number of other nodes in the tracker file at some minimum interval (once a minute, or a few?).
This is a bit different from existing torrent behavior in that nodes would need to notify others that a shared file has been updated, then they initiate a broadcast request for the file, but, only a version with the latest time specified in the notification. There"s probably some risk of a circular race condition happening if some data is dropped or delayed, so we may need to use a small random delay, similar to how packet collision back-off algorithms double the timeout with successive collisions, plus a small random delta by each collider, to offset their respective next attempts.
Yes, as hard as it might be to believe, none of the kernels available for our Arm11v6 CPU was built with floating-point hardware support, but, we have to remember that the BCM2835 SoC the Foundation selected (used in the Roku 2 series of media streamers) was designed specifically for streaming digital video and audio from network sources, with minimal user interface and housekeeping performed by the Arm CPU. It was never envisioned as a general-purpose computing platform – the CPU doesn"t even boot from the SD card, the GPU does! Since OpenGL and OpenVG APIs are provided into the GPU, access to all of the floating-point hardware capability we could want (even for much more than $35) is available, but, we may have to take over the system, rather than run within X via LXDE, etc., at least until the kernel mavens figure out how to integrate GPU acceleration into the kernel for X support. Actually, that may not be a problem because running on top of anything else like X and a desktop just means that much less RAM will be available to us, and we"re going to need every bit we can in order to pull off this project at the lofty levels I"m dreaming might be possible.
The RAM constraints mean implementing at least some of the infrastructure in C is probably advisable, and we may need to be careful about just glomming a bunch of libraries on from which we may only need a limited number of functions. We may need to cull just the code we need, which will also reduce the SD card footprint, although, even with a 1 or 2 GB card, there"s still an insane amount of space available since 3-D models tend to be only hundreds of KBs in size, and even the 1,024 pixel image maps are only around 100 KBs. If we do need card space, we can also remove the vast majority of the release cruft not needed by the game, resulting in a Puppy-like svelte OS baseline. We can always wrap the C code in Python as modules that will be easier for our less-experienced team members to use, not to mention us Brainiac developers typically working late in our spare moments not needing the headaches associated with misplacing pointers and mangling memory management.
The point about a spacecraft/station being a "world" is a good one – "Deep Space 9" was nowhere near any planets, Class M or otherwise, to which they could beam poor, hapless red-shirts to live out the brief rest of their lives before being turned into freeze-dried little piles of their constituent chemicals.
I think it"s perfectly fine for each of us to do some experimentation at this stage, and it doesn"t really need to mesh together until we have some hardware to try out the more performance-challenging aspects of what we want to do. In fact, I would prefer each of us owning independently buildable modules that share data both locally and over the network through very clean, well-defined interfaces that are self-describing. For example, named-slot/value structures and protocols could be used, at least until we know what we really need, and then we can collapse things to type-order based signatures as in traditional function/procedure/method calls and protocol block-order streams. I think I"ve said before that I"m not looking to build a singular, gargantuan monolith of tightly-linked code that would take hours to build each time we all submit a bunch of changes. Doing resource critical stuff in C and then the bulk of the functionality in Python will make it easier to maintain that loose coupling. The protocols will be the key, and it"s going to take a while to iron out how those should work, after we have the data structures for shared information figured out.
It would be really cool if, in the process of building this, we managed to finally crack the nut that makes building 3-D games, and games in general, too hard. I"ve always admired Pinball Construction Set and similar drag-and-drop configurable games from the late 70s or early 80s, that provided the ability to design games via pinball primitives like flippers, bumpers, spinners, poppers, lights, lanes, plungers, rollovers, etc. If we could come up with something even a fraction as easy to use, we would really have something, even if there is a whole lot more to do and will take quite a while to get so many elements figured out.
To dream, perchance to snooze!
).
).
) and we"ve ported a Panda3D client to the Pi, we"ll be ready to do some alpha testing with non-developer players (I"d guess sometime in June, based on the latest info from the distributors).