Fandom

Pi-finity! Wiki

Pi-finity! Requirements Specifications

4pages on
this wiki
Add New Page
Comments0 Share
Rotating Raspberry Pi Logo

2012-04-04

  4
 44
4 4

44444

  4

Prime Directive: If we are not having fun, we are doing something wrong.

Secondary Directive: In all other cases, see the Prime Directive.

Below are the requirements specifications in bullet form, and they are subject to change without notice (but, we will make reasonable efforts to provide advance notice). Beyond the bullet points are the original posts by RaspberryPi.org forum members who contributed ideas (thanks very much, in order of appearance: Davespice, fox1t, ashleysands, SN, Liam Fraser, jacklang, n3tw0rk5, geeus, liz, Gert, SiR, Dinosaur, mole125, greenglue, Robert_M, Robert, PiOfCube, mkopack, hippy, scifi, DataSpree, pythagoras, colincoach, Wolfpaw, RaTTuS, yaccin, DannyG, mightymik, IzitTech, NegentropicMan, moldovan_catalin, Rivalo, and HeadCase, DannyG, samarthwiz, dhicks, droidix - if I missed you, I apologize and please let me know).


REQUIREMENTS SPECIFICATIONS FOR Pi-finity! A GAME DEVELOPED SPECIFICALLY FOR THE Raspberry Pi (TM) COMPUTER

. Pi-finity! will be the working name for this project, unless and until another name is chosen by a consensus of the developer team.

. Pi-finity! will be developed for educational purposes first and foremost. The target of this educational effort will primarily be school students at all levels and, secondarily, the public at-large as developer time and other resources will allow.

. Pi-finity! will be developed in a friendly, cooperative environment where participants will need to maintain a passing grade in "Plays well with others", which will be determined by a consensus of all other participants. This will be a public activity which, if done right, will likely attract a lot of attention, including from the media. It will also be focused on educating students of all ages, so, all public communications should keep that in mind at all times. There are bound to be disagreements among very talented, passionate people and we will need to work those out amicably, usually by a consensus of the participants. In the case of a serious disagreement that can't be resolved otherwise, Jim Manley in his capacity as Project Founder, Chief Architect, and Benevolent Dictator Only When Necessary will make a final decision that will be respected by all participants. Any attempt to stage a coup will result in severe punishment involving being slapped with very large halibut along the edge of Teddington Lock. Just checking to see who's actually reading this blather.

. Pi-finity! will only run on Raspberry Pi (TM) computers. This is a point under discussion, and perhaps only more popular features will require use of a Raspberry Pi (TM) computer, or performance of the user interface will be best on a Raspberry Pi (TM) computer.

. Pi-finity! will be a highly-distributed, user-extensible federation of game elements, possibly heterogeneous, where common basic data structures, actions, and communications protocols are used among all elements, but, higher-level details may follow a variety of divergent directions that may include compatibility with elements from existing game systems outside Pi-finity!

. Pi-finity! will support an unlimited number of users, as in a massively multi-player on-line role-playing game (MMORPG), but, it may be extended to support perspectives beyond traditional MMORPGs, such as first-person, over-the-shoulder, isometric fixed-position, and God's eye views. Eventually, it is envisioned that many, if not all, game genres will be supported through a variety of potential means. For example, a classical video arcade, console, or PC game might be played on a virtual arcade, console, or PC game machine created in a Pi-finity 3-D world, and the game would be viewed as a 2-D display, with player input via keyboard, mouse/trackpad, or game controller, as appropriate. Winning or achieving a particular level in the classical game might result in receipt of an award in the form of points, virtual coins, or objects that could be used in the Pi-finity! world, or entire game system, if compatible.

. Pi-finity! will be developed by Raspberry Pi (TM) users and other volunteer personnel and all software will be published as open-source material. However, the Pi-finity! software will be copyrighted to ensure that exclusive control cannot be claimed by singular entities such as individual persons or corporations without legal agreement of a majority of the developers of software and data created specifically for the Pi-finity! project, in proportion to the contributions of each developer by lines of compilable and executable source code and object definition data accepted into the public distribution repository (potentially hosted by the Raspberry Pi (TM) Foundation).

. Pi-finity! will use network-distributed data sharing to disseminate updates on object states, object descriptions/definitions, etc. Data will be disseminated among network "meshes" of Raspberry Pi (TM) computer "nodes" that are participating actively in a local interaction. A hierarchy of meshes might be formed on an as-needed basis when the number of nodes participating in a local interaction would result in overloading of the network, processor, and RAM resources in the nodes in a local mesh. Persistence of object states and descriptions/definitions will be maintained on the node of the user/owner/creator at a bare minimum, and will be replicated on other nodes in a mesh, and hierarchy meshes, as needed. When the local storage capacity is close to being exceeded on a node, the least-recently-used data for objects replicated from elsewhere will be deleted unless it has been flagged by the node user to be maintained.

. Pi-finity! will use the minimum amount of computing resources possible, particularly RAM. Depending on computing load, virtual memory may be used to off-load non-critical code and data to SD card or external USB storage devices (e.g., hard drives).

. Pi-finity! will support 3-D graphics and multi-channel audio to the full capabilities of the Raspberry Pi (TM) computer. However, there may be game elements where the number of dimensions, colors, pixels, audio channels and spectrum, etc., may be reduced for artistic effects and desired game play behaviors. For example, an SDTV (4:3 aspect ratio) 2-D, gray-scale, monophonic experience mimicking "black-and-white" television shows may be desired. Or, players could find themselves in a low-res world with blocky graphics featuring a limited color palette reminiscent of classical video games.

. Pi-finity! will leverage existing open-source software developed outside the Pi-finity! project development team as much as is possible. Existing non-Pi-finity! project software may need to be modified, extended, or both in order to be compatible with, and useful for, the Pi-finity! project. "Wrapping" of existing code may be used to create a consistent set of interfaces between software modules derived from various legacy code bases, as is sometimes done with Python.

. Pi-finity! will be implemented in Python as much as possible since that is the programming language currently being considered by the Raspberry Pi (TM) Foundation for its other educational efforts. If performance or resource utilization requires it, use of other programming language(s) such as C, C++, Java, or assembly language will be pursued as needed by a consensus of the Pi-finity! developers.

