Update #30: How Stuff is Made

Today's update is different from what we've done so far, and is to give you a look at what's going on at the studio. During the making of Project Eternity we want to give you an idea on how our games are made. Making games is not magic - game development just boils down to a lot of work from a lot of talented people. I would like to pull back the curtain, and give you the who (the talent) and the what (the work that they do) to make Project Eternity a reality.

The Stuff

RPGs are large and complex games that have a ton of stuff, and much more stuff compared to most games. Characters, companions, dialogues, areas, monsters, abilities, spells, items, weapons, armor, sound effects, visual effects, interface art, music, crafting recipes, animations, textures, crates and quests are the bits of stuff in Project Eternity... and the list goes on and on. At the time that we finally ship the game, we will have hundreds of thousands of bits of stuff in the game. Managing and creating this stuff is one of our major problem when creating RPGs. Our task is to make all of the stuff as efficiently as possible with a high level of quality.

Right now we are knee deep in pre-production. Pre-production is the period of time at the beginning of development where everything is planned and prototyped, production schedules are made, and pipelines are constructed. I'm not talking about oil pipelines here - I'm talking about asset pipelines. An asset pipeline can be described like an oil pipeline - First the asset is made by a content creator (like an artist), next the asset is processed by a tool so that the game understands what the heck it is, and finally the asset is placed into the game world in its final location. All of the different types of assets (stuff) require a custom pipeline. Pipeline creation is one of the many problems we are tackling right now in pre-production.

The Team

We have many different roles (sometimes called "hats") on the Project Eternity team. Most of the team fall into three categories: content creators (makers of stuff), programmers (making the stuff work), and production (making sure the stuff gets made). Our role percentage breakdown is a bit different than what we typically have on a project. If you look at my fantastic pie-charts below, you can see that we are content focused because we have larger design team, and since our team size is small we don’t have the need for a large production staff.

All of these roles are equally important and are all vital for making the game great:

Art

Animation: Animation adds life and movement to the game. Every moving object in the game requires an animator to be involved.

Effects Art: Spell effects, sword swings, fire, smoke, and blood are animated and designed by an effects artist.

Character Art: Character artists create the characters, companions, and monsters. They also model and texture all of the weapons and armor.

Concept Art: Concept artists paint and illustrate environments and characters that fit within the art and design vision. Their art is used by the rest of the team for reference on style, mood, color, size and proportion. They also paint the 2D portraits and touch up the 2D pre-rendered environment scenes.

User Interface Art: All of the buttons that you push, the interfaces that you interact with, and all of the mouse/item/weapon/spell icons in the game are designed and crafted by the UI artist.

Audio

Audio Design: Audio design is responsible for any and all of the audio that comes out of your speakers. This includes the creation and production of all of the music and sound effects, and making the character voices sound great.

Design

Area Design: All of the cities, towns, dungeons, and wilderness areas that you can explore are designed by area designers. They take the environments and characters made by the artists to construct a rich and believable world. They also fill the game with quests and combat encounters.

Narrative Design: RPGs contain thousands of lines of branching dialogue and huge non-linear storylines. The world, story, companions, factions, lore, and themes are created by the narrative designers.

System Design: Rules and systems specialists. They like numbers and spreadsheets. Combat, abilities, spells, non-combat skills, and items are designed by the systems designers.

Production

Production: The producers organize the team. They make sure everything is running like a well-oiled machine. Producers have the responsibility for making sure the game is delivered on time, on budget, and is awesome when it's shipped.

Programming

Engine Programming: The engine programmers deal with system, rendering, and physics code. Unity handles a lot of our engine-level programming for us, so we can focus our programming time and energy on gameplay.

Game Programming: The game programmers implement the game design including the rules, combat, and abilities. They also code up gameplay systems like dialogues, quests, stores, and create artificial intelligence for monsters.

Tools Programming: Pipelines and tools used by the team are made by the these programmers. Most of their code lives "outside" of the game code.

Quality Assurance

Quality Assurance Testing: The QA tester reports in-game problems to the rest of the team. They make sure that all the stuff is working together and functioning properly.

We want to go into more detail on what each person does on the team in future updates. A two sentence description trivializes the responsibilities for each team member, so in the future we will dig deeper and take a closer look into the disciplines.

@Sondre, I don't need to be schooled on what QA is or how important it is. The comments below me (and maybe yourself) don't understand that perhaps the reason some past Obsidian games were buggy were not related to their QA being bad, but other reasons that publishers and developers don't make public for various reasons. Just don't assume bugs = QA screwed up. There's so much more going on.

The insights that you're showing along the way through development are very interesting. I loved reading about the challenges to designing a good armour system, and this window into the practical world of games production is illuminating. This is altogether different experience than a meagre content drip to appease fans, I hope you will have the energy and time to continue providing these snippets, for they offer a unique and engaging experience before the game has been finished!

As a former QA tester, I can tell you that at this point there is little for QA to do other than make sure the latest build actually loads and runs. All the hard work and long hours come much further along in dev, as I can attest from 18+ hour/7 day weeks in the final push to release. I don't have any issue with the current level of QA and am very confident from the current report that these guys have got a solid plan and are VERY competent at their jobs.

