Draft Proposal For An Open Source Multi Platform Game Lobby

  • April 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Draft Proposal For An Open Source Multi Platform Game Lobby as PDF for free.

More details

  • Words: 1,591
  • Pages: 4
Proposal for an open source multiplatform game lobby and digital distribution platform. It is time for open source to take on Steam, Direct2Drive, Greenhouse, and all the other proprietary digital distribution methods and friends systems. Main Requirements 1. Should support as many open source games out of the box as possible a. Spring, GLEST, FreeCIV, OpenTTD, and more b. Back end should be modular so you can write interfaces for new games without any needed upstream access. XML + some scripting language based? c. Should be bundled with at least one game, maybe more. Will probably require projects to sign up and agree to support it with their installers. 2. Should be multiplatform a. Windows and Linux support should be mandatory due to the size of the userbase on Windows and the support for FLOSS software on Linux. b. Other platforms should be targeted based on size of user base, and willingness of developer support. Ideally the next target would be Mac OSX given the size of the user base, but Solaris and *BSD would be other great targets. c. A bare minimum chat client with support for basic games like Tetrinet would be great for smaller, embedded environments like Nokia internet tablets, Android OS mobile phones, etc. 3. Requires chat and game launching functionality a. Spring style “Battle Rooms” for pregame setup and chat while everyone gets ready instead of having to go in game for the setup. This allows you to multitask and browse the web, send emails or instant messages, or other tasks while waiting for a game to start. b. Friends list support so you can see when your buddies are online and what games they are in. Friends list should have group membership for clans/guilds or websites to organize groups of players. c. Chat rooms for general chat about games or just hanging around. Basic functionality would include locked rooms, muting people, kicking and banning, and channel topics. d. The chat protocol should be standardized early on, and changes should be avoided as much as possible. This will allow people to write their own basic lobbies for other platforms, or add support for this lobby to existing programs. e. The chat should use Unicode for support for as many different languages and character sets as possible. f. The back end should be similar to IRC with multiple servers passing data between each other to avoid server overload and provide more local servers. We should host an “official” server network, but the server software should be available for others to host their own server network as well. 4. Digital Distribution

a. Allow for easily downloading new games or mods for games, and highlight new content b. New maps, models, and other materials should be available as well. Maybe even game replays or videos. c. Should be accomplished by either tying it to a repository system or distributing files via BitTorrent. The back end for this feature should use a well documented XML config file allowing people to easily run their own repositories, or add multiple repositories in the style of the 3rd part APT capability coming to Ubuntu and already in OpenSUSE. d. Advertising may need to be integrated into the client in a few small spots to offset the hosting costs for large amounts of files depending on the hosting website’s requirements. Once again, this should be easily removed should it not be needed by another file hosting website. Optional Features / Future Features 1. Support for non-free / abandonware games a. Modular architecture means the lobby could probably support almost any RTS or turn based game b. The community will probably release plug ins to support a wide variety of games, but we should consider supporting the most popular / most played of these games c. We could replace dead game lobby services like Bungie.net, MPlayer, Westwood Online, etc. 2. Virtual Lan support a. Support for passing IPX or TCP LAN games over the internet KALI style b. It would allow support for almost every multiplayer title available, even obsolete ones. c. Probably not needed for open source games but would increase the player base significantly and make users very happy. d. Probably extremely technically challenging, so it would need to be determined how much it would be used before we try to tackle it, resources may be better spent elsewhere. 3. Internet game browser a. A game browser that would work with every FPS style game where you join dedicated servers with games already in progress. b. First target the open source FPS market c. Include friends lists, chat rooms, etc similar to Steam or XFire d. Possible non-free / abandonware game support, especially if combined with our own “Master servers” e. Replicate the amazing features and performance of All Seeing Eye’s server side filters which hasn’t yet been equaled f. Running our own “master servers” could replace the dead master servers for games like C&C Renegade, WON versions of Halflife, and a few other older titles g. Also extremely technically challenging and difficult to run and maintain so the same caveats as virtual LAN support apply. 4. VOIP Support

a. Voice over IP chat rooms and game communication based on free open source software like Speex b. Would probably have to be implemented in some sort of peer to peer fashion because of the extreme bandwidth requirements c. Would also probably have to be capped at a small number of users per room because of those requirements d. Would hopefully replicate features of Steam and Ventrilo’s voice chat e. Code may be available from a few other open source VOIP projects like Ekiga, Asterisk, and whatever the open source replacement to Ventrilo is (Find this link on the Spring forums before I publish, maybe the name is mumor / rumor?) 5. Technical implementation ideas a. Base as much of this on extending standard off the shelf code and protocols as possible. b. Maybe it would be possible to expand standard internet protocols like XMPP or IRC to handle game lobby traffic c. If that’s not possible, I see no reason not to make our protocol a derived but extremely similar version of one of these existing protocols. There’s no need to reinvent the wheel. d. We should standardize the main parts of the protocol as soon as possible to begin fostering an ecosystem of different clients that can “talk” to each other. Various camps may want to make their own clients for native interfaces in Windows, Gnome, KDE, OSX, etc. e. The key concern should be scalability. This will need to scale up to handle thousands of users, and it should cost and arm and leg in bandwidth and hardware to do so. f. XML should be used for configuration of both game joining protocols and describing anything else. This will make most of our platform human readable and easy to modify. g. Our first client should be as multiplatform as possible from day one. This means using either QT, Swing + Java, or WxWidgets. Later native interface clients could be written using GTK, Winforms / .NET WPF, and Cocoa. Project Name The project name should incorporate either Free or Open in the name. Usually, this sort of thing is called a game lobby, but a .net name may make sense or there could be some other brilliant name idea. Suggestions: OpenGameLobby, FreeGameLobby, Vapor (Steam joke), OpenLobby.net Reason d’être Currently, there are a multitude of different FLOSS RTS or turn based strategy games available. Many of these are reasonably popular and are gaining more users. However, each game uses a completely different lobby system and client. If you want to

play with your friends, you may have to run the Spring lobby, the OpenTTD lobby, the Tetrinet lobby, just to play with the same group of people across a few of your favorite games. Proprietary software like Xbox Live, Steam, and X-Fire are making great strides in allowing you to have one buddy list to launch and play with all your friends with no hassle. Shouldn’t open source try to catch up? Meanwhile, there’s a variety of new digital distribution methods for proprietary games like Steam, Direct2Drive, and Greenhouse. These services are gaining a user base of millions, and selling a lot of software to people. Unfortunately, they are all closed to open source free projects since they’re not profitable for the game companies. Imagine the promotional power of a 10 meg installer that would allow you to browse for and install a huge variety of open source game titles on the OS of your choice, even down to a mobile phone platform. The KDE and Gnome projects are providing an enormous amount of casual games in addition to the more full features open source titles already released by different projects. This could provide a huge potential audience for open source titles and would move a lot of open source software onto average people’s desktops. Combining the two could become even more powerful. The software could ship with most Linux distros allowing people to be up and running and playing with their friends in minutes. Windows users may take a little longer, but it will be just as easy if a little more time consuming. It would allow people to discover and install new titles, and convert them into open source users as they discover how much easier software is when you don’t have to pay $50 like most commercial games, or it isn’t riddled with ads or spyware like many casual games.

Related Documents