And you see that quick list as "not a challenge?". You should look up the dunning-krueger effect.
Play nice. Your post comes across as rather terse.
Perhaps you should pay more attention to what was actually said? I don't see it as 'technical challenges' (Allan's term) which from the sounds of it implied there was some sort inscrutable project killing difficulty involved not inherit in doing a human protagonist.
I think this might be part of the issue, because my usage of "technical challenge" wasn't really meant to be "Think of anything so fundamentally challenging that it just couldn't be done." Just challenges beyond simply writing words.
-Armour models would need to be resized for each race. Alternatively you could have fewer armours but make them rarer/better and race specific, so something like Orlesian Plate would be top end stuff for humans and truly valuable but wouldn't be wearable by elves or dwarves due to it not being crafted with them in mind.
This is definitely one thing. And it's keen of you to realize that in doing so, it likely means less armor variants (we take a bit from one pot and put it into another pot, so to speak) in general. Which may or may not be a bad thing, and if one is super keen on race it's probably a cost worth making to boot.
-Additional triggers to factor in race would need to be added to conversations/events when appropriate.
Yup. Much of this exists in our conversations and plot systems, so those flags would need to be created (probably not too much work), and then hooked up (this would be more work) properly via the scripting system. Fortunately the Eclipse engine had some tools in the Conversation Editor to try to make this fast for the majority of lines.
On top of this would be the QA work to playthrough with the various races. If there's any systems that are created to assist with race specific functions (cameras would be one thing) then those would have to be tested as well. I mention this just more as a "the web gets thicker, and the potential for bugs goes up with it."
-Cut-scenes would need to be abdjusted, more so for dwarves, elves if they were roughly the same hieght as humans like in DA2 would probably be fine with no tweaks for 90%+ of them.
There'd likely be some work here, yes. The most obvious ones are when the camera is design to track and follow the player character. There might be some where the player character is simply on camera. A less obvious one would be considerations for how the custom race armors end up working, which could create an X-Factor if we realize that some armors cause issues with particular shots.
I'm at home now so I'm going to just go off from the top of my head. Some of these you likely are aware of, and probably catalogued into your other points, but I want to list them just to make sure they get covered. I'll also try to mention the risks for some items as they pertain to Frostbite's engine, compared to Eclipse, for the system as a whole (not just for player races). Some of this will be repeat from your points too, and some of them I'll have more insight into than others (namely, Digital Acting stuff) since those things directly affected me in my work.
First off is writing. I think this is kind of easy, and probably something you factored in in your second point. The lines will need to be written, and the more variation/flavour, the more lines that will need to be written.
Frostbite challenge: Upon receiving Frostbite, first and foremost was the complete lack of any sort of conversation editor. All lines spoken in other games were set up manually. For our games, which tend to be conversation heavy, this would never have worked (and it would have been made more complicated with variations based on race/gender). The big problem with this is that some of the unknowns are not only creating the front end for the editor, but much of the backend pipeline as well.
Our games have a ton of lines (strings). Localization is also important, and something that couldn't possibly be done manually. So we don't just need to create a conversation editor, but one ensures that the lines have appropriate metadata for localization, meaning (all StringIDs must ultimately be uniqued.. there must be a way to flag lines as ready for Loc/VO, etc. etc.). This also includes having to build the Database to properly store all these references for quick look up and editing, while ensuring things like copy/pasting/cutting do not break the system.
So, there were questions: "Will our writers be able to write content as quickly into the engine as they could in DAO/DA2?" The answer was unknown (as many of them are) So we have to try to figure out how much writing are we willing to commit to in order to make sure we cover a story that we feel is appropriate in scope, length, etc. and this is without considering other dependencies that other teams might have (you can write billions of lines, but if your CinDesign team has the capacity to do 100, it's going to complicate how much the writers will actually be able to deliver, and force us to come up with alternatives than having "all lines must be touched by CinDesign" in order to get that content in).
Slightly separate, but related, is of course the VO. Aside from tracking different audio files based on player race, this is mostly a fairly easy to comprehend cost: we'll need to pony up for the VO if we want to have voiced characters (and we do).
From there, we'll segue into design. This is covered by your points 2 and 3. Level design will need to create the plot flags and hook them up in the editor so that the game can properly react to the choices. On top of this is the cinematics work.
Frostbite challenges: There was nothing resembling a plot system. We needed to create one from scratch, which involves creating the GUI front end for the designers/writers to use, as well as the backend to ensure the game itself understand what those bytes of data are for and how to use them. Frostbite uses a visual scripting environment, so there will have to be some alterations in how the editor was created from Eclipse (which had a more traditional, text based scripting system). Get the editor to a point where we can mimic similar workflows is a bit easier to conceptualize, but a risk is that there may be be some loss in velocity due to lack of experience. There may be some gains in velocity once people are familiar, but at the beginning of a project it's still an unknown.
Moving onto CinDesign, the CinDesigners are going to need to create/modify cutscenes to account for player race - you've recognized this.
Frostbite Risks: Outside of a sequencer that could play out some scripted animated sequences, there was really nothing resembling a cutscene editor. WIth the cutscene editor doesn't just come the ability to create the content, but to audition it in a speedy way to minimize iteration time. Ideally the designer can find this out without having to load the game up proper. There is a mode in Frostbite to let us do this (Called "GameView"), but there were some functions missing from it, such as variable party members, multiple camera viewports, and everything needed to be done manually. The only way for us to work on small scale changes at this stage of the project was to rebuild the assets every time (depending on size of the level, 5-15 minutes the first time, and 1-3 minutes for each subsequent time). This cripples velocity, so we need to build up the infrastructure and tools to allow this:
Stuff like:
A staging editor, that lets us create stage templates for quick references to stage marks and cameras
A new camera system that deals with the conversation cameras.
Building up the functionality of the current tools to allow CinDesigners to manipulate the scenes in a way that is efficient for them.
- We ended up agreeing that we should rebuild this system, which did have the plus side of having buy in from teams such as Frostbite Vancouver, who have helped out in a lot of ways since the idea was for these tools to be rolled out to all studios using Frostbite (indeed, I think Need for Speed used the "Timeline" system in some capacity, though I can't remember for certain).
This stuff is many man months of work just from the programming side (and my QA side.. >.>), and with it there isn't even assurances that the tools, once completed, will be as speedy as they were with DA2. In fact, our assumption is that they very likely won't, since Eclipse was a very mature engine with loads of iteration done on it.
SO now we backpedal a bit. Okay, some stuff that we typically put in our standard conversations may result in too much work. So now we need to go back "Are there things that we can do differently, that didn't even exist in DAO/DA2, to allow us to still get the word count in that we feel is necessary? And so on and so on.
I'll cut it off here (other things still come into play, such as animation rigging - for DA2 humans, elves, and dwarves did not share the same animation rig apparently - and so forth) since this post is already getting VERY long.
When there are a lot of things that are deemed potential high risks, and a lot of workflow efficiency is completely unknown since we don't know how well we can get to the speed at which we were able to deliver on. As such, on some of these things conservatism was the way to go, because for all this stuff multiple races just becomes an effective force multiplier.
Our original goal was to get a game out for the end of this year. Still doing so would have had some definite risks, especially in terms of employee health (crunch crunch crunch.... no one wants to do DA2 all over again!), so we were able to push the game back a year. Part of why we could push it back so far is because (at least in my opinion) we have some pretty promising stuff, as well as some solid foundations for other systems. We want the game to be super high quality. Some of the time extension lets us assure that we can get our original commitments to quality, but also awards additional opportunity to get in other stuff. What exactly that is (if anything) is part of discussions that I'm not directly able to really influence, but I do take part in on a tertiary level.
But yeah, player race was one of the first cuts because it was a quick way to reduce the force multiplier for the workload on several teams, since there was a lot of uncertainties because we were working with a new engine. It's also, in my opinion, a situation of "Don't let the fanbase get its hopes up if we are already pretty sure we aren't going to do it" since it was definitely something that some groups have been pretty vocal about.
There was quite a handful of stuff that got nixed earlier in development that people don't ask about, but I do think that for a feature like that, it's probably better to say it sooner rather than later.
Retour en haut
