This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Even though we had a lot of production time during the false starts before Reckoning, our preproduction time for Reckoning itself was entirely too short. At the beginning of Reckoning, we were in heavy pitch mode and our goal became to get a publishing deal signed instead of spending the time to figure out the normal outputs you are looking for in the preproduction phase of development. Once we signed a deal with EAP, we needed to get into full production quickly. Or so we thought.
What we should have done was make sure we had defined everything that needed defining. We had a basic scope of content, but we hadn't done much to understand the feature set or the game's major hook. We decided to go all-in on combat fairly soon afterward, but the development budget and schedule had already been set, and so we weren't able to anticipate how many additional animators and designers we would need to bring the combat system to life.
Our content pipelines weren't fully fleshed out, and we only had basic or less than basic functionality of some of the tools we would need to create that content. But given our tight schedule and the mountain of content we had to produce for this game, we jumped in to full production with a lot of questions unanswered. Needless to say, this is not ideal.
We also hadn't really figured out the density of our content (quests, reagents, dungeons, and so on), which had long-term negative repercussions for both design and production. We frankly made "too much game," and we probably wouldn't have (at least not to that extent) if we had more time in preproduction to figure out the density question.
As I mentioned above, we didn't have a good head start on the development of our tools and pipelines early in development. We knew the basics of what we wanted once we had a feature set figured out for the game, and we knew the type and quantity of content that we were planning on making, but we really didn't have a clue how much tools work we needed to do.
A lot of the systems in the game were still very much in the blueprinting stages where we weren't even sure how they would function in the final game. The dialogue system is one example. We came out of preproduction without giving much thought to the dialogue system other than, "Yeah, we should probably do that." We didn't nail down how we would display dialogue and choices in-game and how designers would enter that data in a tool.
This put a huge amount of pressure on our tools programmers. They had to jump from tool to tool getting functionality to a point where users could actually use it right before they needed it. In a lot of instances, our tools programmers had to roll out a tool before it was fully functional or bug free because of time constraints.
Obviously, this hurts content creation. Devs would submit tool feature requests and not see any movement on them for months (or ever, in most cases) because the tools team had a ton of other issues that were higher priority. It basically meant the majority of our tools were functional but woefully inefficient.
I'm truly amazed that the tools team did as well as they did with such limited time and manpower. For the most part they were able to stay just ahead of the train, and we ended up with a suite of tools that—while still a bit disjointed— work pretty well. Things will only get better as we ramp up into preproduction on our next project.