Update #30: How Stuff is Made

[megabyte01]

It's cool that you're showing us how the team breaks down for this project. I love the art and world-building parts, which are very important to a game like this. I look forward to when you guys are ready to talk about how the technology is being used.

[makryu]

I'm pretty sure Obsidian knows what to do with the feedback they'll get. It's not like any backers have executive power over the game development (Thank God for that!). We're essentially meddlers (with a few exceptions). That said, I believe it's only normal that, in a pie chart, QA will be a small slice. Also, if you compare it with the "other game" chart you'll see that the QA slice is even slightly bigger in Project Eternity.

[Ranath]

Let's not forget there's no scale on the pie chart, it's just percentages.

Also, relating to buggyness: the field representing 'QA' for Project Eternity is relatively about twice the size of the the 'QA' slice in the "generic game X' when set out proportional to the 'programming' field.

I don't exactly see how having twice the amount of quality assurance testing would be detrimental to the quality of the code, and if so, how having more of this apparently evil detrimental QA would result in a better game .

 

Also; does the piechart plot for number of people, cost (wages etc.), or working hours?

 

That said; I'm sure it will be awesome!

[Cantousent]

I think Feargus mentioned to someone that he was entering or looking to enter into an arrangement for the QA work and, in the meantime, Obsidz has some in-house QA people who rock. I also think it's cool to see the production folks get a slap on the back.

 

