Digital Foundry Article Technical Discussion Archive [2015]

Status
Not open for further replies.
Games teams are so huge because of art teams. From what I watch from GNOMON presentation or masterclass of Christophe Balestra in Paris, some of Naughty Dog artist are very versatile and some of the technical artists have artistic skills and programming skills like Anton Maximov. And another things it seems is Naught Dog and Ready at Dawn have a very good relation. Yibing Yang worked at liltle at Ready at Dawn as an environment shading artist. At least one naughty dog developer worked there a little when they were doing Daxter on PSP.

During an IGDA event in 2007 in Paris, Christophe Balestra explained than they like programmer who have a strong skill in one speciality but are versatile and can help out of their speciality. The only problem was the custom physics engine they were using because it was so complicated few developers were able to work on it. It is probably one of the reason, they choose to use Havok instead. I heard many good things about havok physics engine. In 2007, they were outsourcing but not so much maybe it is the reason they have so much people now.

I am not in the industry but I speak online with some artist and I know one indie game designer and some people doing outsourcing work in videogames. I work in financial software industry....
 
Last edited:
Games teams are so huge because of art teams. From what I watch from GNOMON presentation or masterclass of Christophe Balestra in Paris, some of Naughty Dog artist are very versatile and some of the technical artists have artistic skills and programming skills like Anton Maximov. And another things it seems is Naught Dog and Ready at Dawn have a very good relation. Yibing Yang worked at liltle at Ready at Dawn as an environment shading artist. At least one naughty dog developer worked there a little when they were doing Daxter on PSP.

During an IGDA event in 2007 in Paris, Christophe Balestra explained than they like programmer who have a strong skill in one speciality but are versatile and can help out of their speciality. The only problem was the custom physics engine they were using because it was so complicated few developers were able to work on it. It is probably one of the reason, they choose to use Havok instead. I heard many good things about havok physics engine. In 2007, they were outsourcing but not so much maybe it is the reason they have so much people now.

I am not in the industry but I speak online with some artist and I know one indie game designer and some people doing outsourcing work in videogames. I work in financial software industry....

For The Order we peaked at around 120 people (including some contractors, who were mostly animators), and I think around 30-35 of them were programmers. I'd imagine that ratio is pretty similar for other teams of our size. The thing about content is that you can't just scale up on content creators without scaling up on engineers as well. You need more tools for the artists so that they can create content more efficiently without wasting all of their time on minutia. You need runtime support for content pipelines that make their lives easier, and also make it so that your game doesn't run at 200ms per frame. You need people fixing all of the bugs and errors that come up in those tools, so that production doesn't grind to a halt. Hell, just the content itself is a major engineering problem: storing terabytes of data in version control and then moving it through your offline content baking systems requires a lot of planning, optimization, and spot-fixing of issues. Its also a problem that tends to ripple through every aspect of creating the game, and all of your engine's subsystems.
 
Last edited:
Not suck, but I am of the opinion that if your body of work can be improved by outsiders in short order, then perhaps your body of work was pretty sub par. Devs aren't lazy, they do the best they can with the resources and time they have, but that doesn't mean their work is always top notch. Think of it this way, if a third party was contracted to port a game from PS4 to X1, and the X1 version was better than the source material, would that not seem ass backwards to you?

One of my main functions is to deal with the performance of my game, but I'm also juggling bugs and feature work for multiple platforms. So for 2-3 years I'm only looking at one product. When I encounter a performance issue I'll learn the quirks of the hardware behind it as best as I can, fix it, and move onto the next thing.

One of Xbox ATG's main functions is to assist developers with performance. They see all kinds of things, in all kinds of engines. They have a lot larger list of what to look for and a lot better concept of how related or competing titles perform, because a) they dig into or hear about most performance related fixes across all titles on the console and b) they have a much more narrow focus on performance as a group.

It's not that the work is subpar or the developers are less skilled, at least not across the board. The active principle here is that someone who has significant experience doing a specific thing will be better at that specific thing that someone with more general experience divided across more areas.

Really groups like ATG are very valuable just for the extra pair of eyes even if everything they tell you is something you already knew or planned to fix, because they might notice something you've just missed either because you were busy or because you weren't looking for it.
 
One of my main functions is to deal with the performance of my game, but I'm also juggling bugs and feature work for multiple platforms. So for 2-3 years I'm only looking at one product. When I encounter a performance issue I'll learn the quirks of the hardware behind it as best as I can, fix it, and move onto the next thing.