. Pi-finity! will ensure data integrity errs on the side of duplication rather than accidental deletion such that data is always redundantly replicated in at least two places at a time, e. g., the client/owner node and a network-adjacent node.

. Pi-finity! will implement security such that no player can alter the state of another player's internal character data, e.g., location, health, rewards/coins/equipment/objects earned, etc., via direct access to the owner's node data store. Only valid, player-directed interactions between characters can result in changes in a player's character's state.

. Pi-finity! will provide automatically-generated characters that use artificial intelligence to seek out and interact with actual players' characters. This will also be used to test the system for loading purposes.

. Pi-finity! will allow a player (who must be a node user/owner) to create any number of characters and can control them separately or collectively in any-sized group. Any character can be either active and able to participate in a game, and visible to other characters, or inactive and be unable to participate in any games, and be invisible to other characters.

. Pi-finity! will use geographic proximity to determine whether any pair of characters are close enough to sense and interact with each other. Being in the same world is not sufficient to allow sensing of and interaction with one another.

. Pi-finity! will provide means for sensing of and interacting with other characters. Sensing will include visual, aural, touch, and smell. Interactions will include calling, responding, giving, receiving, blocking, striking, and falling down.

. Pi-finity! will use the data contained in the node used/owned by a player to determine the state of a character. This data will be replicated to other nodes in a mesh via peer-to-peer (P2P) data replication mechanisms. This is the sole means for tracking the physical, geographic, and communication relationships between characters.

. Pi-finity! will provide a mechanism for mesh membership. It will be allowed or prohibited by the founder/owner of the mesh after an announcement of intention of a character to join the mesh. The default process will be to allow entry into a mesh, but, this can be set to require permission to join. At any time, the owner of a mesh can revoke membership of another character in the mesh.

. Pi-finity! will provide a mechanism for

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

. Pi-finity! will

MUCH, MUCH, MORE TO COME



Original posts from which requirements were identified:

The evidence keeps mounting that yes, Virginia, there really are 10,000 R-Pi boards Out There and we can now increasingly hope that hundreds of thousands more will be delivered over the next few months. As this growing reality has started to sink in, I"ve begun thinking about some very cool things we could all do with each of our boards that would nicely demonstrate its many capabilities, encourage everyone with a board to participate and learn how to work cooperatively on a large computing project, and establish a real community of users that can bring us all closer together.

It soon occurred to me that one approach might be to establish an R-Pi massively multiplayer online role-playing game (MMORPG), since you can"t get much more massively multiplayer than hundreds of thousands of rabid R-Pi fans looking to share their newfound infatuation.

Eben and the team have demonstrated Quake 3 running on a prototype board, but, it had issues that I don"t think have been resolved, yet (some excuse about pesky prospective customers with torches and pitchforks marching on the castle needing to have hot oil poured on them ). However, even after the client is debugged, establishing and supporting Quake 3 servers for hundreds of thousands of players probably isn"t something very many are willing to do on a volunteer basis and donating resources.

So, after a few more moments of thinking, it occurred to me that it would be really cool if we developed one, or more, MMORPGs unique to the R-Pi community that could only be played on R-Pi systems. Since the preponderance of comments suggests that there is a lot of experience with Python, and that contributors without much software development experience might be able to come up-to-speed the fastest using Python, which does have extensive libraries available that should provide all of the functionality needed to build games (I seem to recall that some work may need to be done for full 3-D graphics support via the GPU). It"s been quite a while since I"ve done any game development, but, I do have pretty extensive 3-D graphics and network-distributed computing experience, specifically in modeling and simulation and virtual reality for application areas like military command and control, communications, intelligence, and computing. I"m assuming that there is a fairly extensive open-source game code base we could draw upon from a variety of places, and I"m sure there are plenty of experts here that can help get things organized fairly quickly.

I haven"t thought much about what kind of game would be both popular and appropriate for all ages, given that the focus of the community is supposed to be educational. So, a first-person shooter is probably out, unless the weapons operated non-violently (think ammunition like Silly String, whoopie cushions, popping balloons, bubble gum, etc.). A purely fantasy-oriented game featuring unicorns and rainbows might not be as popular as other genres, although something that combines humor/silliness with more traditional features might turn out to be very popular. Perhaps a melding or updating of classical early computing games with modern graphics capabilities and techniques would be the ultimate tribute across the years. Think Breakout/Brickout in immersive 3-D, Grand Theft Auto with Zelda characters and behaviors, Donky Kong in virtual reality, Super Mario Brothers as a space quest, a Zork adventure game with hundreds of thousands of players, etc.

I haven"t looked closely to see if an appropriate game engine already exists, but, I have a gut feeling that some sort of peer-to-peer means of sharing parts of the game landscape among players active in given virtual geographic areas so that centralized servers won"t be necessary might be possible. I do understand that maintaining consistency of shared data across thousands of systems that could have transient connectivity via peer-to-peer technology could be problematic, but, I"m aware that research has been done to address this kind of problem, if it hasn"t already been resolved in open-source code. 3-D graphics will be used in order to show off the capabilities of the GPU and 1080p HDMI output. It"s not clear whether there is support for more than stereo digital sound via the HDMI port, but, if there is, it should be exploited to the maximum extent possible.

As you may have gathered by now, this is just at the nascent brain fart stage, and there is a huge number of details that need to be worked out. However, I don"t want to focus in on details, yet, and would rather hear as many wild and crazy possibilities voiced as part of a free-association mental exercise. Once we"ve laid out what we all can come up with, then we can start winnowing things down to what"s reasonably feasible and most popular to the largest number of people, across all demographics by age, gender, educational level, economic status, etc.

The key principles are that we would be doing this for fun and to help R-Pi users learn how they can develop software that satisfies common goals shared by a large number of people. Anyone who just wants to take pot-shots, cast aspersions, or otherwise non-constructively criticize what"s being done is hereby being put on notice that such behavior is not going to be tolerated. If a criticism is made, a positive suggestion to resolve the perceived problem must be provided and, if it"s not accepted by the group, so be it. We will follow the monkey owner principle – if you remark on the monkey someone else is carrying, then you take responsibility for the ongoing care and feeding of that monkey.

