How do companies like Valve manage to release games to all three major gaming platforms? I am interested in the best-practices regarding code sharing specifically between Windows, Xbox360 and PS3, since the ideal solution is to reuse as much code as possible instead of rewriting the whole thing for every platform.
How can I learn about cross platform game development?
Asked Answered
It's not any different than writing platform-independent code in other contexts. Hide platform-specific details (input, window interaction, the main event loop, threading, etc) behind generic interfaces, and test regularly on all the platforms you intend to support.
Note that the Cell's threading model is unusual enough that doing threading "generically" takes some care. I am not a Valve employee and I know none of their secrets, but it's my understanding that most game developers who want to target the PS3 use a job queue that the individual cell processors grab tasks off of as needed. This isn't necessarily the best way to use the Cell, but it generalizes nicely to more conventional threading models (like, frex, the one that thet PC and the 360 both use).
There's a bunch of Game Developer Magazine articles and GDC talks on the subject. In fact, since you mentioned Valve, they delivered a talk describing their approach at GDC08.
This is really a huge subject that I could (and have) talk about for hours upon hours, but elevator summary is:
- Determine which parts of the engine are completely platform-specific and put them behind an abstraction. File and asset loading, for example, need to be rewritten for each console; but you can hide that behind an IFileSystem interface which provides a uniform API that the game code talks to.
- The PS3 makes this hard because its abstraction point has to be someplace completely different from the other platforms. Even game features like collision and nav will have to be written differently for the Cell.
- Try to keep leaf game code (entities, AI, sim) as platform-agnostic as possible...
- But accept that even the leafiest of game code will sometimes need some platform-specific #ifdefs for perf or memory or TCR reasons. A lot of UI will have to be rewritten because the manufacturers have conflicting certification requirements.
- Anyone who says the words "I'm not worried about performance" or "memory isn't an issue" shouldn't be on the payroll.
"Anyone who says the words "I'm not worried about performance" or "memory isn't an issue" shouldn't be on the payroll." Sad but true. For most kinds of software these people can be a big help if their perspective helps them write correct code quickly. In game development they are poison :-/ –
Unswerving
This question can be divided up into two separate questions. "How can I write portable code?" and "What are the divergent requirements of mainstream gaming platforms?".
The first question is relatively easy to answer. Best practices for abstracting your non-portable code are covered in Write Portable Code: http://books.google.ca/books?id=4VOKcEAPPO0C&printsec=frontcover
Turning theory into practice, the Quake 3 source code does a pretty good job of dividing out different platforms into separate areas for a C codebase, available at http://www.idsoftware.com/business/techdownloads/ However, it does not demonstrate C++ patterns such as abstract interfaces, implemented once per platform.
The second part of your question, "What are the divergent requirements of mainstream gaming platforms?" is tougher. However, it is notable that your largest areas of change are still your renderer, your audio subsystem and your networking.
Each console platform has a series of certification requirements, available under an agreement with the respective console owners. The requirements drive consistency in user experience and are not focused on gameplay or qualitative, high level issues. For instance, your game may need to display a reasonably interesting animating loading screen, and black screens are unacceptable.
Getting your hands on this documentation as soon as possible is key to making the right choices in developing for a specific console platform.
Finally, if you can't get your hands on a console devkit, I suggest you port your code to the Mac from Windows. The Mac gets you an OS port ensuring you are not tied to Windows as well as a processor port if you support universal binaries. This ensures your code is endian agnostic.
If you support both PC and Mac, you will be well positioned to support a third platform, should you gain access to it in the future.
Addendum You wrote:
the ideal solution is to reuse as much code as possible instead of rewriting the whole thing for every platform
In many game porting scenarios, the ideal solution is not to reuse as much code as possible, but to write the optimal code for each platform. Code can be reused between projects and is relatively inexpensive as compared to the content that the engine takes in. A more reasonable goal is to aim for lowest common denominator content that runs on all platforms without modification (a build phase that packs the content for media is okay).
It's great to do simultaneous development. You find all kinds of bugs you wouldn't find doing just one platform.
I remember that programmers in DOS had null pointers all the time because writing to low memory didn't immediately crash them. When you ported to an Amiga, Atari ST, or Macintosh, boom! I remember telling a DOS programmer that he had a couple null pointers on an aready-shipped game. He thought for a couple seconds and grinned, "That explains a few things."
Now that games have such large budgets, it's important to ship them all at the same time so you don't waste marketing and ad budgets.
My advice on simultaneous development is to pick one lead platform, but never let the other platform(s) get more than a week behind. It will become obvious as you program which parts of the code are common to all platforms and which are different. Pull out the differences into one or more platform-specific areas.
My experience is in C/C++. It's a bigger problem if you have to port against different languages (say, Java and Objective-c).
A few years ago the Opera CEO said in an interview that the key to developing for independent platforms is to move away from any single OS/platform libraries. He went on and said that they developed their own libraries that improve OS performance.
My assumption is that big companies will have a common, Xbox, PS, windows, FooOS, separate teams. Each platform needs to be tweaked differently and requires different implementation methods. I don't think they do one source for all platforms; rather, they build one for each OS thereby, improving efficiencies. I remember EA used to release some console games earlier than the PC versions and vice versa.
Another issue is that different consoles have different hardware thus requiring different programming techniques.
there are two extremes, build one source that fits all (java for instance) but you run the risk of inefficiency or write 40 versions; one optimized for each platform
Back when I had a friend into educational computer games (before The Learning Company gutted the field), he was a great fan of creating cross-platform libraries for doing everything.
This is easier for games than other apps. If you have a word processing app to run on the Mac and Windows, for example, it really does need to look and behave like a Mac app on the Mac, and a Windows app on Windows. Write a game, and it doesn't have to conform to the native behavior, look, and feel.
If you want open source examples, you could look at source code of Quake 1, 2 and 3 engines. They are structured quite portably. (Of course, no ps3 or xbox360 support, but same principles apply)
© 2022 - 2024 — McMap. All rights reserved.