HOW TO: Design a Mod

Kael

Deity
Joined
May 6, 2002
Messages
17,401
Location
Ohio
[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?

Soren Johnson said:
Look at other successful games as an example of the number of units/buildings/choices to include. For example, Blizzard RTS's stick to a very rigid limit of 12-15 units per faction. That's a reasonable number of choices. We tried to have about 8-10 unit choices per era in Civ4, with the understanding that there would be some overlap. This is one area where there really might be a "magic formula" for how many choices are just right for fun gameplay.

Sevo said:
You need to be careful about adding every new unit that pops up or you can think of--at some point you'll lose focus. I prefer a slower staged approach: add a unit or two and play out a game; see how the new units work in the overall schema. Actually, that's a point I should have made earlier: if you're in any way responsible for the overall direction and management of a mod, you ought to be playing it pretty regularly during "upgrading". It's the single best way to learn how your mod is functioning and what the problems are.

Thamis said:
I will only add buildings or units if they have a gameplay value. In terms of units, this means that the CIV4 concept of one unit being better against another requires a counterpart. I will create that counterpart unit, but only if it also makes sense historically or thematically. If not, I will change the first unit to something that would work.

In TAM [The Ancient Mediterranean mod], we changed the boni for units and added buildings according to feedback we got on what is overpowered and what building is necessary. An example would be that many players complained that there was too much health. Thus, we reduced overall health, and gave health penalties to buildings. We then noticed that in the early game, there wasn't enough health for some civilizations. So we added the well and the cemetary, which are early health buildings.

Rhye said:
Statistically, I decline 80% or more of the proposals I receive from users, for different reasons. One is the design schema: often they don't fit it. Another reason is the lack of graphics: I don't add anything that hasn't an adequate representation. Another reason is complexity / feasibility: often what they propose can't be done or is too hard: but in most cases the idea is good and a simpler variant would be fine.

And a final aspect, one always has to ask himself: will the AI know how to use this change?

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?

Soren Johnson said:
It's easy to think that Function (gameplay) should beat Flavor, but really the Flavor is the whole reason people decide to play a game in the first place. They come for the Flavor; they stay for the Function. You've got to have both elements, so if you have a nice Flavor bit without a matching Function, either work harder to find the Function or cut it out entirely.

Sevo said:
This is probably the most important question to answer in creation of a modpack, in my opinion. This game is so open to creation and modification and there are so many interesting ideas floating around that one tends to want to throw it ALL together and it's easy to get carried away. I think what you leave OUT of a mod is as important as what you put in.

To that end, when I'm working on my mod, I tend to focus first on function and second on Flavor, because if it's beautiful and it's unique but it's totally unplayable because of balance issues or gameplay, then no one will play it. That's really the trick, I suppose, to making a great mod: creating the flavor and style you picture without losing the function.

As to the need for a functional element without flavor and vice-versa: this is where the ingenuity and creativity of modding comes into play. You will find things that are imbalanced, or pieces you need, or things that must be adjusted: you as a modder can implement them any way you can imagine, and your charge is to keep the feel of your mod while you do it. On the other hand, sometimes you have a flavor, an idea that you really love, but the function is poor. You have two choices: find a way to MAKE it function, or drop it despite its flavor.

For example, the settler religion mod: At one point I included this in Sevomod, but it completely unbalanced gameplay since ALL new cities started with a religion. I really like the idea, but it doesn't work in the mod, so I had to lose it. It hurts, but if you can't find a way to keep it functional, then it's better to leave it out. I've tried and dropped dozens of ideas/units/etc because they just didn't fit.

Thamis said:
Flavour is the most important thing for a MOD, as it is what makes it different from the normal game. Flavour graphics, maps, and sounds are the most important thing in my opinion, as they are very easy to implement and they do not alter the gameplay fundamentally.

As soon as a flavour element starts to change gameplay, I ask myself: "Does this really improve gameplay, or does it complicate it?" More is not always better.

Rhye said:
I always tend to add only things that have both function and flavour. I mean that if I have a cool unit designed by somebody else to add, but nowhere to put it without unbalancing the game, I won't bother. And if I feel a gap should be filled by a unit, but I don't have an adequate graphical representation, I won't add it as well.

If we speak about maps, then the function is more important than the flavour. See how many giga maps are being / have been developed: they're pointless, because nobody has a computer strong enough to play them.

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?

Soren Johnson said:
Innovation should not be a primary goal - fun gameplay should be the goal. Innovation is the process of both improving old systems as well as creating new ones out of thin air. However, it is always best to understand what your game's aesthetics are so that your new systems aren't a mis-match. For example, Civ's aesthetics are tiles, turns, and boxes-filling-up-with-stuff.

Sevo said:
This is a harder question to answer, and I think it falls into the domain of "what makes a good mod". It is certainly easier to simply change combat values or movement or whatnot; to actually innovate an entirely new system is difficult.

Sometimes a new system works very well: for example the new Civilopedia I started with was well received because, I think, it was a marked improvement over the old system. On the other hand, I tried a new system for religions in "Faces of God" and while I spent hours and hours putting together the units, python, etc for that mod, in the end the system didn't lend itself to great gameplay; at least not as it stood and I haven't had time to go back and re-examine it. So there's a bit of trial and error involved, certainly, but hitting on a successful new idea is worth the losses you'll encounter.

Thamis said:
The question is whether we are designing MODs or whether we are designing new games. Of course it would be possible to build a new game with the CIV4 SDK, but unless it is totally different from the original gameplay, people will not expect significant changes to how the game plays in a MOD.

There is no rule to balance novelty and familiarity. I like to stick to Soren's design principle (which I learned while doing development testing for Firaxis), which is to keep some of the old (so much that the game is accessible to players of the previous game) and add in something new (to make it more interesting).

Rhye said:
I think that this is a concern. That makes the difference between a mod for personal use and for sharing. For instance, if I just want to boost some units stats, I will not post it. Usually I'd eventually find out another mod better than mine, that does the boost I wanted, plus something else.

I'll share it if I have a unique idea instead, something that hasn't been done before by anybody.

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?

Soren Johnson said:
The best place to introduce complex ideas are at the fringes, in places where the player doesn't have to understand the complexities if they he or she doesn't want to. For example, many Civ4 players probably didn't realize how Great People probabilities are calculated - but not knowing the details didn't necessarily stop them from progressing and enjoying the occasional Great Person that they got naturally.

Sevo said:
I don't worry too much about adding new ideas to gameplay, but my mod is primarily an expansion of gameplay so most users I think follow pretty readily. Even when I change stuff I find that gamers by nature are quick to pick up new functions, if they aren't too mysterious or complicated.

Thamis said:
My approach is always "keep it sound and simple" (aka the KISS principle). I also agree with Soren Johnson's and Sid Meier's design principle of reducing the elements in the game to a minimum while allowing "interesting choices" (to quote Sid) to come to a maximum.

I would never add a feature just because it is cool or new. Features need to fit in with the theme or historical era that the MOD is about, they need to give additional features, not cause gameplay to slow down, and they may not confuse the player. A feature that is only available with a certain key combination (like the buildings razing mod) cannot find a place in my MOD.

Rhye said:
I base myself on feedback. If I see that a complex change is welcome and understood anyway, it's okay. Anyway documentation (including a site, a faq, and quick answers on the forum thread) can be important. But even more important than this, is the difficulty that it will cause me. When I add something to my schedule, I have already asked myself if it's possible to do that, and how.

Two examples of what NOT to do:

- compile a list of features and advertise it with no idea about how to do it, and
- work without a deadline, keeping postponing your work for months and months. it's true, you work for free, but if you don't finish your work you'll have really wasted your time.


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.
 
  • Like
Reactions: PiR
8.0[tab]Further Reading:

The linked articles were all written by Mark Rosewater, Lead Designer for Magic the Gathering. Although Mr Rosewater is specifically talking about Magic I believe the following articles are just as applicable to Mod design.


Finding a Good Mechanic:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr4

When Cards go Bad:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr5

Timmy, Johnny and Spike:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr11

The Write Stuff:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr12

Keeping It Simple:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr21

Bursting with Flavor:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr60

Rules of the Game:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr66

Design 101:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr68

The Value of Pie:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr85

Design 102:
http://www.wizards.com/default.asp?x=mtgcom/daily/mr132


Soren Johnson has a Blog called Designer notes where he talks about game design issues and is worth checking out. I would especially recommend the following:

Seven Deadly Sins for Strategy Games
 
Fantastic Job Kael. You do so many things for the Modmakers. A truly good Samaritan (Did I spell that right?) I'll definetly follow most of these tips as they come from better modmakers than me. But one thing I disagree on. That conversions from Movies and Book tend to be bad. I agree that you cannot stick to the source but basing something on a movie like I did isn't bad. You yourself based FFH from a D&D game that you made. It was loose, yet see how well FFH did. If I may be so Unmodest, The Star Wars Mod hasn't been that bad.
 
Very nice article/interview you put together Kael. You keep doing more and more for the community: Thanks :)
 
