LWN.net Weekly Edition for June 5, 2014

Open-source real-time strategy gaming with 0 A.D.

If you've played 0 A.D., you've heard the phrase "Ti esti?" ("What is it?" in ancient Greek) a lot. Whether you want your citizens to farm fields, mine metal, or build buildings, or want your cavalry to engage enemy civilizations in battle, whenever you select your units, they always ask "Ti esti?". As you continue playing, your citizens continue to display fluency in ancient Greek. That's because 0 A.D. is an open-source real-time strategy game — reminiscent of games like Age of Empires — that has a focus on historical realism.

This attention to linguistic detail is only one sign of the ambition of Wildfire Games: "an international community of dozens of game developers and gamers, who mostly contribute in their spare time on a volunteer basis" to the development of 0 A.D. Different civilizations in the game not only have different strengths and weaknesses, they are also modeled directly on a particular era in that civilization's history. That same attention to ancient language is also a sign of 0 A.D.'s continued alpha status: civilizations that you'd expect to speak in different languages, such as the Gauls, also speak ancient Greek. Nonetheless, the game impresses with its playability and fun, which belies its incomplete state. 0 A.D.'s recent Alpha 16 release on May 17 makes for a great opportunity to look at the project to date.

0 A.D. began in 2000 as a concept for a game to be built on top of the proprietary Age of Empires II engine, but the company Wildfire later decided to develop it as an entirely new, stand-alone game. 0 A.D. uses its own home-built engine, called Pyrogenesis. In 2009, the project became completely open source, with the code licensed as GPL and its art assets available under CC-BY-SA. The project is under heavy development, with significant updates coming fairly frequently. The last couple of years have been particularly good for the project. In 2012, Wildfire Games joined the non-profit Software in the Public Interest, which has given the 0 A.D. project a non-profit structure for monetary transactions like paying for development and receiving donations. 2013 saw three alpha releases and an Indiegogo fundraiser that raised over $30,000 toward development costs. As a result, the project has hired a developer for a year's work on the game.

For those not familiar with real-time strategy gameplay, the following is the general flow of 0 A.D. Games have two to four players, in any combination of human and AI players. In the larger games, players can play free-for-all (where everyone is on their own) or form teams (though it may be difficult to coordinate effectively with an AI teammate).

Players start the game on one part of a map, with a few worker units and a "base" building. In the first few minutes, the priority is almost always building an economy: players click on the units and order them to gather resources, and train more workers to speed up growth. From there, the player has a variety of strategic choices to make, all with advantages and trade-offs.

For example, if they would like to launch an early strike on their opponent, they will focus on training basic infantry and perhaps cavalry soldiers as soon as possible. This means delaying technological development (e.g. by ordering workers to construct buildings that allow players to train more advanced, expensive soldiers rather than pursuing technology). If, instead, the player would like to gain an economic advantage, the player could train many workers, and construct buildings that improve resource gathering. This could allow the player to outnumber the opponent later in the game, as the player could then afford more units, but risks vulnerability to an early attack, as producing an army is delayed in favor of improved resource gathering.

All of this activity, like all actions in the game, takes place in "real-time". That is, there is no waiting for one's "turn": one always has the ability to act (e.g. select units, order units, train units from buildings, and research upgrades for buildings). This makes planning, speed, and adaptability valuable skills for a player.

Thus, the three main economic concerns a player has to "macromanage" in this game are resource gathering, technological development, and unit production. Once the player commits to combat, or has to defend from an attack, "micromanagement" skills become crucial. The player can select individual units or group units (and create hotkey shortcuts for them) and order them to attack in the optimal manner. Skilled players who want to work on their economy while also pushing an attack will often briefly pull back their troops to attend to their own base, and then order the soldiers back on the assault when they can give combat their full attention.

0 A.D. differs from other real-time strategy games with its focus on historical realism, the ability to play multiplayer games without relying on a centralized server (a hosting player must forward UDP port 20595 through any firewall or NAT and disclose their IP address to other players), and with certain gameplay mechanics details. For instance, troops can be grouped into different formations at the click of a button; player's armies can close ranks when on defense, or split their units and flank their enemies. Creative players can also use the built-in Scenario Editor to make maps for multiplayer games or for playing against an AI opponent.

Alpha 16 is a significant step up from the previous release. The game now has 14 different localizations, as noted in the release announcement. This is a vast improvement from the English-only Alpha 15 released just a few months earlier; players from Brazil, Germany, and Japan, and many other countries can now enjoy the game in their own language. A new AI opponent, Petra, is noticeably smarter than the prior Aegis AI, particularly on defense. There is a new song for those playing as the Gauls or Britons, and also some graphical enhancements, such as new ships and animals.

The game's system requirements are pretty light: 512 MB of RAM, a 1 GHz single-core processor, the ability to support 1024x786 screen resolution, and a graphics card that can handle 3D hardware acceleration and OpenGL 1.3 will do. Strangely, the system requirements suggest one needs a dedicated graphics card with a minimum of 128 MB memory, but the Intel HD 4000 Graphics on my laptop worked very well. The game even played quite smoothly for me with all graphical enhancements turned on in VirtualBox running Lubuntu 14.04 (since Alpha 16 was not yet packaged for Fedora 20).

