Ribbentrop's FMR Workshop

[Winchester]

Hello, everyone! Within this thread, I will be posting each new Workshop as I finish them. The purpose behind this thread is to keep all of the Workshops in one place - conveniently, in the workshop - where they can not only be viewed easier, but also where they are free of the autoprune. Because I will still be posting a copy of each Workshop in the main FR forum, I ask that no one responds to this thread. Moderators, please do not approve any posts in this thread, as any discussion of the Workshop should occur in the individual threads posted in the main forum. Note that the links to the discussion topics can be found in the FMR thread.

Now, what is the purpose of these workshops? It's quite simple: within Feature Requests there is a thread that lists all of the most commonly requested ideas. What I do in each Workshop is take an idea, or a group of ideas around a similar theme, and examine them: I determine if the idea is flawed, and if so, how it is flawed; when applicable, I post what I consider the best iteration of the idea; I list the most common iterations of the idea, so that people can tell easier when their idea has been proposed; and, finally, I list the common issues that players must overcome before even considering making a new request on the topic.

Please note that while I am a Volunteer, I do not speak for Astro Empires. These Workshops are done by me as a player, and use my experience playing this game, working on ideas, posting on the forum, and a considerable helping of math and logic. The opinions expressed here do not necessarily represent the opinions of Astro Empires, or its administrators. These Workshops are for educational purposes only, and should be used as such to educate yourselves and others on the various FMR topics. Thank you.

Workshops:

#1: Loaning, Selling, Stealing Ships.
#2: Cloaking, Stealth, and Scanners.
#3: New Units.
#4: Anti-Blob Ideas.
#5: Hardcoded Politics.
#6: Asteroid Belts and Gas Giants.
#7: Anti-Occupation Features.
#8: X for the sake of X.

Special Editions:

Concept Discussions.

[Winchester]

Welcome to the first installment of Ribbentrop’s FMR workshop. Here, I will be discussing various FMR ideas, and will detail some of the common iterations, any problems that might come up with them, and where possible or reasonable, I will post the variation that I believe to be superior, whether it has been posted before or not. As a note, this entire series of posts on the FMR has been approved by Zoran, so please, do not respond with “FMR” or otherwise claim that I am breaking one of the rules. This post, whether I propose an idea or not, is primarily an informative one for newer posters, while simultaneously placing these common ideas within recent search history.

Today, we will be looking at the first few items on the new FMR: Loaning, transferring, giving, selling, stealing, boarding, and pirating from ships.

Fundamentally Flawed?

One of the primary concerns raised about any such idea is the fact that they are typically considered fundamentally flawed. By that, I mean that the entire idea is unworkable; in order to make the idea avoid being under or overpowered, while still providing a distinct benefit, one cannot actually make a worthwhile idea. There are a number of reasons for this, including – but not limited to – the following:

1: Loaning/transferring/giving ships allows players to effectively transfer credits. Even with limitations on who can transfer ships, and how many/what type, the simple fact is that it provides a direct financial benefit to anyone with either multi accounts, or friends. Consider the opening of a new server; if Player A had even one friend that made an account for the purpose of transferring ships over, then Player A would have a greatly increased benefit over those without such a friend. The benefit does not come from any skill of the player, and is essentially cheating – albeit this time, the effect is the same as cheating, but the act itself is within the rules. If the amount you can transfer is small enough that it doesn’t matter, such as a single fighter, then it simply isn’t worth adding.

2: Selling ships will typically run into one primary issue: by allowing players to buy ships from other players, even at an inflated cost, you effectively bypass production capacity requirements. Consider the fact that there are people that quit this game in advanced servers; some have over one hundred million fleet, which they no longer need. If they sell those ships to a few of their friends, then those people have instantly (or near instantly, depending on if the idea institutes a delay) jumped a tremendous amount of fleet. Currently, there are players that double produce fleet, simply because they have the credits to burn, or else it is something like fleet carriers, recyclers, or leviathans, which are unlikely to be destroyed. Therefore, even if the cost of buying is 2x or over, it will still happen; on the obverse, if the cost is too high, you might as well not even have the feature to begin with.

3: Another issue with selling ships is the same as with transferring them; if the selling player makes a profit, then it simply allows credit transfers. If the selling player does not make a profit, then they are unlikely to sell their ships, at which point the idea is either useless, or runs into the problem listed in #2.

4: Stealing ships is, to put it simply, something that will never be added to the game. Consider the fact that players on older serves have over 100-150m fleet; they can easily attack someone with 2-20m, and steal those ships with essentially no risk. It allows credit transfers; it bypasses production capacities (which are the natural soft caps of fleet totals); it allows the strong to get significantly stronger by preying on the weak; and, finally, it runs into balance issues. If it costs money to steal a ship, and even costs more than it would to produce it, you run into the same issue you do with selling ships. If it costs too much, people won’t use it, and if it costs just enough or too little, it will be overpowered.

5: Boarding ships is an idea that essentially utilizes game mechanics that don’t exist. While the effect is likely to either steal, sabotage, or steal from the ships, the mechanic itself would have to be created from scratch, and for that reason it isn’t likely to happen.

6: Pirating from ships is the idea that you can use a special unit to sneak up on a fleet, and then make an instant payday instead of attacking, in the same way that you can plunder trades. In its most basic iteration, this is a blatant credit transfer; even if the defender loses more than the attacker gains, you would need checks and balances to limit the amount of profit that can be taken. Trade routes can only be set 24 hours after they were plundered, and require either your own base or the base of someone else; even with the best of situations, you can only get around 30,000 credits per base plundering trades. The need for such a limiting factor in fleet would require an entirely new mechanic, and would be so unrealistic for the game that it’s unlikely to ever make it in.

Common Iterations?

Buying/Selling Ships: Player can buy X credits worth of units from another player, while paying a Y% tax (either to the other player, or by simply losing those credits). X is defined by either a structure, a tech, or a new mechanic that limits how many ships you can buy, while also limiting how many ships you can sell. Players cannot buy any ship that they do not have the required tech to build.

Giving/loaning Ships: Player can give/loan X ships to a player in his guild. X is defined by either a structure, a tech, or a new mechanic that limits how many ships you can give/loan, while also limiting how many ships you can accept. Players cannot accept any ship that they do not have the required tech to build.

Stealing Ships 1: If player wins in an attack against an enemy fleet, they automatically steal X% of the enemy ships. X% is defined by either a structure, a tech, or a new mechanic that limits how many ships you can steal. Players cannot steal any ship that they do not have the required tech to build.

Stealing Ships 2: Player can build a specific type of unit, and use it to attack an enemy fleet. If player wins in an attack against an enemy fleet, they automatically steal X% of the enemy ships. X% is defined by either a structure, a tech, or a new mechanic that limits how many ships you can steal. Players cannot steal any ship that they do not have the required tech to build. Note that some versions merely require the special unit to be present, while others require the entire fleet to consist of the special unit.

Pirating from Ships: Player can build a specific type of unit, and use it to steal credits/technology/other resource from an enemy fleet. Some versions require the special unit to engage and win in combat, while others merely require the fleet to be on the same astro as the target.

Final Thoughts:

This is, quite frankly, an idea that will not work without a ridiculous amount of work spent balancing every different aspect, or else designing an entirely new mechanic – something that essentially kills the idea before it ever starts. If you have any specific questions that were not covered here, as to why the idea won’t work, or if you want to ask about a specific iteration that wasn’t covered, feel free to reply.

[Winchester]

