Category Archives: September 2010
Stormy Peters interviews Bradley Kuhn, who represents the Free Software Foundation on the GNOME Advisory Board.
Bradley, you sit on the GNOME Advisory Board for the FSF but you don’t work there. How’d that happen?
Actually, I did join the GNOME Advisory Board as FSF’s representative when I was still an employee of FSF. I joined the Advisory Board in late 2001 when I had just been named Executive Director of the FSF. I continued to serve in both roles from 2001-2005, when I left FSF’s employment and Peter Brown took over as Executive Director.
At that time, Richard Stallman asked me to remain on the GNOME advisory board as a volunteer, primarily to provide ongoing continuity to FSF’s representation on the Advisory Board. From 2005-2010, that position was in fact the only official duty that I carried out for FSF. But, as a side point, non-profits are very different from for-profits in this regard; it’s quite common for important roles to be held by volunteers. Since non-profits operate in the public good, many experienced professionals are willing to give their time without compensation.
In fact, earlier this year, I was voted onto the Board of Directors of the FSF. So, now my primary role at FSF is as one of its Directors, and representing FSF on the GNOME Advisory board is an additional activity that I do as part of my role on the Board. I nevertheless continue to carry out both activities purely as a volunteer.
The FSF and GNOME have worked together since GNOME’s beginning. What do you hope to see them do together in the next couple of years?
I think the answer is easy: I hope we can promote software freedom together! FSF has always had a practical approach to advancing software freedom in the world. Specifically, one of FSF’s goals is creating a world where any task people would like to do with a computer can be done using only Free Software. At FSF’s founding, this goal was embodied in FSF’s sponsorship of the GNU project.
As GNU’s official desktop, GNOME is an outgrowth of that activity. By creating more and better Free Software for desktops, GNOME helps FSF promote software freedom around the world. We’re very grateful that GNOME addresses this important job for the freedom of software users, and I hope that collaboration between FSF and the GNOME Foundation can continue for many years to come.
You sit on the GNOME Advisory Board as a representative of a non profit organization. How do you think all of the free software related nonprofits can work together to push our missions forward?
I think the non-profit members of the GNOME Advisory Board have an important role. The for-profit companies on the Advisory Board are generally looking at how to generate revenue through use and improvement of GNOME. Of course, it’s important for commercial activity around software freedom to exist, but non-commercial activity is at least equally important. For our part, we non-profit representatives on the Advisory Board seek primarily to help GNOME on that non-commercial side, by helping the GNOME Foundation advance its public mission as a 501©(3) non-profit.
Indeed, through the Advisory Board, I try to bring my personal non-profit management experience to assist the GNOME Foundation. I’ve been very grateful that Stormy and the GNOME Board of Directors have often asked for my help in matters both mundane and political related to the non-profit mission of GNOME.
One recent example is the work I did in collaboration with Vincent Untz and Michael Meeks in drafting GNOME’s copyright policy document (which was recently approved by GNOME’s Directors). This document is an important counter-balance to the corporate interests who are asking GNOME community to accept their copyright policies as fait accompli. I think the publication of GNOME’s copyright policy had a positive impact on helping those companies understand GNOME’s philosophy. It’s also good that GNOME has now documented its long-standing and strongly-held positions on that issue.
On the more mundane side, I’ve been helping Paul Cutler and others who have been running the hiring process of a system administrator for the GNOME Foundation. I’ve been involved with a lot of sysadmin hiring at non-profits, so I’m very glad that I’ve been able to share some of my experience in that regard to give some “knowledge transfer” to the he GNOME Foundation on that issue.
There’s been a lot of debate on the GNOME Foundation mailing list about “open source software” versus “free software”. In our official press releases, we tend to say “free and open source software”. Some of our members say “free software”, some say “open source”, some say “FLOSS” … any words of wisdom for us in how we should deal with this?
My preferred term is actually “software freedom”. It avoids the misconceptions people have about the other terms, as some people still confuse Free as in Speech vs. Free as in Beer, and to many people, “Open Source” merely means what the words say by themselves: “source code available”, but that doesn’t encompass all the rights that are required to have software freedom.
When I seek to be as inclusive as possible and I am in need of a noun to describe the software, I use the acronym “FLOSS”. I know it generates some dental jokes, but, I think it’s useful at times to be as inclusive as possible. I’ve often drawn an analogy here to the LGBT community, another important social justice cause. That community has added letters to their acronym over the years to include sub-communities who have similar concerns. Sometimes, the goals of Open Source advocates and software freedom advocates do overlap, so it’s good to include everyone when the different groups are collaborating.
Also, I think including “Libre” is important (thus FLOSS rather than FOSS) because it shows the international nature of our community. It also resolves the ambiguity of Free as in Freedom by borrowing the unambiguous adjective from Spanish and French.
The FSF promotes free software licenses. Any comment on the licenses that GNOME is currently using?
Well, copyleft licenses are my favorite ones, so I’m glad that GNOME is copylefted. 🙂 As those who saw my GUADEC 2010 talk know, I’m currently advocating that GNOME consider switching from GPLv2-or-later/LGPLv2.1-or-later to the GPLv3-or-later/LGPLv3-or-later group of licenses. I’ve also posted recently on desktop-devel about this, too.
But, I understand fully that people want to take their time and consider carefully before switching. Software freedom licenses are, for our community, similar to the USA Constitution in their importance and weight. If you are updating the Constitution for your community, you definitely want to consider carefully!
In the meantime, I generally offer my time to GNOME hackers who want to ask questions about the v3 set of licenses. My hope is that we can have a conversation over the next year or so to discuss the idea, and perhaps the community can consider seriously a license upgrade sometime after GNOME 3.0 is released.
What do you hope to see the GNOME Foundation accomplish in the next couple of years?
Well, as I mentioned above, I hope that the GNOME Foundation can help the GNOME codebase move to the v3 set of licenses. 🙂
But, more than that, I think there are technical challenges that the GNOME Foundation can help GNOME answer. The two most important platforms for the next few years appear to be netbooks and mobile phones. I very much hope that GNOME can make its way on to these devices, bringing the whole GNU/Linux system with it onto those devices, too.
GNOME has a very important role in the GNU project, because, for the casual users, it is the system to them, as it’s what they see and are presented with each day while they use their computers. Therefore, my hope is that the software freedom concepts that GNU brings to users can be presented well by GNOME on every computing device that a user might choose. I hope that the GNOME Foundation can help make that happen!
Things have been changing a lot in GNOME. We are busy working on GNOME 3, we are creating a lot of applications and libraries to interface with “web applications”, what do you think is important for us to keep in mind as we move forward?
Software freedom for network services is a serious and newly relevant issue. Users can do much more interesting activities when they network their computers and cooperate online, but if we aren’t careful, users might lose software freedom when they do so. IMO, it’s important that when GNOME integrates with these online services, it favors services that respect the freedoms and rights of users. For example, I hope that GNOME will always favor OpenStreetMap over Google Maps when integrating with online maps, and favor identi.ca/status.net rather than Twitter when integrating with microblogging services.
Also, I think the work going on in the Snowy project is really important: namely, AGPLv3’d network services that integrate well with GNOME desktop applications. I hope that the GNOME community does more such network services in the future. I also heard that the GNOME Foundation is considering hosting some of these services at gnome.org in a way thatrespects the rights and freedoms of users. I think that’s a great idea and support it.
When you’re not working and volunteering at the SFLC, FSF and Software Freedom Conservancy, what do you do in your spare time?
I really like actually writing Free Software. I actually have the background to do Free Software development; I’ve just barely done any myself because I spend so much time doing policy, licensing, and management work. So, in the time left over, I try to hack on some Free Software when I can. I’ve recently written a few patches for BusyBox, and I did a lot of coding in the last few years on PokerSource, which is an AGPLv3’d system to play poker online, written in Python using the Twisted library.I also do play poker, too. I got into poker when I was in college in the early 1990s and ran the game in my dorm. I started playing seriously around mid-2001. Poker is basically the only hobby that I have outside of Free Software. Poker’s an interesting game that requires a mixture of patience, endurance, knowledge of probability, statistics, and basic logic, and a strong ability to judge how others are going to react in various situations. I actually think there is a lot of overlap in skill sets between working in the Free Software community and playing poker well. 🙂
A group of us even got a €0.01/€0.02 no-limit hold’em poker game going at GUADEC 2010 on the last night in the hotel lobby. Although, I think someone in the GNOME community (I won’t name names) is still mad at me because I was eating a stroopwafel when I was supposed to be dealing the cards and I subsequently caused a misdeal that changed the outcome of a €4.45 pot. 🙂
About the Author
Iago Toral introduces Grilo, a framework for making media discovery and integration easy.
This article introduces the reader to one of the challenges that media application developers have to face when they attempt to design and implement modern multimedia applications: the integration of content provided by many heterogeneous sources, and how Grilo, a framework focused on making media discovery and integration easy, helps developers face that challenge successfully.
Modern life and the new multimedia challenges
Traditionally, software platforms addressed the problem of multimedia by focusing mostly on providing means for application developers to deal with the huge variety and complexity of media formats and streaming protocols available: RTSP, MMS, OGG, MP3, Matroska, Theora, Vorbis, MPEG, H264, etc. Nowadays, thanks to projects like theGStreamer multimedia framework, developers can create multimedia software capable of rendering a wide variety of content without having to learn about the underlying complexity of all these formats and protocols or deal with other low-level considerations. GStreamer makes all of those details transparent for them, remarkably easing application development. It is no wonder then that any software platform today ships a multimedia framework: developers demand this from their platforms just as they demand a graphical toolkit and many other commodities.
However, thanks to the technological progress during the last decade or so, and in particular, to the growth of multimedia services on the Internet, a new challenge for media application developers has popped up: users all over the world consume massive amounts of media content every day. Users enjoy their personal collections of media, which can be stored in different places like hard drives, usb keys, network shares or UPnP servers. Users can also watch videos on YouTube or Vimeo, listen to music from services like Jamendo, Shoutcast or Last FM, and like being up-to-date by subscribing to podcasting services. These are just a few examples as there are many media providers which most people regularly use. Of course, this changes the way application developers face the development of multimedia software today; it is not only about playing back content in various formats and protocols, it is also about content integration: users want access to all of these services. Users want them properly integrated and they want the same experience no matter the service they consume the content from or the device they use to consume it. Whether it is a personal computer, a smartphone, their new connected TV or a Set-Top-Box, they only care about being able to consume the content from the services they like and have a great experience while they consuming it.
Unfortunately, existing platforms do not provide developers with appropriate tools to manage this situation yet, and thus, application developers interested in integrating multimedia content from these services are in for a lot of hard work. They must learn about the different APIs, protocols and technologies involved as well as coding application specific solutions for each individual service. Well known media applications in the GNOME desktop like Totem or Rhythmbox suffer this problem, but this is notGNOME specific at all, many other platforms lack support for this emerging issue.
It is only a matter of time before modern software platforms start shipping solutions to help developers face this new challenge. Just as we all expect any platform worth our consideration to provide a multimedia framework, there will be a moment too in which all of us will come to expect any software platform to ship a framework to help us with integrating multimedia content. This is because such a framework will be fundamental for creating successful multimedia applications in the near future and will be a tool developers will not want to be without.
Grilo is a new project which aims to make media integration easy for application developers. The way it operates is very simple and familiar. Grilo abstracts the differences among media providers, hiding them from application developers by exposing a single high-level API that can be used to interact with all of them. This remarkably eases the effort required on the application development side. Application developers can now code their solution once and know that it will work for all the media providers supported by Grilo.
Because of the familiarity of the solution used and the high level nature of the framework, most developers should feel fairly comfortable understanding how Grilo works. This also helps with getting started very quickly.
Grilo is split into two parts: the core (grilo) and a collection of plugins (grilo-plugins).
The core defines the fundamental concepts used by the framework, like the concept of media (GrlMedia), which packs metadata associated with a particular media resource (a specific audio, video or image item). By metadata we mean information like Title, Artist, Album, Duration or the URI of the actual media resource. It is a representation of the media that is independent of the service that provides it.
Another important concept defined in the Grilo core are the media providers (GrlMetadataSource, GrlMediaSource). These objects expose APIs that application developers can use to gain access to the media content exposed by the various providers. These APIs specify how you can browse, search, upload or remove content among other things. The key idea is that no matter the service you want to interact with, it will offer a well known interface. Because of this, application developers do not need to code specific solutions for specific services. Instead, Grilo makes all of them behave alike. Interacting with YouTube is no different than interacting with Jamendo as they both expose the same API and thus behave the same. The only difference between them is the content that they expose is different.
With the fundamental concepts defined, all that is needed are GrlMetadataSource and GrlMediaSource implementations of interesting media providers. This is achieved through a plugin system through which developers can write implementations of these objects as plugins for Grilo. A Grilo plugin is nothing more than a wrapper of the public APIs exposed by a particular media provider that adapts them to the cross-service APIs defined by Grilo. The actual implementations of the plugins live in the grilo-pluginssplit.
Right now Grilo has plugins for many services: YouTube, Vimeo, Jamendo, Flickr, Shoutcast, UPnP, Media Bookmarks, Podcasts and more, with a varying level of completeness and maturity. This means that application developers who choose to use Grilo can create applications that consume content from all of these services in one go and with very little effort.
Grilo and GNOME
Grilo started as a standalone development, not integrated with any specific platform, because we wanted to create a solution useful for as many developers as possible,GNOME or otherwise. However, because of the close relationship of its main developers with the GNOME ecosystem, Grilo was developed using GNOME technologies (GLiband GObject mainly) and GNOME was also the first and natural choice for the development team to explore. Indeed, Grilo is kindly hosted by the GNOME project, providing us with all the resources we need: wiki, bugzilla, a mailing list and Git repositories. All of this makes Grilo very natural for GNOME developers as this is a very familiar set of tools.
GNOME should define what its vision is on how media applications should consume and share multimedia content. Grilo can help by providing the building blocks to implement that vision. Indeed, some GNOME developers are already working on defining how this should work which is represented by the GNOME Media Server Specification. The idea is to separate the content provider code from the actual application consuming the content and communicate them over D-Bus.
This vision has benefits and drawbacks when compared to a non-distributed approach that should be apparent to most developers, but let’s focus on two of its advantages: it does not require applications to link against the media provider code which helps with stability for example, and enables application developers to use any language they like to implement their application. There is no need to use language bindings to exploit the media provider library.
With these principles in mind Grilo is being used to create a daemon that implements the provider side of the GNOME Media Server Specification. This daemon exposes the D-Bus APIs defined in this specification for application developers to consume. This is the Rygel-Grilo project (Rygel is the first consumer of this interface), a name we will change soon to something more representative. Just like Rygel, other GNOME applications can use these D-Bus interfaces to consume content exposed by this Grilo-powered daemon. The team already has plugins for Totem and Rhythmbox that we hope to push upstream soon.
It is important to note that the D-Bus APIs defined by the GNOME Media Server Specification are different from Grilo’s and are restricted to browsing and searching content while Grilo has a wider scope. It may turn out that some GNOME developers will still prefer to use Grilo directly. It is up to application developers to choose the approach that fits their needs better.
Nowadays our efforts are focused mainly on these areas:
- Polish the APIs to support more use cases or fix limitations. Ideally, feedback from application developers should guide this work.
- Complete and improve the plugins available, adding support for more features offered by the underlying services.
- Provide GObject-introspection based bindings to be more developer friendly. Grilo is written in C_, but many application developers prefer to use more modern languages to code their applications. As we mentioned before, developers have the option to use _Rygel-Grilo and D-Bus from any language, although this approach has some limitations at the moment. Therefore having language bindings is still an important milestone for us. We are working hard on that and we expect to have related news very soon.
- Integrate with the GNOME desktop. Rygel-Grilo and the Totem and Rhythmbox plugins are the first step in this direction. We are working on finishing a first version of these projects and then we will try to integrate them upstream. Another idea in this regard is to start moving plugins from these projects to Grilo, which would have two advantages: the plugins would become available for any other application using Grilo and all interested developers could cooperate in the maintenance work.
- Help application developers to use Grilo successfully. This last bullet is particularly important since every framework developer needs feedback from application developers to improve and evolve the framework in the right direction.
For readers interested in learning more about Grilo and how they can use it to create modern media applications I suggest that they look at the documentation available in the project repository. This documentation includes a quick start guide for application developers that will get the interested reader started in a few minutes through a few simple code examples.
About the Author
Iago Toral is a partner and employee of Igalia where he works as Software Engineer in the Desktop and Mobile group.
Paul Cutler continues GNOME Journal’s Behind the Scenes series, interviewing Joanmarie Diggs. Joanmarie talks about her work on GNOME accessibility, her motivations and some of her favorite things.
- Age: Old enough to have grown up with rotary phones, to have typed papers and filled out forms via typewriter, and to remember when a college education cost less than a house. We are approaching the second anniversary of my 39th birthday. Oh, alright, I’ll be 40 in November. 🙂
- Located in: Nashua, New Hampshire, USA
- Profession: Assistive Technology Specialist and Curriculum Developer (boils down to: I’m a teacher working with individuals who are blind or visually impaired.)
- Nickname on IRC: Joanie (both gnome and freenode)
- Homepage and blog: ‘http://blog.grain-of-salt.com’:http://blog.grain-of-salt.com, but like many folks, I stopped blogging and started microblogging. I’m “joanmarie” on most networks and primarily use Twitter.
In what ways do you contribute to GNOME?
I’ve been contributing to Orca for a little over four years, most of that time as one of the developers. Since the end of March 2010, I’ve been the Orca maintainer. I’ve also dabbled a bit in WebKitGtk accessibility.
How and when did you get involved in GNOME?
‘Twas early 2006, courtesy of Massachusetts threatening to make ODF the official file format of the Commonwealth. In the ensuing brouhaha, a number of companies came to visit the agency for which I work (The Carroll Center for the Blind), one being Sun Microsystems. Peter Korn and Willie Walker did some demos, including Orca. And for the first time I saw something I had wanted for the bulk of the previous decade, namely a screen reader that didn’t cost $1200 and which users (and teachers) could truly make their own by providing input and contributing code. At the time, my non-work systems were running Kubuntu, so it was just a matter of crossing over to GNOME and getting up to speed on Orca and how things worked in the GNOME community.
What motivates/keeps you motivated to work on GNOME?
- The original motivator has not changed: Seeing people taking charge of their destiny by shaping the tools they want and need to achieve their goals is extremely cool.
- The people: I’ve met and worked with a bunch of incredible people, both users and developers, whom I wouldn’t have otherwise had the privilege to meet, let alone have in my life.
- The challenge: Some people climb mountains; I help develop a screen reader. The latter seems to be a better fit with my lousy balance, not to mention my fear of heights, bugs (of the creepy-crawly, multi-legged variety), and large woodland creatures with sharp teeth and/or claws. 🙂 But all joking aside, I do enjoy a good challenge and learning new things. Working on Orca provides me with both.
- The personal commitment I’ve made: To the users, to the GNOME community, to my fellow developers.
How much time do you usually spend on GNOME?
These days, it’s pretty much a full-time (volunteer) job. I re-arranged my DayJob schedule so that I work (insanely long days) midweek. That frees up Friday, Monday, and the weekend to focus on GNOME.
What do you think is still badly missing in GNOME?
- Sufficient funding and contributors to ensure that GNOME is compellingly accessible. With respect to Orca itself, my new teammate Alejandro Leiva introduced me to the concept of “bus factor” yesterday. Alas, he does have a very valid point, one whose applicability extends beyond Orca to all things GNOME accessibility.
- Other and improved Assistive Technologies: Solutions for users with learning disabilities; voice recognition, both for people who cannot use a keyboard and people who would prefer not to; continued development of OCR solutions, a braille translator, etc., etc.
- Women, especially developers and module maintainers.
- Market share.
- Bling (hopefully the GNOME Shell team is providing that).
- Eye-poppingly awesome games.
Which book is on your bedside table?
At the moment, there are a couple—both of which I am about half-way through (and put on hold due to too much Orca work to do. See the ‘bus factor’ reference above):
- Seth Grahame-Smith’s “Abraham Lincoln: Vampire Hunter”
- Michio Kaku’s “Hyperspace”
Who or what in your life would you say influenced you most?
I wouldn’t say. I couldn’t, even if I wanted to. Life is a journey. I am who I am and where I am because of the myriad of people whose paths intersected my own, and the nearly four decades(!!) of experiences I’ve had. To single out one person or one thing would at best be an inaccurate representation; at worst, it would be unfair to many wonderful people.
How would you describe yourself?
I’ve been called “endearingly neurotic.” Though, admittedly, some days I’m more endearing than others. So perhaps it would be more accurate to say “mostly harmless.”
What do you get passionate about?
Aside from Orca and accessibility, you mean? 🙂
Any hobbies outside of GNOME?
And I’d schedule those in when, pray tell? 🙂
In a previous lifetime, I spent a lot of time cooking (vegetarian) and baking. And reading. I also used to find it amusing to attempt home repair. I’m admittedly a bit of a homebody….
But all of that said, to this very day, I can always find time (sometimes hour-long chunks) to peruse the OED. I own the 20-volume set and simply love etymology. I’ve just crossed the line from geek to nerd, haven’t I??
If someone visits your country, which spot is a must-see?
What’s your favorite:
Eccentric/quirky + brilliant + hilariously funny
“What doesn’t kill you makes you stronger.”
“Monty Python and the Holy Grail”
Toss up between Indian and Thai
Outside: Northern New England, especially in the fall and winter.
Inside: LL Bean’s Freeport Flagship Store at 3 AM. Yes it is open then, and yes, it is quite surreal to be the only shopper in an enormous campus of stores.
That’s a hard one. But if forced to pick one…. Rusted Root.
According to last.fm, “Numb” by U2. But Talking Heads’ “Psycho Killer” (the live version) might really be my favorite.
Chris Lord shares his experiences and six laws of writing simple games for GNOME, using Clutter.
At GUADEC 2010, my colleagues and I did a talk, Everything you wanted to do in Clutter (but were afraid to ask)”, which covered some of the things that we don’t often see people doing with Clutter. My part of this presentation was focused on writing simple, real-time games. I chose Clutter as one of the primary tools to achieve this, but I hope the tips I gave would apply equally well to a game written in any library. In this article, I’ll elaborate on what I presented.
The GNOME community contains many talented application developers, and yet you see very few games. In particular, there are very few real-time games. This is probably down to a number of reasons, but one of those reasons may be that the focus of writing games is very different to the focus of writing applications.
Writing applications, your top priorities tend to be stability, usability and maintainability. An application often goes through several developers in its lifetime, so keeping the code tidy, readable and adhering to best practices pays off immeasurably. Likewise, applications are often used for critical work, and to increase productivity, so they are of no use if they aren’t stable and they aren’t understandable. GNOME’s focus on ease-of-use produces great applications that are often used even in corporate environments.
Unfortunately, very little of that is of any use when it comes to games. When a game crashes (and with modern games, it’s usually ‘when’), it isn’t that big a deal. You reset, load up your last auto-save, and replay the lost 5 minutes. With smaller games, such as those on the iPhone, the likelihood is you didn’t lose anything at all, or that the time-impact of recovery can be measured in seconds instead of minutes. Of course, no application should crash, but stability is less of a concern with well-designed games.
Usability is also less important. Games are inherently a learned activity. Like driving a car, you have a way of interfacing with the world that isn’t through direct manipulation and this is something that must be learnt and practised. With this in mind, and with the fact that any well-designed game should place you within the game with as little interaction as possible, there are far fewer usability concerns than with applications.
Finally, maintainability is a much lesser concern too. It is unlikely that you’ll use the code from a game again. If you’re lucky enough to have had such a successful game that you can consider a sequel, that would be the time to start focusing on maintainability, but small games tend to be one-shot activities. Quite often written by one person. Spending hours creating a great abstract representation of your gaming world isn’t going to benefit those that play it and diverts you from the real focus of game development.
The primary, and possibly only, focus of games development is gameplay. Your number one priority when writing a game is to get to a point where you can test how well it plays, and how well your ideas and concepts work given the limitations you work with. Unlike application development, shortcuts do work in games. The quicker you can get to testing the gameplay, the longer you have to make sure your game is actually fun to play.
Turn-based games are much easier for applications programmers to grok, as they are usually driven directly by user input. Real-time games have a world that continues regardless of the user, over which the user has some influence. This is very different to the environment of an application.
With this in mind, I’ve come up with six guidelines that I think will benefit anyone developing a small, real-time game. In true Intel fashion, I’m going to name these ‘laws’ after myself as well. Let’s call them “Lord’s Laws”.
Law 1 – Steal
After you have your game idea, the first thing you want to do is find some software; either another open-source game or library, that will do most of the heavy lifting for you. Writing a new library may be fun, but it’s not the quickest way to reach your objective.
Law 2 – Take advantage of your software
Once you’ve chosen the software to steal, you need to make sure to manufacture your game to take best advantage of it. Using Clutter, for example, you have a great animation framework, great support for 2d effects and lots of supporting libraries for doing video, physics, user-interfaces and the like. You shouldn’t try to do something if the software you’re using makes it difficult.
Law 3 – Use images for everything (aka Generation is bad)
Lots of programmers have the great idea of programmatically generating all of their graphics. In the majority of cases, this is actually a work-around for lack of drawing skill. It’s the rare occasion where this doesn’t just make everything look a lot worse than it ought to.
Law 4 – Keep it simple
The classic games that everyone remembers are almost all simple games. Space-invaders, Frogger, Pac-man, Donkey Kong, Defender… It’s easier to excel when your objective is simpler. The more complex the objective, the more people you need to accomplish it well, and the more time you need to accomplish it at all. Simplicity isn’t a bad thing.
Law 5 – Quick and dirty
Hacks are totally OK in games. You’re not going to reuse the code, and if you are, you can always rewrite it when you get round to reusing it. Don’t be afraid to introduce gross hacks if they work and they save you time.
Law 6 – Get help
The final, and most important law. It’s rare that one person excels in all the areas required to create a game. The GNOME community is very accommodating. Find a hero, or heroes, to do the jobs that you aren’t good at. It can be surprising what people will help you with if you just ask.
When I presented this talk at GUADEC, I had written two games. One of the games, I had broken every law in this list and the other I had followed them. The first game was a simple maze/collection game, available here on Gitorious. In this first game, I used generated, vector graphics and a massively over-engineered abstraction of the game concept. This resulted in an incomplete, bad-looking game (Clutter does not excel at vector graphics), riddled with bugs. I also wasted a lot of time writing library code. Thankfully, most of this library code has actually succeeded in being reused now, but the game itself was never finished.
The second game, Happy Wombats, I followed each law. While I have continued development since GUADEC, at that time it was no bigger (in lines of code) than the first game, yet included a fully-featured level editor, high-scores and, ironically, far fewer bugs. In this game, I make extensive use of support libraries (namely ClutterBox2D), and highlighted the strengths of the libraries I used.
Most importantly, I got help from a GNOME hero writing this game. Hylke Bons drew all the graphics for me and provided a lot of useful design input. This isn’t something I could have achieved alone.
Since GUADEC another GNOME hero, Iain Holmes, has been helping out, writing music and generating sound effects. Because I got the gameplay developed more quickly, it generated more interest and resulted in a better looking (and sounding!) game more quickly.
With these laws in mind, I think any capable programmer can produce a decent game that we can all enjoy. I hope that others will be able to follow them and we can have a much larger, and more compelling library of games for GNOME-based platforms.
About the Author
Chris Lord works as an engineer in Intel’s Open Source Technology Centre, working on MeeGo, formerly Moblin.