It is a term mostly applied to movies, but believe it or not, it is a huge part of game development. Director cuts are a big deal in all media facets. Movies, books, TV shows, and games all have this period where they have to look at the project as a whole and cut out elements for various reasons. For me, one of the most infamous directors cut in gaming came with the Knights of the Old Republic 2 video game published by Obsidian, as well as the original Fable. Both of these, being video games, had a more glaring reflection of their cuts. The video game industry and PnP game industry may not seem to have a lot in common, but that is not true. In our industry director’s cuts exist, though you may not see them. So, what are they, why do we have them, and why am I talking about them?
In movies content is generally cut for two reasons: time, and ratings. Content is removed because the movie runs too long and scenes are removed to shorten it and to tweak the flow. It is a story telling device and a good one. Though some scenes are missed, and people would argue their relevance, they are ultimately removed to make the project better. The second, not being relative to PnP gaming, is ratings. Movies want a rating within a certain range to increase sales within a target audience. PG13 ratings are optimum for summer movies as you can get a bunch of teenage dollars for good weekend sales. Rated R movies are fine if you demographic is for adults, but in some cases cutting a scene that is the only scene that would give you the R rating is worth cutting to get the PG13 rating. You get a bigger audience with PG13 than R.
In books, content is edited out because of page count mostly. This goes back to time. If you can cut out wasted sections to give a more fluid read then you should. In some cases an artists writes in a scene they want in a story that may be nice, but really doesn’t advance the story. There are many books that I read that could have stood a little more of this.
In gaming, particularly video games, content is cut due to publisher’s wanting to release the content. A publisher invests money to a developer to build the game. This pays the payroll of the developer for all the programs. A publisher wants a return on the investment. It falls to the developer to make benchmarks within a certain time or lose funding. This includes a release date. Most publishers understand that release dates are fluid and will change during development. However, at some point a publisher will exercise their right to stop funnelling money into a project and force a release. This was, in my opinion, what happened with KotoR2. When a developer begins a project they start by ironing out what will be developed first. They get the most important elements finished. Working from the top down they build the overall story arc scenarios and the necessary game play development done. They add in extra features towards the end. For instance, online play options. In a game focusing on single player play, online matches are at the bottom of the development totem pole. That is why some good single player games have terrible multi player. Multi player reviews tend to say things like “tacked on” and that is exactly what they are.
Ultimately, the developer has the responsibility of making the product and keeping the publisher happy. The publisher has a responsibility to fund the project and tug the leash. Developers being what they are, tend to keep going and if they were allowed would continue building on their project till until the end of days. They are artists working on a project. A publisher steps in and says “Good work, this is enough to release so you have to stop and release it now.” So the developer cuts out unfinished stuff, or stops developing certain elements to finish what they need.
In independent development the publisher and developer are the same person. There is no money guy in the corner stipulating what gets done, how or when. It is nice to be independent as you don’t have an accountant telling you what development decisions have to be made. You simply make them, knowing that the bottom line is either going to suffer or benefit from your choices.
This is the problem with most independent developers. While you think it is great, you have to stop and remember to think like a publisher to. There is money involved and it is usually your money. So you have to think, on some level, like a businessman who is out to make a buck. At least, you are not dictated by it, but you are conscious of it.
I wear two hats. The developer in me is working on projects, the publisher in me is looking at it and saying “Are you done yet, I think you need to cut the cord and run with it. You are going to have to sacrifice X and Y to have Z”. The two hats vie for dominance on my head, but they are, in some sense, both there at the same time. If I stopped listening to either points of view Ironwood will fail.
This weekend the developer in my had a great idea that the publisher in me said “Sorry, it is going to have to wait.”. The idea was to add in a few new features I had initially decided to leave out. One was adding images to the content creator. This allows you to upload images for the content. Sounds simple enough, and in truth it would be easy. The developer in me said I could just add the lines of code, real simple like, and I am done. The publisher in me said WRONG!
If you could imagine a meeting with two people like, developer Dan, and publisher Paul, it would have played out like this:
Dan: I think we should add in images. People will like being able to add images to their content and it will be real easy to add.
Paul: Sounds good but I have two questions: will that push back release, and how many images do you have ready to go?
Dan: It may push it back a week or so. We don’t have any images.
Paul: Well, wouldn’t developing images for the content we have take longer than a week.
Dan: Absolutely, but we weren’t going to add in images for our content, just add the feature.
Paul: You can’t do that. One thing is that if you have the feature people will want artwork already there. Another thing is that you can’t release it without having images for your own content. It would look half assed and it would hurt the image of the product more than not having images as a feature at all.
Dan: Maybe, but I don’t see why not supplying images would be bad.
Paul: A reviewer or a customer may say “It would have been nice to have images,” and leave it at that. Or, you could add it in and get comments like “The image feature is nice, but there are no supplied images, not even for supplied content. Its like the feature is tacked on.”
Dan: ????
Paul: It is a matter of having a small line or a larger one. It sounds silly, but you can leave out the option, see how big of a demand there is for it, and we can add it in a patch. If we add it in a patch you can release that at any time, and with any level of additions, or none at all. At the same time, when you release the patch for free it shows that we are conscious of the needs of the user, and we will listen. I, as the publisher, fully support more features, however, they must be implemented properly or not at all. We can’t keep a release date back to develop artwork for all the content. However, we can start working on artwork now and add it all in a patch later.
Dan: So we are not going to add it in?
Paul: No, we are going to add it in. We are just not going to do it now. What you can do is add in the code, but do not add the feature. Furthermore, you cannot push release back even a day. Therefore, if you add in the code, it better be real simple code or none at all and just wait for it to be done later.
Dan: [Dejectedly] alright. You are the publisher. We will add it in later. I’ll add it to the patch feature list.
Paul: Good boy, Dan. Now get back to work.
That is what it is like for me to make decisions with the projects. (BTW, while the above conversation is a bit of a parody on the process, the actually discussion of the feature of images was similar, but not entirely within that line of purpose. In other words, yes, I am adding in the images feature in a patch, but the cited reasons above are only part of a much bigger list of reasons to push it to patch rather than release).
Every single feature in the projects I work on gets that kind of discussion. There are about 75+ pages of rules not included with the player’s guidebooks because of time and space. One thing was simplified rules. I removed the simplified rules because of space, time, and confusion. I didn’t want a book with too many versions of rules. So I test those separately and release them as free downloads (simple combat for Fantasy Sagas being a prime example).
I know that independent development of anything has a two sided reputation. On the one side the content is usually more interesting because developers don’t have to worry about publishers or anyone getting uptight about what you are doing. It is not guided by the bottom line. On the other hand, it has the reputation of being unpolished or, at best, disorganized. This is because of the lack of a publisher. A publisher is necessary to keep the project in check. Without a publisher, or at least the attitude of a publisher, the project can run way off target and run into more problems. Independent developers call themselves independent publishers but this is not true. They are developers. They need to start thinking like publishers on some level or their projects will ultimately fail.
So, there will be features not included in my projects that I want to be there but I have to cut. One thing is that I want everyone to know that the cuts I make from my projects are done because it is better for the project as a whole, and thus better for the customer. I make the choices as to what to cut because I know, deep down, that this is the best way to get the project into a format that the customer will enjoy. If a feature or element is not included I will almost always add it later for free, or release a different product that can give that feature the focus it deserves.
One case in point, and I am closing with this, is that the CRM doesn’t include anything for building a campaign world. That is because I will release a world builder separately. However, the world builder is going to be very in depth. I could add something in the CRM for that, but it would be a joke compared to what I want to do. Why? Because if I added the full featured world builder I have in mind there would be way too much to the content creator. The idea is to make things simple and organized, but the more content you add the more complicated it gets. So the CRM lets you build the elements, another product, a big product on the size and scale of the CRM, will build the worlds. It is done this way because it is fair to the products, and ultimately to the customers who buy these products. They are cheap enough that it is obviously not a lame attempt to get more products sold. It is a simple truth that I want these products done right, and the only way to do that is to cut the idea that a world builder could be part of the CRM.
By the way, I decided long ago that they would be two different products. When I started writing the design docs I realized that I had to put the world builder into a different doc for organization. When they were both done, I intended to merge them, but they were so big in and of themselves that they obviously stood alone as separate products. They still work together (CRM files are uploaded to the world builder), but they are, and since the design docs, will remain separate programs. It is the publisher in me that made that decision and the developer in me agrees. Partly because that allows the developer in me to truly explore both projects fully.
Happy gaming!