Much is still missing, which is to be expected in an alpha release. On first start-up, 0 A.D. tells the players that the AI is incapable of using naval forces, for example. 0 A.D. can also slow down noticeably in the late-game, as more units are built and the demands on the AI are increased; improving game performance is a task for the next alpha. There is still no single-player story campaign, only the option to battle the AI ad hoc or play multiplayer matches. I found the multiplayer game lobby to be sparsely populated; I was unable to join a multiplayer game while preparing for this review. It is possible to set up a game for friends to join through port forwarding as mentioned above, but I was unable to find someone to play multiplayer with me that way. However, there is some discussion on the forums about starting regular multiplayer meetups.

0 A.D. has no official final release date, nor an official expected date for a beta release. Nevertheless, a look at the forums shows significant interest from potential contributors, and the difference in quality between alpha releases is palpable. Those with knowledge of C++ and JavaScript can contribute as developers as described on the project's Trac page. There is also space for many other volunteers: people with knowledge of ancient history and languages, voice actors, musicians, and artists. Those interested in supporting the project, but lacking the time to contribute, can donate to assist development.

0 A.D. is an intriguing game, with an interesting future ahead. I look forward to following this ambitious project as it continues development.

Comments (16 posted)

Questioning corporate involvement in GNOME development

It is a rare free software project that feels it has too many developers; indeed, most could benefit from more development help. One way to get that help is to have a company pay developers to work on a project; the presence of paid developers is often one of the first signs that a particular project is gaining traction. But paid developers often bring with them worries that the company footing the bill will seek to drive the project in undesirable directions. The GNOME project, which is conducting its annual election for its board of directors until June 8, has an opportunity to say that corporate involvement in development has gone too far — or not.

In particular, board candidate Emily Gonyer has taken the position that corporations have too much control over the GNOME project. Her declaration of candidacy is explicit on this subject:

After a bit of discussion, it became clear that Emily was concerned about one company in particular:

She also stated that contributions from unpaid developers should be "favored" in some unspecified way. A project like GNOME, she said, should be run and developed by volunteers.

Needless to say, this set of opinions is not shared by everybody in the GNOME development community. Bastien Nocera (a Red Hat developer) made it clear that he found that position insulting. Even Richard Stallman chimed in, saying "We're happy when the developers of free software get paid." But Emily's remarks will certainly resonate with some developers; concerns about corporate involvement in free software projects is more widespread than one might think.

In this case, it is not entirely clear that companies are behind whatever difficulties GNOME may be facing. The GNOME project has clearly struggled in recent years; the proliferation of GNOME forks and ongoing criticism of the project's core decisions make that clear. But it has not been demonstrated that some sort of corporate agenda is behind these problems; it is not in Red Hat's interest, for example, to cause users to flee from its flagship desktop environment. If corporate desires have truly "trumped what anyone else wants/needs", it should be possible to point out specific examples where this trumping has happened, but such examples are not (yet) on offer.

Equally unclear is what can be done about this problem, if, indeed, it is deemed to be a problem. Certainly the GNOME board could, if it were sufficiently determined, manage to reduce the amount of company involvement in GNOME development. That does not seem like anybody's idea of the path to happiness and the Year of the Linux Desktop, though. So one would have to attack the problem at the other end by trying to increase the level of volunteer contributions. The GNOME project appears to work hard already at attracting new developers; examples include its Google Summer of Code participation, the Outreach Program for Women, and numerous conferences around the world. There is undoubtedly more that could be done to bring in new developers, but it is hard to fault the project for its current efforts.

Another option, suggested by former GNOME executive director Stormy Peters, would be to increase corporate participation by bringing in support from a wider range of companies. Involvement from more companies would serve to reduce the influence of any given member of the group. That seems like the sort of task the board of directors should be concerned with.

For the curious, Dave Neary and Vanessa David performed a survey of corporate involvement in GNOME development back in 2010. Their report [PDF] showed that unpaid developers, while making up about 70% of the development community, accounted for just under 25% of the contributions to the project; a group of about a dozen companies, led by Red Hat, accounted for the bulk of the rest. How that picture may have changed since 2010 is unclear; no followup survey has been done thus far. But things probably have not shifted to the point that any single corporation has a dominating influence over the development of the GNOME project as a whole.

And that is important. When a project is controlled by a single company, that company's needs will almost certainly win out over anything that the wider community may want to do. One need only look at Android for a classic example; company-dominated projects can still be valuable free software, but they tend not to be community-driven. If GNOME were to be controlled by a single company, it might well go in directions that would not be welcomed by its development community. Some people, it seems, feel that one company has indeed reached a level of control where it is able to take the project in unwelcome directions.

When one reads the discussion among the candidates for the board, there is one topic that stands out by its absence: with the exception of Emily, none of the candidates have expressed any discomfort with the direction of the GNOME project or the functioning of its community. Perhaps that is appropriate; there may be no cause for concern. But, again, the forks and ongoing controversies suggest that the project might want to be asking itself whether all of its decisions have been wise. Emily may or may not have found the correct target when she named corporate involvement, but she may be doing the project a favor by asking, in a high-profile way, whether something might be wrong.

In any case, the GNOME community now has an opportunity to make a statement about corporate participation and the direction of GNOME development. If enough GNOME developers are sympathetic to Emily's position, they will elect her to the board and she will be able to push for change, though there are limits to what the board (which is not empowered to make technical decisions) can do. Her chances are reasonably good; there are eleven candidates for the eight available positions. Voting continues through June 8, with the results to be announced on the 10th.

Comments (102 posted)