Software architecture optimized for sharing?
October 24, 2013 11:05 AM
This is very video-game centric. I've worked on lots of games in a half dozen studios, and I've noticed that the architecture of game code with respect to sharing between projects is often ad-hoc and unplanned...
(I've asked this question on both gamedev.net and stackoverflow.com, with no responses. I figure there may be other experienced developers here)
I've noticed that in good studios, it tends to approach a pattern like so:
Sharing usually happens at the Core and Platform level, with merges being more dicey in Engine, with no Product-level sharing (beyond the first copy and paste). Real sharing is also rare, and takes lots of effort.
I'm wondering if there's a more codified list of best practices out there for organizing and sharing code in studios where there are many games in development. While I understand that you can't share everything, I'm looking for examples of architectures and policies that worked well.
Thanks!
(I've asked this question on both gamedev.net and stackoverflow.com, with no responses. I figure there may be other experienced developers here)
I've noticed that in good studios, it tends to approach a pattern like so:
- Product: product specific (ex: MyAwesomeGameApp class)
- Engine: game-type specific (ex: MMOScene class)
- Core: shared by most games (ex: Vector2 class)
- Platform: platform specific (ex: File class)
Sharing usually happens at the Core and Platform level, with merges being more dicey in Engine, with no Product-level sharing (beyond the first copy and paste). Real sharing is also rare, and takes lots of effort.
I'm wondering if there's a more codified list of best practices out there for organizing and sharing code in studios where there are many games in development. While I understand that you can't share everything, I'm looking for examples of architectures and policies that worked well.
Thanks!
I agree that it is a broad and opinionated topic. Unfortunately, I don't recall Code Complete discussing horizontal sharing between products (2003 edition). It's a great book though!
posted by hanoixan at 12:20 PM on October 24, 2013
posted by hanoixan at 12:20 PM on October 24, 2013
About a decade ago, I worked for a game studio that did annual releases of multiple franchises, and the code structure really wasn't too bad, especially in hindsight.
Third party code, and code shared between franchises, were segmented into libraries and had their own source control branch. UI, AI, online components, and other broad groups were segmented in source control, but were all compiled in directly. Classes, files, and variables were supposed to follow a coding standard, though we hardly ever did code reviews. There were separate projects in the solution (this was with Visual Studio) for the game editor and game, since they needed to be launched differently and with different UI. But the code was so similar it could mostly be handled with a few #ifdefs. There are cleaner ways to do it, but a redesign would have taken much too long.
High level code was required to be platform-independent. I believe the include paths were set up so that it wouldn't compile if you tried to sneak low level code in. Platform-specific code was split out in source control, and confined only to low-level implementation source files. Each platform had its own solution or equivalent, since they usually required different build toolsets.
Checking in code that did not compile, on any platform, was strictly forbidden. Once a week, an official build was made and sent to QA.
But no matter how well you organize, you'll eventually need to do some ugly, problem-specific hacks, due to the tight scheduling and platform-specific oddities. The longer the code has been around, the worse this generally is.
posted by Sibrax at 9:06 AM on October 25, 2013
Third party code, and code shared between franchises, were segmented into libraries and had their own source control branch. UI, AI, online components, and other broad groups were segmented in source control, but were all compiled in directly. Classes, files, and variables were supposed to follow a coding standard, though we hardly ever did code reviews. There were separate projects in the solution (this was with Visual Studio) for the game editor and game, since they needed to be launched differently and with different UI. But the code was so similar it could mostly be handled with a few #ifdefs. There are cleaner ways to do it, but a redesign would have taken much too long.
High level code was required to be platform-independent. I believe the include paths were set up so that it wouldn't compile if you tried to sneak low level code in. Platform-specific code was split out in source control, and confined only to low-level implementation source files. Each platform had its own solution or equivalent, since they usually required different build toolsets.
Checking in code that did not compile, on any platform, was strictly forbidden. Once a week, an official build was made and sent to QA.
But no matter how well you organize, you'll eventually need to do some ugly, problem-specific hacks, due to the tight scheduling and platform-specific oddities. The longer the code has been around, the worse this generally is.
posted by Sibrax at 9:06 AM on October 25, 2013
« Older Illustration for effective communication? | What should my elderly parents do with their only... Newer »
This thread is closed to new comments.
posted by Aleyn at 11:59 AM on October 24, 2013