@Bryy,
Not necessarily. (I'll excuse technicalities like Age of Empires, Minecraft, and SimCity which aren't RPGs) As an RPG, Drox Operative IS decidedly non-linear. But with this kind of freedom, you lose the ability to have progressive dialogue as the story unfolds (the computer might not even know what the story is). It also means each additional feature could, on its own, break the game for everyone. Also, it requires extensive balancing for every unexpected interaction the features could have (which is why Drox Operative needs - and has - a large Beta community which provides a lot of feedback). So while you can't have infinite freedom nonlinear game, there definitely are nonlinear games that exist.

Project Eternity is just the kind and scope of game that couldn't be made "truly nonlinear" yet. It may be a very open world (like Morrowind), but I imagine with the kind of story they are going to tell there will be one solution at the end of the game (kill the Big Bad), making the game linear.

Thank you for sharing this information. :D This is one of my favorite updates so far.

@Zael: AI isn't developed to the point where a computer game can have a "truly nonlinear" storyline, as opposed to a multilinear one. There's just no way they could program that in. Their hope of making a quality multilinear experience is probably a significant part of why that designer wedge is so large.

Nice, honest and interesting update. I´ve feared some people might complain "oh, this is the stuff we already know," but I never really saw somebody to flesh out making of game so clearly and honestly. Definitely informative, I´ve enjoyed that.

I don't get it. If you want to play a strategy game, an off-beat shooter, or a political text adventure.. why are you looking to this project? Tarn Adams makes really cool games. They're really elaborate takes on established genres, but none of them have much to do with a game in the style Project Eternity.

This would be like me complaining that Project Eternity is going to be nothing like Ben Croshaw's "1213". Well. Duh.

@zLumer,
Yes, I would very much prefer the game being delayed over it being released in a buggy state. Why the heck would you, as a costumer, want to go through the frustrations of a buggy game and wait months for patches that may or may not come and fix a few issues, when all that can be avoided by just waiting a couple more weeks/months to get the game with a lot less bugs. It's the same waiting but without the frustration.
This is the very reason why I stopped buying games at release. Now I wait for price drops, patch releases and modders having had the time to fix the worst bugs and so I spend less on a game that is more finished. Everyone wins! No not really, but I do.

Why would you pay full price for a incomplete product? I bet that if your plumber left your house with the message that there might be leak or 2 still in your new bathroom, but that he'll be back in a month or 2, maybe, you wouldn't just pat him on the back and hand over your money.

That Obsidian managed to extort such a large sum of money from me up front anyway is a testament to how much I miss this type of game...

@Chris if your that interested in QA, they had a Beta Key at the $110 reward level, which I believe you can still upgrade to. I for one would not like to be involved in the Alpha stages of this game, as because of the size of the game, and the variety of systems int it, I have the feeling there may still be some game breaking glitches and bugs left in at that point. I also don't really feel like Beta Testing, but that is more personal preference.

I'd love to hear more from programming department. Something like wasteland2 team posted recently, though probably with more details:) there is so much interesting stuff about the engine, the way you're gonna do the graphics, the systems..
All that awesome stuff!!!

As for the QA comments, KOTOR2 was shipped really early from a short timetable to begin with, and then LucasArts didn't have money to patch much. FO:NV was built on the crappy Gamebyro engine. Morrowind, Oblivion, and FO:3 were equally buggy. DS3 however was built on Obsidian's own engine and wasn't nearly as buggy because they had far more control over it.

@Sondre
What gel is trying to say is that not only QA is responsible for bugs in the game.
There are tight schedules, deadlines and release dates that get in the way of fixing bugs.
It's nice to have the game cool and bug free, but it's also important to release it fast, even if it means skipping a couple of bugs.
Or you would rather have the game delayed? Then just wait a couple months after the release for patches.

Superbacker

@gel QA is there to assure the quality of a product. If you skip it, then you'll have no assurance of quality.
Bugs are a defect in quality, they are caused by glitches in the aformentioned "asset pipeline". QA is there to catch the defects so that they don't appear in the final product. The quality of the QA and the quality of the asset pipelines as a whole is therefore adamant to the final quality of the product.

Superbacker

Considering that you are now entirely on your own I would advice you to invest a little more on QA. You won't be able to blame anyone else if the release is horribly bugged.

For the final stages of QA, you should get external, professional, College/University graduate QA to look it over. They'll see things with a fresh eye and they'll be able to speak your lingo so that you'll get the best possible feedback/reports.

Chris, QA is NOT hanging around playing the game all day. Play testing is completely different than what QA engineers do. With no QA, you won't even make it TO alpha testing. As giant_snark pointed out, once alpha/beta testing starts, QA guys run the triage on all problem reports and tease out the actual bugs to report to the dev team for fixing. In the early stage of the development, they'll be unit testing and integration testing the bare bones of the system. Proper QA is not crowd sourced.

@Chris I seriously doubt that a closed alpha can make up for a complete lack of in-house QA testing personnel. If anything the participants in an alpha just find more even more bugs for the QA guys to then properly document for squashing. A horde of "X stopped working when I tried to Y, not sure what's going on" tickets from alpha testers means someone still has to find the actual cause of the bug in a reproducible fashion before it can be then fixed by programmers.

I find that you have QA people a bit iffy.
I mean sure, for small parts maybe, but what should have been done and what should still be done is let the people who are funding the game test it, or at least the higher funders. Most other kickstarters have offered the prototype builds, alpha builds, etc.

I can understand having maybe one or two people that test out a room as you think it's finished but to maybe run around a whole town and see what works and what doesn't, we'd love that sort of stuff.