Indie Game Middleware

I

Video game development is both complex and complicated, arguably more so for independent developers who must often wear many different hats. Yet it’s not necessary to reinvent (and remake) the wheel each time we start a new game development project and developers can exploit a range of common technologies (middleware) to minimise unnecessary repetition, reduce complexity, enhance reliability, and expedite the development process. After all, implementing compelling gameplay logic is sufficiently challenging without also needing to consider efficient collision detection algorithms, scene graphs and hardware APIs.

Developers can approach these technologies in a number of ways. A multitude of off-the-shelf solutions, both unpaid and commercial, are available for most mass-market platforms. Alternatively, developers may choose to create their own middleware technology or modify an existing tool to fit their own purposes. So how should independent developers approach the selection, creation and management of middleware technologies? Unfortunately, I cannot offer an objective and universal answer. However, it is a question I grappled with over several years and, in this article, I outline the approach we adopted at Ozymandias Australia; the state of our current technology; and the lessons that may be extracted.

While I endeavour to present a critical and concise account of the decisions and their merits, a degree of narrative is necessary to present the context and considerations that informed what are quite complex choices. I also strive to provide an account that is accessible to less experienced developers and readers without a strong technical background. As a result, the article is reasonably lengthy and I fully encourage you to jump straight to the sections most relevant to your interests or, if you prefer, join me through the entire journey starting below.

Contents

  1. Overview of Approaches to Middleware
  2. Background to Ozymandias’ Approach
  3. Ozymandias’ Approach to Middleware
  4. State of Ozymandias’ Technology
  5. Lessons for Independent Developers

The What and Why of Middleware

Before launching into my experience at Ozymandias Australia, it’s worth and clarifying identifying the range of approaches available to independent game developers. Broadly stated, game developers can approach middleware in the following ways:

  1. Develop each project from scratch.
  2. Use existing middleware technologies without modification.
  3. Develop new technologies, or modify/extend existing technologies.

Each approach brings its own advantages and disadvantages, and developers will frequently combine aspects of multiple approaches to suit their needs. I’ll briefly address each approach in the most sensible order for consideration.

Developing from Scratch

It’s rarely advisable for independent game developers to invest their time and resources into building a game completely from scratch, without using any middleware technologies. It requires the developer to invest significant time and resources into developing solutions for problems which have likely been solved in available technologies. Developing the underlying systems without employing reusable technologies also dramatically increases the likelihood of errors and inefficiencies. The approach demands a high degree of technical competence and the capacity to transition between several different problem domains in a complex project. The viability of the approach is questionable in even niche cases, where low-level middleware technologies, such as graphics hardware abstractions, are likely to be employed.

Developing a game from scratch, or with only low-level technologies, may be necessary in a very small number of niche cases. For example, developing for archaic or embedded hardware; developing for obscure or emerging operating systems; or creating a game with novel architecture necessitating fine control over hardware operations. However, developing each game from scratch is not a viable standard approach and would require developers to repeatedly solve the same problems for each project.

Using Existing Middleware

Independent game developers now have access to myriad middleware technologies, from specialised modules through to comprehensive game engines. Unity and Unreal are both extremely popular commercial game engines amongst independent developers and larger studios alike, but many employ lower-level frameworks for 2D game development in particular.

Clearly, using an existing technology, or set of technologies, can save developers significant time and resources. Those resources can then be invested in the development of the game’s unique features and marketing, or the administrative and managerial burden of running a game development business. Comprehensive middleware solutions, particularly the more popular game engines, are also capable of dramatically lowering the technical barriers to entry, allowing developers with less technical expertise to create interactive experiences within the (often broad) confines of the toolset. Developers using off-the-shelf technologies also benefit from the technical expertise of the technology’s developers, often resulting in a framework that is highly stable and efficient, despite the flexibility required of a general-purpose tool. Similarly, off-the-shelf technologies are frequently subject to far more rigorous testing and quality assurance processes than most independent developers would be able to realise.

The benefits of using existing technologies are pretty clear: time and resources saved, lower barriers to entry, efficiency and power, testing and stability; so what are the downsides? Putting aside the specialised cases where there may not be any viable middleware solutions, the most compelling downsides to using existing middleware technologies are the comparative lack of flexibility, and the impact on skill development.

Firstly, in some cases, the existing middleware technologies may be poorly suited to the game you’re developing. Trying to work around the limitations or design philosophy of a tool may be more resource intensive, or produce a worse outcome, than creating a bespoke solution. The computational power of modern devices and breadth of available frameworks, modules, and engines have diminished the frequency of this problem dramatically. It’s almost certain that there will be suitable middleware technologies for the vast majority of independent game development projects, even if a single comprehensive solution isn’t available.

Secondly, using existing technologies may contribute less to the professional development of the developer, insofar as the developer is interested in cultivating a deep technical expertise. There’s a temptation to this line of reasoning that can prove disastrous if adopted uncritically. Yet there is merit to the deliberate cultivation of technical expertise that comes from personal familiarity with the design and implementation of middleware technologies, so long as it is undertaken in full awareness of the costs, direct and indirect.

Developing a Custom Solution

Whilst comparatively demanding and resource-intensive, custom solutions afford developers many advantages, particularly in terms of flexibility, iteration rate, and professional development. The development of new technologies need not be an all-or-nothing approach, and few developers eschew middleware technologies entirely, even when creating their own engines or toolsets.

Modifying or Extending Middleware

Many common middleware technologies are extensible by design, or developers may have access to their source code. In such cases, developers can modify or extend the functionality of the middleware to accommodate their needs. This approach blends many of the benefits and disadvantages of using existing technologies and developer a proprietary approach, depending on the extent of the modification.

A Beginner’s Naïve Approach

I founded Ozymandias Australia with Liam Alkamraikhi in 2010 amidst the flooding of the Brisbane River and rapidly diminishing employment prospects in the Australian game development industry. Liam and I had both majored in Game Design at the Queensland University of Technology. Liam, already a skilled designer and artist, was responsible for visual design and art. I was responsible for programming. Despite some experience in addition to my education, I was not yet a passingly competent developer. Unfortunately, this lack of experience shaped the early phases of the company’s development

About the author

Nathan Runge

Add comment

By Nathan Runge

Recent Posts

Recent Comments

Archives

Categories

Meta