Welcome to the next installment of Ribbentrop’s FMR workshop. Here, I will be discussing various FMR ideas, and will detail some of the common iterations, any problems that might come up with them, and where possible or reasonable, I will post the variation that I believe to be superior, whether it has been posted before or not. As a note, this entire series of posts on the FMR has been approved by Zoran, so please, do not respond with “FMR” or otherwise claim that I am breaking one of the rules. This post, whether I propose an idea or not, is primarily an informative one for newer posters, while simultaneously placing these common ideas within recent search history.

Today, we will be discussing cloaking, stealth, and scanners.

Common Iterations:

As this is a rather broad topic, I would like to start by listing the common ideas associated with cloaking, stealth, and scanners; mind you, this will be in very generic terms.

• A new tech/structure/mechanic that increases scanner range
• A new tech/structure/mechanic that allows scanners to detect units earlier
• A new tech/structure/mechanic that allows players to see recently landed fleets on their scanners
• A new tech/structure/mechanic that lets guildmates share scanner views
• A new unit/modification to existing unit/technology/mechanic that allows a unit(s) to have scanner coverage on the astro/system/region where it is currently landed, either in full, or in a limited capacity
• A new unit/modification to existing unit/technology/mechanic that prevents enemies from detecting the unit/fleet with the unit for X amount of time, whether on scanners, on the astro, or both
• A new unit/modification to existing unit/technology/mechanic that completely hides certain units when in motion, and/or when landed
• Making all hangar units invisible
• A new tech/mechanic that creates a false variable flight time that is different from the actual flight time
• A new mechanic that allows scanners to see where the fleet launched from

Flaws and Common Iterations:

Rather than speak generically for all of them together, I’m going to go through each of the listed ideas and detail why they are typically flawed.

A new tech/structure/mechanic that increases scanner range

The common iteration of this idea is usually a structure, such as a Sensor Station, that allows the player to see incoming fleets at one of the eight surrounding regions per level; alternatively, the same effect is normally achieved through a tech that does the same thing. There are also iterations that increase the range by a certain distance all around the base, or that allow the player to see fleets over a particular size in surrounding regions.

The primary issue with such a thing is that there is a huge gap between free players and upgraded players, and between new upgraded players against old upgraded players. Currently, scanners give a set bonus, which only increases by the number of bases you have, as well as your tactics in placing bases. By increasing the scouting range, advanced upgraded players can cover practically an entire galaxy with scanners by themselves. There are generally around eighty regions per galaxy that have systems. Given the common iteration and nominal placement of bases, each base can cover nine regions at the cap; therefore, with twenty bases on average, a single player can actually cover two galaxies singlehandedly. Even if you reduce the effectiveness by half, that’s still an entire galaxy; even by reducing it to the equivalent of one additional region, that allows one player to cover half the galaxy, instead of a quarter. You are literally doubling the amount of scanner coverage. Given the prevalence of stronghold galaxies, no guild would ever be without an active member that has scanner coverage across any potential landing zones. In fact, if one player can cover an entire galaxy, a single average guild could literally have scanner coverage over the entire server.

A new tech/structure/mechanic that allows scanners to detect units earlier

This particular idea isn’t terribly flawed, when approached from the right perspective. The biggest problem is that it needs a soft cap that won’t allow all fleets to be visible the second they launch, regardless of size, and will still allow scouts and corvettes reasonable stealth. The other primary concern is that these ideas are almost always grouped with a counter – namely, one tech allows scanners to detect units earlier, while another tech allows units to stay hidden longer. It is very rare that these requests are anything but a change for the sake of a change, as the inevitable configuration is a simple arms race – whoever has the highest level of that tech is the only one that can possibly benefit from having it.

Of the common iterations, there’s usually a tech that goes by either a percentage or a flat time, which makes all incoming fleets visible sooner. However, other versions include a structure that does the same effect, while yet another that I’ve seen is a simple mechanics change that allows scanners to see incoming fleets a certain amount of time faster than those fleets appear to anyone with eyes on the astro. In any case, the specific way that you accomplish the result no longer matters, since they all invariably wind up with the same type of effect, with the only difference being how they tweaked the numbers.

A new tech/structure/mechanic that allows players to see recently landed fleets on their scanners

Admittedly, this is one that I like…but only in very limited ways. My normal variation is that players can see any fleet that landed within the previous 30-60 seconds, to allow for active players to catch scouts or to refresh their memory on where the enemy fleet was landing, while still being limited in its scope. Other formulations involve a structure or tech that allows fleets of X size or bigger to be seen after it landed, or to allow all/some fleets (by size, sometimes going alongside the previously mentioned idea) to be seen for X minutes after landing.

The real flaw here is simply in scope. Allowing diligent players to see fleets that slipped by in a moment isn’t terribly game breaking, while allowing them to see every fleet from the last hour, two hours, day, etc, is overpowering in favor of upgraded players. But like the previous idea, the method of delivery isn’t enough of a change to warrant bringing this up again, because the effect is always the same, within normal variations.

A new tech/structure/mechanic that lets guildmates share scanner views

One of the things that keep scanners balanced is the fact that you have to be online to use them. Having twenty bases across twenty regions and an upgraded account only does you good scanners-wise if you are online to benefit; by allowing guildmates to see the scanner views of each other, you eliminate the need to be personally online. Consider the fact that the trend for the majority of the servers is that of the fortress galaxy; the chances of having a base that belongs to an upgraded player in any given region is quite high. This means that the chances of an enemy slipping in unnoticed drops substantially, and not through an increase in activity on the part of the defender, but through a decrease in activity.

This normally shows up as a generic mechanics change, although I recall at least one idea that allowed you to see the scanners of any guild member around you for X distance, with X increasing as you build up levels of a structure, or research levels of a tech. The specific formulation doesn’t matter, though, because the entire concept of allowing members of a guild to see each other’s scanner views is fundamentally flawed. It increases benefits while decreasing the need for activity, which is detrimental to the game.

A new unit/modification to existing unit/technology/mechanic that allows a unit(s) to have scanner coverage on the astro/system/region where it is currently landed, either in full, or in a limited capacity

This normally pops up as either a new unit, or an addition to death stars; however, there have been techs proposed that increased the range and/or detection time, for whatever units it applied to. I actually proposed an idea involving this once, which essentially gave dreadnoughts the ability to see the system it was sitting in, and only be able to detect fleets that were landing in the next thirty minutes.

The primary issues involving this one are similar to the problems involved with increasing the range of scanners, as they technically do the same thing, albeit in a different format. By allowing units to provide full or partial scanner coverage, you make it so that a single player can gain scanners across a huge area, with little to no increased cost, and with substantial mobility – something that bases don’t have. Most people try to balance this by putting it on death stars, at which point someone mentions that it would therefore take 600 hours to land in an enemy galaxy cluster, making this useless for offensives. However, for defending a fortress, an entire guild could have each player make 1-2 death stars, and they now have scanner coverage across the entire galaxy, with enough overlap that people can be offline and there is still someone on to watch the scanners.

For any change that gives units scanner capability, it will either be overpowered or underpowered; while sometimes underpowered works for what it is supposed to do – for example, my idea was simply a way to watch occs – the simple fact is that we’ve heard every iteration. The only thing that you’re changing is the specific times, ranges, and units – the mechanic is what matters, and that’s what is identical in all of these.

A new unit/modification to existing unit/technology/mechanic that prevents enemies from detecting the unit/fleet with the unit for X amount of time, whether on scanners, on the astro, or both

