Note: If you’re not into game development this post will be pretty boring. So you may want to just skip this.

Introduction

In traditional game development there are usually two parties: The Developer and the Publisher.  There is no exact definition of the responsibilities for each party so I will only discuss our experiences with it.

The Developer

The Developer is responsible for creating the game. Their responsibility is to provide the publisher with a title that is reasonably functional and adheres to the agreed upon design. They are also responsible to address bugs and other defects identified by the publisher.

The Publisher

The publisher typically gets the lion’s share of the revenue from the game so in turn they have a greater responsibility. Their job is to make sure the game is good. If a game is not good (buggy or not fun) it is the publisher’s fault, not the developer. The publisher is supposed to provide the quality assurance and have the distance from the development process necessary to be able to stand back and look at the game objectively. They also are responsible for the marketing, support, promotion, sales and defect releases. A customer with problems contacts the publisher and the publisher puts this together as a defect report for the developer.

Stardock: The Developer but NOT the Publisher

We have developed games in the past where we were not the publisher. The Corporate Machine, Starcraft: Retribution, Business Tycoon, The Political Machine, Galactic Civilizations.  Our experience with different publishers varied greatly but in each case we can say we had a very positive experience except in the case of Strategy First who didn’t provide any real QA or feedback and didn’t pay royalties. Ubi Soft and 2K Games were both excellent with Ubi Soft providing outstanding marketing support for The Political Machine and helping considerably with QA.

Stardock: The Publisher but NOT the Developer

In my opinion, this is where we have done the best historically. A studio also doing publishing provides a level of feedback and QA not normally available to publisher-only companies.  The initial concepts for Sins of a Solar Empire and Demigod, for example, were radically different than what was eventually released. In both cases, Stardock has helped with development (i.e. source code sharing) which is not the norm but made a huge positive impact.  While Demigod had networking problems on launch, this was largely the result of the sheer volume of players versus the scoped infrastructure (i.e. it was a network engineering issue that neither Stardock or GPG had a lot of experience in).

But in terms of internal game review, both games benefited greatly from the game review process in making the games better.

Stardock: The Developer AND Publisher

Ironically, Stardock has a much less even record in this regard. With the benefit of hindsight, it isn’t surprising. A lot of benefit of the game review process comes from not having an emotional investment into the game “as-is”.  Otherwise you get this:

It’s just a little slimy. It’s still good! It’s STILL GOOD!

Literally one year ago, Stardock finally did something about this problem by explicitly breaking the groups up. This required quite a few new hires that was a pretty big investment for a small company that didn’t anticipate having any new games out for a year. But it was important.  Fallen Enchantress is the first title to go through this new process.

Example: Fallen Enchantress 0.42

WARNING: SPOILERS! TURN BACK NOW IF YE DON’T WANT TO LEARN THINGS YOU MAY NOT WANT TO KNOW…

.

.

.

.

.

.

.

You’ve been warned…

.

.

.

.

.

This is a typical UI comment that’ll get sent in and logged. Nice to have means “If there’s time”. The other request is more pressing.

Nothing new here. Just an example of a missing asset.

This is one of those XML / programming things. The game sets the minimum distance between players but there is no XML to define typical distance. I was on a large map recently where all players were bunched up in a corner.  You don’t want to make it so that players know that no one else will be near them but at the same time, you want to generally have some distance between players if you can so that they can build up. You can always add lots of players (I think our limit is 32 players) if you want a brawl.

Some UI requests.

Information UI request.

Another UI request.

The process you see here is the same with titles we publish. But it wasn’t really present before on games internally developed because the Executive Producer was also the lead designer (i.e. me) which is an inherent conflict of interest.  I’m much better at complaining about other people’s designs than my own.