Ok...now, I'm not a resident techphile here at GAF, so I'm going to be putting a lot of things in layman terms. I'm sure someone can point to some of the more hardware/devtool focused discussions to add some clarification or further your interest in the subject.
Hardware
Hardware itself is, in my personal opinion, the least contributing factor to the issues with Dead Rising 3. That does not mean that it isn't a significant factor. It is the baseline after all. However, it is also of my personal opinion that these issues would not be as severe if it weren't for outstanding factors. If this were to have started from scratch on the system and be released 2 years from now, which is in my mind minimal development time for a substantial title, it could probably run at 1080p/30fps locked. Possibly higher with a basement ceiling of 30fps, but let's just keep things close to the chest to avoid a controversy.
So what in the hardware is the issue? That would lie primarily with the 32MB eSRAM and 8GB DDR3 RAM. While eSRAM is fast at 140-150 GB/sec and capable of simultaneous reading and writing, the data moving through it is restricted to the small capacity. Essentially, it creates an additional bottleneck to the 8GB 2133MHzDDR3 RAM (which can only read and write at a given time and only at 68.3GB/sec). Essentially, in theory, the eSRAM can provide a boost to the read and write capabilities of the Xbox One when needed at a given moment, but the slow DDR3 and small capacity eSRAM provide difficulties for developers on how to distribute the data to which process. Another issue worth noting is that only certain pathways seem to enable the eSRAM to simultaneously read and write.
As I said, this is using simple language with limited understanding, so hopefully you're still bearing with me. I may have mixed up how RAM and eSRAM work and the way information flows between them, so I welcome corrections from HardwareGAF.
Edit: Thanks to Chobel for providing the homework to get me out of opposite world regarding eSRAM and DDR3.
While this ties in more with the next section, in an attempt to draw parity with Sony's system, Microsoft made changes with the hardware that now encouraged developers to go further and possibly bite off more than they could chew in the amount of time available to them. With the changing environment already creating problems with optimization, developers had to contend with issues with the tied in software in development.
Finally, this was a game purportedly intended for development on Xbox 360 hardware/architecture that was transferred at an unknown stage of development onto the Xbox One. The architecture is the chief issue, but this also has strong ties to the software element of game design regarding development kits.
For more information on Xbox One architecture:
http://www.eurogamer.net/articles/digitalfoundry-vs-the-xbox-one-architects
Development Kits
To aid Capcom Vancouver in developing their exclusive title to the Xbox One, Microsoft provides development kits to the team, which is software that allows game development for the Xbox One in this case.
http://www.kotaku.com.au/2013/10/rumored-xbox-one-launch-issues-lead-to-lots-of-questions/
There seems to have been quite a few issues with the development kits, reportedly as quite buggy. Iterations/updates of the software that released with new Xbox One SDKs didn't provide any improvements to the situation.
There is also the purported transition of working with final Xbox 360 development kits to ever-changing Xbox One development kits. I'm not a game developer, so I don't know what changes aside from the hardware end that would obviously have an effect on the options available in the software. However, it's bound to be jarring to have, with the very same project, go from software optimized for a system over 8 years to software that changes potentially on a weekly/monthly basis for new hardware.
Time
An obvious issue that ties in with the other two is that there was a strict deadline for this product to be released when Microsoft made that call for the Xbox One. Reading the above issues, on how changes are occurring rather often and probably disrupting development, imagine now with that deadline fast approaching. That doesn't make for tequila shots and penthouse strippers in my mind.
In between all of this and running up to the date, you have to make time for the press, meetings, conventions, creating vertical slices or creating demos, and whatever else needed to be done in between actual development.
In-Game
So why are the issues taking place in certain instances? So far I've observed it in areas with large draw distance and crowds. It also escalates in vehicles and large amounts of particle effects, or just effects if that isn't the right term.
Upon loads, checkpoints/saving, cutscenes (which look to mask loadtimes from the DF footage), and quickly covering distances, that's where quite a few noticeable dips come to play. Everything taking place on screen at once is a problem to put quite simply.
Yet we are also seeing dips where nothing seems to necessitate or feature any of the above reasons, so something behind the scenes is also causing issues.
However, this all falls back on to the above reasons in varying ways, as well as some concluding statements below on Capcom Vancouver's chief mistake in development choices.
Conclusion
Honestly, it's hard to put this on solely Microsoft or Capcom Vancouver. At this stage, most of the blame is on Microsoft for buggy development kits, unconventional architecture, and rushing the project to meet this holiday to be a launch exclusive. Blaming them for changing the hardware itself is a factor, but not really a fault of the company.
However, Capcom Vancouver decided effort > execution. Instead of perhaps reducing draw distance, segmenting the world in a more manageable way, or cutting down on the zombies present on screen at a time or some other factor in order to stabilize framerate, they kept reaching with more = better. Now you have bandwidth not being able to support all the data coming through at the necessary speed to communicate with the CPU, hence the framerate issue.
Another issue is that this is now made worse by CV having possibly lied about the game featuring "locked 30fps" in September:
http://www.videogamer.com/xboxone/dead_rising_3/news/dead_rising_3_now_frame-locked_at_30fps.html. It looks to be that a demo available back then was damn close to that, but we don't know exactly how that slice was presented. For all we know, it was an optimized demo benefitting from being a closed environment rather than an entire game. Video in question:
http://www.youtube.com/watch?v=ttO1i8_Anxw
Otherwise, how are these latest videos of what seems to be the final build of the full game now suffering from unstable framerates? Maybe they never did lock it down and were just buying time with the demo so that they can fulfill their promise of reaching that target at launch, possibly with a Day 1 patch.
http://www.escapistmagazine.com/news/view/129398-Dead-Rising-3-Locked-at-720p-30-FPS-Capcom-Confirms Unfortunately, that possibly won't be clear to us for another week, and is not helping Microsoft's position.
A position which, this late in the game, should not exist.
Edit: To state the obvious, this is only an exploration on the possible issues behind the latest look at Dead Rising 3, with my personal conclusion to the crux of the issue. The only facts here are regarding the Xbox One architecture, the claims by Capcom Vancouver, and the quantifiable data and observations in the Digital Foundry article and footage. The rest derive mainly from an investigative report from Jason Schreier of Kotaku and my own responses and conjecture to what I observed in the DF footage in relation to the other supported elements.
Of course, some of you may find the hardware to be the bigger issue, or the time crunch at launch to be it, or maybe that I don't understand how the awesomeness of thousands of zombies on screen negates any technical issues. If you do, feel free to discuss it.