As mentioned above, this is almost always grouped with an idea that allows scanners to pick up units earlier, thus canceling each other out. However, another issue with this one is the simple fact that, given the new detection times, any decrease in visibility is overpowered. The soft cap for visibility is at forty-eight hours; if your modification cuts that down by 25%, you can have an entire blob suddenly showing up with thirty-six hours of travel left, giving them an advantage that surpasses wormholes, as they aren’t landing on an oft-scouted location. It’s a simple matter of either being too effective, or not effective enough, given the new detection times.

A new unit/modification to existing unit/technology/mechanic that completely hides certain units when in motion, and/or when landed

This one usually shows up as a “cloaking ship” which is detectable by the enemy, but hides X credits worth of ships that travel with it. People usually point out that you can hide your fleet composition, or make people think that you have more than you really do. However, the entire concept is terribly flawed. Consider the instance of a blob crash: you see that an entire enemy guild is heading for your blob, but all that you can see is a million of these units. You don’t know who to attack, or with what; an HC stack trying to shield rape could hit a frigate fleet, or a fighter drop could hit a levi stack. You effectively kill all hopes of defending. While some might feel that this makes a good anti-blob idea, it is manifestly unfair, given the fact that no one can defend against an enemy. You make this a game that purely consists of who attacks first.

Another issue, of course, is when those units hide your fleet when it isn’t moving. In such an instance, you also eliminate all attacking, because no one knows what fleets to bring in. These ideas literally kill the game, because this game relies upon knowing what you’re up against.

Making all hangar units invisible

This idea is just like the last one, so I’ll keep it brief. If you don’t even know how many fighters the enemy has until you drop a scout to attack, then you can’t plan a hit. It’s as simple as that. And, again, take a blob crash – attackers don’t have time or the ability to figure out who has what number of fighters, which means that they’re attacking blind. Defenders can’t defend for the same reason. This is another idea that would kill the game.

A new tech/mechanic that creates a false variable flight time that is different from the actual flight time

Here’s what I mean by this: say that your flight time is 100 hours exactly. This new feature would make the enemy see your flight as 100.5 hours, or as 99 hours, or even as small as 100h, 00m, 05 seconds. It’s something that throws off your enemy, so that they could either miss you completely, or give you the drop on them to counterattack or flee. It’s one of those features that is either mind bogglingly useless, or is just capable enough of being abusable. Consider the situation where you cannot trust the flight time of your enemy, but you know the soft cap of the variability. The proactive attacker will spam the attack button until you show up, which makes the idea useless. However, I believe that most people will simply guess, and the defender will fly merrily away – meaning that recall traps and the simple act of pouncing on an invasion fleet flies out the window, and as such is overpowered.

A new mechanic that allows scanners to see where the fleet launched from

To put it simply, this makes recall traps unbelievably simple, and takes all of the work out of scouting and preparing. It is not beneficial to the game in any way, shape, or form.

Final Thoughts:

All of these ideas have been presented time and again, and always use the same mechanic, but dressed up in new packaging. I implore anyone that reads this to leave well enough alone; we don’t need to see how you tweak the specific numbers to an idea that has been presented dozens of times.

[Winchester]

Welcome to the next installment of Ribbentrop’s FMR workshop. Here, I will be discussing various FMR ideas, and will detail some of the common iterations, any problems that might come up with them, and where possible or reasonable, I will post the variation that I believe to be superior, whether it has been posted before or not. As a note, this entire series of posts on the FMR has been approved by Zoran, so please, do not respond with “FMR” or otherwise claim that I am breaking one of the rules. This post, whether I propose an idea or not, is primarily an informative one for newer posters, while simultaneously placing these common ideas within recent search history.

Today, we will be looking at one of the more common things from the FMR: New Units.

Are all new unit requests restricted by the FMR?

The short answer is that yes, they are. Given the fact that FMR ideas can be posted if they have a substantial new variation, this doesn’t mean that no one can ever request a new ship. However, there are a number of requirements necessary for any new ship request, which I’ll discuss here.

What does a new unit request need to not violate the FMR?

1: The unit must serve and/or create a new, distinct, original purpose – a new combat unit that works like every other combat unit doesn’t cut it, for example. If your unit could be described as a bigger/smaller/faster/slower/more powerful/less powerful/more efficient/etc __________ then you aren’t allowed to request it.

2: The post must include full stats for the unit, including cost, tech/shipyards required, speed, weapon, etc.

3: The unit must utilize the existing combat formula. No first-strike, point-defense, only-targets-this-unit, etc. If you don’t know the combat formula, find out before posting, or don’t post.

4: The unit must be balanced; if it’s not useful enough to be worth building, then it’s not a good idea. If it confers a massive advantage or is otherwise overpowered, then it’s not a good idea.

5: Include some mock combat scenarios (if a combat unit, whether offensive, defensive, or auxiliary), so that you can demonstrate its uses and how it works in a real ingame scenario. If it’s not a combat unit, provide some data to show what it will do in a realistic situation, for whatever its purpose is.

Common Iterations

I’m not going to go too far into the specific ideas, such as the problems with them, because most of them fall under new categories. This list is for more general purposes.

• Mobile Jumpgates
• Swarm unit – something smaller than fighters, normally credited as being used for killing fighters
• Flagship/Capital Unit
• New Carrier
• New Scout/Mobile Scanner Unit
• New general combat unit
• New bomber, usually a photon bomber
• New Ion unit – normally cruiser-type, but not always
• New shield raping unit
• Unit that increases debris generated
• Unit that increases experience gained
• Cloaked/cloaking unit
• Privateer unit
• Pirate unit
• Unit that does splash damage
• Unit that repairs other units
• Unit that mines asteroids/gas giants
• Unit that can become an outpost/deploy as a structure
• Unit that can move debris
• New recycler unit
• Unit that can move other units
• Minelayers
• Missile platforms
• Unit that performs some function normally attributed to structures
• Unit that produces other units
• Unit that increases econ
• Unit that can increase armour/power/shields of units
• Unit that can decrease armour/power/shields of units
• Unit that can prevent, disrupt, or otherwise interfere with the movement of other units either landing, taking off, or already in flight
• Unit that can disrupt, turn off, or otherwise interfere with CCs, jumpgates, defenses, or any other structure/aspect of structure (such as shields on defenses)
• Unit that increases/decreases bleedthrough of units
• Unit that temporarily disrupts enemy units

We just want new units!

This is the common argument people try to use to justify requesting new units, so I’ll close this workshop by addressing it. To put it simply, if a new unit is added for the sake of a new unit, it doesn’t do anything – if it’s more effective at its role than the closest equivalent unit, then you’ve just replaced that unit. If it’s less effective, then people won’t use it, except for a very short time out of novelty. If it’s identical in terms of effectiveness, then you aren’t actually adding anything to the game; you might as well duplicate every unit and give them a new set of names.

If a unit does not serve a new purpose, then as mentioned, it will be treading on an existing unit. If it’s better, worse, or identical, it doesn’t need to be added. Period. So, any new unit that does not fulfill a new, distinct role will be a ship for the sake of a ship, and will not benefit the game.

[Winchester]

Welcome to the next installment of Ribbentrop’s FMR workshop. Here, I will be discussing various FMR ideas, and will detail some of the common iterations, any problems that might come up with them, and where possible or reasonable, I will post the variation that I believe to be superior, whether it has been posted before or not. As a note, this entire series of posts on the FMR has been approved by Zoran, so please, do not respond with “FMR” or otherwise claim that I am breaking one of the rules. This post, whether I propose an idea or not, is primarily an informative one for newer posters, while simultaneously placing these common ideas within recent search history.

