THE PEARLY GATES OF MIDDLEWARE



We (selectparks) were considering using the engine of the first person game Quake III Arena in our own current project 'acmi {{ park }}'6. To increase the polygon resolution (polycount) in our game models, and the scale of landscape available in the game, we found we would need to rewrite most of the engine. Even if it were more practical to do this than construct our own engine (which would take around two years and a huge amount of labour), we would need to purchase the engine sourcecode for $US250 000 in order to be able to legally and freely distribute the resulting game. Our two options of a basic modification with restricted functionality and distribution, or an engine crafted from the existing codebase were oustide both our own ambitions as artists, and the feasibility of the arts funded project.

To solve this problem, we investigated the use of 'middleware' which costed around a quarter of id Software's Quake III for a full license. Middleware comes in the form of pre-compiled (closed source) code libraries that can be used in conjunction with components of an existing engine to provide certain 'bleeding-edge features'. Thankfully we were able to aquire sponsorship for these libraries and used them with our own engine, the 'Park Engine'.

While it was unimportant to us at the outset, we are restricted from adapting the middleware in any way as the code is pre-compiled (not source code). Also, we are legally restricted from using the middleware itself to further develop the engine (we have spent a year and a half making) after the designated development period.

OPENING THE ENGINE

These problems will continue to plague both artists, developers and the medium's own critical development unless strategies are in place to make the medium more accessible to both artists, arts budgets and audiences.

Put simply, if games are ever to have a scene as prolific and critical as that of digital video short films, the cost of material needs to drop to that of a handycam, rights must reside with the artist, and the presentation medium needs to be as generic as any domestic computer.

GarageGames have taken an interesting approach to this problem. The complete sourcecode to the excellent cross platform Torque engine [Tribes II] can be aquired at the cost of $US100 per seat. While this is a great starting point for an emerging developer the licensing agreement still holds proprietory restrictions that ensure that should the project do too well [US$500,000 or more] the license suddenly switches to that of a full commercial rate. Secondly the codebase can not be distributed without paying the per seat fee. Understandably companies like GarageGames, 4drulers, Conitec must protect their assets. However, when the artist ihim or herself is a developer, is this abstraction of ownership necessary to make a game, and is it [in a wider sense] conducive to the development of the medium amongst artists?

Here Open Source and the General Public License become integral partners in the future of truly independent game development. From my perspective as an artist and developer, it is the only way forward. While I have used the (open source) Linux operating system for a few years, discovery of quality open source options for game production came late and so my massive relief at having powerful free and open code is mixed with some regret.

Clearly the greatest value of open source projects to the independent developer or artist is the transparency of the technology and the ability for the artist, not the proprietor to have rights to contribute to the medium's development at every level.

Recent years have seen the emergence of many opensource game-engines, free engines with open code-bases that are not far behind many of the proprietory products available. Under the GPL anyone is allowed to use these projects without distribution restriction or cost.