The role of gnome-games (and broken promisses) :)

As Jordi blogs there is a thread on the gnome-games mailing-list where we would like some feedback from users, distributions and game developers. It started with a wish to get gbrainy included in gnome-games but sparked the need to discuss the general role of gnome-games. I promised to blog a about it yesterday but I went out cold after getting back from my exam and slept the rest of the day away. Beers after the exam may have had an impact here… 🙂

Gnome-games status
Gnome-games currently consists of 17 games and an internal library that is used for common code like high-score, boards, etc. The games are currently coded in C, C++, Scheme and Python. Most games use the library but not all do as e.g. there is no python bindings yet.

Jason and me are the official maintainers of the module but in practice some games have other “real” maintainers. Christian Persch and Vincent Povirk rule aisleriot. Robert Ancell and Thomas M. Hinkle of glchess and gnome-sudoku fame both still maintain and develop their games within gnome-games after the inclusion. For these games I am not much more than a release droid.

The games in gnome-games are automatically included in many distributions as the default game pack. This has attracted many game developers as they hope to get their game into gnome-games in order to get distributed automatically.

Code maintainers or game inclusion judges
This leads to the question of the role as gnome-games maintainers. Is our role to maintain code or is it to judge what games gets to be included? I can maintain code but I am not sure I am the most qualified to be judging the quality of games. What do the distributions want? What about the users?

The case of gbrainy
Jordi wrote a really nice puzzle/memory trainer game called gbrainy. To reach more users he asked to get it included in gnome-games. I really like the game but there are issues to discuss:
– dependencies (mono)
– increasing gnome-games binary/code size
– yet another puzzle game

Who are our users?
Looking at the current games in gnome-games most are puzzle games. This seems obvious as I expect that programmers prefer to play those kinds of games. The question is if our users share this love for brainy-games or if they would prefer more action games like Nibbles and Gnometris. Perhaps we should think about getting a more diverse set of games. More action games, perhaps a game targeted for children, etc.

Flash and the games support library
Now that we have swfdec should we start considering using flash for games in gnome-games? Should/can we add some sort of support for flash based games in the games support library? I am completely clueless about flash so I don’t know what will be possible. There are many great flash based games out there and many good game developers that might be interested in doing some for gnome-games. I do have some fear about how such games will integrate into the GNOME desktop though.

Before we can start to make decisions about all this we need more information from you.

Questions
Distributions:
– Do you want gnome-games to be some sort of meta package including the games we see fit?
– Would you rather customize and mix your game pack and include new games like gbrainy your self?
– Does the binary size of gnome-games matter? Can we expand and include more games?
– Is 17 games too much choice in the menu. (I have to start scrolling the list soon if we add more)
– Would you consider using –enable-games=[only-games-we-like] and be okay with more games added in gnome-games?
– Would you ship flash based games?

Users:
– What kind of games would you like (Are we focusing too much on puzzles?)
– Do you want more games as default? More multiplayer/network support in the games? More bling?
– Is there a need for a child game in the default pack?
– Is it okay with a “static” games list or should there be change from time to time?

Developers, Developers, Developers:
– Should we make the games support library a real library? Is there a demand for it at all? – Opinions about flash based games?
– What can we do to help new games get exposure?