Today, we will be looking at one that has produced more heated discussion than nearly any other topic: anti-blob ideas.

Why anti-blob ideas?

Most people, myself included, feel that blobs are one of the primary reasons for server stagnation; as such, this is a very common topic for requests. There have been numerous attempts at solving the issue, and very long debates, both in public and in the volunteer’s forum. So, I wanted to make this the next workshop, because it’s something that a lot of people feel the game needs, but it’s also one of the most fiendishly difficult ideas to make work. I’ll explain the problems that these ideas normally face while going into the versions that we most often see.

She’ll make .5 past lightspeed, but only when she’s alone

Speed. It’s one of the main things that you need if you’re going to work as a guild, which is why there’s so much importance placed upon high level jumpgates and logistics commanders. Understandably, this is one of the ways that people tend to attack blobs; whenever a certain condition is met, units are slowed by a certain amount, or jumpgates work less efficiently/don’t work at all. That certainly prevents people from attacking blobs, but does it really prevent them from blobbing?

The answer is no. If you’re sitting on an astro with your blob and don’t intend to go anywhere, then you also know that no one can attack you, because the fleet necessary to hit your blob would leave them crawling through interstellar space, with all the speed and ferocity of a pissed off snail. Blobbing suddenly becomes more safe. What’s more, let’s say you have a jumpgate the next system over; you have 5-10 people go at a time, and you suddenly avoid the negative effects. The only thing it does is throw off coordination, which again means you can’t make a coordinated attack. This also negatively impacts guilds, as the limitation is often low enough that you can’t have 5-10 people work together to make a hit against 3-5 enemies sitting on the same location.

Splish splash, we were planning a crash

You all knew it was coming: splash damage. I give full credit to some of the FR regulars that came up with a very respectable idea for splash damage. However, by and large, these ideas run into two problems:

1: If you have a unit that does a guaranteed percentage of damage to every unit, then you’ve got some amazing fighters. Imagine dropping 5m fighters, with each one doing 1% splash damage to every unit on the blob. Suddenly, those 5m fighters are doing 250k damage to every fleet on the blob. This just isn’t funny anymore. By the time four people have done their fighter drops, you’ve got 1m damage spread around to every single person on the blob – with 100 people, yes, that’s right – your 20m fighters just did 100m damage.

Sounds pretty sweet, right? No one would blob with something like that going down, right? Well, you need to decide how to make it so that only the attackers can do that sort of splash damage, or no one would risk attacking blobs. This means that:

• You can’t have a new unit that does it
• You can’t make it apply strictly to guild, or people will deguild when an attack is coming to avoid it
• You have to make it account for the entire system, or people will spread out
• You need to have a high enough level that it doesn’t trigger for the aforementioned 5-10 person hunting parties
• You need to make it so that the defenders can’t avoid it just by flying off the astro for half an hour and then hitting recall
• You have to make it so that splash damage triggers when the attacker is attacked, or it won’t be very effective (this causes its own problems, of course)

Some other problems to consider:

• It needs to generate a combat report to let people know they were hit. This means that a single corvette suicide will generate a combat report for everyone on the astro, and makes spamming incredibly easy.
• If you don’t make it splash every unit, you need to figure out who it will attack, and how to make it fair. It won’t do any good if the splash damage only affects, say, the next fleets according to size, because then the defenders can minimize their losses.
• You need to decide if the damage is stopped by shields; if it is, then it isn’t very effective, because people can move all of their unshielded away, and levi stackers become even more powerful. If it isn’t, then you’ve suddenly got a way to bypass the issue of shield rapists – send fifty million fighters in on suicide runs against targets, and you’ve got 2.5m damage going to every single person on the blob, which will utterly destroy a levi stack. Grossly overpowered, that.

Still, let’s say you deal with all of these issues, which brings us to the second problem:

#2: Lag. For those of you that were involved in or heard about the Alpha blob crash, the lag was obscene. Well, imagine what the lag would be like if every single attack involved not one calculation, but over one hundred calculations. No matter how you slice splash damage, that is an incredibly hurdle, with no real way over it. It’s a shame, because I know that I could create a viable splash damage formula if lag weren’t a problem.

That wasn’t a laser blast; something hit us

Here’s one that always pops up sooner or later, like a stiffy at a petting zoo. Essentially, imagine something – either mid-space collisions or flying debris – automatically doing damage to blobs. Sounds fun, right? Blobs destroy themselves, with no need for you to attack? Think again.

The first and biggest issue with this idea is simple. No game mechanic should ever make a player lose their fleet without the player actually doing something. Everyone responds to this by pointing out UCs and Drekons, but let’s be honest. 8k credits worth of heavy cruisers isn’t a big deal, and if you parked on the UC and occed it, it’s your own fault. For Drekons, same thing – they don’t fly off to your base to blow up your fleet. Anyways, this is a PVP game, not a PVE game; your fleet should only be blown up without your consent if it is done by another player.

Second, you have a lot of the same issues as splash damage:

• The fleet number that triggers it has to be big enough to stop blobbing, but small enough to not stop coordinated multi-player activities. Also, it has to grow with server age, which means that you need a unique formula that manages to hit blobs as defined by the server age and politics, but that doesn’t hit small groups of players.
• The damage has to bypass shields, or it isn’t useless; however, due to the lack of meat, shield rapists will take a disproportionate amount of damage. This one isn’t terribly hard to solve, though – you make the damage be a flat credit reduction in fleet. Still, it’s something to consider.
• Damage calculations and combat reports are necessary, which means increased server strain.
• The actual timing of the damage is problematic, because it has to be unavoidable, while still being regular and effective.
• Debris generation is an issue, as it opens up the realistic possibility of credit transfers. Additionally, the specific generation and amount is a problem, and when in the case of debris damaging blobs, you need a distinction between the defending guild and the attacking guild, or no guild can ever clean up a large debris pile.
• How much damage is allotted to each fleet; it has to be enough to make a noticeable impact, without being able to completely wipe out smaller fleets.

All in all, automatic damage to fleets is so finicky that the specific formula would have to be a masterpiece to work at all, and leaves open so much room for abuse and destroying gameplay that the risks are inherently stronger than the benefits. It’s one of those ideas that simply isn’t feasible.

Lot A full; proceed to Lot B

Another very common idea is the notion that there is only X amount of room for fleets on an astro, and that one the current fleet on the astro meets X, no one else can land there. I sincerely hope that people are already starting to understand what the problem is, but I’ll explain anyways.

1: What happens when two people send to the astro at the same time, and their fleet combined puts the fleet total above the limit? This is a major issue. Additionally, the base owner has to be exempt for obvious reasons.

2: People can blob across several astros/systems if needed, invalidating the entire idea.

3: If the fleet limit is total fleet, then no one can possibly attack a blob that meets the fleet limit.

4: If the fleet limit is fleet per guild, then blobs can defend themselves by deguilding, or going into multiple separate guilds. The attackers are additionally hindered from having to use multiple gates to launch a single attack.

In short, there is no way to make this idea work.

Who ordered the large pepperoni Drekons?

This is one that has come up numerous times in the last few months, and amounts to nothing more than a free derb-delivery service. Imagine having massively powerful Drekons fleets launch for any blob over a certain size, thus destroying them or forcing them to run. There are multiple issues with this idea.