One of Xbox ATG's main functions is to assist developers with performance. They see all kinds of things, in all kinds of engines. They have a lot larger list of what to look for and a lot better concept of how related or competing titles perform, because a) they dig into or hear about most performance related fixes across all titles on the console and b) they have a much more narrow focus on performance as a group.

It's not that the work is subpar or the developers are less skilled, at least not across the board. The active principle here is that someone who has significant experience doing a specific thing will be better at that specific thing that someone with more general experience divided across more areas.

People forget multiplatform development is hard. I often heard too some stupid things like PC power means doing a PC version is easy. Doing a PC version is already like doing a multiple console version because of the different version of PC...

XB1 API and PC API are only a bit different, PS4 API is different... After PS4 and XB1 similar architecture is great...
 
People forget multiplatform development is hard. I often heard too some stupid things like PC power means doing a PC version is easy. Doing a PC version is already like doing a multiple console version because of the different version of PC...
It's nowhere near as bad as that. Support and bugs can be an issue, but it's one codebase, one API, one executable, one set of tools for all PCs. Each different platform brings in a need for new code, new APIs, new specific quirks.
 
It's nowhere near as bad as that. Support and bugs can be an issue, but it's one codebase, one API, one executable, one set of tools for all PCs. Each different platform brings in a need for new code, new APIs, new specific quirks.
PC games need to optimize to driver behavior. And then the other way, drivers adapt to game.
 

Interesting. So even in it's hopelessly broken form the game can still match or exceed the PS4's performance and graphics on a half decent Nvidia GPU if configured correctly. However console level consistency seems to be off the table for AMD cards thanks the the game broken frame rate limiter (and AMD's lack of a decent alternative).
 
It's nowhere near as bad as that. Support and bugs can be an issue, but it's one codebase, one API, one executable, one set of tools for all PCs. Each different platform brings in a need for new code, new APIs, new specific quirks.
There have been many PC releases with both DX9 and DX10/11 code paths. DX10 GPUs can be supported through DX11 API, but compute shaders do not work, so you need lots of alternative (pixel shader) code paths to emulate modern console code in DX10. Releasing both 32 bit and 64 bit executables has also been quite common, since some customers have bought 32 bit versions of Windows Vista, Windows 7 and Windows 8 (and it seems that Windows 10 will still continue to sport a 32 bit version). A few developers have also shipped different executables for SSE(3) and AVX. AVX support is still too limited in order to drop SSE support.

Even if you only release a single build (DX11.0 + 64 bit + SSE3), the GPU drivers vary a lot. With some drivers and/or GPU architectures it is better to store + update all constants in a single buffer, while others benefit from split (split immutable and dynamic data). Texture map/unmap/update has similar differences (as does immutable resource creation at runtime vs reuse existing with map/update). The preferred technique most likely differs with the GPU memory size. Extra driver generated shadow copies might cause hiccups if the GPU memory is almost full, but other update techniques might cause overhead. There are too many trade-offs and performance cliffs that are impossible for the developer to know. The API is just too abstract.

Writing high performance (robust) PC port is much harder than writing good console code. Writing fast console code is straightforward since you get exactly what you write. There are no shadow copies, no random stalls and no driver generated bullshit. I can't wait the day when we can finally drop DX11 support (and code solely for DX12). With Vulkan this might actually happen even sooner since it seems to support Windows 7 as well.
 
Does anyone know the framerate of MotoGP 15? :) DF analyses "AAA" games mostly, but certain titles would like some love, too. I miss the days of a more independent DF with articles featuring face-offs galore.
 
I saw a video on VG where they mention it's targeting 1080p60 and appeared to achieve it without hitching, they didn't actually analyse their capture but they have a 1080p60 vid on YT if you have the tools.
 
http://www.eurogamer.net/articles/digitalfoundry-2015-can-halo-5-deliver-on-its-60fps-promise

DF article on the Halo 5 E3 demo. They are using an interesting dynamic res technique.
With 810 vertical lines in play we're looking at a resolution ranging from 1920x810 to 832x810. However, in b-roll distributed during E3, minimum resolution observed comes in at 1152x810 - not exactly wonderful but presumably more indicative of where the system is right now during gameplay.

At this point is it better to aim for 1080p30 for singleplayer? If the game drops this low to keep up with the framerate i suppose 900p60 is out of the question.
 
They can't sustain 60fps @ low res for the E3 build, so it'd be unlikely to be 1080p30 solid.

They certainly have a lot of work to do beyond the corridor...
 
I wonder what this means for large scale more open level battles?

It will be interesting to read the DF article (hopefully with dev interview) once the game is released and optimized!
 
Status
Not open for further replies.
Back
Top