I"ll put together something with a lot more structure over the next few days, and in the meantime, I"d like to just hear what ideas others have about such a project. I"m not interested so much in just yay/nay responses, but, rather what you think about the factors I identified, plus any others you might think are important. I haven"t listed all of the issues that will need to be addressed, so, this will give others the opportunity to share what they can contribute toward the project"s goals.

I really like the peer to peer idea.  There is potential there to have the game world content hosted in a kind of distributed way.  For the sake of argument let"s say the game is like Elite or Eve Online.  Each player could host a solar system on their device.  They could choose what planets and resources were available and could also maybe run a space station out of it.  Other players could then come into your system and you can go out and explore others.  There will probably be implications for network load and connectivity though.  So it might be best to have the architecture with a central server that all the user content gets mirrored onto or something.  But anyway an entirely user content created MMO could be a first I think.

The world would be continually evolving and changing.  It could be quite cool.

I know this conflicts with want you in many ways, but Browser Quest is excellent open source multiplayer RPG that could be turned into an MMO: http://browserquest.mozilla.org/

I think this is a great idea but I agree that beginners to programming will probably struggle at 3D. Also, I think Python may start to get a bit messy when it comes to a huge project and there would probably be a performance loss because it's interpreted.   Perhaps it would be a good idea for the new programmers to contribute to more simple things than the 3D (not sure what they would be). These parts would probably best be done in a garbage collected language to avoid worrying about memory leaks.   With regards to age, how about having different worlds for different ages? In the young world you have bubble gum guns and all the rest of it. In the adult world we get tanks and bazookas   One thing that is VITAL to this projects ability to teach others is well explained (over the top) comments. Also, self explanitory variable names help. Too many times have I been interested in how something works and gave up because there are no comments and only the current developers understand how it all fits together. How are people supposed to contribute to that? That's probably because of my inexperience in C, which tends to be what most of the Linux stuff is written in. Everyone has to start somewhere though.   I personally would love to see it written in C or C++ (object oriented is nice for games) because it would help me learn those languages in a fun way and it would probably give the best performance.

Anyone want to help to port Second Life viewer? http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux)

Python is grate also for huge projects which uses openGL…  http://www.panda3d.org/ many commercial games are made using it… We have to see if it is possibile to combine c, c++ for the pure engine with python for the scriping/drawing objects part. Anyway imo also a 2d rpg with educational quests that uses python to be solved 

