HOW TO: Design a Mod

AI is pretty darn relevent to these discussions, especially when complexity comes up. A lot of the best features and best games fall short because they cannot be used by the AI. This is clearly an example of "bad complexity".
 
dh_epic said:
AI is pretty darn relevent to these discussions, especially when complexity comes up. A lot of the best features and best games fall short because they cannot be used by the AI. This is clearly an example of "bad complexity".

Yes, although that was not what the discussion started about. The initial discussion was about whether complexity would be a desirable feature at all, regardless of the question whether it would be possible to implement it or not.

I must admit, however, that when I would succeed to implement my economic model, the major challenge would lie in making the AI take advantage of it. My guess is that with the AI, you should follow the same rules that CIV IV has followed in game design: add a few simple concepts that interact (see the earlier discussion in this thread). If you choose otherwise, I guess you will be making complex what is complicated already. And I fear you'll never get it working.
 
That's exactly my point, Griffin71. When you design a mod, complexity sounds all well and dandy, but can lead to all kinds of unintended pitfalls and side-effects.

Complexity isn't really a "yes" or "no" issue is the main point. There are advantages and disadvantages as you add more and more. I happen to think there's at least a few sweet spots, though, where you can find a good tradeoff.
 
griffin71 said:
Agreeing that games are essentially learning activities, it is a good approach to let the game start sober, so that you have only a limited number of concepts to learn. As the game progresses, more and new concepts should be introduced. Complexity is then especially achieved by finding out how the new concepts work together in the conceptual system as it has so far developed.
Let me reword my original post to be more in line with the actual source I'm riffing from:

One reward for many players is recognizing a PATTERN and then delighting in the expansion and mutation of that pattern. This is not exactly the same as complexity, and in fact, I think the problem is often mistaking an elegant pattern for complexity. Complexity that captures a RECOGNIZABLE pattern is something fun to learn (and thus, ramping is important); complexity for its own sake is useless.

Right now I am struggling with a "Fluff" element added to our game: exactly that spawned enemy named as Fluff (guilty as charged!). Now, this spawned enemy actually serves a purpose: to create an adversary that forces harder decisions on the player (defense becomes much more important much earlier on) and really it's just a mutation on the original Barbarian concept. However, on its own the element is just a hack, not a fun new element.

What can we do to make that element meaningful and fun?

I don't have a full answer yet, but I think it can be. For example, it could be that this enemy unit only spawns on a certain kind of feature, so removing that feature would get rid of that unit. Thus you learn through observation (Oh, enemy X only spawns on feature Y) and figure out both an immediate solution (kill X) and a long-term solution (destroy feature Y). However, this remains fluff built on top of fluff.

If, however, the very existence of feature Y turns out to be a core game mechanic (feature Y is super-high in yields, feature Y is itself your main enemy, some combination of the two), then what used to Fluff could, arguably, be a real game mechanic.

Anyway, enough about my mod. I think all I want to convey here is the idea that it's not complexity but rather patterns that potentially become complex that is one element of fun in games.
 
Seven05 said:
My most recent completed mod was a 4-year multi-player only project. For the first year the mod was only seen & played by the development team and a select number of testers. At the time of the initial public beta we all felt that it was challenging but still fun. Unfortunately, once we let the "unwashed masses" onto the server we suddenly had to deal with people who put substantial effort into exploiting any weakness in the mod and people who were serious "power gamers" who were able to easily overcome what we had felt was a good challenge....

I'm just returning from a game developer's conference (well, sort of), and one idea echoed by the (few) true developers in the conference was RAPID PROTOTYPING: create a small chunk, release, respond, repeat.

This is now a concept repeated throughout product development theory. As a matter of good project management, I think that the skill of being able to "chunk down" a project into discrete pieces that people can understand and respond to is critical.

One concrete idea people had for chunking included turning a long saga into episodes and releasing them individually. Besides being a new and intriguing business model for some game companies, this also allows for instant feedback and making sure "the customer is always right."

Not that we are yet practicing what we preach!
 
That's pretty much the oldest rule of good software design. ITERATE!

Too many people design an entire mod as they'd like it to work on paper... then implement it... then live with it. They create a blueprint, and that becomes the instruction that goes down the hierarchy of the development team.

In actuality, you need to do a snap design, a snap implementation, and then evaluate it. Then you need to redesign it, and repeat. You work on that individual piece, get it perfect, then tack on another piece... and build from the ground up.

The challenge, of course, is that sometimes it's hard to evaluate how the whole thing will work based on a single piece... and that piece isn't even implemented fully! So you do need a good combination of "Top Down" and "Bottom Up" design.

Too much top down design, and you become inflexible. You end up so committed to what you did on paper that everything is now tangled up together, and you have to live with however it turned out.

But too much bottom up design and you can end up with very bizarre and unintended results. A feature that was meant to make a big impact turns out to be nothing more than fluff, because you never bothered to think about how it would fit into the overall final vision.
 
With the help of a friend, I found this really valuable quote from the developers of Civ 4:

“One of the lessons we constantly learn while developing Civilization games is that we want to put fun in the hands of the player by providing simple systems that interact to generate complex results.”

I'm almost positive that at one point they went into more detail in another interview, but the main idea stays the same. Rather than trying to design a complex system, you design several simple systems, and let the complexity emerge from those.
 
Padmewan said:
I'm just returning from a game developer's conference (well, sort of), and one idea echoed by the (few) true developers in the conference was RAPID PROTOTYPING: create a small chunk, release, respond, repeat.

This is now a concept repeated throughout product development theory. As a matter of good project management, I think that the skill of being able to "chunk down" a project into discrete pieces that people can understand and respond to is critical.

One concrete idea people had for chunking included turning a long saga into episodes and releasing them individually. Besides being a new and intriguing business model for some game companies, this also allows for instant feedback and making sure "the customer is always right."

