Thursday, December 08, 2011

Gnome Games Modernisation

The GNOME Games project maintains fifteen small "five-minute" games for the GNOME desktop.

Unfortunately over time the games have struggled to keep up with the latest GNOME technology due to the time required to do this.  And the further behind we've got the harder it is for new developers to get involved as the code is hard to work with.

So the time has come for a great modernising.  And here's where you fit it :)

We've picked eight of the games we think are the best and we want to focus on bringing them up to modern standards.  The games are Chess, Five or More, Mines, Iagno, Mahjongg, Sudoku and Swell Foop.  These games all have been or are in progress of being ported to Vala.  Vala is a modern programming language that will be familiar to anyone who has used Java or C#.

We have a Matrix of things to do:
with the goal being to turn everything to green.

So, if you're interested in helping out follow any of the bug links and start fixing the bugs!  All the tasks should be able to be completed independently and shouldn't be too complex to achieve.  Anyone is welcome to attempt these and there are non-coding tasks (documentation and design).


amigadave said...

Do you think that any of these tasks would fit in with GCI (Google Code-In: I can imagine that some of the documentation might fit, as relatively short, self-contained tasks. Some of the other tasks seem to be of the right difficulty as well.

The next round of updates to GCI tasks happens on the 16th December, so would you be willing to submit and mentor some tasks based on the modernisation goals? I can try to organise some mentors for the documentation tasks, and possibly the artwork tasks, so that would leave mostly coding, and possibly some research, tasks.

Please let me know if you are interested, so that we can plan in time for the 16th. Just send me an email or find me on IRC (amigadave). Thanks!

MrMcQ2u said...

I always thought it was a bit strange for desktop enviroments to ship games developed specifically to said enviroment rather than developing a framework to add value to desktop agnostic games(sdl, opengl etc).

It is slightly annoying to have a game require qt dependancies when you use gnome and vice versa.

I dont want to take away from the great work people put into creating games for gnome or kde but I think that if gnome and/or kde are to compete with the likes of Microsoft with regard to gaming then they need to collaberate on creating an alternative to services like xbox live.

Maybe create an open gaming alliance in order to develop a good decentralized protocol(backend) which games developers can utilize and which individual DE's can develop ux upon.

Take advantage of standards which mozilla and other groups are developing like .

this way to the blixtra blog said...

One thing that bothered me when developing a simple game was that the score api was a local library in gnome-games. If I wanted to make use of it I either needed to get my game in gnome-games or copy the relevant files. It seems to me it'd be a good idea have the scoring as a separate library or a service with a dbus api.
What do you see as possible issues with such an approach?

Anonymous said...

The whole Achievement/Trophy is the only thing I would gladly pass on these changes.

Andrew said...

How about you put some of these as tasks for Google Code-In?

Anonymous said...

Is Vala a requirement? To be honest, I'd like to contribute... but I don't want to learn a new niche language (by now it's Gnome only, isn't it?) when I'm fluent in other "modern" languages such as Python (that I believe it's OK for Gnome).

At least it's not a rewrite in javascript, but... why Vala?

Anonymous said...

Sudoku is currently written in Python using Pygtk... surely it would be easier by far to port it to the new introspection bindings, than to rewrite the entire thing in a new language?

Robert Ancell said...

MrMcQ2u, in some ways the role of the GNOME Games project has changed over time. Initially it brought together a set of games for a desktop that had none. Since GNOME has got more successful there are many more games around and new technologies have got more popular.

So now we have a narrow focus, to produce small games that use only GNOME technology (so they can be installed on any GNOME desktop and run for all users).

We're less focussed on leading the way for all gaming on GNOME but very happy to fit in with existing frameworks where they exist.

Robert Ancell said...

this way..., libgames-support has been a private library so we didn't have to maintain an API. There's talk of splitting the games into separate modules which would probably require it to be public. I'm not opposed to it being public and the best place to discuss this is probably on bugzilla/the mailing list.

Robert Ancell said...

Why Vala? C is very easy to make mistakes, have poor structure in the code and hard to find new developers to work on it. We experimented with Python and Javascript. The former is also hard to maintain without a large set of unit tests (due to not being a type safe language) and has some performance issues (particularly in startup time). The latter was too new, has the same type safety issues as Python and is being downplayed as a language to use in GNOME. Finally consistency across all the codebases was seen as important as we were limiting which games each maintainer was able to work effectively on.

Anonymous said...

Maybe, but doesn't the use of Vala substantially restrict potential contributors? I know it resembles C# or Java, but really - are there more than a few dozen experienced Vala coders on this planet?

Robert Ancell said...

In my experience and in others (e.g. Shotwell) Vala has not been a blocker to contributors. I have actually had a number of contributions to projects where the contributor has said "I have no idea about Vala but I think this patch is correct" and they have provided patches that work perfectly. That's a major difference to C and also Python. (Python patches often have side-effects that contributors don't notice).

BTW I was a Vala skeptic, my thoughts on why I changed my mind:

Jeremy Bicha said...

Bob, nice blog post!

Sudoku was ported to pygobject for 3.2. See John Stowers' comment at The port to vala is a bit more work but some of the initial work has already been done.

Tiffany Antopolski said...

@amigadave, We had a successful gci for gnome-sudoku docs in the first round, and I will be posting 6 gnome-games documentation tasks for the second round.

Anonymous said...

I want to add to the discusion about vala. I've learned c and java at the university. The last year I've added to a vala based project. At first I found it a pitty that the project was not written in java, but now I'm really glad. Vala is fast, has a good object oriented syntacs and is close enough to c that anyone that knows c, can start coding in vala right away.

Anatol Pomozov said...

Robert: I really think that Vala is the right choice. It is super fast (about the same speed as equivalent program in C) and it statically typed (I think that it is a big plus).

I've used Vala for a few of my toy projects on gtk and I can say that I *love* Vala language.

Anonymous said...

If I wanted to learn Vala, what steps would I have to take?

The language itself isn't even totally documented.

Anonymous said...

Dear Anonymous,

1) read wiki first:

2) Try small examples:

3) Join mailing list or irc to ask questions.

4) Have fun :)