RB Mod Approval for the BUG Mod

all done and submitted to Realms Beyond for approval. The final document can be found here.

http://www.freewebs.com/ruff_hi/BtS Unaltered Gameplay Mod Approval Process.pdf

Wonderful work! :goodjob:
Can this be adapted to make a "manual" of BUG to be included in the documentation folder?
Don't worry, I'm not asking you to do it, I'm just asking the permission to do it myself :D (not now, though), and to translate it in Italian... [I have not found a note on copyright, so... better to ask :blush: ]
 
RB MOD Approval document said:
This document sets out how the BtS Unaltered Gameplay (‘BUG’) modifications
changes the vanilla edition of Civ 4.

Do you mean 'vanilla' as in the original Civ4 game or 'vanilla' as in the version of BTS released by Firaxis? I suspect this is a bit of cut and paste that wasn't amended correctly. :p Equally you probably need to make clear that this applies specifically to BTS 3.13.
 
Wonderful work! :goodjob:
Can this be adapted to make a "manual" of BUG to be included in the documentation folder?
Don't worry, I'm not asking you to do it, I'm just asking the permission to do it myself :D (not now, though), and to translate it in Italian... [I have not found a note on copyright, so... better to ask :blush: ]
Go for it.

Do you mean 'vanilla' as in the original Civ4 game or 'vanilla' as in the version of BTS released by Firaxis? I suspect this is a bit of cut and paste that wasn't amended correctly. :p Equally you probably need to make clear that this applies specifically to BTS 3.13.
Arrr - good point. I will amend.
 
We got the following (and some others) reply from Sullla at RB. Truth be told, I was expecting this reply because of the 'uneven playing field' argument. I've asked a follow up question.

Sullla at the RB forum said:
Ruff (and others), that's a tremendous amount of work that has gone into putting that mod together. I think you know how I feel about mods, so I want to be very clear about going over a decision. First, let's look again at Sirian's take on the issue:

Utilitarian mods are the tough calls. Stuff like Civ3 Mapstat falls in to this category. Mods that are primarily graphical in nature can turn in to utilitarian mods, by design or by accident, so that's the main hurdle they face. It is my intent to approve all graphical mods that are shown to me to have no utilitarian or rebalancing effects. (I don't care what your game looks like. I only care how it plays. However, some graphics can affect gameplay, so that is where I start to care about those.)

Most utilitarian mods will not be approved, but we'll take them case by case -- if "the committee", which does not yet exist, does the leg work of investigating.


I strongly concur with these sentiments. I had no problem with approving Blue Marble, a purely graphical modification, and I think Sirian (eventually) would have gotten around to doing the same. But note what Sirian said about utilitarian mods: "most will not be approved", and I'm of the same mind there. The BUG mod is a gigantic utilitarian mod, reworking a tremendous amount of the information accessible to the player. That's quite a big deal, and a lot different than simply recoloring the look of the terrain.

The prevailing argument for approval of this mod is that it does not provide any information not available to the player somewhere else in-game. While that may be true, I would counter with a related question: when does making information more accessible begin to affect the gameplay? We had the same discussion with Civ3, for those of you who were around back then. Civ3's MapStat utility didn't provide any information that wasn't technically available in-game; you could count up all the tiles on the map by hand, then count up all your tiles and figure out the Domination percentage through calculation. But such a calculation was so tedious, it was clearly something that no one would ever undergo. Providing access to this information actually changed the gameplay and gave players an advantage over those who were not using the utility.

Similarly, there was another Civ3 utility that would notify the player whenever one of their cities was about to revolt (more unhappy faces than happy ones). Now again: this didn't provide any information that the player couldn't figure out themselves, by checking every city every turn. The idea was a good one, to save micromanagement. But if one player was using this mod, and another was not, was the game still a "fair" competition? The former player would never have to worry about city revolts at all, while the latter player would surely lose some production at some point. Everyone would more or less have to start using the mod to ensure a level playing field - not a good thing!