General:
– Does it make sense to have one module with many submodules/submaintainers?
– Do we want to depend on mono for gnome-games?
– Do we want every gnome based game under the sun in one module?
– Would it be responsible to be maintainer of a module that contains code in languages I don’t know (C# and flash)

If you have any input please comment in the thread or here in the comments. Thanks!

38 thoughts on “The role of gnome-games (and broken promisses) :)”

  1. I like the idea to have a bit of all kinds of games.
    * one-player cardgame
    * multiplayer cardgame
    * puzzles
    * table games
    * fun games

    Also i’d like to see games like these in gnome-games:
    gnome-hearts
    pybridge
    pychess (because of FICS support)
    gbrainy

  2. (I think something is broken somewhere–by default, the name field was filled in with “Adam” and the website field filled in with “http://reviczky.myopenid.com/” both of which strike me as poor default choices for most users.)

    I’d only distribute Flash games if they played completely with a free software Flash player like gNash. But there too you have a technical question to answer about increasing the size of the game (via a dependency on gNash). I wouldn’t distribute any game that had a non-free dependency, like Adobe’s proprietary Flash player.

    I’d prefer games that didn’t require fancy 3D hardware to play (Crack Attack, for instance, is a nice game but it has a not-strictly-necessary reliance on 3D hardware to play smoothly; the game would have been better if it were implemented with 2D graphics and effects).

    I’d like multiplayer/network games so long as they’re super-easy to use. I should be able to use Zeroconf to identify other players and simply click on them to initiate a game with them. Of course this means coordinating with the firewall stuff to make sure I can read and send Zeroconf data. I would also like the same ease of use for games played over the Internet where Zeroconf data wouldn’t be routed (as I understand it).

    Is C# and Mono a settled issue with regard to dependency in GNOME? I’d like to read more about that, as I recall reading some years ago patent-related difficulties surrounding that.

    Thanks for asking about these things.

    J.B. Nicholson-Owens
    mail@digitalcitizen.info
    http://digitalcitizen.info/

  3. I’d like to be able to include as many games as possible, but I’m worried that if we include all kinds of games using all kinds of development frameworks in a single tarball, it becomes unwieldy.

    Therefore, I think gnome-games should be split up and made into more of a support library.

    Having games as individual packages should make things easier for both upstream maintainers (desynced release schedules) and distros (easier to pick and mix).

    It’ll take some work, though, so the decision obviously rests with whoever’s in a position to do said work 🙂

  4. Well, I can’t say I’m a big user of gnome-games but I would really consider splitting the whole thing into individual packages. A compile option is nice but distributions would probably still not split the package.

  5. Are there any free flash authoring tools? It’d be a shame to include stuff that requires nonfree (or even windows or mac) tools to make changes.

  6. Users:
    – What kind of games would you like (Are we focusing too much on puzzles?)

    Thats hard to say, what counts as puzzle. There are some games I would like to see in Gnome Games like Monkey Bubble, Gweled, Gnome Mastermind, Caboodle and some form of Go

    – Do you want more games as default? More multiplayer/network support in the games? More bling?

    Yes, yes and yes.

    – Is there a need for a child game in the default pack?

    Games for children should probably be in another pack.

    – Is it okay with a “static” games list or should there be change from time to time?

    Change is good, get new Games in, kick games out that aren’t being maintained.

  7. with regard to flash games i can only mention that swfdec-gnome is officially part of GNOME 2.22, so i don’t see a reason to not have flash games.
    gnome also has an external dependency on ibggz and ggz-client-libs 0.0.14 for network games.
    (i know, these were only “technically-possible” comments and no decisions on whether and how to include more games or not.)

  8. Users:
    – I like the puzzle games, I am currently a big fan of gnome-go, gbrainy and sudoku.
    – I don’t think more games is the right way. There’re probably too many in the default Ubuntu install for my liking anyway and with some rather obscure names. Network/Multiplayer is nice – maybe Avahi would be a nice way forward for this? bling is nice but if it’s the packages aren’t fully installed by default (looking at you gnome-chess) then they just end up confusing users who haven’t got a clue what their admin has/hasn’t done.
    – Children games – now that’s an interesting one, what about something like KDEs edutainment stuff? Kids can play the action games or install what they really like but some nice *optional* edutainment games would be nice as an additional build flag for distros 😛
    – Static games list? Not really it should be revised on each distribution – maybe a reporting feature (optional of course) to gauge whether the current set are used enough and maybe phasing in/out new games.

    Developers, Developers, Developers:
    – A library is a good idea but for what? Networking API? a proper OpenGL Widget for use in games that degrades gracefully? or just things like high-scores etc?
    – Flash is great for games but it could mean the swfdec guys get a lot more work to do but does mean a lot of existing games are available, maybe a container could be made to go to a library of playable flash games as opposed to each flash game having a seperate entry. That way if swfdec/Flash isn’t present then they don’t go show up.
    – With regards to exposure, what do you mean – they’re installed with every distro! 😛

    General:
    – Mono – always tricky. If Mono is staying as part of Gnome then you may as well. If Mono continues to be unpopular then you’ll lose a lot of games (or have them installed without the necessary runtime) if it eventually gets dumped
    – You can be a maintainer but I suggest that you act as more of a gatekeeper on games being actively developed (manage releases etc) and either drop games no longer being developed if you don’t know the language or offer their lead to the community to continue. If you do know the langauge then you can maintain them as you see fit.

  9. Also – do any Flash development tools exist for Gnome? This could be an issue as it raises concerns with an entire set of games only being developed on non-linux platforms due to the tools being unavailable. Maybe pigment/clutter would be a nicer way for fancy transitions and RAD to be incorporated? That way we’ve also got OpenGL & Cairo enabled goodness as well

  10. gnome-games is already too big!

    I think the ideal solution would be to break the games into separate packages. Similar to Gstreamer’s “core”, “good”. “bad”, and “ugly”.

    Of course, this implies you become more of a package maintainer than a coder. Hopefully clear rules can be use to classify games as they can for codecs.

  11. For the love of Freedom, please, don’t even consider including Flash games. It is worse than Java. Don’t fall into the trap. Even more if you need non-Free Software to modify them.

  12. Pingback: Late breaking news
  13. I like the puzzle games (solitaire; mah-jong; mines), but I also like — sometimes — to play something a little more fast moving (like gnometris).

    I’d love to see a decent, fun pinball simulator in there though. That’d be just fine with me.

  14. Second the pinball game. Thatd be real nice. Also please no flash (unless you’re a freedom hater), or mono (quite heavy system requirements). The cool thing about gnome games is that it works on really old pcs as well, adding flash and mono would completely ruin this.

  15. I’d think that it makes sense to have many games available, since the primary purpose is entertainment. But this obviously does not work with our current menu system. Perhaps it’s time for a “game center” that works similar to popular flash game websites.

  16. Gnometris is great, but the latency of the game increases with the number of blocks on the screen (technical issue), this is a little annoying since you have to be really good 🙂

    I don’t like flash so I don’t want it in gnome (btw, flash games are everywhere on the net)

    I installed KDE4 for testing, I don’t like the desktop bloat, but the games are nice (fast with pretty graphics), but some of the KDE games aren’t interesting at all.

    I like action games (tetris, crack-attack, supertux…), some puzzles (mahjongg, mines…)

    I don’t mind having mono games, since it’s allowed by gnome, a configure option would be perfect.

  17. I think you should have find out if people even play some of the games and put them in a game-old package and keep it nice and fresh with games that are maintained updated and popular

  18. First of all, this is no troll post. To be honest gnome-games is the somewhat stepchild of the gnome desktop, except for the new chess game all of them are really crappy games. None of them appeal to a user more than a couple of minutes and I would even go as far and say less than 5% of the gnome users out there use them on a regular basis. The packages are only maintained and not actively developed and thats what the user soon realizes while playing.
    Also, the selection of games is very redundant, three card games, two of them a version of solitaire and black jack which sucks if not played against another human being.
    The tetris close is okayish but somewhat slow and lacking netplay a la gtetrinet. The only bright spots are chess and the sudoku game which is also rather new.
    In my opinion, which is neither representative nor crucial imho, a balanced selection of games would consist of several clones of contemporary games. At least a networked tetris version (preferably tetrinet compatible), a jump and run game a la Mario/Sonic, a networked version of Bust-a-Move (e.g. Monkey Bubble), a networked poker/black jack version, sudoku, chess, pinball, an action-adventure (roguelike?!) and a memory/pacience game like mahjong. Each of these games should primary use svg graphics which scale to resized windows. The networked games should support avahi and xmpp/jingle via empathy (which in my opinion should already be part of the next gnome release – despite its roughness). Ideally, all of these games would share a scoreboard/time recorder a la wii gallery. I know that probably nothing of the above is going to happen in the future, however, this is one of the current problems of the gnome community, which seems to be almost paralyzed and not willing to undergo major revamps of the desktop – a development which I sadly keep track of since the days that a gnome topaz (or whatever you wanna call it) was ruled out and incremental updates considered the future. Nothing is wrong with that if you want to keep a stable platform, but seeing other desktops gathering momentum (no I am not only talking about KDE4) makes me wonder whether there is a future for gnome at all.

  19. I suggest that we start splitting up the package and make a library like libgamesupport with python and mono bindings.

    I think the games fit in the desktop category and that they are all quite fine. There is a bit of overlap that can be reduced and some minor details that can be improved. Also adding network capabilities to most of the games will rock.

  20. Gnometris is not an action game, it’s a puzzle game. Maybe puzzle-action. Same with Nibbles.

    My guess would be that puzzle games dominate because they’re easy to develop and are easy to integrate with the desktop (GTK+ and GNOME in this case, common highscore lib, etc). Other types of games would introduce a massive game-library dependency, like SDL, which doesn’t really integrate with with desktop (how is a fullscreen custom non-gtk widget game related to gnome?). It would be pretty cool if there was some gnome-sdl integration and a larger variety of games, though!

    What would be good:

    more network support. Maybe experimental server infrastructure via online desktop?
    real action games
    music/sound!
    gnome nethack!!
    17 menu items is too many. subcategories are needed. This could be broken down in packages, as well: gnome-games-extra? gnome-games-kids? gnome-games-3d? gnome-games-action? All of which would be more like meta-packages, I guess?
    Flash would be fine if games could be fully developed and played on Free software. Otherwise, SDL and OpenGL would be better options, I think.

  21. People only use GL to develop action games due to Gtk/X having extremely poor performance, it has nothing to do with integration issues at all. In fact, coding 2D games in GL often leads to crappy ingame user interfaces.

    So the real solution is to speed up the low-level rendering stuff and then develop games on top of that.
    And I’d eally love to have a flipper, too. But a good one. And most flippers are crappy.

  22. Pinball and networkable games are my two biggest wish list items for gnome-games. An option for online play like what comes with XP would be super awesome.

  23. Allow me to throw in a completely different kind of suggestion, one that you might find some logic in by reflecting on the GNOME Online Desktop initiative:

    What if the gnome-games future is not as a big pre-installable collection of games, nor as a split-apart collection of individual packages, but as a sort of “MiniClip on your desktop”, a desktop front-end of a free games “portal”, where the games can be downloaded from? Unlike the typical web games portal, this would be focused on *free* games (in both senses of the word), could support either games that work in a web browser, or those easily installed to the gnome-games sandbox (that obviously doesn’t exist now, but could). Like the portals, it could offer online highscores, a meeting place for finding multiplayer opponents, updates, and latest games recommendations.

    Just a thought.

  24. A few points I’d like to put forward:

    Less is more: It’s important for a default GNOME install to have some games but having a wide selection of games is not as important. A smaller selection of games should make it easier to maintain. 17 is really too many.

    Consistent Look and Feel: One of the things that makes good games great is great graphics. I’m not talking about fancy 3D stuff and fog and what not but just easy-on-the-eyes good looks. I would love it if we could have a sort of Tango for games – a set of color and drawing guidelines for game elements so that things look good and look like they belong together. Why is frozen bubbles more popular than monkey bubbles? graphics and music – that is all.

    Just Works™ Networking: Avahi should be used in games where it makes sense to make it brain-dead simple to play against someone on your local network. Perhaps tubes / xmpp to play against friends elsewhere. Again, though, consistently. Any game where network play might make sense should have the same UI for it. It might be prudent to work out some protocol guidelines as well.

    Instant Gratification: GNOME is used by people who should be working. One major qualifier for inclusion should that the user can play for a minute or two with some sense of gratification and then stop. A game could be addictive so that the user doesn’t want to stop, but if I only want to play to relax a little and then get back to work I should be able to. That probably rules out nethack 😉

  25. From a user perspective, I’d like to see fewer games installed by default. The majority of them hold absolutely no interest to me and it’s shameful that the only way to remove one is to remove the lot (at least in Debian). They should really be split into a meta-package in my opinion.

  26. Not sure if the split you’ve suggested is right, but I do think the gnome-games package should be split somewhat – it’s a very large monolithic tarball right now, forcing updates to any single game to be queued for a big tarball release instead of smaller independent releases.

    On the counter side, that’s not so say each individual game must have it’s own package – some grouping is probably desirable just to avoid a massive increase in package numbers, if nothing else.

  27. I vote for less, not more. Gnome games should provide some minimal level of entertainment for anyone who needs to entertain themselves for 5-15 minutes and show off the platform’s fit & finish with every release.

    As such I would nominate Mines, Solitaire, and whatever games people actually play out of windows. Any distro can create a games meta-package, I don’t see why Gnome would want to be involved in that.

  28. While I like that the quantity of games is controlled, I’d like to see a better breadth to cover a wider variety of games styles/types and appeal to a greater variety of game players, and for each type to see more variants playable within the game.

    So, say there are a set of game categories, like “Card game”, “Chess/checkers game”, “Falling blocks game”, “Bouncing ball game”, “Invaders game”, “Platform game”, etc. and one game “package” for each category able to implement multiple variants of that type of game. So the “Card Game” category game might play several different solitaire variants, cribbage, poker, etc. The “Bouncing Ball Game” entry might do pong, breakout, billiards, foosball, and pinball.

    It sounds like there is an issue currently, in that Gnome Games gets many proposed *new* games, but has a harder time attracting maintainers for already accepted games. There seems to be good motivation for getting *in* – namely, seeing your game and your name installed on every Gnome desktop – but less motivation for maintaining/improving the game.

    A thought for addressing this might involve encouraging a “engine + implementations” architecture, where certain code, artwork, and so on is shared by multiple games. A requirement could be set that a game implementation must be no larger than X mb’s, but that anything it uses from the engine (and shared resources) is not counted against it. This would allow people the freedom to create new games, but encourage them to reuse or update the shared portions.

    To combine both of the above ideas, Gnome Games could allow anyone to propose a replacement for a given category, so long as it implements ALL the games and functionality of the current entry in that slot, *plus one* new game implementation, and must fit within specified disk, memory, and cpu requirements.

  29. I would stray from flash games.

    Some of the current games don’t appeal to normal users, I would prefer to see them split off like has already been mentioned (Klotski, Iagno, and Robots are some I’d prefer not to have).

    I don’t think the size of the package matters (within reason), because the internet is getting faster, and hard drives are getting bigger, but, even now, the games menu seems bloated, so I would vote for games sub-menus.

    Pinball would be fun too…

  30. Splitting gnome-games is a very bad idea. There is a lot of shared code, translations, graphics and sounds. So splitting the package into many smaller would mean that each of the smaller packages would be larger and maintained worse.

Leave a Reply

Your email address will not be published. Required fields are marked *