I think a major part of this sort of games is the graphics. So yes, novel users will not be able to help with the 3D engine, but they can help with the graphics. I would suggest you build a collection of objects you want to have and let user compete for the best graphics. (Green slimy stone, Sand dune, dungeon floor, Castle wall, <plus five hundred others> All you need for that is an artistic talent and a tool like Gimp. Has anybody tried GIMP on a Raspi?

I think I remember seeing GIMP working in either a screenshot or a video but didn't actually see image manipulation, just displaying an image. Hopefully, it won't be too bad once there is some kind of X acceleration in place.   It would be even better if we could get blender working on the GPU for 3D model making .   It would be cool the game could be developed exclusively on Raspberry Pi's and built on a cluster of Raspberry Pi's – just to make it a bit more fun

It would be better and more manageble if it had a centralised server, like it or not kids will end up using this so some policing will be needed. Thats just the way the cookie crumbles.   If the central server was a bramble,then it would be a totally RasPi powered platform, which would be way cool. I know this is just adding another dev & support complication, but I think it"s a better approach. Plus I cant program for toffee, but i"ve built enough cluster large clusters over the years

I completely agree that there has to be a centralised server with policing, code review and so on.   A bramble of Pi's would be fun but I suppose you'd get a lot more power from a server for the price that is x86 or x64 based with a decent amount of ram. Would be hard to get a bramble of Pi's into a datacenter also

A distributed architecture would be interesting. WIth a central server it becomes just yet another MMORPG I don't see policing and child safety as insurmountable, any more than any other community project

Just curious as to how you would restrict access to the game to Raspi's?

Mac address. we know that eben has a chunk just for the ref!

CPU architecture and other hardware info would be a better idea imo. I remember seeing that the mac address could be set in the config file on the boot partition. Or with ethtool / ifconfig.   I think it would be silly to limit it to Raspberry Pi's. It would be open source so someone could simply remove the checks and use it on something else. However, the primary supported architecture should be arm on the RasPi

Agreed, Arm6+OpenGl ES would be sufficient to make it targeted at the pi, if people choose to port and support it then that is up to them.

Agreed! No point in restricting access to raspi's only as the main point would be to follow the foundations goals. Get kids programming, no matter what roundabout way they end up doing it. For old fogeys like me we get a platform to play on so everyones a winner!

Perhaps a way to help novice coders (like me) up to speed is to have a branch called "Coder's Quest" where – somehow – the learning of code helps one advance in the game while simultaneously helping one learn how to program for the game, and program for beyond the game.

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!"


Wow! Very exciting project!! FWIW, i really like the idea of Robert_M to have a "branch" of the game that allows users to learn coding. Perhaps something as simple as having to complete some code correctly to get points/next level. The "Game" itself wouldn"t have to necessarily be a tutorial – a lot of that could be provided in a wiki or a "walk thru" on youtube – i know my 8 & 12 y/o are already very adept at researching how to advance their gaming skills and so hopefully learning a bit of coding to unlock something cool would be sufficient motivation for them. Unfortunately i have no skills to contribute in game development, coding, graphics etc. I do have some project management skills (video/film/tv/print production) and have been an active member of several online communities, but possibly having a fair slice of the target group (5 kids aged 3-12y/o) may mean we can contribute by some pre release testing?

I"ll gradually be adding content over the next few days describing the general characteristics of the system, organizing and expanding the feature descriptions we"ve discussed in posts here. Once I"ve got the basic outline established, I"ll invite everyone to review and add their inputs. Within about a week, we should have enough information to begin trying out some rough ideas using existing open-source game development software. This will allow us to determine what software libraries may be suitable to use for development of the Pi-finity! environment. That will also enable us to establish a baseline of requirements specifications, since we"ll know what can probably be built upon and what will need to be built ourselves. Then, we can begin the design phase and, when there"s enough detail there, implementation of the application programming interfaces (APIs) can start. The specifications will also identify all of the software development tools and libraries needed to build the software, as well as recommended enhanced tools (e.g., integrated development environments). On-line code and document file repositories will also be identified and the file management philosophy will be stated.

We will be using a rapid prototyping methodology with frequent iterations on at least a weekly basis, so, things will be moving along fairly quickly. The system will be built inward from the interfaces using placeholder stubs that will later be fleshed out with functional code. This way, the system can be tested at any time, with additional functionality appearing at each iteration.

Hopefully, the future is in peer to peer. This has the potential to be an awesome proof of concept for that   Python it is then? Would make sense I guess because that's the language the foundation are going with. As you say it can be expanded in lower level languages if necessary. Python also means we don't have to worry about memory management / garbage collection so that's a plus. I think the P2P stuff will be extremely interesting to have a poke around once the experienced network guys have sorted it out.

I like this idea a lot – and in particular, I like it even more if it was something where the "game" involved programming to advance in level.   I"m thinking something like "Core Wars" or "Robocode" with a mix of "infinite Pac-man" thrown in as well…   Something where players write some code to build a new portion of the "world" environment. Or, they could just write some code that is their "player". That player starts out with VERY limited computational resources (memory, CPU, IO) (think stats/hit points) that the player can use to write their "combat code" with.  As they explore the world, they gain "level ups" which give them maybe more computation power / memory storage to work with, so they can make more advanced code. When encountering other players or "monsters" their combat code gets run vs. their adversary, and the player with the better code (with some randomness thrown in) wins. Winner gains EXP that they can use towards upgrading their combat code through better stats, etc.   So, for instance,  a new player might only have enough CPU+Memory+IO to make their "AI" spin in a circle and shoot randomly. As they get more EXP, maybe they get enough IO to start "sensing" the world around them, so they can start shooting only when pointing at an enemy. Then as they get even more, maybe they can change how they move in relation to the enemy. More still, and maybe they can do more complex things like A* path planning or field flow to control movement through the environment. Or maybe they start taking on tactics like manuever to get the enemy into a corner and then blast away.   Basically, to advance, you need to write better and better code as you get access to more resources.   The exploration would also be influenced by this code – as you explore the maps, when you run into other players, your ability to interact with them (and whether they are friendly or not) will be determined by your I/O interfacing capability.  Like if you don"t spend any of your resources  on making friendly I/O, everyone and everything you encounter will treat you as a bad guy and attack you.   Boards would likewise be built based on your gained EXP – The more you earn, the more complex you can make your board/map (or make additional ones).  You can program in new NPC"s. As they "win" combat against players, your room gains additional resources that you can use to improve the room.   Could also have a "marketplace" where players could exchange resources – like if you win through combat some additional CPU, but you REALLY need more RAM, you can try to trade in the extra CPU for more RAM.

One thing I would say is the game world should cater for entrants with different tastes; those who want to fight each other and those less interested in conflict, who want to explore, reach goals, collect treasures, or simply build communities. There should probably be some invisibility or immunity from each other so all can share the world but still enjoy what they want out of it. I think it is very important having the choice between something which is immortal and something which isn't.

After lurking for quite awhile this is finally the idea that made me register last night.  I decided to sleep on it a bit and see that the post @32 mimics a lot of a what I was thinking.   The idea of having peer-to-peer solar systems could be really cool if done right.  Perhaps you could have nodes volunteer as "hyperspace relays" to coordinate traffic between systems/announce availability.  That way when a node goes offline the relay node could just lock out that address until such time as it re-announced that it's allowing guests into the system.  Essentially functioning like the DNS system, or a torrent tracker, in your post above.  So you'd have a server as the master node/registration/tracker, local-ish relays to handle traffic control between nearby systems, and finally individual star systems.  Also it'll apply a nice layer of handwavium to cover when a relay or two goes offline (it's hyperspace I ain't gotta explain %&$#).   When a user first logs into the game they have option to create their solar system and register with the nearest relay.  Say specify star type, type of and number of planets / moons, that kind of thing.  Bonus points if you could somehow incorporate data from the Kepler survey as a quick setup option.  Heck you could go the full route and implement a quick astronomy tutorial into the process.

I really like the idea of a massively multiplayer game with decentralized servers. I would like to see a 3D world where a player can move between servers in a method that is as transparent as possible. Ideally the player would only notice a change in new content and whatever ramifications that the decreased or increased latency to the new server causes on the client-side game engine.   I have misgivings about relying too heavily on Python because of bad performance experiences I've had as a gamer of other 3D games that use bytecode based languages running in a virtual machine. I would recommend a game engine based on C++ with Python or Javascript as an embedded scripting language. I believe that since our intended target is a 700Mhz ARM with, by my estimation, 148-186MB of RAM available to userspace programs optimizing for memory usage will be important I think. If the general consensus is Python with C or C++ based libraries then I will adapt to those requirements.   I don't think we should limit the game to only users of Raspberry Pi. I just think our main target for good game performance should be the Raspberry Pi. If both the client and server are open source then the algorithms used to detect a Raspberry Pi would be known and could be duplicated to return the same results by someone porting the game to another computing platform.   As for game content and style I would like to see either a fantasy based RPG with crafting and world formation/deformation or a trading based space sim could be fun too. Are there any game engines anyone has in mind that could be ported or are we going to try to write one from scratch?

So I"m still seeing this as a Second Life type experience. So you have two immediate challenges you need to crack as part of building a framework upon which everthing else is built on: data structure (definition and lifetime) and rendering engine. Is there Open solutions available in Linux that can be leveraged for these?

And can I suggest that "fighting" interations be explicitly excluded from this. Theree is no need for these and I would like to think we could "rise above" the need for this. Think "The Sims". Not Doom or Quake. Please?

Something just popped into my head. To use the maximum capacity of the GPU, it has to have 128MB of the ram if I'm not mistaken. Therefore, we only have about 70 or 80 to work with before we start swapping. May get a little tough at times!

You are all "getting it" precisely as I"m envisioning it. I was a little worried that I"d gone off the deep end to the point where the bubbles were getting too small to see (the ones that you can hear a tiny "Help!" when each one pops ).

The "programming for food" concept is absolutely the kind of thing I want to have. Both the media content (3-D models, textures, etc.) and object behaviors (laws of motion, material properties, etc.) will be able to be created and modified at-will, in enough of a controlled environment that catastrophic actions can"t destroy everything (at least not permanently – it would be really cool to be able to set gravity near a tipping point where, if too much stuff is in proximity, it could implode! ).

The ability of each user to create separate worlds/systems/galaxies will provide the separation some have identified, and there will be permissions mapped on everything to prevent rogues from nefariously destroying others" work. Since the object models and associated attributes can be defined by each user, they can decide who can access anything on a read or write basis. Deletion will probably be made somewhat of a pain to do to ensure that mistakes aren"t easy to make and, even if they are, they will be reversible while storage space is still available.

There will be automatic replication within a "local mesh" – I haven"t figured out exactly what that means, yet, probably negotiated through a published list of "super mesh" nodes, similar to how P2P trackers work, but, with a definable hierarchy so control can be exercised as to how much network bandwidth is consumed by object copying. In fact, I will be looking at the P2P file sharing mechanisms/protocols to see how much of that code can be used as-is. Since objects can be represented in files, it may just be a matter of using P2P file sharing as-is, perhaps with some additional attributes needed to specify the mapping relationships between nodes, local meshes, and super meshes. Local meshes wouldn"t necessarily need to be connected to the global mesh collection all the time if they wanted to limit interference/performance-loading (e.g., during a tournament).

Where it makes sense, I think things should be stored in files as plain text to make it easy for anyone to look at the contents (e.g., students), and that also means that data can be readily parsed for reasons we can"t foresee. Image and other binary-oriented data should remain in its native form, of course, and collections of related files can be compressed using standard techniques (e.g., zipped) for transmission across meshes. We will reuse as much as possible, but, I would like to make the mechanisms as transparent as possible and organized to make them beginner-readable, e.g., slot-value pairs. That reduces the need to have data in specific orders/hierarchies and also allows only what needs to be updated (dynamic data) to be transmitted (e.g., object ID, timestamp, 3-D position, 3-D velocity, 3-axis rotation rate, energy state, etc.), while the static values are defined within the object files and only need to be transmitted when a user enters a world they haven"t yet visited. Dynamic data will only need to be updated between nodes that are "in proximity", e.g., within sensing range (e.g., visible). These sorts of things are all handled in existing MMORPGs, so, we should be able to leverage open-source code to handle these. If existing code has everything encoded in binary files, then we may need to develop a reader/editor, if that doesn"t exist.

As others seem to understand, this could be a federated system, where a variety of genres could be developed in the various local meshes (each mapping to a given solar system/galaxy, perhaps), where the physical and chemical constants, behaviors, etc., are consistent. Hyper-jumping into a system you haven"t been to before would require you to rely on sensors and test maneuvers in order to ascertain the local environment. At advanced levels of play, maybe instrumentation/equipment could suffer damage, requiring code/data to be repaired, or maybe it would need to be adapted in response to local conditions (e.g., a throttle"s maximum setting would need to be adjusted in order to make maneuvering easier/possible without overshoot/undershoot).