Its not a problem. I was as interested to read the responces from Soren, Sevo, Thamis and Rhye as you guys are.
 
Amazing article, Love the wizards links

GO MARK ROSEWATER...
 
Civmansam said:
Fantastic Job Kael. You do so many things for the Modmakers. A truly good Samaritan (Did I spell that right?) I'll definetly follow most of these tips as they come from better modmakers than me. But one thing I disagree on. That conversions from Movies and Book tend to be bad. I agree that you cannot stick to the source but basing something on a movie like I did isn't bad. You yourself based FFH from a D&D game that you made. It was loose, yet see how well FFH did. If I may be so Unmodest, The Star Wars Mod hasn't been that bad.

It easnt my intent to say that basing your mod on movies or books (or D&D games) is bad. Just that mod makers should be more aware of the danger of designing from flavor in that case.

I suspect that at some point you will will have to decide if you are going to stay true to your source or make the best mod possible. You do everything you can to stay close (to match the flavor of your source with the functional aspects of Civ4), but those decisions will come. When they do I would recommend you not be afraid to do whats best for the game play of the mod and not allow it to suffer for authenticity.
 
Thanks for this fantastic article Kael! I have only just begun working on a mod and since I'm completely new to mapmaking, python and xml I get stuck from time to time wich can be ever so frustrating, but it's useful information like this that gives me the energy to keep trying and eventually make it work.

