[tab]This article will focus on the design aspects of making a mod, not the technical challenges. The goal is that readers will gain some insight into common pitfalls, how to avoid them and that our mods will be improved by it. [tab]Let me start by saying that there is no perfect way to make a mod. Understanding that I am unqualified to write this article I enlisted the aid of some of my fellow mod makers (and my favorite designer) so that readers could get a wide range of opinions. Each of the Danger sections are concluded by a question that has been asked to the designers about how they deal with the challenges of development. Their responses are the heart of this article and offer very practical advice for all mod makers. [tab]I would like to thank the following people for responding to the interview questions and providing input to this article: [tab]Soren Johnson- Civilization 4 Lead Designer [tab]Sevo- Designer of Sevomod 3, Sevo’s Civilopedia and Sevo’s Faces of God [tab]Thamis- Designer of the Ancient Mediterranean mod (Civ4) and the Ancient Mediterranean mod (Civ3) [tab]Rhye- Designer of Rhye’s Catapult and Rhye’s of Civilization Build the Game You Want to Play: [tab]The first rule: you are the only person who has to like what you have created. Don’t make the mod you think other people will want, don’t change a design based on outside feedback unless you agree with it. It is better to have an unpopular mod you enjoy than a popular one you don’t. That goes for all of the advice in this article, if you don’t like it, don’t use it. This is the advantage of modding, Firaxis has to worry about making sales and mass appeal, but we don’t. [tab]The truth is, if you stick to what you like in time you will find others that are looking for the same thing, so it will work out anyway. 1.0[tab]Avoiding the Design Pitfalls: 1.1[tab]The Danger of More: [tab]“Perfection is not achieved when there is nothing left to add, but when there is nothing left to take away.” -- Antoine de St. Exupery [tab]Every new object has a cost, not just in what it takes to create, test and manage, but the player has to keep track of it as well. In general we should only add items because they offer a significant improvement to some aspect of the game, and not just to have more units, more resources, etc. [tab]It sounds good to be able to offer a long list of new objects. That was much of the appeal of the very popular Civ3 Double your Pleasure (DyP) mod. But the success of DyP wasn’t because of all the new objects, but because each one had a distinct functional purpose. Adding buildings is easy, making them truly worthwhile is the hard part. [tab]Is it needed? Would it be missed if it was taken out? Is it functionaly unique? If the answer to these is no, it should be considered for removal. Q: There always seems to be one more building or unit that would be perfect to have in the game, how do you decide what to include and what to keep out? 1.2[tab]The Danger of Flavor: [tab]Why do games based on movies and movies based on books always seem to be bad? There are exceptions, but we are usually disappointed with the results of these conversions. The reason is that the design of the new game or movie is based so strongly on the flavor of its source that its own functional design suffers. [tab]At some point you should look at your mod as just a functional process, a board game without any stylized components, an exercise in mathematics. A game must be enjoyable at this layer to be fun. Some games are so well designed they only exist at this layer and are still amazing to play (chess, othello, tetris, etc). But a game that has incredible flavor but no meaningful functional elements will always be a bad game. [tab]If you fall in love with a concept that seems like a great idea, but doesn’t have any functional value, the temptation will be to come up with a functional need. There isn’t anything wrong with this, some ideas come from flavor, and some come from function. Different people are more apt to think from one end or the other. But, be aware of the danger that designing from flavor presents. If you aren’t able to come up with an elegant functional need you are best off to remove or change the flavor rather than let the functional design suffer for it. [tab]This danger is even more prevelant when you are basing your mod on a known source. It is nice to already have all that flavor developed for you, but it can be as constraining as it is helpful. You will either have to let your design suffer (to what level is up to your own ability to find creative elegant solutions) or be willing to step outside the bounds of the source material and develop new elements, or exclude elements despite their existence in the source when the material doesn’t improve the game play of your mod. Q: How do you balance between Function and Flavor? What do you do when you have a functional need for an element but aren’t excited about the flavor ideas you have? How do you deal with a good flavor concept that has no functional need? 1.3[tab]The Danger of Patterns: [tab]Starcraft was a big eye-opener for me, an RTS that offered 3 different forces that were balanced but completely unlike each other. It’s so much easier to balance a game by making the options mirror each other but it’s more enjoyable for the player to have a variety of options that are dissimilar. [tab]We could be talking about any feature of the game. For example we could have a series of Civics that gave +3 research at the first level, then you could upgrade to one that gave +9 research when you learned the appropriate tech and up to +15 with the final tech. Or you could have a series of civics, one of which gave +3 research, another gave +3 gold and one that game +3 hammers. In either case the result may be balanced but uncreative, and dull for the player. [tab]The obvious response to this is that if we don’t stick to patterns then invariably some options will be better than others. Better or unbalanced options are the same as no options. But I think we have some flexibility here. This is the challenge of design, presenting the player with multiple options with different risks and rewards for each, and having each viable for different reasons or in different situations. Q: It seems easier to build on a tested design, and have new elements be functionally similar concepts to existing ones but with a new power level or different range of effect. How do you determine when this isn’t innovative enough? Or is that even a concern for a strategy game? 1.4[tab]The Danger of Complexity: [tab]Overly complex designs are the easiest mistake for a designer to make. A designer should differentiate between systems that are fun to design, and those that are fun to play, they are rarely the same. [tab]Personally I am fighting this issue all of the time. I find myself designing the system the way I imagine, setting it down and coming back to it with a clear head to take a look at what I made. Most of the time I can cut a lot of the design without losing its functional purpose or flavor, or I find that the mod is better without it at all. [tab]As in all things there is a balance here. Every new feature brings in some additional complexity, just as every new object adds to the amount of information the player needs to track as we discussed in the Danger of More section. Having the idea is only the start. [tab]I was considering a manufacturing process for a mod. If you have access to dyes and cotton you can build a tailor shop that produces a “Cloth” resource. If you have access to fur you can build a leatherworker that produces a “Leather” resource. If you have cloth and leather in a city then all units produced in that city get leather breastplates that improve their combat ability. And on and on it went, it was a lot of fun to design, huge complex systems with interdependencies everywhere. It would have been a disaster to play for most players. That’s not to say that some people wouldn’t have enjoyed it, some people love complexity. Just keep in mind that what sounds reasonably simple in the design stages, when added together with everything else and in the hands of a player that hasn’t spent the hours considering and tinkering with the mod as you have, can be a substantial roadblock. Q: How do you balance between complex ideas that bring new elements to the game and the difficulty they cause casual players? 2.0[tab]Writing your Design Document: [tab]It’s not fun, everyone wants to get right into making changes and seeing those changes in the game. But your first step is to get a design document written. It can be a forum post you update, a Word document or just notes on paper. Without it your mod design won’t have focus and it will be difficult to make the best use of your time without a clear idea of what needs to be done. It will also be difficult for team members to help you if they don’t have access to the full design list. [tab]I have a hard time being creative in front of a computer so I grab a notepad and pen when I want to do serious design work. Sitting in a comfortable chair I jot down ideas and think about things I want to improve. Different people have different methods, the important part is to find one that works for you. 3.0[tab]Economics = Choice under Scarcity: [tab]A game is an entertainment activity that gives us options and rewards us for selecting them skillfully. The quality of those options, the amount of appropriate risk and reward we get from each, the variety of options (without being overwhelming) and the successful merger of function with a matching flavor determines if the game is a good one. [tab]To make choices we need to have some cost, something we give up to gain the advantage the option offers. This could be paid in some other resource like gold or production time, or it could be in something less definable. One of the classic early game options is, do you build the infrastructure of your cities or build defenders? If you build the infrastructure you will have better cities by the mid-game, if you last that long. But the price you pay for it is in increased risk of attack and losing the game. [tab]That is beautiful game design (God bless you Sid Meier!). To have options we need to have limits, we can’t do it all so some things need to be sacrificed to gain others. That doesn’t mean that all of the options need to have a direct disadvantage, it may be enough to just have the sacrifice be that you have given up taking other paths, it is economics. [tab]I’m particularly fond of Civ4’s civic design. Personally I like having civics that have a direct disadvantage along with whatever advantages it offers, but from a straight design perspective I have a deep appreciation for what Firaxis did. The civic’s don’t need disadvantages, their disadvantage is that if you pick a civic you can’t pick any of the other ones in that category. [tab]Another truism of scarcity is that we must have good and bad elements for it to work, the Desert dilemma. From a players perspective deserts seem useless, they have a few functions but are generally the least useful of the terrains. So you may wonder why they can’t be removed and replaced with something that does more. Their design function is that they aren’t useful, and therefore by comparison other terrains are. The difference between the two makes the players strategic options more interesting. [tab]There was an RTS game (I don’t recall which one) that marketed the fact that if you moved your land units through water tiles they automatically turned into boats and crossed. You no longer had to worry about making transports and moving the units across yourself. Although it sounded like a good idea the end result was that water didn’t matter anymore. It was just land you couldn’t put cities on. The cost that water travel imposed was gone, and with it the function of the water itself. 4.0[tab]When in Doubt, Trust Firaxis: [tab]The old saying is if there is a fence in the woods you should know who built it and why it was built before you tear it down. That was never more true than when making mods. I will admit, I love changing things more than I love reading about the way things work so the trap I sometimes get caught in is designing something without a good appreciation for the way its associated systems work. [tab]My advice is before you make a significant change you review the way a similar system works in detail. If you want to make a new unitcombat, look at the ones that are already developed. Do a search in the python, xml and the SDK for matches against a similar unitcombat and see where it has been used and what it has been used for. When you understand how the data is used you will be better prepared to make your own. [tab]The same goes for balancing. Firaxis has done more work, and has had more man hours invested in “Vanilla Civ” then we can hope to with any one mod. Don’t let all of the testing and feedback go to waste. Look at the iCombat increases between upgraded units that Civ4 applied when you consider your own. Base your new specialists effects on those that already exist. 5.0[tab]Prioritizing and Saying No: [tab]The sad fact is that we all have limited time. As much as we may love to mod there are only so many hours in the day and most of us have jobs and families that also demand our time (sorry honey, I mean that we want to spend time with). [tab]We have to be careful about our ambition. If our only goal is to mod for fun, to play around, change our game and learn a little bit in the process then this isn’t a big concern. If we are working with others and they have helped by devoting time and effort to your mod this becomes more important. In those situations there is some responsibility to produce a working mod. [tab]So we have to realistically decide what will and won’t be done, at least for the short term. If you aren’t familiar with python or C++ then starting a mod that requires programming changes is probably going to be too much. But you could focus on xml modding only. [tab]Once you have your idea you will need to prioritize them. I am always on the lookout for “Drool Factor”, those features or additions that will make people want to download and play the mod. No one ever downloaded a mod because it had 17 different kinds of infantry or a ice cream truck unit that played music when it drove around (well, maybe I would download that mod just to try it out) so as interesting as those ideas may be they don’t have any “Drool Factor”. [tab]You are all players and have read countless marketing releases talking about one game or another. What features did you read about that excited you? Those are the kinds of things that should be at the top of the priority list. I hate to spend time working on a feature that players aren’t going to be excited about. [tab]And some changes shouldn’t be made at all. This is more difficult when you are working with a team that is as excited and working as hard on the mod as you are. But the mod owner has to be the one to say what is going to go in and what isn’t. Remember its easier to say no and then change your mind and add it later than it is to do all the work to make something only to remove it later on. 6.0[tab]Building a Team: [tab]There is no magic trick to building a team. Assume from the beginning that you will need to do all of the work yourself, then start working. If people join you along the way to help out, so much the better, but don’t expect it. [tab]In most cases an idea, no matter how appealing, won’t draw a team by itself. Instead the mod owner will have to show the work he has done to start getting help. The reason is that there are new ideas for mods posted every day asking for help. Naturally people don’t want to spend time working on a mod idea that won’t ever be released. If they see that you have put a lot of effort into it yourself the risk that their work will go wasted is lessened and they will be more apt to join. [tab]It is my opinion that the mod owner for a complex mod should be a programmer. He doesn’t need to be the best programmer on the team (I’m certainly not on my team) but he does need to understand the programming aspects. This is because the mod owner has to be the one to decide what is and isn’t going to go into the mod, he won’t be able to make these decisions well if he doesn’t have a decent appreciation for what has to happen “under the covers” to make it work. Also the mod owner always has to be prepared to do it alone if need be. If you leave the programming aspects to someone else without an ability to pick up if they leave you may risk losing your mod if they go on to other things. [tab]One more point about teams. This is an open, fun, collaborative process. Don’t expect deadlines and arbitrary goals to be met unless you are willing to pay your team. It’s the mod owners responsibility to get the work that needs to be done listed and the team members can work on different aspects as they desire. Anything more than that isn’t fun for anyone. Invariably you will be working on some component and want a piece from a team member to finish it, or team members will come and go as their real lives dictate, but that is the nature of collaborative modding. 7.0[tab]When to Release: [tab]A mod is never perfect, there is always some new feature, art or object you would love to get added before you release. The danger of that is that you may never get it out. [tab]Momentum is important for a mod, both for you (hearing from players that enjoy your mod will give you the energy to keep going) and especially for your team (who want to see their contributions out and available). Other mod makers may have different ways of doing this but I like to set hard release dates and then work back from them instead of working from feature lists. If I commit to release a new version on the first Friday of each month then you and your team know when they have to have new stuff in by to have it included. [tab]Releasing after certain features are in creates a pressure to get work done that may aggravate your team if they feel like they are holding up the release. Better to just tell them the dates and let them manage their part as they prefer.