I changed my mind. This is clearly Pi(e)lite isn"t it?

Good point! We"ve seen Quake 3 runs as a client, so, at least we know that we should be able to handle more than stick figures, but, serving up models from an R-Pi being used to render an active scene with multiple users could be a bit much.. That just made me think that a world could be populated completely by stick figure people, animals, structures, etc., but, fully-modeled/textured visitors would look normal. I like it! This is going to be soooo much fun!

A mmorpg version of Elite, I like it. Instead of buying a docking computer you need to program it!

And os each world would be named for the language you must code in for it. Such as: Pythonia Fortranox Pascalon Basicasia And errrmmmm C Take no notice if this not what you had in mind

It you"re thinking along the lines of procedural (or almost so) generation of ships, there was a great deal of research done about 30 years ago on soap bubbles and how to map the vertices of them to construct usable shapes (not bubble shaped LOL).   They managed (IIRC) to create complex constructs which looked mice but took up very little computer power to manipulate and store. They did tend to look a lot like the ship on elite but with more detail. I can"t remember who did the research but it could have been Berkeley or MIT.   Erm.. not mice but nice LMAO

Note that every named star in the International Astronomical Union catalogs that has at least three planets, has a planet named "c", since they are named in order of discovery using ascending lowercase letters of the English language alphabet (i.e., "a", "b", "c", etc.) following the star"s name and catalog number, as in "Gliese 876 c". Moons are named with a second lowercase letter, so, if Gliese 876 c has three moons, the third one detected would be named Gliese 876 cc, so, such moons would be capable of executing an ANSI C compiler by name!


