Mobile Games developers face a number of challenges not least of which is pressure to deliver multiple application variants.

Multiple variants are needed because:

• Device variability – hundreds of handset types are in common use with varying functional and non-functional (quality) characteristics.
• Operator and publisher requirements – each operator has its own set of requirements, e.g. mandating the use of proprietary APIs. Where a game has been commissioned by a publisher they too may have their own specific requirements.
• Locale variability – different locales may require different game user interfaces and possibly other changes. Laws governing gambling, for example, may require different game variants to be deployed in some locales.
• Variable Billing solutions – the charging mechanisms to be applied for game use are different across operators and locales.

Lowest Common Denominator Development

When faced with these issues, the response of many developers has been to take a Lowest Common Denominator approach – a single game is developed for all platforms using the characteristics of the least functional platform as guiding constraints or in some cases devices may be grouped into functionally-similar clusters – multiple games are then developed, one for each cluster, using a Lowest Common Denominator within the cluster approach. Games in different clusters may or may not share code or other assets depending on the specific development arrangements.

One obvious problem with this approach is that in order to be most competitive a game should exploit the advanced (non-common) features provided by the target devices.

Product Line Potential is an measure of how suited the Software Product Line approach is to a particular problem.

Product Line Potential is determined by looking at how an organisation matches up to a number of criteria. These criteria are described below and an assessment is made comparing each criteria against the Mobile Games domain.

Essential Criteria are the necessary conditions that must apply in order to have product line potential.

• More than one product is developed or planned to be developed - if the organisation is not going to be developing multiple products then SPL are not applicable. Most, if not all, mobile games developers plan to develop more than one product.
• Products have common functional requirements – unless the products have common functional requirements it unlikely that the organisation will be able to develop reusable assets in a cost-effective manner and hence their SPL efforts will not break-even. Mobile Games are likely to contain similar functional requirements. This is especially true for games within a specific genre e.g. race games, simulations, first-person role-play, card games etc.<//strong>
• Products have common quality (non-functional) requirements - unless the products have common quality requirements it unlikely that the organisation will be able to develop reusable assets in a cost-effective manner and hence their SPL efforts will not break-even. Mobile Games are likely to contain similar non-functional requirements. This will be true across categories of game but will be especially true for games within a specific category e.g. race games, simulations, first-person role-play, card games etc.

Supporting Criteria give an indication that software product lines could be beneficial but are not necessary conditions in order for there to be product line potential.

• The same part of software is used in more than one product – the organisation is already using reuse concepts. This indicates that increasing reuse (in a SPL setting) may be beneficial. Many mobile games developers already make use of reuse techniques. However, a critical factor for many developers will be the current structure of the mobile games market the pressures of which may make it difficult for them to invest sufficient time and money into development of reusable core assets.
• The organisation has quality problems – one of the benefits of a PL approach is improved product quality and customer satisfaction. This is expected to vary across different development organisations. But a critical factor for many developers will be time-to-market pressures placing quality at risk.
• The organisation has complexity problems – one of the benefits of a SPL approach is in an improved capability to manage complexity. Mobile games developers face many challenging issues. As noted above this is a highly-complex domain.
• The organisation expects products to become increasingly differentiated – the SPL approach allows more products to be developed in a shorter-time while using the same or decreased effort. This will vary across different development organisations. As device characteristics change and as user-expectations grow it seems unlikely that the Lowest Common Denominator approach will not be sustainable and developers will have to differentiate their products further.

Exclusion Criteria indicate conditions that indicate that product line potential may be limited.

• There is an immature, unstable market for the products – it will be expensive to develop a stable set of reusable assets hence the PL effort may not break-even. There is a growing market for mobile games.
• There is technological change – it will be hard to develop a stable set of reusable assets hence the PL effort may not break-even. There is technological change in the mobile domain but mobile games development organisations monitor such change and it is within their capability to build software assets that can adapt to changing technologies.
• New products are developed infrequently – the SPL effort breaks-even when reusable assets are used in a number of products, if few products are developed the SPL effort may not break-even in a sufficiently short time-scale. Mobile games are developed in very short time-frames and so it should be possible to amortize the costs of reusable assets across a large number of products in many development organisations.
• The organisation develops specific, commissioned products – an SPL effort requires focus on a target market addressed by a set of reusable assets, if specific, commissioned products are developed it is unlikely that the organisation can focus on a target market and reuse common assets to a sufficient level to justify the investment in an SPL approach. Some mobile games developers work in this way and so the SPL approach is probably not suited to them – even if they could make a business case for SPL a further complication would be ownership of any core assets. However, other organisations should be able to carve out markets by using SPLE e.g. by focussing on specific game genres or sets of genres. A hybrid approach, i.e. developing a mix of own-brand and commissioned games – possibly in the same genre, may also benefit from SPLE, but again, the issue of core asset ownership should be considered carefully.
• Software plays a small part in the overall product - if software is only a small part (size, cost (development effort)) of your overall product then the organisation should probably consider improvements to other parts of their product development process before they look at improvements to their software development process. Software is the main cost for mobile games developers.

On the basis of this analysis it is possible to conclude that Software Product Lines are a viable approach for mobile games development.

Recent research which applies Software Product Lines to commercially-developed mobile games provides supporting evidence that this is indeed the case.

Read about pure::variants, a tool for developing Software Product Lines.

Find out about starting Software Product Lines.

Read how our assessment service can help you decide whether or not to start a Software Product Line.