The Question of Backward Compatibility
A couple of weeks ago, I was on a gaming network, and I came across an older thread in which someone was asking if anyone was still playing on the Xbox 360 or if most people had made the move to the One. There was, of course, a lot of discussion on the thread, everything from make the leap, to make the switch to PS. There was also a lot of talk about how good a console people think the 360 is, with which I have to say I agree; I still play mine.
All the talk about old systems got me thinking about backward compatibility. How do we as developers handle the issue of backward compatibility? What are the factors that go into making the decisions that so many players both praise and lament, and ultimately lead to such statements as, ‘that game is too new for my hardware’, or ‘now I can (or, now I need to) upgrade my machine’?
As I pondered these questions, I realized that the answers were quite complex. There is no doubt that the march of technology is relentlessly forward. And although my experience is mostly with small studios, research and connections have taught me that even large studios wrestle with this relentless force. There is no one singular factor which determines backward compatibility decisions. In fact, it’s not even a few factors; there are many factors and forces which influence how this decision is made.
Evaluating Backward Compatibility
When developers evaluate a title for backward compatibility while it is in development, three major factors influence our thought process: new hardware adoption, old hardware support, and new development software. I have seen that as these factors come into play and change, we see even the larger developers, and publishers, shifting backward compatibility.
One of the major things these factors affect is profits. Expected profits are greatly responsible for how backward compatible a particular title will be. Now I know that many small indie studios see the subject of making money as somewhat taboo. While I understand that this subject can be easy to ignore for many reasons, no studio, large or small, can afford to overlook this issue; after all, we still must pay the bills and eat if we wish to continue to do this thing we love so much, so profits matter.
The Hardware Angle
Now, new hardware adoption, the speed at which the newest hardware gets adopted by the largest number of current players, greatly influences the adoption of any new title. There are several ways through which this manifests itself, one being how many players’ hands can we get a title into, and who is going to be the most energetic audience for playing and talking about a title. Often a studio will put a title on the newest hardware to get that wow factor, and to get some free marketing from the hardware manufacturers, all the while working on a backward compatible version so that the game can then be taken up by the larger community of players and help the title hit a critical mass of adoption. By looking at new hardware adoption trends yet staying aware of older hardware saturation, studios can take advantage of newer technologies while staying relevant with the current norm. There is also the fact that when we start development on a title, we are usually out on the bleeding edge of hardware, but by the time we finish development and release a title, that hardware may have been available for several months if not a year or more.
Old hardware support is how long hardware manufacturers are supporting older hardware with updates for software functionality and compatibility, and this too has a large impact on backward compatibility decisions. We are often in communication with the various hardware manufacturers in various ways, either directly through contacts, or through information they make available to developers on when they plan to phase out or no longer support older hardware. Sometimes a manufacturer will want a studio to support an older technology for various reasons and a backward compatible title is a good way of keeping older hardware fresh. Eventually, however, that hardware will drop off a manufacturer’s radar and at that point we developers must also decide when we no longer will support it with new titles. This decision is often made from an amount-of-work standpoint. The larger the scope of hardware we support, the more work it is for us, so there is a cutoff at which it is simply no longer cost effective to be backward compatible, which affects the backward compatibility horizon.
The Software Angle
The new development software factor is multi-facetted and shares many similarities with, as well as intertwines with the hardware factors. This factor mainly encompasses development software which takes advantage of the latest and greatest advances in personal computing technology, from render capabilities, to faster code processing. Again, we’re usually out on the bleeding edge here when we start development on a title. The software we use during development, from the art software to the game engine, often takes full advantage of the newest, or even upcoming hardware capabilities and is designed to push the boundaries of what is possible in real time interactive media. As we work through development we look at many aspects of the development software, all of which influence how new this software is for any given project. Some of the specific factors which influence this facet of backward compatibility decisions are how long older development software will be supported by their respective software publishers, how the development software’s capabilities will be supported by newer hardware, and how newer versions of targeted operating systems will support the development software’s capabilities. These aspects of the development software’s evaluation are quite complex and often intertwined.
In addition to looking at how long a particular development software will be around, we also must consider the issue of patches and bug fixes to that software. This facet not only affects how well the development software runs in-house, but may also address a security vulnerability the development software has introduced into the title itself. Sometimes this alone forces us to shift backward compatibility as we are forced to upgrade development software, because no one wants a title running on a device that may be a security risk, or simply doesn’t work. Also, as development software progresses it usually comes with great and exciting technological advances, but those advances can overwhelm older hardware and operating systems, thus limiting backward compatibility and again placing a horizon on our backward compatibility view from a development software standpoint.
Expanding the Small Studio View
As a small studio, there are other factors which influence our look at backward compatibility as well, such as how long we want to walk the road of older system support, what is the market for older operating systems and what hardware do they run on, what’s the market for whatever older systems we wish to support, and when can we afford the latest and greatest development software. These factors can allow us to support upcoming systems but at the same time rule out older systems. They are likely also things that large studios consider, to greater or lesser degrees, but they are particularly applicable to smaller studios, who are often only as forward looking as we can afford to be. So, as you can see, whether we are a large studio or a small one, our backward compatibility view is greatly influenced by our leading edge.
These are, I believe, the biggest factors considered whenever we think about backward compatibility and how old a set of systems we wish to support with any given title. We are constantly walking a balance of what is new and exciting and what is older and more established, or even comfortable to players. Of course, there is also the issue of older title support, which is an entirely different but somewhat related subject, so I’ll leave that set of opinions for another article. If you have anything to add, or anything you wish me to go further in depth into, please comment below. Thank you all for reading, and I’ll type at you later.