1: If the defenders can beat the Drekons, it’s free debris.

2: It requires NPCs killing player fleets without the active consent of the player, which is frowned upon.

3: If the guild blobs just below the fleet level needed to trigger the Drekons, then no one can attack them, because that would require massing more fleet at a single location.

4: Any blob that is successfully destroyed by the Drekons will eliminate the need for blobbing, as the other side will have effectively won. Any blob that is attacked by Drekons that can’t weaken them to the point that the other side can still win is a blob that isn’t deterred by Drekons, thus going back to point #1.

Final Thoughts

If you’re interested in designing an anti-blob idea, here’s my checklist of what you need to make sure you cover:

• The idea must be able to target blobs, but not affect groups of 10-15 players working together.
• The idea must not activate when one group of 10-15 people is attacking another group of 10-15 people.
• The trigger for the idea must take into account the fact that blobs in a one-year-old server are vastly different from blobs in a four-year-old server.
• The solution must not utilize hard caps, at all, and should strictly avoid arbitrary numbers (example: 1b fleet will trigger the effect.)
• The idea must be such that it cannot be avoided by spreading across multiple astros or systems.
• The idea must be such that it cannot be avoided by deguilding or switching to another guild.
• The idea cannot prevent one blob from attacking another, either directly or indirectly.
• The idea must not create a significant increase in lag or server strain.
• The idea must not result in players losing fleet without the actions of themselves or another player.
• The idea must not result in a “derb delivery” for anyone.
• The idea must either operate within existence game/combat mechanics, or must fully explore and justify the effects of any new or altered mechanics.
• The idea cannot overpower attackers/underpower defenders to the point that a sizably inferior force can inevitably beat a blob.

Really, there’s always more to say about this subject, but at this point we’re probably hitting information overload, so I’ll stop here. Until next time!

[Winchester]

Welcome to the next installment of Ribbentrop’s FMR workshop. Here, I will be discussing various FMR ideas, and will detail some of the common iterations, any problems that might come up with them, and where possible or reasonable, I will post the variation that I believe to be superior, whether it has been posted before or not. As a note, this entire series of posts on the FMR has been approved by Zoran, so please, do not respond with “FMR” or otherwise claim that I am breaking one of the rules. This post, whether I propose an idea or not, is primarily an informative one for newer posters, while simultaneously placing these common ideas within recent search history.

Today, we will be discussing hardcoded politics.

What counts as politics?

This question, which is what prompted me to do this topic (Thanks Wlerin), is a rather difficult one to answer. In general, when someone refers to hardcoded politics, they are talking about the notion of some sort of inter-guild relations being built into the game. This includes, but is not limited to, the following:

• An official state of war between two guilds
• Official pacts – NAP, MDP, etc
• Linked guild boards
• Official/linked training guilds
• Official protectorates

Now, with that in mind, it is hopefully a bit clearer what is meant by politics in this sense. The more generalized way of looking at it is anything that involves two or more guilds – it does not matter what it is, but if it involves two or more guilds in any sort of official, coded capacity, it typically falls under this category. The exception to this would be officially-noted KOS.

What are the common ideas?

There are several that tend to spring up; most of the ideas revolve around the general archetypes noted in the list in the previous section, so we will discuss those.

State of War

This can include a number of different things:

• A section of the guild profile that the GM can put a guild ID # into, which shows that you are at war with them
• Some versions of the above make it so that your guild page automatically reflects who has listed you in their war declaration spot
• An official “state of war” – two or more guilds both agree to enter into a war, and gain various bonuses and penalties, such as double pillages against enemy bases, double attack power on a base occupied by the enemy, etc
• Some of these have actually included protection from having your bases hit by anyone that you are not at war with

Official Pacts

• As with the state of war, there is a section on the guild profile where you can list your pacts
• Some contain user-specified fields for the pact name, while others contain a list of choices, such as NAP, MDP, etc
• A number of these, such as NAP, come with official restrictions – things like being literally unable to hit people that you have a NAP with, in the same way that you cannot hit your own guild members
• These are also usually tied into the war – for example, if someone declares war on you, your MDP automatically lists that guild in their war section

Linked Guild Boards

As the name implies, this one is very simple: people constantly request that you be allowed to link your guild boards (usually the general and trade boards) with another guild.

Training Guilds/Protectorates/Brother and Sister Guilds

I’ve linked these, as they all share the same characteristics: essentially, it is the joining of two different guilds, either directly or indirectly. These typically include:

• Making the training guild a subdivided part of the main guild. Individual boards, internals, etc, but still within the main guild
• Extending all guild benefits – shared vision, shared jumpgates, guild boards, etc – to a training guild or brother/sister guild
• Extending guild protection rules (ie, cannot plunder trades with a guild member present) to another guild, which is listed as a protectorate under pacts

Why are these bad?

The first reason that people will cite for the more general ideas, such as official NAPs, is that everyone has a different definition of what a pact consists of. Your NAP may be total, while someone else’s might be more akin to what some would call a LAP – a Limited Aggression Pact. Hardcoding such a thing is disingenuous.

Second, every guild has a profile space for a reason. Why waste time coding in an official spot for wars, pacts, etc, when the guild can simply fill out the information on their own?

Third, anything that provides a bonus is abusable. If you get higher pillages while at war, guilds will simply declare on every smaller guild on the server. If they are limited, then they will declare on the faction they attack the most. On a polarized server like Ceti, there are only two factions – you would be giving them benefits for the sake of benefits. There is no purpose to such a thing, and it can be easily abused.

Fourth, things such as shared guild boards and privileges simply increase the player limit on guilds; having an aesthetic distinction fails to serve a unique, justifiable purpose.

Fifth, the ideas that prevent you from attacking a pacted guild are simply hardcoding something that you shouldn’t be doing already, according to the rules of your guild. If your guild says to not hit bases belonging to [XYZ], then don’t hit them – you don’t need to waste developer time to prevent dumb people from making mistakes that are only relevant to player-driven politics.

Sixth, politics are an entirely player-driven part of the game. If you decide to name another guild a NAP, a bloodpact, a target, etc, simply do so – there is no need for the game to make that choice official. Politics is not a fixed, official part of the game, because it is entirely based upon the decisions of the players; to use a very relevant example, the politics of Alpha are beyond different from any other server. They actually have a pact that prohibits blobbing. How can you even hope to code something like that, and make it relevant to every server?

Final Thoughts

The result for all of these is that they are generally a waste of time. They don’t add anything substantial or legitimate to the game, and when they do, they are usually overpowered or abusable. While a number of people would agree that player interaction is the lifeblood of this game, it is equally true that this is the case because of its fluidity – you do not need to officially list who you are at war with in order to be at war, and being stuck in a pact because of arbitrary rules is detrimental to the game. For example, take the idea of being unable to hit a NAP – what happens when you want to sneak a hit or two in, to try to get them angry? That’s a political maneuver, yet is hindered by the hardcoded politics.

When it comes down to it, however, nearly every iteration of hardcoded politics has come up in the past. There is no reason to continue posting ideas that involve such things, because they have all been proposed before, and Wizard has seen them – hence why the blanket statement is in the FMR. The biggest thing to consider when making ideas that use politics in the periphery, rather than as the point of the idea, is this:

1: Does it fail to benefit the game in a clear, distinct way? (Note that “it will make the players happy” is not a sufficient benefit unless you can detail how, why, and that the negatives don’t outweigh that benefit)
2: Can it already be done by the players?
3: Can it be abused?
4: Does it limit, reduce, or remove the options of players and guilds?
5: Does it apply arbitrary, generic, or incomplete concepts or terms?

