4 ms·

> ...anything else is distraction Is it? I was under the impression that many game shops do several releases based on the same code. It seems it would be valua

> ...anything else is distraction Is it? I was under the impression that many game shops do several releases based on the same code. It seems it would be valuable to limit the incremental cost for extra episodes, DLC, Madden YYYY+1, etc.

caseysoftware 9y ago
Notice that those examples are wholly dependent on the first thing being successful. Cash flow can solve many, many problems.
MaulingMonkey 9y ago
> extra episodes, DLC This is pretty likely to share code. > Madden YYYY+1 This may or may not. Just to keep up with the Joneses, so to speak, may require adopting new graphical techniques and occasionally rewriting your pipeline to better align with the current generation of graphics hardware and APIs. A triple-A studio isn't likely to target the Xbox One or PS4 with an aging d3d9 forward renderer - for one thing, d3d9 isn't even an option for either, and for two it'd look quite dated. Oh sure, you can reuse a little vector math when overhauling to, say, a PBR-oriented d3d11 hdr-supporting deferred renderer, but you've rewritten a huge amount - and what hasn't been rewritten may be a bit awkward and ill-fitting. And of course graphics APIs aren't the only thing changing between console generations. Even the basics like multithreading primitives, basic I/O, gamepad input, user profiles, etc. change wildly. You can build abstractions, but those don't always age well on either the design or the performance front. It's also not uncommon to prototype e.g. your core gameplay loop in an entirely different engine (likely something lightweight that focuses on speed of iteration) than your actual implementation of the idea as a final game (which may focus more on efficiency, high fidelity graphics and animation, etc.) The internal overhauls of a long lived MMORPG may also leave the codebase bearing little resemblance to the earliest released versions. Ports - especially if outsourced - are often developed as very divergent forks, rather than variations on the same shared codebase. So in a very real sense you may have multiple unrelated or barely related sets of code for the same release. If you're less successful, you may be able to stay in the game by reusing your existing codebases more to be a bit more efficient. If you're even less successful, the most efficiently reused codebase in the world won't keep you in business.
vvanders 9y ago
They do, however there's one important distinction. Usually somewhere 6-8 months out from ship they fork the codebase from mainline with the discrete intention of not ever merging back. After that point all sorts of game-specific optimizations go in that would/could break other types of games the engine could be used for. Also, if you do ever have to rebase on mainline, it's a bastard to do :).
ehnto 9y ago
You should check out the rather prolific and open development of Star Citizen. They are building in what I would considered a great compromise between feature focus and long term technical investment. Some context to why they need to have strong systems in place is that they intend to deliver new content continously into the same platform/engine/world over the course of at least a few years. So their focus is on fast and efficient asset pipelines and the ability to scale, and to that end they have built some very cool technology, but never without a direct purpose that aligns with those goals. It is a great example of pragmatic development. They didn't do network optimization until they had to, they didn't use microservices until it made sense, and then only where it made sense, they have made some nifty tools but only to solve problems that had actually manifested. Not without their failures of course, but we get to learn from those even more so.
- chii 9y ago
  and yet after this many years of development, there is still no "game" - just tech demos after tech demos. At some point, you have to question whether the 'real' game is going to be delivered!
  - ehnto 9y ago
    Perhaps you haven't been paying too close attention to progress if that is how you feel. Other games of smaller scale have taken more time, and they didn't have to build out a team of hundreds and have massive scope creep like SC has had thanks to reaching various funding goals. Not to mention it is actually two games developed concurrently! The game to be delivered is nothing like the game in the kickstarter, and it only really kicked into full development in the last couple of years. In game dev time it's really impressive how far they have gotten, all things considered. So long as you don't expect the impossible, and understand it is likely still a couple of years away, then you get to see the project in a much more positive light.

caseysoftware 9y ago

Notice that those examples are wholly dependent on the first thing being successful. Cash flow can solve many, many problems.

MaulingMonkey 9y ago

> extra episodes, DLC This is pretty likely to share code. > Madden YYYY+1 This may or may not. Just to keep up with the Joneses, so to speak, may require adopting new graphical techniques and occasionally rewriting your pipeline to better align with the current generation of graphics hardware and APIs. A triple-A studio isn't likely to target the Xbox One or PS4 with an aging d3d9 forward renderer - for one thing, d3d9 isn't even an option for either, and for two it'd look quite dated. Oh sure, you can reuse a little vector math when overhauling to, say, a PBR-oriented d3d11 hdr-supporting deferred renderer, but you've rewritten a huge amount - and what hasn't been rewritten may be a bit awkward and ill-fitting. And of course graphics APIs aren't the only thing changing between console generations. Even the basics like multithreading primitives, basic I/O, gamepad input, user profiles, etc. change wildly. You can build abstractions, but those don't always age well on either the design or the performance front. It's also not uncommon to prototype e.g. your core gameplay loop in an entirely different engine (likely something lightweight that focuses on speed of iteration) than your actual implementation of the idea as a final game (which may focus more on efficiency, high fidelity graphics and animation, etc.) The internal overhauls of a long lived MMORPG may also leave the codebase bearing little resemblance to the earliest released versions. Ports - especially if outsourced - are often developed as very divergent forks, rather than variations on the same shared codebase. So in a very real sense you may have multiple unrelated or barely related sets of code for the same release. If you're less successful, you may be able to stay in the game by reusing your existing codebases more to be a bit more efficient. If you're even less successful, the most efficiently reused codebase in the world won't keep you in business.

vvanders 9y ago

They do, however there's one important distinction. Usually somewhere 6-8 months out from ship they fork the codebase from mainline with the discrete intention of not ever merging back. After that point all sorts of game-specific optimizations go in that would/could break other types of games the engine could be used for. Also, if you do ever have to rebase on mainline, it's a bastard to do :).

ehnto 9y ago

You should check out the rather prolific and open development of Star Citizen. They are building in what I would considered a great compromise between feature focus and long term technical investment. Some context to why they need to have strong systems in place is that they intend to deliver new content continously into the same platform/engine/world over the course of at least a few years. So their focus is on fast and efficient asset pipelines and the ability to scale, and to that end they have built some very cool technology, but never without a direct purpose that aligns with those goals. It is a great example of pragmatic development. They didn't do network optimization until they had to, they didn't use microservices until it made sense, and then only where it made sense, they have made some nifty tools but only to solve problems that had actually manifested. Not without their failures of course, but we get to learn from those even more so.

chii 9y ago
and yet after this many years of development, there is still no "game" - just tech demos after tech demos. At some point, you have to question whether the 'real' game is going to be delivered!
- ehnto 9y ago
  Perhaps you haven't been paying too close attention to progress if that is how you feel. Other games of smaller scale have taken more time, and they didn't have to build out a team of hundreds and have massive scope creep like SC has had thanks to reaching various funding goals. Not to mention it is actually two games developed concurrently! The game to be delivered is nothing like the game in the kickstarter, and it only really kicked into full development in the last couple of years. In game dev time it's really impressive how far they have gotten, all things considered. So long as you don't expect the impossible, and understand it is likely still a couple of years away, then you get to see the project in a much more positive light.