And that icecream-truck sounds kind of interesting too... ;)
 
A brilliant revelation of the minds of great mod makers.
 
I'm just going to rip through this commenting on a few things I feel like commenting on!

Kael said:
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.
I agree 100%. I had great fun making the 40k units for Civ 3. They weren't very good, and not very many people used them, but they were great fun to make!

Kael said:
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.
To be honest I couldn't stand DyP. Far too much stuff in it.

Kael said:
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.
Personally I'm fearing quite some troubles with this myself. The mod I'm making doesn't have much room to manouver backstory-wise. I've already taken quite a few liberties with the plot to make it work for Civ, and I've a feeling I might have to do a few more. I don't like doing it, as it takes away some of the connection to the universe it is based off, but if I was true to that universe then I probably wouldn't be able to even have a tech tree...


Kael said:
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.
While it may not be extremely relavent, I'm going to hark on about 40k again (although not my mod). This "Starcraft factor" has been attempted quite recently in the 40k game "Dawn of War". It has 5 completely different races which work completely differently, but still manage to be fairly balanced - in fact, Warhammer & 40k tabletop games are the same. While it is alot harder to balance things this way, as the best way of balancing is to put alot of playtime in, it makes for a much better game.

Kael said:
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.
I'm pretty sure you're referring to Rise of Nations. The key was that the units couldn't fight when on the water, so could be easily killed by naval units.

I'm not disagreeing with your point though ;)

Kael said:
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.
This is a good point, but sometimes the best way to understand something is to tear it down, and see what happens when you tear it down. More likely than not you will then see quite quickly why it was there, and, to use your fence analogy, why it was so high (to stop the dinosaurs), and quickly rebuild it (before you get eaten).

This can put you in a good position to see what was wrong with it (if anything) - maybe the fence should have been electric so that it more effectively prevented dinorsaurs from crossing it (excepting a huge storm).