If you answer yes to any of those, then the political component should be reworked, or dropped altogether.

[Winchester]

Welcome to the next installment of Ribbentrop’s FMR workshop. Here, I will be discussing various FMR ideas, and will detail some of the common iterations, any problems that might come up with them, and where possible or reasonable, I will post the variation that I believe to be superior, whether it has been posted before or not. As a note, this entire series of posts on the FMR has been approved by Zoran, so please, do not respond with “FMR” or otherwise claim that I am breaking one of the rules. This post, whether I propose an idea or not, is primarily an informative one for newer posters, while simultaneously placing these common ideas within recent search history.

Today, we will be discussing asteroid belts and gas giants.

They aren’t used for anything!

This is the first statement uttered by 99% of the people that decide to post a request involving asteroid belts and/or gas giants, and to put it simply, it’s wrong. Gas giants allow moons without planets, while asteroid belts are required in order to have any colonizable astros at all. So, while you might think that they aren’t useful simply because you can’t land on one, think again; they’re just like stars, in the sense that they provide an ingame function, yet you cannot interact with them directly.

Mine! Mine! Mine!

Right after they finish discussing how these two celestial bodies are useless, the average poster will often propose the following: players should be allowed to mine asteroid belts and/or gas giants. This idea typically involves one of the following:

• A mining ship, which provides X credits an hour when over an AB/GG
• Being able to build a regular base, with a new structure that provides economy/production/construction, or else has a higher metal content
• Being able to build outposts, which mostly provide economy
• A mobile outpost/mining colony, which crosses the first and third ideas together

The problem with the first option is readily apparent; a unit that provides income from a limitless source allows people to bypass economy soft caps, and without the risk and activity of destroying fleet for debris. Some people attempt to circumvent this issue by placing limits on how many units you can station at each AB/GG, or how many credits you can pull from them per X amount of time. However, all of those solutions involve either hard caps, which are not allowed, or increased server stress, unrealistic capacities, insufficient value to make it worth adding, or some other such problem.

The second issue is rather simple; adding a new astro type at this stage in the game would be distinctly unfair to those with established accounts. While it is possible to add it only to a new server, Wizard has thus far refused to make special rules for new servers. The one exception is the upcoming speed server, but that is another story altogether, and does not include new ideas such as this one. Aside from that, of course, it is almost always a case of X for the sake of X – increasing some stat for the sake of increasing that state, or for no other reason than to have the pleasure of a new astro type to colonize.

The third issue almost always revolves around X for the sake of X, and is also difficult to balance. The forum user Ilshur has made numerous detailed attempts to institute a system for colonies, yet has never managed to make one that is both useful and balanced. The core issue is that AE simply does not need a colony feature that does not do anything unique, which means that being able to sit on an AB/GG is a side feature, rather than the point of the idea; this belies the fact that most of the requests for colonies on AB/GG strictly revolve around the desire to see those two astro types colonizable.

”You’re not actually going into an asteroid field, are you?” “They’d be crazy to follow us, wouldn’t they?”

Yes, this is the next most common iteration for AB/GG: hiding. The general requests are as follows:

• Fleets flying toward/away from an AB/GG are invisible for X% of the flight
• Fleets sitting on an AB/GG are invisible
• Fleets sitting on an AB/GG only show X% of their actual fleet
• Fleets sitting on an AB/GG are only visible to players with ships in the same system
• Fleets sitting on an AB/GG are only visible to players with X new unit in the system/region

As you can see, they are almost always variations on that basic theme; for the major problems with stealth ideas, please read this thread. Regarding AB/GG in particular, suffice it to say that any stealth concepts would need to pass muster with the other Workshop, and that these particular astros would once again be nothing more than a side effect to an otherwise independent idea.

Are there any plans in store for asteroid belts/gas giants?

I’m glad you asked! As a matter of fact, Wizard has said in the past that he does have intentions to utilize them down the road. Because of this, it makes the point of the FMR – Wizard already has a use for them on his to-do list, which we do not have access to. Therefore, making suggestions on something that Wizard has already decided to do is either useless or redundant. Okay, so both are useless, but you get what I mean. So please, just sit tight, and wait to see what Wizard comes up with.

Really, these are the main ideas behind nearly every request for AB/GG. Everything else tends to either revolve around this theme, or else utilize AB/GG as a secondary feature to an independent request.

[Winchester]

Welcome to the next installment of Ribbentrop’s FMR workshop. Here, I will be discussing various FMR ideas, and will detail some of the common iterations, any problems that might come up with them, and where possible or reasonable, I will post the variation that I believe to be superior, whether it has been posted before or not. As a note, this entire series of posts on the FMR has been approved by Zoran, so please, do not respond with “FMR” or otherwise claim that I am breaking one of the rules. This post, whether I propose an idea or not, is primarily an informative one for newer posters, while simultaneously placing these common ideas within recent search history.

Today, we will be discussing anti-occupation features.

What constitutes an anti-occupation feature?

In essence, anything – a structure, a commander, a game mechanic – that makes it easier for players to free themselves from occupations and/or prevent longterm occupying of their bases is an anti-occupation feature. Within the current game, many people consider command centers and tactical commanders as anti-occupation features, as they increase the attack power of your units when over your base, which makes it easier to fight off occupations.

Common Iterations

To be entirely honest, there have been numerous different iterations of this concept; I will thus not be going into all of them, as it would take too long, and I frankly don’t remember them all. However, I will hit the central themes.

We need more power!

Following the trend of command centers and tactical commanders, one of the first things that most people think of is boosting the power of your units. This normally occurs through one of the following:

• A new structure
• Automatic power increases when occupied
• Increasing the effectiveness of command centers/tactical commanders when occupied
• A new commander
• Buffing the tactical commander/command centers
• Increasing power over time – ie, your attack power goes up X% for every hour spent occupied, either consecutively or over the last Y hours

While none of these are bad per se, they often run into the same few problems:

1: The power boost is not enough to make a difference
2: It requires building structures/training commanders that are only useful when occupied
3: It requires building structures while occupied, which takes time and money
4: It provides an overpowered boost when not occupied
5: It can be abused, such as having a friend occupy you before an enemy comes for your fleet, or if you have a base on a wormhole
6: An occupier can circumvent the issue by releasing and reoccupying the base

These are the issues that you have to consider if you want to propose an anti-occupation feature that increases damage; however, given the fact that there have been successful ideas in the past, it is unlikely that the average person will have an innovative take on the subject – hence why it is an FMR topic.

Boost Production!

The next most common idea is to give players the option to increase their production while occupied; these ideas normally use the following:

• A new structure that increases prod/con when occupied
• Lowering the prod reduction suffered while occupied
• Have prod commanders provide extra prod while occupied

There are three central issues involving these: First, if the idea lets you boost prod higher than your unoccupied production, it is abusable. Second, lowering the prod reduction removes one of the strategic reasons to occupy your enemies, which removes one of the valid reasons to occupy other players. Third, more prod does little or nothing to help low level players escape permanent occupation. The following is a bit of math used to explain this notion in a previous thread:

What would you say is the normal low-level production? 100-300? We'll go all the way to 500 just to make a point. Let's say that there is no reduction in prod, in fact. So, you've got a whopping twenty CCs, and you're being occed by a leviathan. With 500 prod, it would take you 181 heavy cruisers - with a very generous plasma 20, armour 30, and shielding 20 - to kill the leviathan, assuming normal high-level techs. Now, that cost is 90,500 credits to build those heavy cruisers. At 500 production, it would take seven and a half days to build. Which means the following:

1: The occed would need high prod
2: The occed would need high tech
3: The occed would need high CCs
4: The occed would need a large number of credits on hand
5: The occed would need a week to remove the leviathan...and then another week to kill the next one

Given a more realistic scenario of 250 prod after the reduction, it would thus take 15 days, provided he even has enough credits. And at more realistic levels of CCs, while even still giving him the same tech, it would take 335 heavy cruisers - 167,500 credits. At 250 prod, this would take twenty-eight days.

Given these issues, an increase in production does not work as a standalone anti-occupation feature, and while it might work in conjunction with an otherwise valid request, any such feature would have to pass muster from the other points in this thread.

Forced Limitations

Another idea that has come up in the past involves automatically removing occupations after X hours; while some iterations remove this for inactives and NPCs, there is still one primary issue: if the occupier can simply reoccupy, they will, which means that this solves nothing, and if they can’t, then it’s abusable to have an un-occupiable base. Once again, this idea has potential in conjunction with other ideas, but is ineffective on its own.

Remove the Reason to Occupy

This is a very common one. In essence, it involves removing the reason to occupy someone; this is done through lowering econ gain, reducing pillages, etc. For one thing, this has already been implemented to a lesser degree, as occupying someone below your level reduces the income you gain from them. But aside from that, there is a balancing issue at stake. As the current reduction shows, people will still occupy low levels, as they cannot fight back. Additionally, inactives and NPCs should be exempt, while active players should get a larger reduction. You have to reduce it in a way that discourages longterm occupation, but that does not harm the initial day or two of occupation, as occupying bases is in fact part of the game.

The other problem with this is that there are more than just financial reasons to permanently occupy someone. For example, if you want to farm them out of your fortress galaxy, punish them, stifle their production/economy, prevent jumpgate usage, etc, you would be willing to suffer any losses to do so. This is a problem for the majority of anti-occupation ideas, but is particularly relevant to the economic considerations.

Ministry of Silly Features

This is just a list of the more random, silly, and improbable anti-occupation features I’ve seen:

• Retain the ability to pillage, but remove the ability to occupy
• Remove/reduce all deficits to econ/prod/con when occupied
• Disallow occupation for anyone that is not within X levels of you
• Allow a friend to occupy your base without transferring credits
• Disallow occupation for X hours after an occupation has been released

The Best Idea Yet

Pardon the egotism, but there is one anti-occupation feature that I believe does everything it is supposed to do, in a manner that is logical, reasonable, and effective, without being overpowered/without wasting area on every base just in case you’re occupied. And yes, I proposed that idea. I will copy the basics of it to this thread, but the original thread can be found here.

NOTE: Do NOT necro that thread, and do NOT comment on the validity of this idea here. This is for informational purposes ONLY.

New Commander Classifications: Insurgents

Insurgent commanders exist separately from the normal commander setup. Their base cost is 25 experience, but the player can substitute experience for credits at a 1:1 ratio, instead of 1:2 like normal commanders. Insurgent commanders can be stationed at any base that the player owns, even if there is already a normal commander; however, their bonus only activates once the base is occupied. Insurgent commanders can only be killed when 100 or more hours have passed since the last pillage. Insurgent commanders cannot be unassigned while the base is occupied, but can be assigned while the base is occupied. Multiple insurgent commanders (including two or more of the same type) can be assigned to a single base; however, it requires ten levels of command centers to assign every commander after the first. Insurgent commanders are tallied separately from regular commanders, as far as computer tech is required; at level twenty computer tech, you can have twenty regular commanders, and twenty insurgent commanders, simultaneously.

New Structure:

Resistance Headquarters
Cost: 512
Energy: -2
Economy: 0
Population: -1
Area: -1
Advanced: X
Requires: Computer 10
Each level increases the bonus provided by all Insurgents by 25%. Can only be built on one base. Bonus doubles when base is occupied.

Insurgents:

Raider Insurgent
Each level increases attack power of the base owner’s fleet against the occupier’s fleet by 5%

Demolitions Insurgent
Each level reduces pillages and hourly income provided from the occupied base by 2%. If bonus exceeds 100%, the occupying player loses credits by holding the occupation and/or pillaging the base. Base owner does not receive excess credits.

Repair Insurgent
Each level automatically restores defenses by an equal percentage when the occupation is released. Bonus cannot exceed 100%.

Smuggler Insurgent
Each level increases production and construction cap by 1% of max value, while lowering economy by 1% of max value. Production cannot exceed 100% of max value, and economy cannot drop below 0% of max value.



Final Thoughts

Finding a good feature to eliminate permanent occupation of active players is something that a lot of players – myself include – want. However, it should be noted that any attempts to do so should take into consideration the fact that we should not deny players their submissive farms. If a player is unwilling to free themselves, then they do not deserve to be freed; therefore, any ideas in this vein should require proactive effort on the part of the occupied.

Likewise, all of the above concepts have been tried and beaten to death. Unless you have a very innovative take on the subject, you will be violating the FMR by posting an anti-occupation feature. Again, not to brag, but I believe that my Insurgents idea is sufficient for everything that such a feature needs, which means that any idea you come up with will be compared to that one.

[Winchester]

Hello, everyone! Today we will be doing something different; instead of looking at another FMR topic, we will be looking at what is and is not a concept discussion. Because of this, I will be deviating from my normal Workshop format.

Concept Discussions

As the name suggests, a concept discussion (CD) is a thread devoted toward discussing a particular idea or theory, rather than one intended to request a specific feature. Because the objective is discussion, rather than simple approval or disapproval of a proposal, the rules forbid any posts that do not contribute to the discussion – posts such as signing or unsigning are thus not allowed. The general understanding is that any posts made in a concept discussion discuss the concept – this includes, but is not limited to, listing problems that need to be taken care of, discussing the merits of the idea, fixing the problems, determining balance, etc.

Ever since concept discussions began roughly a year ago, there have been people that posted concept discussions that, quite simply, were not concept discussions. In order to understand the difference between a request and a concept discussion, consider the following points:

Types of Concept Discussions

There are two general types of concept discussions: brainstorming and refining. A brainstorming CD is one such as this; the OP has a general concept, and wants to hear from the players to know what they would like to see in association with that concept. The majority of the actual work in such an instance rests with the OP; it is not generally up to the people responding to balance or innovate with their suggestions, as the purpose is simply to generate feedback and general ideas from the playerbase, while simultaneously stimulating the formulation of ideas in the OP.

The second type of concept discussion, that of refining, begins with the OP doing all of the work that they can on a concept. Now, this concept can include such details as general idea features – things like cost and specs of a new unit. The point of all of that is to provide the necessary background for understanding the entire picture, yet the focus is in the concept. This is the critical point of understanding: a concept discussion is not a place for you to request a feature that is essentially finished, but in a type of thread that cannot be signed or unsigned.

This happens on a regular basis. Someone will post an idea with stats, details, etc – all to varying degrees – and then end with something along the lines of “Will this work?” or “What will it take to make this work?” That is not the point of a concept discussion. These sorts of things happen with higher frequency when discussing a new feature that does something that is already in the game, such as a new propulsion system, or a new unit. The concept of a tech that makes certain ships move faster is one that is already in the game, which means that there is nothing to discuss concerning the concept – only in how that concept is manifested in an idea.

