void Update( Time dt ) { m_pMode->Update( this, dt ); } bool HandleMsg( Message * pMsg ) { m_pMode->HandleMsg(this,pMsg); } private: ServerMode * m_pMode; }; To couple this to an actual game, subclass again (see Figure 5.50). 5.4.12 Summary This has been a long chapter. And yet we’ve touched only briefly on the techni- calities of the topics we’ve discussed. That was the plan: the idea all along has been to demonstrate that, with a few straightforward OO design principles, we can create component architectures that minimise bloat, are reusable, flexible and light, and perform decently. To that end, this chapter has been a start. The rest is up to you. Object-oriented game development226 GamePlayer Player ServerModeSlave ServerMode ServerModeMaster NET GameServerModePeer GameServerModeSlaveGameServerModeMaster GameDataModel DataModel Server Data model Mode Figure 5.50 Game implementations of abstract or overridable behaviours in the NET component. 8985 OOGD_C05.QXD 1/12/03 2:38 pm Page 226 5.5 Summary ● Game engines allow teams to focus on game-play issues rather than technical issues. ● By their nature, they are tightly coupled and monolithic – anathema to software engineering principles. ● A component-based object model – a set of independent building blocks – allows much more freedom and extensibility than a game engine. What’s more, the com- ponents (by virtue of their independent nature) are easier to use and reuse than traditional code. ● Localise simple auxiliary classes within a component to minimise external dependencies. ● Keep data and their visual representation logically and physically separate. ● Keep static and dynamic data separate. ● Avoid making unrelated systems interdependent. ● Tr y to avoid using threads in a game. They make debugging a nightmare, and you may lose the precise control over scheduling and timing that sequential methods give you. ● All high-level game systems can be written as components. The component model for game development 227 8985 OOGD_C05.QXD 1/12/03 2:38 pm Page 227 8985 OOGD_C05.QXD 1/12/03 2:38 pm Page 228 6.1 Introduction If there is a single constraint that will either invalidate parts of or even entirely break your painstakingly nurtured object-oriented design, it is that your game will have to work on a variety of target hardware. And what a diversity of hard- ware! PCs – with a combinatorially huge and broadly unregulated set of constituent components, Macs, and, perhaps most importantly of all, the ever- expanding console market, including handhelds. Starting from scratch (with nothing but some middleware, perhaps), a single platform’s implementation will – on average – take about one and a half to two years to get on to the shop shelves. A lot can happen in that time! Platforms can come and go, and bottom-line hardware will double in speed. It would be inexcusable to spend another similar amount of time to produce a similar version of the game for another machine, which would look seriously out of date by the time the shrink-wrap cools. More to the point, it can be eco- nomic suicide. 1 In other words, if we are to release the game for n platforms, then we’ve got to do it all pretty much in parallel. There are two ways we might go about this: either support n teams to write bespoke and largely (maybe even entirely) inde- pendent versions of the game, or support m teams (where m ≤ n), with some amount of common code shared between platforms. Clearly, having n development teams for n platforms is an expensive luxury that the majority of games developers cannot afford. Since all developers are inevitably slaves to the vagaries of the free market (albeit occasionally happy slaves), there is clearly a strong motivation to develop the skus (as they are called) in parallel. 6.1.1 Analyse this First off, let’s consider two parameters in the analysis of platforms: capability and methodology. Cross-platform development 6 229 1 This doesn’t apply to all genres of game. Those that can escape are the lucky ones, but usually they will generate a whole new set of challenges for developers. 8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 229 Capability This is a measure of what the hardware can do: number of instructions executed per second, number of colours displayed, number of simultaneous sounds, number of executables that can be run in parallel, etc. Methodology This is how the hardware goes about doing the things it’s capable of. Factors contributing to this are things such as byte ordering (big or little Endian), bitmapped screen memory versus display list generation, and presence or absence of a hard disk. In real life, these are not mutually exclusive concepts. How something is done can inevitably determine what it can do. For the purpose of this analysis, though, it remains useful to keep the distinction. We need to consider several possible circumstances for cross-platform development: ● Platforms A and B are broadly similar in capability and broadly similar in methodology. ● Platforms A and B are broadly similar in capability but radically different in methodology. ● Platforms A and B are quite different in capability but similar in methodology. ● Platforms A and B are so different in capability and methodology that the game cannot even potentially be the same on both systems. 6.1.2 Welcome to Fantasy Land The case in which two target platforms are similar in both the what and the how is pretty rare. It’s an appealing notion that we just need to select a different compiler, hit ‘build’, go for a coffee and return to find a game that looks and plays near as damn identically on platforms A and B. Let’s just assume for the sake of discussion that this is the case. The challenges that we meet will form the minimal experience of writing multiplatform. So we’ve changed the flag in the make file (or selected the build type on our favourite integrated development environment (IDE)) and initiated the compila- tion. What might take us by surprise? Well, experience overwhelmingly dictates that you are going to be very lucky to get through the build without a compila- tion error. Welcome back to the real world! Compilers that really ought to comply with the ANSI C++ standard don’t. And even those that do still have a bewilder- ing scope for behavioural difference, sometimes subtle, sometimes less so. Depending on how conservatively you have written your code, you will get fewer compile-time errors the less you use templates (and STL in particular), recently added keywords and multiple inheritance. Indeed, the number of errors and warnings you can get is related directly to how far your C++ code is from a purely procedural interface. Disturbingly, though, even a totally procedural implementation will cause warnings and errors – perhaps lots of them. What will these errors and warnings be about? Here are some perennial issues. Object-oriented game development230 8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 230 Give us a sign Signed and unsigned arithmetic or comparison. Yet another reason to ditch those unsigned variables wherever possible! Compiler writers just can’t agree about how serious a problem mixing signed and unsigned is. You should be less accommodating. Out of character Is a character signed or unsigned by default? Is an enum signed or unsigned by default? Fruity loops I write my ‘for’ loops like this: for( int j = 0; j < 10; ++j ) { /* Do some stuff */ } For some compilers, the scope of j is inside the parentheses. For others, it’s everywhere after the declaration of j. So if you do this int j = 7; later on in that scope, on some machines it’s an error but on others it’s fine. Static constants Some compilers are happy with initialising static constant values at the point of declaration: class Error { static const int PROBLEM = 10; }; Others aren’t, and they don’t like being argued with. STL Ah, if only the ‘standard’ in the expansion of STL was so. Surprisingly, there is a remarkable variation in STL implementations over a multiplicity of platforms. Although the ANSI standard describes quite categorically how the participant classes should behave, some compilers – most notably Microsoft’s – don’t follow that standard. And even among those that do, there is still a wide variation in implementation (though there is nothing wrong with that per se), which means that the performance you get on one platform may not happen on another. 2 Cross-platform development 231 2 There is a version of STL called STLPort that is currently free and works on a number of different tar gets. 8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 231 And so on. Point being that there are a lot of nitpicky issues to deal with. Now, if this wasn’t enough, in order to deal with these pesky messages you will have to deal with the various ways that development systems let you control these warnings and errors. There is no standard for writing this: some compilers use command-line switches, some use IDE settings, some use #pragma direc- tives, and none will agree what a warning level means. Now don’t go jumping to the conclusion that this means you should aban- don all the powerful stuff we’ve discussed so far when faced with a parallel development scenario. Quite the reverse – as we’ll see, object orientation, advanced C++ features and component methodologies are all going to help you to develop across multiple platforms. What it does suggest is that you need to understand your tools quite a bit more deeply, and that more experienced teams are going to fare better when going cross-platform. Teams with less experience are therefore probably better suited to the expensive one-team-per-sku model. Conversely, if your company hires less experienced developers (because they were cheap, yes?), then you’re better off spending the money you saved (and then some) on those n teams. Free lunch, anyone? So the first technique for solving these niggling compiler issues is to not write the offending code in the first place and to put into practice coding stan- dards that make sure nobody else does. Usually, though, you’ll find out that something isn’t liked after you’ve written it. And so up and down the land you’ll meet code that looks like this: # if defined( TARGET_PLATFORM_1 ) /* Do something nice */ # else /* Do the same thing slightly differently */ # endif This is by far the most common method of multiplatform development: isolate the variable bits of code into platform-specific blocks. And it’s fine, so long as a couple of common-sense conditions are met: ● you don’t target too many platforms; ● the blocks of code encompassed by the preprocessor statements are ‘small’. It’s easy for this technique to produce code that is hard to understand and maintain. Too many target platforms will result in lots of preprocessor state- ments that aren’t conducive to tracing control flow. As for the size of isolated blocks, an important maxim to bear in mind is the principle of smallest effect, which says that if you have a block of code like this: Object-oriented game development232 8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 232 void MyClass::Method() { // Statement block 1 { } // Statement block 2 – the bad apple { } //… // Statement block N { } } then it’s better to isolate it like this: void MyClass::Method() { // Statement block 1 { } # if defined( TARGET_PLATFORM_1 ) // Statement block 2 for target 1 { } # else // Statement block 2 for other targets { } # endif //… // Statement block N { } } Cross-platform development 233 8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 233 than like this: #if defined( TARGET_PLATFORM_1 ) void MyClass::Method() { // Platform 1 code } #else void MyClass::Method() { // Other platform code } #endif Not only is the former easier to understand, but it also avoids the unnecessary duplication of nearly identical code. In general, prefer isolating lines to isolating a function, isolating a function to isolating several functions, and isolating sev- eral functions to isolating classes. If you find yourself isolating large blocks of code, then that suggests that the one file you’re working with defines non-negligible amounts of platform-specific code. If so, that code could be cut and pasted into a platform-specific file that helps to isolate the behavioural variations in toolsets. This can end up generating a whole bunch of problems. Multiplatform build systems – especially ones that involve the use of manually edited make files – need to be able to select the appropriate files for a particular build, and they can do that either manually (someone – poor soul – is responsible for maintaining the lists of files and tools and rules) or automatically (someone – poor soul – writes tools that use batch-processing utilities such as sed or awk to generate and update the make files and auxiliary systems). Some IDEs make the process easier by allowing custom toolsets to compile and link for a number of different target types. Usually, someone – poor soul – will have to write the tools necessary to bind the compiler, linker and other pro- grams to the IDE, so the route isn’t clear-cut this way either. All of which amounts to the following: though you may get away with it depending on what system you’re writing for, it’s best not to tempt fate as it has a habit of having bigger weapons than you. Avoid writing the offending code in the first place. Now wouldn’t it be nice if there was a tool, a kind of über-compiler, that didn’t actually generate any code but could be configured to understand the idiosyncrasies of all your target platforms and would warn you of any problem areas before they started giving you headaches? Well, such tools exist, with pro- grams such as Gimpel Software’s PC-Lint (www.gimpel.com). Though requiring a bit of effort to set up and maintain, these utilities can not only spot platform- specific incompatibilities but also find language-related bugs that no other compiler can spot, thus saving you a considerable amount of debugging time. Object-oriented game development234 8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 234 So, in short, language issues can generate a lot of minor, but annoying, problems when developing for multiple platforms. If you know the toolset, avoid writing potentially problematic code and isolate the minimal amount of that source, then you will maximise maintainability and clarity. Coding stan- dards can help to avoid the pitfalls, and there are tools out there that – with some amount of effort – can help to catch the awkward variations in grammar and behaviour before they bite. 6.1.3 Same capability, different methodology It’s hard to be general in this case, as there are many different ways of doing a particular task. But clearly the worst-case scenario is that we will have to write code (and generate data) that works identically (or near as dammit) on radically different hardware architectures. The word ‘identically’ should be suggesting that getting n teams to write the skus isn’t going to be a viable option. Let’s assume that team A writes its AI code using a combination of fuzzy logic and the usual state-based heuristics. Team B writes it using a series of neural nets with a different heuristic system. If AI is a big part of the game then how easy will it be to ensure similar behaviour between skus? Not particularly. So, we assume that a certain amount of code sharing will be going on. The question is: ‘How much code can be shared?’ The flippant answer is: ‘As much as possible but no more’. It’s better to be this vague, otherwise you will find yourself trying to justify exactly what 25% of your code means – one-quarter of your files? Classes? Packages? Lines of code? Lines of code that aren’t com- ments? Trust me, don’t go there. Consider the similarities and differences between two current platforms – PC and Macintosh. At the time of writing, the average PC runs at about 2 GHz and although Macs haven’t got quite such big numbers in front of their specifi- cations, they’re at least of equivalent power. Both platforms’ 3D capabilities are similar – they share similar hardware after all. Both platforms have lots of memory – at least 128 MB comes as standard. They also have big hard disks. What’s different? Byte ordering for one thing. Little Endian on PC, big on Mac. This gives you a couple of choices when considering how to load data into the game. Same data, different code Use the same data on your PC game and your Mac game. If you do that, there’s no need to keep two versions of your data lying around and potentially unsyn- chronised. However, one version of your software – which one depends on what is your lead platform, the one you generate your data on – is going to have to do some byte twiddling, and this has repercussions for your serialisation code. Supposing you have a component like this: Cross-platform development 235 8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 235 [...]... small objects and the Figure 6.3 Bare-bones framework minimalist renderer Generic Object Transform Maths Types Render Target Mesh Renderer Display MeshPlatform1 RendererPlatform1 DisplayPlatform1 *Meshes Platform 1 *Primitives Primitives *Data Low-level maths types 8985 OOGD_C06.QXD 1/12/03 248 2:42 pm Page 248 Object- oriented game development penalty of a virtual method call would be prohibitive for objects... 1/12/03 246 2:42 pm Page 246 Object- oriented game development These files live – by necessity, since they are called the same – in a separate directory in the project (one subdirectory for each platform) If we structure our code like this, the header file is almost entirely ‘clean’ – in other words, generic When we create an object instance, we are oblivious to the actual type of the object created: #include... OOGD_C06.QXD 252 1/12/03 2:42 pm Page 252 Object- oriented game development 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 diversity 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... types Almost every cross-platform development system has a file that looks a bit like this: // File: TARGET_Types.hpp #if !defined( TARGET_TYPES_INCLUDED ) #define TARGET_TYPES_INCLUDED #if TARGET == TARGET1 typedef char int8; typedef unsigned char uint8; typedef short int16; typedef unsigned short uint16; 241 8985 OOGD_C06.QXD 242 1/12/03 2:42 pm Page 242 Object- oriented game development typedef int int32;... The sound manager as a factory 8985 OOGD_C06.QXD 250 1/12/03 2:42 pm Page 250 Object- oriented game development namespace SOUND { class Sound { public: Sound(); virtual ~Sound(); virtual void Play() { printf("Playing sound 0x%.8X\n",this); } virtual void Stop() { printf( "Stopping sound 0x%.8X\n",this); } }; } This ‘null object class allows us to test the base class without getting bogged down in details... corresponding to the source graphics), we can inspect the IFF visually to see if there’s anything odd in there 237 8985 OOGD_C06.QXD 1/12/03 238 2:42 pm Page 238 Object- oriented game development Figure 6.1 Flow of data from asset-creation software to the game APP2IFF Host PC running asset-creation software type = image width = 64 height = 64 depth = 8 palette = { 0x00 Intermediate file format IFF2P1 IFF2P2... similarity, and in terms of the data they manipulate and the way they manipulate they are entirely different 253 8985 OOGD_C06.QXD 254 1/12/03 2:42 pm Page 254 Object- oriented game development 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...8985 OOGD_C06.QXD 236 1/12/03 2:42 pm Page 236 Object- oriented game development struct MyClassData { int x; short a; char c; }; class MyClass { public: MyClass( MyClassData * pData ); private: MyClassData m_Data; }; class MyClassLoader { public: MyClass * Load(... shenanigans going on in the header file: // File: COMPONENT_MyClass.hpp #if !defined( COMPONENT_MYCLASS_INCLUDED ) #define COMPONENT_MYCLASS_INCLUDED 243 8985 OOGD_C06.QXD 244 1/12/03 2:42 pm Page 244 Object- oriented game development #if TARGET == TARGET1 # if !defined( TARGET1_TYPES_INCLUDED ) # include # endif #elif TARGET == TARGET_2 # if !defined( TARGET2_TYPES_INCLUDED ) # include ... 1) SpecularPower 0 EmmissiveColour (0 0 0 1) } Material "WOMAN_MESH_MESH1_MATERIAL0" { Texture "WOMAN_BUGGY WOMAN" DiffuseColour (1 1 1 1) 239 8985 OOGD_C06.QXD 240 1/12/03 2:42 pm Page 240 Object- oriented game development AmbientColour (1 1 1 1) SpecularColour (1 1 1 1) SpecularPower 0 EmmissiveColour (0 0 0 1) } ] VisualList "WOMAN" [ VLMesh "MESH0" "FRAME37" { Vertices [ ( [(3.16834 -0.447012 -0.187323)] . The rest is up to you. Object- oriented game development2 26 GamePlayer Player ServerModeSlave ServerMode ServerModeMaster NET GameServerModePeer GameServerModeSlaveGameServerModeMaster GameDataModel DataModel Server Data model Mode Figure. of them. What will these errors and warnings be about? Here are some perennial issues. Object- oriented game development2 30 8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 230 Give us a sign Signed and unsigned. principle of smallest effect, which says that if you have a block of code like this: Object- oriented game development2 32 8985 OOGD_C06.QXD 1/12/03 2:42 pm Page 232 void MyClass::Method() { //