Also, on a slightly different note, when you understand something it's usually a good idea to document it so that you can re-understand it if you forget at a later date. For example, the fence in the forest should have really had a warning sign saying "Dinosaurs are on the other side of this fence".

Kael said:
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”.
Somebody is going to have to make that ice cream truck unit...

I think this is probably most important when a mod is starting off. Once people have downloaded it they will quickly get past the "Drool Factor" and see the mod what it is really for, however this "Drool Factor" will ensure that people try it in the first place. The further a mod goes without a "Drool Factor" the less chance that a later incorperation of one will cause poeple to download it. With my 40k mod I'm going for a new interface - mainly because it is very obvious in screenshots.

Kael said:
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.
We're already 2 weeks late with the first release of the CCP, although I supose first releases are slightly different because there is no point releasing something which doesn't actaually do anything! *TGA starts planning a schedule*
 
I think that I now uderstand why my mods fail. They lack flavour. I don't mind as I still find them fun but I do wish that more people would play them.

Must go off and design a 'drool unit'. I guess that a few new nukes will do that to people.
 
Incredible article. :goodjob:

Kael said:
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.

That was Rise of Nations.
 
Awesome read! :) Even for s.o. like me that only enjoys your hard work and lacks the skills to do some modding himself. Now somebody tell me again modders aren't Pro's in their own way!
 
Good read. I will try and absorb as much as I can of that into the Untitled Space mod..............................if it is even possible....:(.

Still, V. good read. Taught me a lot. :)
 
I missed this for a week, but I'm glad that you finally got it jotted down so everyone can benefit from FfH's successes (and pitfalls). ;)
 
woodelf said:
I missed this for a week, but I'm glad that you finally got it jotted down so everyone can benefit from FfH's successes (and pitfalls). ;)

The article is definitly more than just what we learned from FfH. The input from the Soren and the other designers is fantastic and I learned a lot from reading their responces.
 
Thank you Kael. This article is great and I'm am definately going to have to re-read this one when I start my second version of my mod. Thanks again for giving to the community.
 
I've designed my share of small games and mods, I also helped Thamis on The Ancient Mediterranean for civ3 and civ4 to various degree and this is my piece of advices.

Being a game designer is hard. Period.

Whether you do a mod or a full game, we're talking about a set of specific skills. Everyone can be a game designer, but not everyone can be a GOOD game designer. Heck, even many commercial games are not very good/fun in the design department because they lack innovation, fun or gameplay. It's not just about creating stuff and adding things, it's about creating a product, creating an experience. There are no recipies, and it's a bit more complicated than just sticking to things that works and adding flavor.

Also, the biggest challenge is that players are usually NOT good game designers. They always want features X, Y and Z, without thinking about the overall game, the whole experience. They don't understand the game system like you do. They always think they can do better or want to add a cool feature. Remember, designing a game/mod is HARD. This means that users/players/customers are usually wrong.

However, players ARE your customers, so if you do not please them, they won't buy/play your game, which is a pretty big problem. You must ALWAYS listen to your players, be polite and do not alienate them. You're not GOD because you've created a mod.

I've learn that at work: you must always keep your ears open. You are there to take the pulse of your players and build a better game. Do not presume that your mod if perfect. You MUST pinpoint the problem/cause of the users requests: why does he want that feature? why isn't he pleased? how can I improve the game so that those problems are gone? You usually never end up adding the exact feature that a player requested; sometimes you tweaked some values, rebalanced some areas, or maybe even ended up adding totally new gameplay elements.

For example, a player is saying that he's researching tech too fast and suggest to add more tech to make up for it. He even has a list of wicked cool techs to add. Wow, those would be great right? Wrong.

What must you do instead? Well, you check to see why he's researching too fast: is it because of a civic that is too powerful? too much science buildings? too fast growth? when is he starting to go ahead of the tech curve?

In the end, you probably won't add any new techs, but you'll have to fix this problem one way or another. You do that by looking at the actual system and finding out what's wrong.