What does a refining concept discussion need, then? First, the OP has to do all the work that they possibly can. Go over relevant details, possible issues, counterarguments for common points of concern, etc. Second, clearly discuss what the concept is; if the only thing that we see is a half-finished request without an explicit concept, it isn’t a concept discussion. An example of the proper way to do things is my old concept discussions on Retrofits; within those threads, I posted all of the relevant data, and asked for discussion on such things as whether the concept of specialization is a valid one.

Exceptions to the Rule

Now, keep in mind that there are exceptions to every rule. If you have a very detailed request that you know will cause a lot of waves, it is not strictly forbidden to make a thread about it. You do not necessarily have to label it a concept discussion, either, so long as you make it clear what the purpose of the thread is. Also keep in mind that it is up to you to do all of the work that you can. If you post a thread that has full stats, and you ask a question such as “Does the cost of this unit work?” it does not warrant a CD, or even any sort of discussion; for all intents and purposes, it’s a completed request, and should be treated as such. Likewise, leaving out a detail or two for the purpose of making it a concept discussion is not kosher.

Cheating the System

Lastly, let’s say that you’ve been dying to see a new feature, but you don’t know how to propose an idea for that feature that will work. For the sake of example, let’s say you want a production capital. You should not post a concept discussion asking people to make ideas for you. Saying that you like the concept of a production capital and that you want people to post ways to make one work is not a concept discussion. Likewise, posting a general outline – such as requirements and cost, but leaving the specific benefit out – does not count, either. Remember, the cost and requirements of a structure are not the idea – they are elements that support the idea. The same thing goes for posting a random or generic benefit from the production capital, such as each level provides fifty prod; doing that and then asking people to fix it is abusing the system, and is not welcome.

Too Long, Didn’t Read

• Concept Discussions come in two general flavors: brainstorming and refining
• Brainstorming involves giving a concept and asking for general ideas on that concept
• Refining involves doing all the work you possibly can on a concept – not a specific request involving an existent concept – and then working with people to turn the concept into a workable one
• Trivial concerns such as cost/balance/requirements do not warrant concept discussions
• A partially completed request does not qualify as a concept discussion
• Simply wanting help figuring out how to make a feature you want workable is not a concept discussion

That's all for today, folks. Until next time!

[Winchester]

Welcome to the next installment of Ribbentrop’s FMR workshop. Here, I will be discussing various FMR ideas, and will detail some of the common iterations, any problems that might come up with them, and where possible or reasonable, I will post the variation that I believe to be superior, whether it has been posted before or not. As a note, this entire series of posts on the FMR has been approved by Zoran, so please, do not respond with “FMR” or otherwise claim that I am breaking one of the rules. This post, whether I propose an idea or not, is primarily an informative one for newer posters, while simultaneously placing these common ideas within recent search history.

Today, we will be looking at something a bit more generic: X for the sake of X.

What does it mean?

In essence, X for the sake of X (whether a ship for the sake of a ship, tech for the sake of tech, econ for the sake of econ, etc) means that the only reason to add something is to add it.

Let’s say that I request a new unit, which has stats that fall evenly between a heavy cruiser and a battleship – call it a battlecruiser, if you will. When asked why we need or want this unit, my reasoning is thus:

1: It would be cool.
2: People want to see new units. This is a new unit.
3: It gives people something new to build.

While there is nothing wrong with these reasons – strictly speaking, of course – they do not justify a new addition. What all of it comes down to is that I want a new unit for the sake of having a new unit – X for the sake of X.

What if there are legitimate reasons to want something?

If the requested addition serves an actual, unique purpose, then it’s fine. Here’s what it comes down to: if your request actually does something new (and having a unit with different stats than the other units does not count as new), fixes some flaw or shortcoming in the game, or provides a genuine, independent benefit to the game, then it’s a justifiable addition. The only time it’s an issue is when the only reason to add it is because you just happen to want it.

To give you another example, there have been dozens of threads requesting new research structures. The claim is that there are four structures that increase construction, and six that increase production, but only one that increases research. So, because of this shortcoming, there should be more research structures. Here’s the problem: there is no need for more research structures. Particularly since tachyon came out, you can increase your research cap to 4-6k on an older server. While this is far lower than average prod or construction caps, tech is something that reaches its cost-effective soft cap much faster. There is no soft cap on fleet, and the cost does not increase, so having more prod means you can have more fleet.

Likewise, construction capacity is as it is because it exists per base; even before tachyon, researches applied to your entire empire. With construction, you have to build each structure on the base that it’s going to stay on; it only affects that base, and only uses the construction capacity of that base. With research, it doesn’t matter which base you build it on; you don’t need research capacity on every base just to be able to get something worthwhile. So, because of that, we don’t need more research capacity. Adding structures – or anything else – to that effect are simply research for the sake of research.

However, this does not mean that all research-related additions are X for the sake of X. Take Tachyon, for example. That feature allowed you to pool your res cap, which meant that in X hours you could either do three smaller techs – all of which finish around the same time – or one larger tech, finishing around that same time, or those three smaller techs sequentially, with each one popping out in 1/3 the time. That provides a distinct bonus, as it allows fine-tuning of how you approach research.

That’s what this all comes down to. If it provides some new benefit, then it stands or falls on that benefit. If the only reason to add it is to add it, then it’s not a justifiable addition.

Is there ever a “need” for anything?

This is an argument that comes up almost every time someone claims an idea is not needed, or that it is X for the sake of X. In short, the answer is both yes and no. In the strictest sense, this is a game, so nothing is needed. However, that sense ignores the fact that there can be a situational need, such as needing one thing to fix another; as this is a game, something that improves the fun and accessibility of the game is technically needed.

At the same time, the point isn’t really what’s needed, but what’s worth having. Yes, some people post ideas claiming a “need” for the new feature, which would justify a response that it is not needed; at other times, however, “not needed” is closer to what we discussed earlier – it doesn’t actually provide any sort of benefit, which makes it a useless addition, and is therefore the definition of “not needed.”

What it all comes down to is cost vs. benefit. There is a cost to adding features; it takes up time from the developers, and will incite a reaction – whether positive or negative – from the players. In the first sense, think about the fact that there are some requests that arguably have a greater weight to them. More people want to see a database than they want to see a change to the trade formula. So, if you request a change to the trade formula, then if that comes before the database it will take time away from the more important request. This is where the phrase Yellow Brick Road comes from; some ideas are not necessarily bad, but are simply unimportant.

For the second one, think about the reaction to the 3D images. There was a lot of anger that the devs wasted time with a useless feature. Or, take the upgraded badges. Those were arguably X for the sake of X, and people responded quite negatively to them. Does this mean that the upgraded badges were bad? Not necessarily, but it does mean that requesting them probably wouldn’t go over too well.

Closing Thoughts

At the end of the day, it really does just come down to what other benefits your idea provides. If you can’t defend a genuine reason to add something, don’t bother requesting it. You also need to look at your idea critically; if it’s something that everyone will wind up getting, and which isn’t unique (for example, a flat boost to power), then it’s an addition for the sake of an addition. You might have a good argument, such as the claim that it will help certain players, but upon taking it to its logical conclusion you might realize it’s worthless. That’s something that you need to do before posting. Remember, it’s encouraged to PM the older FR veterans to run an idea past them before posting. We don’t mind telling in private any concerns that we have with your idea, and it will save you from getting your thread locked, and potentially from getting a yellow.