Not that we are yet practicing what we preach!

It seems to me that episodes are more of a marketing/finacial strategy then a game development one. Though I realize it does break the scope of "full game" into smaller pieces they are still well beyond the workable chunks we are discussing here.

I try not to go a month without a public release just because if it gets to be longer than that to much changes and you start to get to dug in on fucntional changes to take them out if the playtest feedback is negative. Also until you get real player feedback ont he things you have added they exist in an untested limbo that may or may not work.

The speed are which you can develop a concept, get it working, to the public to test, then tuned and working in its final state (iterate as dh_epic said) will determine the productivity of your project as a whole.

It may seem like the profession gaming companies sit and work forever on their patches between releases but most of the time they are releasing and changing their patch to internal groups through the process described above. The 61 number in the civ patch wasnt just pulled out of a jar, I think there were 61 different itterations of the patch between that and the origional Civ4 release. Knowing that patch 61 was released 6 months after Civ4 thats 10 versions per month, a lot of iterations.
 
Wow, 10 iterations a month. That's at least 2 new versions of Civ per week. Crazy to consider.
 
strategyonly said:
How will Warlords impact the making of this thread? any at all or just a few minor tweaks?

Nothing at all. This thread isn't about the tech requirements of modmaking but the non-technical design requirements. Concepts that are true if we are talking about games of any sort.
 
Kael said:
1.1 The Danger of More:

“Perfection is not achieved when there is nothing left to add, but when there is nothing left to take away.” -- Antoine de St. Exupery

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.

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.

Is it needed? Would it be missed if it was taken out? Is its function 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?

I thinks this is what really killed my mod. In the adding of everything (culture, inquisitors, buildings, meaningful resource bonuses...) I lost sight of the goal of my mod. A large mod left abandoned because I didn't know where to go next.

I think another big thing that killed my mod was momentum. I had a lot of momentum and I worked hard on it. I had determined to make mods before, but every time (including Civ4) I hit a brick wall when I hit the limitations of the game. In Dungeon Siege 1, I wanted to make a nice, meaninful skill tree with synergies abound and all. Then I found out when they meant "moddable" they meant, you can add new dungeons to romp in. I wanted to do a similar thing with Morrowind, and later Oblivion, but I ran into the same limitations on a set-in-stone RPG system. I even had some ideas for Diablo 2, but the lack of realm-play for mods kept me from ever trying.

Civ4 was the first game that let me actually do stuff totally unintended by the game creators. It gave creators enough power to add in a random game of tetris, if they so desired. It gave me the power to play with culture, add buildings, edit how the resouces work, and even add new mechanics. I was enthralled. So my first mod was ultimately a sandbox where I played with everything and tested the limits of what I could do. I did find some of the limitations, and that's half of what stopped me, but it was also a lack of clear direction that prevented me from trying to work around those limitations.

I want to get back into the modding scene, but I have a few constraints. Most notably is time, but also there's the expansion and the SDK. Before I had the API reference that was an awesome tool in helping me mod Civ4, but I found it to be incomplete with a few functions missing. Now I need to find a similar reference tool and something to help navigate the SDK as well. I have plans for another mod. Perhaps they are too grand, but as long as I know what I want to do at the beginning before I get bogged down with details and know how to get there I should be fine. :)
 
Thats a blast from the past, heya Mylon! Your progress on your mod may have stopped but so much of what you did has been used and reused by the community (including me, I really studied everything you did in Mylonmod closely when I started FfH).

I think you will find that there is more and better information available than back when you were pioneering modding when Civ4 first released. Documentation still isnt perfect by a long shot, but better.
 
Heh, it's nice to know people haven't forgotten about me. :) It's also nice to know that I've left a lasting legacy. I've seen an improved inquisitor mod (one the AI knows how to use), and even a mod that adds discrete resouces and resource converting buildings, which I anticipate would be a great tool for one economic mod idea I have.

I still have to solidify the basic ideas for my next mod before I can start work so I don't get lost again. :) I think the time for breaking ground and playing has past, so there's time now to really get into game design.
 
Hey should there be a chapter or two about programming faults? I don´t mean a programming guide but telling how to get over bad programming problems that you cannot solve yourself or no-one else knows what to do about it. How to act on that situation and stuff.
 
Hey should there be a chapter or two about programming faults? I don´t mean a programming guide but telling how to get over bad programming problems that you cannot solve yourself or no-one else knows what to do about it. How to act on that situation and stuff.

The scope of this article was just about the non-technical aspects of designing a mod. So that probably wouldn't fit here. I did write another article on isolate crashes that you may want to check out here: http://forums.civfanatics.com/showthread.php?t=175005
 
Okay folks. I'm getting more and more of an understanding of xml files the more I read. But the problem I'm having is actually making the changes!. For example. All I want to do, right now is give ALL of the leader traits to a single leader (say, Washington, since I like playing as America). But when I go into the xml file for leaderheads, I click my mouse where I'm supposed to (I guess) and nothing happens. It highlights in blue indicating that that text has been selected, but I'm unable to type anything. What am I doing wrong? I've downloaded the new patches, sdk, the pitboss, a few mods, etc. But how do I actually make things change?

Forgive me for sounding like an idiot. I've had this game since it was released November 2005 and have never been able to mod. I miss the simple game editor from civ3 and was disappointed to find what looked like a waaaaaaaaaaaaaaaaaaay too complex way of creating a mod and making what I remember from civ3 has "simply changes".

I would also like to change the movement cost on terrain. I just don't feel it should take 40 years (in the early years of a normal game) to go from one square to another even without a road. I mean, really. How realistic is that? (smile).

One day I will have access to a book named "Civ4 Modding for Dummies"
 
Top Bottom