The problem with the BUG mod is that it simply provides too much information; Ruff and the other creators have done too good of a job. For the purely graphical additions - like showing the number of turns to pop a Great Person, rather than requiring a mouseover - this is rather trivial. The net effect of reworking so many game elements, however, adds up to something different. Worst of all is the alert system, which tells the player when cities will grow into unhappiness, when AIs have techs to trade, and when AIs have gold to be pilfered by selling outdated techs. Sure, all of this information is technically available somewhere else in-game, if requiring a great deal more work to access. But I've seen this mod in action in succession games, and I'm forced to conclude that by putting so much information upfront and center, it really does change the gameplay. Furthermore, how can we keep a level playing field when some of our competitors have access to things like the "Glance" screen while others do not?

My primary concern when managing the RBCiv games is to ensure competitive balance, not to make things easier for the players. I think the BUG mod does great work for those who like it; the problem is that things are not equal when some of our players are using bean counters to help them out, and others are not doing so. The BUG mod is therefore not approved for use, unless someone is able to make a persuasive case convincing me otherwise. (I do not expect this to happen.)

I'm sorry to have to turn down such a beautiful proposal, I just feel very strongly that utilitarian mods should be rejected unless absolutely harmless, not the other way around. If there's even the slightest doubt in my mind (and there's significant doubt here), I have to say no.

My follow up question ...
me said:
As I said in the proposal - all elements of the BUG mod can be turned off. Can I get a quick reply regarding how you would feel if we stipulated that the BUG mod could be used if selected elements (Alerts, Glance, etc) were disabled via the ini file? What if we put together a mod that excluded these elements (that is actually pretty easy - just hard code the parts that read the ini file to test for access to those components to return FALSE)?
 
I hate a feeling this would happen when I read over what they said about
Utilitarian Mods when I first saw these docs. I think we'd have to disable so much of BUG to get it approved, that it'd be hardly better then having nothing at all.
 
Sullla's arguments are hard to counter considering the basic stance of rejecting Utilitarian Mods. And I do agree with him that BUG does change the play in some ways - for example I was only barely moving to micromanagement and Monarch level, which BUG now has made easy for me to do. Having had BUG earlier would've made my jump to Monarch a given.

Thinking about the many features of BUG, I'd guess alerts are the first feature to go. Also a part I would never give up... But if you think about those replies with optimistic world view, maybe alerts will be one of the very few features to go?
 
i, too, felt it was going to be rejected since it benefits the player so much, the playing tilts to their favor.

ahh well, was looking forward to reporting adv 24
 
Indeed it would not be very hard to have a stripped down version with hardcoded options for things they shouldn't be able to use. The one minor code change on top of that is an option for the glance tab itself.

And I fully agree with the response that BUG players would have an advantage, being freed up to worry about their game rather than "OMG I missed my chance to whip for 29 overflow!" :)
 
Honestly guys I don't think we should strip it down. Mainly because once we take something out, they'll want another thing out, and another, and another. I'm worried that by the time they're done we'll have the options switching core, and city cycle arrows.
 
It really comes down to the coolness factor of being accepted by RB. I don't play much anymore, and I've never participated in RB, so I'm not the guy to decide.

To clarify, "stripping down" means releasing a version that simply forces values for some options, like "False" for "CIV4LERTS_Enabled".

I think it would break down like this:

Definitely In

GP/GG Bars
Clock
Scoreboard
Espionage Screen
Raw Commerce/Production
City Cycle Arrows (powerful!)
Logging
Unit Naming
Sevopedia

Maybe Cut

Reminders (is this too advantageous??)

Definitely Out

Glance tab
Alerts
 
Here is Sullla's response. He restricted himself to the option tabs which is what I asked.

Sullla said:
Warning: Sirian-length post ahead. :lol:

Ruff_Hi said:
As I said in the proposal - all elements of the BUG mod can be turned off. Can I get a quick reply regarding how you would feel if we stipulated that the BUG mod could be used if selected elements (Alerts, Glance, etc) were disabled via the ini file? What if we put together a mod that excluded these elements (that is actually pretty easy - just hard code the parts that read the ini file to test for access to those components to return FALSE)?