Also, it's important to build systems. Systems are more important than single features. Usually players only see features, but you must think in terms of systems. A game is a series of simple, interrelated systems. Complex is not always better, simplicity and depth is usually what makes a good game. Just look at Civ4. Sure it's not a complex tactical simulation, but it's pretty damn fun and addictive. You must think globally and know your systems intuitively and fully. I repeat, you must understand the systems fully. When we're talking about a mod, it's even more important to know and understand fully how the game works. In civ4 there are lots of systems (research, growth, combat, etc.) and they are ALL related together. Maybe you find that some ARE flawed, but in the end, all of their interactions makes a fully playable and enjoyable game. If you want to design a mod, you must understand that.

So, if you are not pleased with the combat system, before changing it, please understand exactly how it works. Then you see if you can tweak it to do what you want. THEN you build a new combat system if you still need additional features that do not fit in.

For example, when designing the units in TAM Civ4, we designed a 'new' system by just playing a bit with unit classes, promotions and bonus. We didn't code a completely new system because it wasn't needed, everything was there to create the necessary experience and balance we wanted. No need to rewrite Civ4. However, this introduced new gameplay elements, new balance and new ways to approach combat.

Finally: playtest, playtest, playtest. Features and systems are theorical, they are in your head. Play them to see if they work. The better you understand the system, and the better you become, the better you will get. However, you must still playtest. Then playtest more. Do not let everyone test either, players are not usually good testers anyway. Have a couple of people that really want to playtest.

And the most important advice I can give: it's still just a game/mod. Unless you make your living out of it, just have fun and don't worry if you're mod isn't popular. I usually make mods for myself first and foremost, and so should you. If you like it and find it fun, there are probably others too, just don't expect everyone to like it. Hell, check out commercial games: not all of them are hits like Civ4 or World of Warcraft, so it's not an easy task.
 
Thanks Karhgath, thats exactly the kind of conversation I was hoping this thread would generate. I would love to hear from others about what you found out works and doesn't work for you when designing mods.
 
As someone who's more an aspiring modmaker than one who's succeeded, I have little to add except some outside observations.

First, regarding complexity: A strong case has been made (for example, A Theory of Fun for Game Design) that games are essentially learning activities. One of the most difficult things I've seen as a player of games is designing the right level of complexity scaling. Complexity should keep ramping up as the player masters an old element, and ideally old elements recombine to create new elements so that new complexity isn't just introduced for the sake of complexity, but rather as continued variations on a theme that you've mastered, but has just mutated to become more challenging.

Consider the learning curve of Civ4 itself: you basically need to figure out how to feed people and build stuff in the beginning. Not until you "succeed" at this does stuff like unhealthiness/unhappiness rear its ugly head. In some ways, a built-in learning curve.

One of the dangers of a franchise is that each game becomes more complex than a previous one (because each game builds off the learning curve of the previous) such that they stop becoming accessible to new audiences. As a Civ "insider," I can't say whether Civ4 is more or less hard to learn than, say, Civ2. I do think some of the mods I see presume the learning curve is already under your belt from Civ4 -- and since we are all Civ4 players, this is not a bad assumption!


Rhye said:
I always tend to add only things that have both function and flavour. I mean that if I have a cool unit designed by somebody else to add, but nowhere to put it without unbalancing the game, I won't bother. And if I feel a gap should be filled by a unit, but I don't have an adequate graphical representation, I won't add it as well.

There's a great story (don't know if apocryphal) about George Lucas's first screening of "Star Wars" to his backers, at which he hadn't yet finished the Death Star battle scenes, so instead he substituted movie footage of WWII fighter planes. This totally confused and freaked out his backers, and could have cost him the release of the movie.

Personally, I have thought it would be easy for me to put arbitrary units on the board and say, "This Warrior is really a Spaceship." But (a) it turns out my own imagination does not allow me to do this for very long, or perhaps it's the case that I like playing with graphics, but anyway... (b) if you are looking to build a team and get support, most people will probably react like the first viewers of the pre-FX Star Wars. This may not be a bad thing if you want to attract people who are attracted to the fundamental gameplay rather than nifty graphics. And sometimes I find myself wasting hours finding the "right" model rather than just getting on with fixing the broken game mechanics. But it's important to recognize what makes yourself and others motivated -- what Kael called the "drool factor."
 
Top Bottom