I think it was an interesting read and it does give out a little information about the budgetting without giving enough to serve as kindling for massive flamewars. I think the QA actually looks impressive for a couple of reasons. First of all, it's significantly larger in the pie chart for Project Eternity. Second of all, using the Unity engine means that it will be a little easier to track down issues. Now, I don't suggest it will be easy per se, but it will be easier, and that gives a little wiggle room. (no, that's not what she said.) I think QA deserve a lot of credit and, as alan says, catching stuff early is certainly better, but I would also think that the QA team will still be much larger from the halfway point forward. At least that's my take.

 

One thing I would mention to folks who offer to QA for the game is that it's not like playing the game for fun. If you do actual QA work, you're going to hit the same areas over and over and over again. You're going to try to create infinite dialogue loops in dialogue you've read so often you quote it in your sleep. You're going to play parts of the game out of order. Some of you guys who offered might have done it and know it all better than me, so don't take my comments the wrong way. I just wanted to give a little heads up to folks who haven't done QA work and might not entirely understand how much it can ruin the game. If you want to enjoy the story, don't do QA work because you're very likely to play the beginning and the end and then hit big parts of the middle.

[Archmage Silver]

I already knew most of the generic dev stuff, but the PE piechart was interesting.

[Rary the Traitor]

Might want to allocate more resources to QA.

[Wombat]

Thanks for the update. Probably because reading comments, some design documents, and other sources for years, the pie charts seem to be quite natural to my eyes. Also, some designers occasionally complained of feeling like a part of a huge machine as in

.

 

Some of recent entries of K. Saunder's and Ziets' Formspring let us glance at the game development. I hope Obsidian will gradually give info about who are responsible for what elements of the game. For it would work when some of them try to make cloud-funding in future, either as Obsidian or a part of any other entity.* Also, giving such info would be helpful to those who are thinking of getting into the industry.

 

* I don't hope Obsidian will lose some talents but I'd like whole the industry to be more flexible especially in terms of human resource management.

Edited November 10, 2012 by Wombat

[Hormalakh]

Two things that concern me:

 

1- QA. As someone who used to work in software development and as a QA, I realized early that the more you know about the systems you are testing, the better a tester you can be. Knowing how things fit together and how things are inter-related can help with better QA. Why is this important? Most outsiders not invested in the game won't know these systems well enough and might not find those bugs that someone would otherwise look for.

 

2- In a lot of the older IE games, there were a lot of unfinished business mods where developers just didn't have enough time to incorporate all that "stuff" into the game. I really hope this will be minimized, because the more unfinished business left over, the less "completed" stuff gets into the game. Too much stuff that isn't well implemented is just as bad as too little stuff.

 

Not trying to be rude or tell how Obs should do their job. These are just the things that I've noticed while playing older IE games. I'm sure they know what they're doing.

[Hormalakh]

As part of the pre-production the entire team could watch all relevant episodes of Extra Credits.

 

Its entirely free, and the worst that could happen is that noone learned anything.

 

Well, that's the thing. Now that we have a pie chart, people (including myself) who know either nothing or very little about the process are trying to figure out whether this is enough QA, whether they need more QA, what having QA actually means and costs, etc. etc.

 

In Obsidian's other games, they've had a publisher. In most cases it is the publisher's responsibility to conduct the final quality assurance.

With PE, the responsibility of QA befalls entirely to themselves.

 

Wow I would recommend not the devs watching Extra Credits, but us the gamers. That stuff is really interesting and helps us get a better idea of how things are done.

[Wombat]

I think Sawyer is probably one of the best choices for the lead in Obsidian when it comes to resource management, due to his critical thinking and experience. As long as Sawyer keeps other designers on track, preventing them from "improving" things even in last minutes as in their old habits, I don't think the ship is going to end up with being on a mountain.

 

I don't know about other people but I found some of stretch goals were quite ambitious and I even asked for 4M stretch goal to be "realistic." This might have disappointed some people but, I think, Obsidian made a good decision of sacrificing Avellone's private vacation time for the success of the project.

 

Also, quite many old "unfinished business" mods tend to be about some sub-plots, which can mean the main elements were already completed and that there were already enough content and solid system, inspiring the modders to add further content. I guess it's more about interpretation. After all, how can we tell something like RPGs can be completed? In fact, I think rather games after the demise of Interplay felt rushed (IWD2, KotORII, ToEE, Alpha Protocol and FONV*). This is why I have repeated no costly implementations such as full voice-over, 3D camera, cut-scenes, and physics engines.

 

I don't know much about inside QA works and this is not intended for counterargument but rather a personal view from years of observation.

 

Can be more beneficial if these are sorted out depending on the size and the aim of the development.

 

*In FONV's case, despite of the general reception, I think it is in relatively good shape especially considering it is based on Gamebryo.

 

As part of the pre-production the entire team could watch all relevant episodes of Extra Credits.

 

Its entirely free, and the worst that could happen is that noone learned anything.

Can be more beneficial if these are sorted out depending on the size and the aim of each project.

[Monte Carlo]

This was a really interesting update from a layman's perspective.

 

But.

 

I want to know the important stuff. I want a bug place under the coffee machine. I want to know the Machiavellian office politics, to see if Ferg is basically Tony Soprano. I need to see Avellone literally crying into his beer as he tries to think up a romance to keep forum weenies happy. I want to see Sawyer threatening interns with a chainsaw. I want to see Adam's real pie charts, the one costing the spend on beer, pizza and replacement polyhedral dice.

 

This is the stuff we know happens but we would like the warts and all evidence.

[sesobebo]

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...

 

crates confirmed!

[Aoyagi]

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.

 

Yeah, the way you describe production department/team makes me wonder what do they do that they aren't loathed by the rest of the studio ^^

[jethro]

Seeing that stuff is the most important thing in the game I'm happy to see that 100% of the production team is tasked with creating, refining and testing this stuff. But well, it is good to know they have the staff to handle the stuff

 

Sorry, couldn't resist ;-)

Edited November 10, 2012 by jethro

[bahamut_gundam]

Just wondering, if you are using Unity, then what do your engine programmers do ?

Do they modify Unity itself ?

[Dawn_]

Great buggy games will eventually be just great games. Average bug free games will always be average. This is because if you spend more on QA than design and production, you get better quality but less content. I can put up with the bugs in a game that is truly great, because it is a great game, far longer than I can put up with an average game, because it has no bugs.

 

Who said Gothic 3, Daggerfall ? :3

Edited November 10, 2012 by Dawn_

[Ignatius]

Mmm... stuff.

[Falkon Swiftblade]

Just wondering, if you are using Unity, then what do your engine programmers do ?

Do they modify Unity itself ?

 

They still code lots, but a lot of the structure and framework would have been done for them. When I went to College, one thing that made our game dev degree different from other colleges offering similar degrees, was the game dev kids coded their engine from scratch, and didn't use things like Unreal or Unity to code with. I think this has helped them get better jobs as a result because even though everyone primarily codes in C or C++, there's lots of ways to get to x, and when you use something like Unity, you sacrifice some of that control, but Unity is great for allowing teams to add and modify bits and bobs along the way, so I don't see it hurting things.

[nikolokolus]

On the kickstarter page the first comments are about the chunk-size of the QA in the chart.

 

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.

 

I love all of these armchair game developers and self appointed games publishing experts dispensing advice. It really warms my heart.

[Dawn_]

On the kickstarter page the first comments are about the chunk-size of the QA in the chart.

 

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.

 

I love all of these armchair game developers and self appointed games publishing experts dispensing advice. It really warms my heart.

 

It's the beauty of KS, my dear

[Hormalakh]

On the kickstarter page the first comments are about the chunk-size of the QA in the chart.

 

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.

 

I love all of these armchair game developers and self appointed games publishing experts dispensing advice. It really warms my heart.

 

From reading the first few pages, everyone's just worried about bugs, that's all. I don't see it as advice more as concerns.

[rjshae]

I found it interesting that the design slice is much larger. It left me wondering which part of the slice is the biggest contributor to the cost? Is it because this requires development of a whole new game system, or that this is a new setting needs to be fleshed out and integrated? Perhaps both?

[Wombat]

I beleive the division is nearer to that of their projects in BIS: Basically, they are doing what they had been proven to be good at. So, as long as our expectations remain rational, personally, I don't seem too many problems. Of course, unpredictable things can happen but considering their experience, at least, I think it's one of the safer bets in cloud-funding.

[Michael_Galt]

Personally, I gave Obsidian money because I believe they know how to make great games, while I admit some of their games have been buggy, I also believe the following.

 

Great buggy games will eventually be just great games. Average bug free games will always be average. This is because if you spend more on QA than design and production, you get better quality but less content. I can put up with the bugs in a game that is truly great, because it is a great game, far longer than I can put up with an average game, because it has no bugs.

 

If you enjoy beta testing unfinished games, I believe you will share this philosophy, because you can see when a game is good even before it is good enough. Now I'm not suggesting massive ugly bugs that lose save games, crash the client at specific intervals or mess up game play are acceptable, I'm just saying minor bugs, even if they are many can be fixed given time. Minor bugs don't stop great games being great, they just stop them being perfect.

 

We gave money to Obsidian because we believed in them, let's not become "meddling" investors that try to change their design or development process ....because we all hear the stories of how publishers come in and make a mess of a developers vision and there is no end of gamers that cite those reasons as why the games were never as good as they could have been. We are now those "publishers" in this scenario.....scary thought huh?

 

This. I said this before, when discussion was going regarding super stretch goals. Most people don't agree. They apparently would rather modders add new content vice identify and fix issues. I would rather the professionals make as much product as possible, and then it gets "honed to perfection" by the thousands/millions of people that play it and identify bugs. But, as you said, not computer destroying bugs, but minor ones. If I can complete the main quest, I don't really care about bugs.

[Luridis]

They still code lots, but a lot of the structure and framework would have been done for them. When I went to College, one thing that made our game dev degree different from other colleges offering similar degrees, was the game dev kids coded their engine from scratch, and didn't use things like Unreal or Unity to code with. I think this has helped them get better jobs as a result because even though everyone primarily codes in C or C++, there's lots of ways to get to x, and when you use something like Unity, you sacrifice some of that control, but Unity is great for allowing teams to add and modify bits and bobs along the way, so I don't see it hurting things.

 

Unity supports C#, a flavor of Python and Java via AOTC. (That's ahead-of-time-compilation.) External plugins are likely to be written in Mono C#.

 

"C" is a low level language usually used for systems programming, it doesn't support classes or objects or even strings natively. You wouldn't write a game in C unless you were a masochistic coder or you planned to run on bare metal. (Without an operating system.) "C++" is for the most part used as a library language, it's great for things like 3D engines and OS boiler plate code. Because of the manual memory management in C++, I suspect it's used more often in console games. The newer and higher level languages are better for applications as they allow rapid iteration on code an have expansive libraries for things like image compression, XML, modeling, codecs, etc.

 

It's not 1992 anymore and things have evolved past C/C++.