Good question. Obviously some of the elements of the mod are relatively harmless. (Adding a clock to the corner of the screen isn't exactly gamebreaking! :)) My concern is that when you start piling up dozens of small changes, any one of which may be innocuous, the net result starts to turn into something else. I know some people just like modding, but I don't quite understand the thinking behind some of the changes. If presenting the information in a slightly different fashion is so trivial, why bother to make the change at all?

Anyway, since you requested looking at the elements individually, here's a more thorough break down:

General: Even though most of these seem trivial, I'm dubious about any mod that adds new functionality to the game engine. For instance, the raw commerce/raw production is definitely NOT something that exists in the unmodded version of the game. I know, I know: anyone can calculate the information by hand. But it's still not the same thing, because it provides a bean counter that does not otherwise exist. This section overall has to get a veto stamp for now. (I am not going to go through every little individual aspect of each section. The Culture Turns and Great Person Turns would probably be fine, but since they are SO trivial, I don't see the point of jumping through hoops to get the approved. Just mouseover the bars!)

Advisors: This one too is a no-go. It's simply not fair to have some players customizing their domestic advisor in ways that other players cannot do. We already mentioned the Glance tab, the improved Espionage screen was already added to the main game in the v3.13 patch (correct me if I'm wrong on this), and is the SevoPedia really important enough to go through the mod approval process? If people care enough, I suppose we could approve that one, I just don't understand why it would matter...

Clock: Everything here is a non-issue, and in fact many of the features were added in Beyond the Sword anyway. Besides, we more or less already approved this mod when it was called the Simple Clock Mod, so I can't go back on that now.

Scoreboard: The Display names doesn't affect gameplay in any way, aside from the possibility of a confusing "Allow Unrestricted Leaders" game, but that doesn't seem like enough reason to disapprove it. I personally detest the smiley faces to indicate relations (I think they look incredibly ugly), but again all it does is save the effort of a mouseover. That's not enough reason to ban its use. Dead civilizations display is meaningless. The power ratio is definitely not OK, however. That adds new information that is not available to the player without performing a series of calculations. This will not be allowed in RBCiv competitions.

Alerts: As mentioned previously, when the game is modded to issue reminders that it would not have given otherwise, this is an alteration to the gameplay. These changes will not be accepted.

Logging: Ugh, what a can of worms this one is. I think it's well known that I detest the auto-logger, but I'll try not to let that color my opinions. If used solely for the purposes of an aid to report writing, there's no reason not to allow the logger. The problem is that there's no way to ensure that players won't look at the logger until after the game is finished. If the player is actively using the autologger as an aid while playing, it can provide an enormous quanitity of information, so much so that it falls into the "MapStat" category mentioned in the previous post. There is unfortunately absolutely no way to ensure that players are using the logger legitimately as an aid to report-writing, rather than as a gameplay aid.

For these reasons, I am planning on disallowing the logger for RBCiv competitions. On a more personal note, I really do dislike the logger and would vastly prefer that our community members use alternate ways of putting their reports together. However, I'm prepared to be reasonable on this one; if there's a huge groundswell of opinion asking for use of the autologger, I will accede to the requests of the community. Personally though, I hope that that does not happen. ;)

Unit Naming: This has no effect on gameplay. I don't entirely understand the interest, but sure, why not. Maybe it will even make for more entertaining reports.

To summarize:

General - not approved
Advisors - not approved
Clock - approved
Scoreboard - approved aside from "power ratio" (which is not approved)
Alerts - not approved
Logging - not approved
Unit Naming - approved

I hope this clarifies things, and answers what you're looking for. :)

and my response to that ...

me said:
Thx Sullla - sorry to eat up your time with the question. I see enough red lines to pull the plug on a RB version. Unit naming is fun just for scouts called "Recon Delta" and workers called "Drones".

Cheers,

Ruff :D
 
Wonderful work! :goodjob:
Can this be adapted to make a "manual" of BUG to be included in the documentation folder?
Don't worry, I'm not asking you to do it, I'm just asking the permission to do it myself :D (not now, though), and to translate it in Italian... [I have not found a note on copyright, so... better to ask :blush: ]

I've done and updated it. It's not a full manual, only a configuration guide (so it is called BUG Configuration.doc). It is made for mor than 90% with the file used for RB Aproval, and it is limited to version 2.1. The new addition will be added later.
 
I've done and updated it. It's not a full manual, only a configuration guide (so it is called BUG Configuration.doc). It is made for mor than 90% with the file used for RB Aproval, and it is limited to version 2.1. The new addition will be added later.

Updated to 2.11 version :)
 
Top Bottom