P. 1
Gold - Object-Oriented Game Development

Gold - Object-Oriented Game Development

|Views: 98|Likes:
Published by János Strasszer

More info:

Published by: János Strasszer on Apr 21, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

12/08/2011

pdf

text

original

In some respects, if the platforms differ in capability by a significant margin
then the fact that their methodologies may be different is neither here nor
there. A PC with 512 MB of RAM, a 2-GHz CPU, a 60-GB hard disk and an
nVidia GeForce4 video adapter is going to seriously outperform a Sony
PlayStation. If your brief is to produce a title for both platforms, then there are
going to be some tough decisions to make.
First and foremost, can the game be the same on both platforms? This isn’t
just a technical question: it’s as much – if not more – a matter of design. While
it is beyond the scope of this book to discuss the complexities of designing
game mechanics, we are extremely interested in what the consequences will be
for how we design our systems.
So, first off: one of the platforms will have features that the other doesn’t,
and by this merit will become the dominant target. We’ll call this the Major
Platform and the other the Minor Platform. If the difference in capabilities
between the Major Platform and the Minor Platform is – for some appropriate

Cross-platform development

251

RigidBody

ReferenceFrame

Calculus

Generic

Linear Algebra

Linear Algebra
Platform 1

Platform1

MathPlatform1

Maths

Physics

Figure 6.6

Class hierarchies on
the major and
minor platforms.

8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 251

metric – suitably big, then something must change. Generally speaking, we
can vary:

the types of things:the Minor Platform may not be able to support the diver-
sity of objects and behaviours that the Major Platform does;

the amount of things:the Minor Platform may not support the number of
object instances that the Major Platform can.

I also make the following distinction between the two platforms: the platform
on which development will take place first is called the Leading Platform. The
other I’ll call the Trailing Platform. This reflects the fact that although we wish
to develop in parallel, rarely is it the case that the skus evolve independently.
Sometimes this is for technical reasons: perhaps the team has more experience
on the Leading Platform; maybe there is an existing code base to work from.
Other times, there may be pragmatic justifications: maybe there just aren’t the
staff, maybe there aren’t any development systems available. One way or
another, more likely than not, there’ll be a Leading Platform and one (or more)
Trailing Platforms.

These distinctions are important: they will shape the architecture of the
game, and for that reason, if there are choices of who is Major and Minor and
who Leads and Trails, then they should be made carefully.
So why are these definitions so crucial? Well, two of the foundations of
good object-oriented design are thus:

If the behaviour of a class needs to vary, then the class should be polymor-
phic; otherwise, the change in class properties should come about through
varying the instance data.

Subclassing an object should always change or add behaviour, never remove it.

So, consider an abstract class that should be implemented on the targets and
that the Major Target is also the Leading Target. Then the two class hierarchies
could look like this:

Object-oriented game development

252

MyClassMinor

MyClassMajor

MyClass

(b)

MyClassMajor

MyClassMinor

MyClass

(a)

8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 252

In case (a), we are taking the class as written on the Minor Platform, which will
have restricted features – less complex behaviours and/or fewer instances – and
expanding on it on the Major Platform. Now, if we are following the principles
above (and we should be), then in this circumstance we can say that the only
justification for MyClassMajorexisting is if it has different or additional behav-
iour. If it is simply in terms of the particular values that the class instances use,
then it should be a data issue and no subclassing is necessary.
The situation is quite different in case (b). Here, the Major Platform compo-
nent is being subclassed on the Minor Platform. Oops! That doesn’t sound quite
right. According to our design principles, we should never be thinking of remov-
ing behaviour when subclassing, which leaves us only the option of altering data.
In other words, if the Major Platform is also the Leading Platform, then the
only variability in component behaviour should come about through differing data.
Ouch! This can affect the entire balance of programming/design/art
resource allocation, because different data could mean one or more of:

tweaked constants in source files;

different art resources (fewer or more polygons, textures of different bit-
depth);

changes to the scripting or behaviours of entities within the game.

Clearly, we are not looking at arbitrary choices here, and, ideally, we would like
to choose the Minor Platform to be the Leading Platform.
Alternatively, we might choose to arrange the classes differently:

If we are to implement this efficiently, then we want to have as much common
code in the base class as possible (after all, that is the whole point of the exer-
cise). This will be feasible and practical only if there is only a small difference
between the Major and Minor implementations, which in turn will be dictated
by the difference in capability of the two sets of hardware.
At some point, such will be the difference in platform capability that some
behaviours will not be feasible on the Minor Platform. At this point, it is clear
that code sharing via inheritance is probably not going to happen: the Minor
Platform may in fact require an entirely different design.
It would be madness to try to share an architecture for products that shared
nothing in common. This doesn’t lock the door on reusability altogether but –
at this point – it looks very much like the products share only superficial simi-
larity, and in terms of the data they manipulate and the way they manipulate
they are entirely different.

Cross-platform development

253

MyClassMajor

MyClass

MyClassMinor

8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 253

The reader may ask why I am stating the obvious! If the games are radically
different, why try to share an architecture? Well, I’m just being even-handed.
There’s no point in using the wrong tool for the job, but it happens all too fre-
quently and can cost dearly. This is a common Antipatterncalled the ‘Golden
Hammer’ (see Brown et al., 1998). Basically, it can be paraphrased thus:

I have a hammer and everything else is a nail.

In other words, people who take a lot of time and trouble to acquire a skill (be it
juggling or cross-platform development techniques) become attached to that
skill and can favour it over and above the bigger picture (or the obvious referred
to above).

Less flippantly, it is occasionally the case that the games simply have to be
similar on both platforms, in which case the lowest common denominator
comes into effect for better (but often for worse): the Minor Platform becomes
the Leading Platform, so the title risks suffering painfully against the competi-
tion on the Major Platform. The choice to make this call is often outside the
influence of the development team, but if the software architecture won’t fit the
business model, then that’s useful information for someone to dwell on.
OK, enough patronisation (for now, anyway). We’ll assume from now on
that the architectures are not so radically different as to require independent
development.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->