So, I moseyed on over to The Wikipedia page for game engines (http://en.wikipedia.org/wiki/L…..me_engines) and there are no less than 59 free or open-source systems listed that are implemented in everything from C/C++, through Java, Python, and Pascal, to PHP, and everything in-between (I"m sure someone has a FORTRAN version running in their basement! ). As police chief Brody would say, "You"re gonna need a bigger boat." Holy Moly! If we limit ourselves to a Python implementation (only because the Foundation is leaning in that direction), the possibilities drop to five: Blender, Cocos2D, Ignifuga Game Engine, Multiverse Platform, and Panda3D.

The Blender engine appears to be built into the modeler tool, so, I assume it"s just a component that can be run in the background, but, if the entire system has to be run, that may not fit in a Pi"s limited RAM, especially since half the RAM has to be dedicated to the GPU at boot time if it"s going to be used, leaving around 80 MB for user applications and services such as Blender. On my Debian x86 system, Blender is using 118 MB, so, that could knock it out of contention if it needs a similar amount of RAM on the R-Pi. Virtual memory might be workable if only small sections of code really need to be in RAM to keep things running – really wish I had some hardware to run it on …

Cocos2D and Infugia are 2-D only, so, those are non-starters, and Infugia is only an alpha version, anyway. Multiverse (MIT) appears to meet the desired requirements of Pi-finity! the closest, based solely on the brief features summary on the Wikipedia page and, although they ceased operations in December 2011 due to funding shortfalls, the code and documentation is available while they reorganize financially. Panda3D (Disney) Is 3-D, implemented in C++, has C++ and auto-generated Python interfaces, and can import models from Blender, 3ds Max, or Maya. Evaluation of these will keep me busy for a few days, and then I"ll be looking at links to games/tools that others have provided here and elsewhere.

Early indications are that we should at least be able to run MMORPG clients on the R-Pi with traditional servers doing the heavy lifting running game engines. I may pursue the P2P possibility experiment once we have a stable baseline server-based system running with a reasonable number of users and we have had time to determine how to best use the R-Pi boards, taking into account RAM needs, virtual memory usage/performance (most likely via an external USB hard drive), network loading and performance, etc. This is very much in keeping with the Pi-finity! Prime Directives of leveraging existing code as much as possible, building the system via modules with well-defined APIs, using rapid prototyping to try out new ideas (in parallel where feasible), and documenting everything in the wiki.


Pi-finity!

Post edited 5:17 am – April 2, 2012 by scifi I was going to suggest maybe vega-strike (http://vegastrike.sourceforge.net/) but it looks like it"s mostly C++ with some python thrown on top.  It"s system requirements are REALLY low though (I think it"s wiki page listed something in the 200mhz range for processor).  I don"t remember the graphics being too offensive to the eyes when I loaded up their privateer remake a few years back.  So it may be a viable option perhaps?   EDIT:  Well nuts to that…I mis-red the system reqs page.  VIDEO ram reqs was 16mb…actual ram is 512 (with some users reporting 256 would work).   What are the minimum system requirements for Vegastrike? A:Your computer needs to have OpenGL support (which most do nowadays). Minimum Requirement Processor: Pentium I 200Mhz or Apple G3 400Mhz Video card: 3d card with 16Mb of memory (although it will work without a 3d card too) Screen color depth: 16bit RAM: 512 Mb (I use 256 Mb in WinXP without any troubles – smbarbour / same to me in Linux Ubuntu – federoy) Swap space: ??? HD: ???


Don't forget the game engine will need to support OpenGL ES – which probably limits the choices. Though you may be able to port an existing OpenGL based engine to ES?


Wow what a great and fascinating idea this is.   I would definitely be interested in playing this MMORPG on my Pi, can't really contribute anything I'm afraid regarding the initial construction and infrastructure, but once the game concept and ongoing enhancement capabilities have been designed and implemented would certainly look to host a world and build components and gameplay within it!!!!   There are some amazing people with amazing ideas in this community!!

given the ram shortage would it not be an option to step back to an isometric display paradigm like Populous/Sims/RollercoasterTycoon Pi's have to be able host the world engine (for external consumers) and the GUI engine (for the local owner) – I just think there is not enough horsepower (or RAM) to go around for a GUI engine any more complex than an isometric view

I think it would be interesting to see what kind of memory footprint quake 3 has when running on the device… just as well I brought that up I guess before we all got a bit too ahead of ourselves 

This is actually a very interesting idea. I believe that EVE-online run on stackless python if python is the way forward. I like the idea of PIs acting as shards for a MMORPG – it wouldn't be too expensive to buy several at a time for this purpose.


Wolfpaw said: This is actually a very interesting idea. I believe that EVE-online run on stackless python if python is the way forward.   it does but the server options end is a lot different from the client end

This also needs to be able to survive when raspi's are offline – turned off or just running another SD card.  So parts of the 'world' will 'disappear' from time-to-time simply because people will want to use their raspi's for something else. Someone mentioned DNS before – this is a good idea, as long as the world can be referenced in a hierarchical fashion and that there is a way to hook in virtual geography to it.

So I guess you need to start by generating a virtual "tiling" framework for the world, make some assumptions about "tile" sizes and how many tiles are needed before you go up one level to a "group of tiles" (and if you need to go any further – or just make it flexible) – naming/identification should be easy – I suggest use reverse DNS style – universe.galaxy.star.world… would suffice and have some central location hold a list of all the TLD servers (hold the universe entries)

This should all be of courses centred around Liz/Eben's reality.milkyway.sol.earth.uk.cambridge 'world' 


yaccin

I am sorr for not yet reading all the posts so far (i will catch up on that soon) but i just wanted to say that i like the idea. and that it would be great to keep the "game" very simple and have a web-interface controller so you can play it on your tv and controll the game from your smartphone/tablet 

i probably could contribute with some graphics and ui/web design stuff


DannyG

Love the idea guys and am happy to help with game logic when things get off the ground.


yaccin

make it a space simulation (because of all the solar system talk) but way easier to control than eve online! the server software could be decentralized in that everyone who wants to can run a linux server app which acts as kind of a hyperspace-gateway to all the connected solar systems. the solar systems run on the RPi"s and "register" at any hyperspace gateway they want.

and for the learning effect: you basically have to program the board computer of your spaceship yourself (in an easy-way that gets a bit more difficult with each ship upgrade)


mightymik

SN said: A raspi version of Second Life… Pi Life perhaps 

I believe OpenGrid is the open source version of SL. And yes i'd like to see a version running on RaspPi. cause ethernet port.


mightymik

SN said: So I"m still seeing this as a Second Life type experience. So you have two immediate challenges you need to crack as part of building a framework upon which everthing else is built on: data structure (definition and lifetime) and rendering engine. Is there Open solutions available in Linux that can be leveraged for these?

And can I suggest that "fighting" interations be explicitly excluded from this. Theree is no need for these and I would like to think we could "rise above" the need for this. Think "The Sims". Not Doom or Quake. Please?

OpenSimulator.org is a place to look. I know there is an open version of SL, but i don't know much about it. SL does have going for it the fact the you can build new 3D content IN WORLD. you live inside a 3D content creating engine.


IzitTech

One the main contributors to the R Pi project is David Braben who wrote the Elite series of games.  He has been considering an Elite MMORPG for a while but for various reasons hasn't been able to start.  An Elite MMORPG would be an excellent idea for the R Pi.


mightymik

OpenSim is the software, Open Grid is a protocol… and there's a LINUX version out there. There is a LINUX viewer as well. all you have to do is get it to run on the Pi.   mightymik said: SN said: So I"m still seeing this as a Second Life type experience. So you have two immediate challenges you need to crack as part of building a framework upon which everthing else is built on: data structure (definition and lifetime) and rendering engine. Is there Open solutions available in Linux that can be leveraged for these?

And can I suggest that "fighting" interations be explicitly excluded from this. Theree is no need for these and I would like to think we could "rise above" the need for this. Think "The Sims". Not Doom or Quake. Please?

OpenSimulator.org is a place to look. I know there is an open version of SL, but i don't know much about it. SL does have going for it the fact the you can build new 3D content IN WORLD. you live inside a 3D content creating engine.


yaccin

SL also generally performes rather badly. i.e. uses a LOT of ram and cpu/gpu.

and another factor: bandwith. SL uses a lot of bandwith since (almost) everything you see is user generated and has to be downloaded to your machine. educational institutes (besides most universitys) usually don"t have a very good internet connection (at least in germany. many schools dont have a public internet connection at all!)


NegentropicMan

Has anyone of you ever played Noctis IV (deep link, Main Site here, Wikipedia)? I like the idea of a seemingly endless, explorable (and simple… ok, the controls in Noctis are confising…) Space Sim.

My arguments here are:

- The world is generated procedurally (as in elite), so it is not necessary for "the world" or "tiles" to be stored anywhere

- There is enough room for everyone to name "his own" solar systems, planets and so one. Even with excessive naming it would be no problem to either store the name database at some central server or to sync it across clients, as it can be text-only and only diffs can be sync"ed

- It would have the advantage of an "endless" universe, so there will be things to discover, even if players have played it for years

- Players could communicate via "hyperspace" (global chat) or "traditional radio" (star system wide chat)

- Maybe some sort of minerable ores? Trading?

OK, the arguments are not only for a space sim, but I like space sims   

PiOfCube

yaccin said: SL also generally performes rather badly. i.e. uses a LOT of ram and cpu/gpu. and another factor: bandwith. SL uses a lot of bandwith since (almost) everything you see is user generated and has to be downloaded to your machine. educational institutes (besides most universitys) usually don"t have a very good internet connection (at least in germany. many schools dont have a public internet connection at all!)

This is where a repository system such as the one we are working on will work very well in situations like this. You could setup a plain ftp server on the LAN which is a mirror of the main repo and the clients can use that instead of going through the internet. There would be no reason to use WiFi to do this if there isn"t drop cables available.   We would prefer people that wish to make mirrors to use the torrent downloads instead of using a lot of bandwidth on our repository server.   I hope to get the specs of the repository finalised over the next few weeks so we can concentrate on adding content.   We do have an IRC channel on freenode.net #OIP if anyone wants to drop by 

PiOfCube on YouTube: http://www.youtube.com/user/PiOfCube Open Indie Project Dot Org: https://www.openindieproject.org


moldovan_catalin

As a suggestion, for the 3d engine, I would go with one of the best known 3d engines like Ogre3D  that already has a working OpenGL ES backend that can be easily ported to R Pi. Another alternative could be Horde3D is lighter and smaller (code wise) than Ogre3D but very capable also. It will require porting to OpenGL ES.

My personal choice would be Horde3d, it's light but very capable.

An interesting idea would be to use QtQuick3D for making the game graphic engine. As far as I know there is already a port of Qt5 working quite well on R Pi (from the videos posted in the blog). Making the engine using QML and QtQuick3d would be easier for programming beginners to jump into the equation. I don't know though how a big QtQuick3d project will fare on a rather constrained device.

Almost forgot, a big decision factor would the tools that come with the engine or the capabilities of the engine to export/import different asset formats. We're talking here about programming but there are also a lot of people that would like to get involved but don't like programming, instead they are interested in game art, game concepts,  modeling, animation and so on.


yaccin

i vote in favor to anything qt related  the repository thingy is a good solution  there is an "open source" mmorpg called planeshift (www.planeshift.it – the artwork, music and story/setting are not open though). i am not sure which engine they use (it is a "ready made" open source 3D mmo engine iirc, maybe irrlicht?) that – in my memory – also performed rather bad. it had horrible graphics and even on a pretty decent machine used all the cpu it could get and often was quite slow.

for graphics i would suggest something like World of Warcraft. it is not too heavy on the gpu but still looks rather good after all these years.

oh and then there is order & chaos online, which is a (nonfree/non open) mmorpg for iOS, which means it uses open GL ES too, right? it looks nearly as good as WoW 


Rivalo

I'm not that good at coding but I love the idea. Unfortunately I don't have a RasPi.  But I still can contribute something. I'd like to make the sounds and the soundtrack.    Just one thing: If you want to succeed you need to organize this. Get a website or something. And just let people register and just select people. 


Get some idea's on what MMO we are going to make. Sci-fi, Fantasy, Medieval? And just boring WoW style or something total different(It's a community project, loads of people who are really good at programming, why not?)


Just to add to the previous poster who mentioned VegaStrike. That project has been around for a while and it was the engine used in the Privateer remake. Vegastrike is just a 3d engine, so rewriting a RPi optimized substitute should be possible (not simple, but hopefully something a GLES expert could do).   The interesting thing about Privateer remake is that it is open source, and all the game content is available for non-commercial use.  What's more, the remake was scripted in python, so you can download thousands of lines of python code and pull it to pieces, see how the game effects are done etc.  Privateer remake fizzled out due to lack of interest in the PC world – not really surprising.  Even if it is only a sort of sandbox for aspiring game writers it is a fantastic resource and maybe a nice fit for RPi.   For those who may not know their space sim game history, Privateer came from Origin Systems "We Create Worlds" .. Richard Garriote, Ultima, Wing Commander. Very creative company in the 90's.   Privateer owed quite a lot to Elite – trading, combat, exploration – but with 10 years of hardware improvements Origin could do a lot more. And of course, all these games trace back to the tabletop RPG game Traveller which was a huge source of ideas and inspiration.   Privateer was a really well designed game. Origin had all the elements in there that are in modern MMOs.  Complex interesting maps, background story, multiple factions with player reputation affecting outcomes, quest driven plot, working economy with equipment upgrades, loot, and lots of combat.  All that and it only required 4M of RAM!  Apart from the $200M or so Bioware just spent on making Star Wars, I think Privateer was a much better designed game.     It's just sitting there in cyberspace – abandoned – while Angry Birds and Farmville take over the world.


Jim Manley

I know it"s completely insane (no news there for me ) and it would be a long-term goal, but, I wonder if it would be remotely feasible to support multiple game engine protocols? Then, we could leverage what"s been done everywhere else – it would most likely mean you would only be able to cross between worlds and only exist in one at a time, but I"m guessing the data streams look an awful lot alike at some level. Transmitting ID and 3-D location/orientation/velocity at a bare minimum would be extremely lightweight (a few dozen bytes, much less than a TCP/IP packet) and character feature details (stick-figure body mechanics, texture maps, etc.) could be served up from distributed repositories elsewhere, reducing the load on any one R-Pi, and keeping its data persistent even if it"s not on-line – that"s why I"m thinking about P2P. I"m guessing even some commercial games publish the specs for their protocols for this kind of data, so, we should be able to build on them.

I definitely want this to be educational scientifically as well as for teaching software development at various levels, so, knowledge of spaceflight mechanics, effects of gravity on planet/moon surfaces, chemistry (need to find and combine materials to make fuel, food, water, etc.), and math will all be important for players to have. The challenges could vary between worlds so that beginners don"t become overwhelmed and frustrated, and teamwork could be rewarded the way it is in dungeons and dragons style games (I know this is true in many on-line games already and I want to ensure we include it as a primary feature).

For the Qt fans, I"ve been in contact with the folks at Nokia sponsoring Qt on Pi and they"re interested in supporting this, as well as other work I"m involved in. If we can establish a federated, distributed system that allows crossover between various other game systems, that would be great, as I"m a big fan of cross-platform compatibility. I also know how hard that is, so, it"s going to be a long-term goal.

I think the graphics coming out of the HDMI port are going to look as good as anything out there, which is what originally and instantly attracted me to the R-Pi. It"s going to be at least as important to have high-quality 3-D models, textures, backgrounds, etc., as it will be to have honkin" hardware and software – that intersection of Technology and Liberal Arts thing that Steve Jobs always insisted on at Apple. It would be a mistake if we had a system that produced a crappy visual and auditory experience at 26 billion floating-point operations per second – I would much rather sit in a Ferrari making "vroom-vroom" noises and not going anywhere than be stuck bouncing around in a clunker at highway speeds, belching toxic fumes and making rude noises.

It"s interesting how many different games people have referenced as candidates for a baseline or compatibility – I"m going to be kept plenty busy playing games while becoming familiar with their technical details (yeah, that"s what I"ll be doing – that"s my story and I"m sticking to it). Work, work, work. Work, work, work. Well, somebody"s gotta do it, right? 


Jim Manley

SN

Can we have a Crystal Maze world – where everything is a Three (or Two) Minute Game?


samarthwiz

Instead of making an mmorpg Make an mmocomunity Now this are classified as mmorpg But instead of having an goal You just talk to people,play games with them and roam around the world. Examples include:club penguin, minecraft multiplayer survival server(smp)

Oh yeah im learning opengl


Robert_M

I'm not a programmer, so maybe I misunderstand this; but I've seen mention of P2P being considered, and I was wondering if this is the sort of thing that would exclude folks like me who are behind Comcast's anti-torrent wall?


dhicks

Robert_M said: I've seen mention of P2P being considered, and I was wondering if this is the sort of thing that would exclude folks like me who are behind Comcast's anti-torrent wall?

You raise an interesting point. If the idea is that each Raspberry Pi hosts a self-contained solar system / dungeon / etc that other players can wander into and explore, at some point network traffic is going to have to get from the Internet to the Raspberry Pi. Most Raspberry Pis will be behind a NAT device of some sort – maybe a firewall device in a school or business, or an ADSL router at home. Having to set up port-forwarding on your (or, more importantly, your parent's, if you're a 12 year old) ADSL router is going to stop a large percentage of people, and you also need some way of hosting multiple devices running in, say, a school environment – a class or after-school club can't each have an individual IP address assigned to their Raspberry Pi.

For a peer-to-peer system to work, there will still need to be some kind of DynDNS-like connection-brokering service that the system registers with on boot to tell everyone that it's available and ready for connections. This could be set up as some kind of "stargate" type system – go to a central server to choose a system to visit. That could also, potentially, act as a kind of filter by group – maybe have some "stargates" be invitation-only, or available only to authenticated users.


droidix

I don"t think anyone has mentioned this yet, but Ryzom went open source a few years ago and contains a complete client and server implementation.  Since the game is older, I would think it would be a perfect fit for the Pi"s GPU power.  They also licensed all of the art assets under CC-BY-SA.     I don"t think the world or quest data was open sourced (likely because they want to keep making money running the official worlds), but they do have samples areas that are.  With this thread"s project wanting to create it"s own world for the Raspberry Pi, this fact shouldn"t be much of an issue.   http://dev.ryzom.com/projects/ryzom/wiki   There are already ports for Mac and Linux, and work is currently underway to make the Linux port work natively (it currently uses Wine).   I want to work on porting the client to ARM after I get my Pi (which is hopefully soon).


Jim Manley

Robert_M said: I"m not a programmer, so maybe I misunderstand this; but I"ve seen mention of P2P being considered, and I was wondering if this is the sort of thing that would exclude folks like me who are behind Comcast"s anti-torrent wall?

Hi Robert, Great point that I hadn"t thought of, myself.

We should be able to use essentially the same technology as P2P file sharing often used for illicit purposes, but, tweaked with some networking tricks. I need to bone up on how they block it, and if it"s actually by IP filtering (e.g., PirateBay, etc.), we won"t need to do anything. If they"re looking at port numbers, we can establish registered ports that should be fine. If they"re doing more nefarious things by looking at packet contents, we can encrypt them. There are many more ways to skin a cat than they have lives (no actual cats were harmed in any way in the production of this post, even though I"m more of a dog kinda guy  ) and this is one of those teaching moments for the kids (of all ages).

I realize this might not be intelligible to the technically challenged, but, I promise that if you hang around this project, you will learn more than you ever thought possible. If it hasn"t already been made obvious in my too-voluminous posts, the purpose of this project is educational, and if a game happens to break out and we have even more fun, so much the better.


Zaragon

Just a thought since I can't otherwise contribute much but one view of this is as a learning experience in developing things and potentially introducing people to the world of distributed systems etc. Anyway the world doesn't consist of just R-Pis why not consider that some people may have access to other systems such as more powerful linux and therefore can host more complex objects.

So you could, to use the current examples, host a world on a Pi but then you could find an old computer to run Linux to host the solar system. You just take a step up in scale a bit like moving from infant to junior to senior to university.

You are still targetting the same people just allowing them to grow and potentially have less to worry about in terms of the restricted environment of the Pi. Though if you can get the whole multiverse in a Pi I'm sure there would be lots and lots of people very interested.

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.