All posts by CCP Greyscale

Principles of Industry in EVE Online

This is not a feature blog, but rather a view of the bigger picture, of what we're up to and what you can expect out of it.

Coming into this industry work, we had two main goals. Firstly, industry should be easy to understand. Once you've decided what you want to do, it should be obvious how you do it. The UI should be easier for you to read and easier for you to use, and it should be simple for you to understand the consequences of your actions. If you want to do an invention job, for example, you select a blueprint, see what materials you need, what skills are affecting the outcomes, and what your chances of success are, and then just click the "OK, invent me this" button so you can get on with your next job. The math is simpler, the factors affecting each job are clear and consistently presented, and every click represents an actual decision to be made.

Secondly, industry should be interesting and skillful. You should feel that *you* are "good at industry", rather than just that your character is. You're good at industry because you make good decisions, you outsmart your competitors, you've invested in the right places and you're ahead of the market. You invest in the long term, and those investments pay off, and you stay involved because there's always something new to do, some new market to conquer, some new tricks to learn, some new process to master.

EVE industry generally treads a different path to comparable professions in other games. You're not crafting that one perfect weapon, trying to work out the perfect ratios of rare ingredients, because you're not a master craftsman, you're a master industrialist, and you work at /scale/. And in the new system, that's where your challenges will be: how to scale up, how to spread out, where to settle and when to move.

Your sums will drift over time, as the activities of other players around you affect your costs and your outputs, and you'll have to figure out who to team up with and who to compete against. Maybe you'll find a quiet backwater system and hire mercenaries to keep others out and your costs down. Maybe you'll cut a deal with some fledgling nullsec group, trading arms for facility access. Or maybe you'll pick a high-value system and form a local industrial cartel to control the system and outbid those heathens in Jita for the best manufacturing teams. And you'll always be asking "am I working in the right place?", but the answer will only rarely be "no, I should move" - because industry works on a slower cycle, and because in teams and player interactions you have the tools to change the answer if you don't like it.

This is the world we're trying to create, the industry that New Eden deserves: one where you're in charge, where you're facing a new challenge every day, and where you have all the freedom in the world to decide how to solve it.

Crius will be the first step in this process that you'll experience, laying the groundwork for future development. You'll see further improvements to invention and reverse engineering in follow-up releases, along with tweaks and enhancements to the Crius release, and possibly a few extra surprises - all aligned around giving you more control and more options, making the work easier and the decisions harder.

This blog is a bit of an experiment, to see if this kind of blog is a useful addition to our usual feature-heavy ones. If it goes down well, we’ll probably do more, and if you think there are ways we can do it better, please let us know in the comments and we’ll tune future iterations accordingly!

Build safe,
-Greyscale

 

 

New to EVE? Start your 14-day free trial today.
Returning pilot? Visit Account Management for the latest offers and promotions.

The Price of Change

Greetings space pharaohs,

Let's talk about job pricing!

Older blogs in this series can be found in the archive: Reprocess all the things! - Building better Worlds - Industry UI - Researching, the Future

 

Currently, the amount you usually pay for installing a manufacturing or research job in EVE Online is on the order of tens of thousands of ISK, which is such a small cost that it's not really relevant to most build decisions. This has never been entirely ideal, but a couple of upcoming developments in Industry coming in the summer release mean that more "decision-relevant" job costs are an important piece of the puzzle.

  • First, the imminently arriving “Work Teams” (stay tuned for a later blog) will give people a strong reason to want to do their work in particularly well-staffed systems.
  • Second, the removal of slots (as discussed in CCP Ytterbium's earlier blog) means there's no hard limit on how much work can be done in a given system.

The first is intended to act as a "pull," giving people a reason to come together and build in the same space, and the second allows players to do so in a more organic way. Counteracting this will be pricing that rises in line with activity, acting as a "push" to incentivize people to spread out. Carefully balancing these two forces gives industrial players another decision to make, and having the values be both continuous and varying over time (on the scale of weeks and months) creates a decision that 1) has an interesting range of options; and 2) has the potential to change over time. This, we hope, will -- in conjunction with rounding off a lot of the rough edges and making the mechanical work easier -- move industry from a play-style dominated by clicking to one driven by smart, long-term decision-making.

Two things I want to clarify before diving into the rest of the blog:

First, we're hoping to broadly maintain the current balance of manufacturing between hisec, lowsec, nullsec and w-space with these changes, purely because it reduces the risk of the changes as a whole. We're hopeful that the summer release will make manufacturing in nullsec more viable, but we're not attempting to comprehensively address nullsec industry in this expansion as it needs to be done as part of a wider consideration of the nullsec ecosystem.

Second, to be totally clear, all the pricing modifiers being discussed here are modifiers to the installation cost of a job. With the exception of outpost manufacturing upgrades, nothing in this blog is offering a material cost reduction. So, when you see "0.5x cost modifier", please keep in mind that that's modifying the installation cost, which is typically 1% to 5% of the material cost.

 

Base pricing

OK, let's get into the meat.

We aimed to create a pricing system that responded to player activity by raising or lowering prices, but in a way that didn't require us to decide on a fixed relationship between activity and price. A fixed relationship would not be future-proof, and also would likely make no sense on the Serenity server (the Chinese mirror server to Tranquility), which has a different population dynamic. We experimented with faking a market, with the server acting as the seller, but while functional that approach ended up being bad gameplay (prices would rise in a system until a significant number of players moved elsewhere, which is pretty rubbish).

What we're doing instead is setting the base price for a job based on two factors: the cost of the job output, and what fraction of the universe's total job-hours are being done in a given system. These are framed as workforce cost, i.e. the cost of hiring the skilled workers needed to run the facilities in question. The workforce is pretty footloose, being able to work anywhere in the system, and the more demand there is for their services the more they will generally charge for it. This applies the same everywhere, including wormholes. Even on the unknown edges of space, building stuff still requires people to run the machines.

Thus, the very basic pricing math is:

Let's break that down some.

Run cost is calculated per activity type (manufacturing, copying, Material Efficiency research, etc.), per system. That is, at a given time, the base cost for a given run will be the same everywhere in a given system. Multi-run jobs will obviously cost some multiple of this.

Price of output is based on the system used for calculating values in killmails, which is also used to manage bounty and Factional Warfare (FW) kill payouts. We're very aware of the risk of price manipulation, but we're pretty confident this system is robust in this regard. The one deviation we're making is that, just for the purposes of pricing jobs, blueprints are assumed to be worth 2% of the value of whatever they build, so research jobs don't end up being outrageously expensive.

To give an example, let's take an Abaddon, and let's say for the sake of easier math that it has a calculated value of 200 million ISK.

Fraction of global job hours is calculated as a moving average over the past 28 days, so it will be substantially “non-swingy”. We're taking its square root to create a bigger spread between more and less active systems. It should also be noted that, again, this is per job type, so we're comparing (for example) the number of copy-hours in this system over the last 28 days to the number of global copy-hours over the last 28 days.

For manufacturing, we took a snapshot a while back and the highest system had a fraction of 0.0253 (i.e., 2.5%), or 0.15 after you square-root it, and a more typical square-root value for a semi-busy system would be around 0.05, giving our Abaddon a base job cost of 10 million ISK. If you spread the hisec manufacturing load (~85% of total job hours in the snapshot) even across the whole of hisec, you end up with base job cost of 2%, or 4 million ISK.

 

Pricing modifiers

There are then a number of things that can affect pricing.

Team costs: choosing to hire a specialized team will come with a cost. This will be explained in the upcoming Teams blog, but for now all you need to know is it's a multiplier, and it's one of the two modifiers that can make a given price larger independent of system activity.

For now we'll not use a team with our Abaddon, so the cost is still 10 million ISK.

System facilities: stations in a given system make a job cheaper. We want to ensure that the landscape is lumpy rather than flat, and it makes sense that systems with more stations (and more factory or research stations in particular) are better places to do specialized work. Every station in a system has two facility multipliers -- one for manufacturing and one for research -- and the system's various multipliers are all multiplied together and then multiplied with the price. (We do a lot of multiplication with pricing, and we therefore wield large calculators)

For NPC stations, these multipliers range between 0.95 and 0.98, based on how well the station's activity (factory, testing facility, warehouse etc) is judged to be suited to building and/or researching things. Stations can have different ratings for manufacturing and research. These are not huge numbers, but because they multiply together they can have a big effect. In manufacturing, the current record-holder in empire space is Nonni, with a multiplier of around 0.48 - building things in Nonni will, all other things being equal, halve the cost of installing a job.

For conquerables and outposts, we wanted to keep things pretty competitive despite being limited to one per system, so their multipliers range between 0.5 (manufacturing in an Amarr outpost or researching in a Caldari one) and 0.8 (all jobs in a Refining conquerable).

A couple of things should be noted here. First, these bonuses apply system-wide, including to jobs installed in starbases. Second, keep in mind that this is still a smallish percentage of the total build cost -- it's not a 50% reduction in build cost, it's a 50% reduction in job installation costs which are typically (well) below 10% of build cost.

Let's put our build in a mid-range system, with a multiplier of 0.75. Our build cost is now 7.5 million ISK.

Some kind of starbase bonus: we're hoping to add a bonus for having multiple starbase structures at the same time, so removing slots doesn't just mean you only ever need one lab on your hisec research tower. We're still determining exactly whether or how we can get this into the initial release without causing performance issues. Wish us luck!

We're not using a starbase in this example, so we're still at 7.5 million ISK.

Multi-run discount: makes each subsequent run of a given job cost a little less than the last, mainly to give another small thing that industrialists can optimize for once they've got the basics under control. For each run, the job cost is multiplied by 0.99 raised to the power of however many hours (or fractions thereof) the job will already have run at that point. This is calculated at installation time and therefore the job doesn't actually change price over time. Rather, we do the math up front. We're looking to cap the maximum bonus of this using the old Material Efficiency skill, which will no longer be affecting waste (see previous blog).

Let's build five at once. With a build time of 4 hours, our average cost per run drops to 6.93m.

Outposts and FW upgrades: These are both places where, previously, you could get more slots. With slots gone and pricing serving a similar purpose, we're transitioning these bonuses mostly into pricing bonuses.

For each level of FW upgrade in a system, you'll get an additional 0.9x multiplier to job prices for manufacturing and industry, so level 5 gives a 0.59049x multiplier on top of everything else.

For each previously-slot-improving outpost research upgrade, you'll similarly get a 0.9x multiplier to research job prices.

For each previously slot-improving manufacturing-related Outpost Improvement, you'll get a 1% bonus to ME instead (we can do that now). This is different because the manufacturing slot upgrades in particular are pretty substantial right now, and installation costs are assumed to be a sufficiently small fraction of final item costs in nullsec that a cost multiplier here seemed underwhelming. We're still looking at the exact bonus here, and the relationship between Amarr and Minmatar outposts in particular, so this may change before it's released.

We're building our Abaddon in hisec, so this doesn't matter to us.

Taxes: NPC-owned facilities will levy a 10% tax on top of everything else. This will be at least absent in player-owned facilities, and if we have time, we will allow players to set whatever arbitrary tax rate they like on their own facilities, the proceeds of which (the tax specifically, that is) will go directly into their own (or their corporation's in most cases) coffers.

Finally, we're in an NPC station, so our build cost goes up 10%, to 7.62 million ISK per Abaddon.

 

This means the full formula is:

 

There's a fair number of terms there, but they'll rarely all apply at once, and the actual math is very straightforward.

And here’s a mockup of how we’re presenting this in-client:

Please note:

  • The “1% value” is a benchmark we’re using in the UI so we can show activity variation as a +/- percentage, it has no functional power.
  • All numbers are placeholders that I made up months ago. This was just created to show how we would lay out this tooltip, they may not be even ballpark-accurate in some cases!

 

Wrap-up and examples

And that's really it. There are a fair number of potential variables, to be sure, but they won't usually all apply at once, and they all just multiply together to get the final number. We think this meets our balance goals, introduces some interesting decisions for players to grapple with, and results in prices that are relevant without being overpowering.

On that note, let's look at some examples.

Manufacturing: The largest run price we generated from the snapshot we took was 15% of build cost in Saisio. 10th place is Juunigaishi at 8%, while 50th is Kakakela at 5%. Jita is in 106th place, at 4%. The highest lowsec system is <redacted> at 53rd and 5%, and the highest nullsec system is <redacted> at 147th place and 4%.

Copying: Max is 14% in Vuorrassi, 10th is 9%, 50th is 6%, and we drop below 5% at 95th.

TE: The same numbers are 13% in Nomaa, 9%, 6%, 90th.

ME: 10% in Abudban, 7%, 5%, 79th.

Invention: 12% in Nomaa, 9%, 7%, 119th.

Reverse Engineering: 35%(!) in Droselory, 17%, 6%, and there are sufficiently few systems doing reverse engineering when the snapshot was taken that the bottom one is still above 5% of output value.

If you've got feedback, comments, suggestions etc, please post in the comments -- we're expecting to continue tuning this all the way to release, so there's plenty of time for adjustments.

-CCP Greyscale, on behalf of Team Super Friends

The Price of Change

Greetings space pharaohs,

Let's talk about job pricing!

Older blogs in this series can be found in the archive: Reprocess all the things! - Building better Worlds - Industry UI - Researching, the Future

 

Currently, the amount you usually pay for installing a manufacturing or research job in EVE Online is on the order of tens of thousands of ISK, which is such a small cost that it's not really relevant to most build decisions. This has never been entirely ideal, but a couple of upcoming developments in Industry coming in the summer release mean that more "decision-relevant" job costs are an important piece of the puzzle.

  • First, the imminently arriving “Work Teams” (stay tuned for a later blog) will give people a strong reason to want to do their work in particularly well-staffed systems.
  • Second, the removal of slots (as discussed in CCP Ytterbium's earlier blog) means there's no hard limit on how much work can be done in a given system.

The first is intended to act as a "pull," giving people a reason to come together and build in the same space, and the second allows players to do so in a more organic way. Counteracting this will be pricing that rises in line with activity, acting as a "push" to incentivize people to spread out. Carefully balancing these two forces gives industrial players another decision to make, and having the values be both continuous and varying over time (on the scale of weeks and months) creates a decision that 1) has an interesting range of options; and 2) has the potential to change over time. This, we hope, will -- in conjunction with rounding off a lot of the rough edges and making the mechanical work easier -- move industry from a play-style dominated by clicking to one driven by smart, long-term decision-making.

Two things I want to clarify before diving into the rest of the blog:

First, we're hoping to broadly maintain the current balance of manufacturing between hisec, lowsec, nullsec and w-space with these changes, purely because it reduces the risk of the changes as a whole. We're hopeful that the summer release will make manufacturing in nullsec more viable, but we're not attempting to comprehensively address nullsec industry in this expansion as it needs to be done as part of a wider consideration of the nullsec ecosystem.

Second, to be totally clear, all the pricing modifiers being discussed here are modifiers to the installation cost of a job. With the exception of outpost manufacturing upgrades, nothing in this blog is offering a material cost reduction. So, when you see "0.5x cost modifier", please keep in mind that that's modifying the installation cost, which is typically 1% to 5% of the material cost.

 

Base pricing

OK, let's get into the meat.

We aimed to create a pricing system that responded to player activity by raising or lowering prices, but in a way that didn't require us to decide on a fixed relationship between activity and price. A fixed relationship would not be future-proof, and also would likely make no sense on the Serenity server (the Chinese mirror server to Tranquility), which has a different population dynamic. We experimented with faking a market, with the server acting as the seller, but while functional that approach ended up being bad gameplay (prices would rise in a system until a significant number of players moved elsewhere, which is pretty rubbish).

What we're doing instead is setting the base price for a job based on two factors: the cost of the job output, and what fraction of the universe's total job-hours are being done in a given system. These are framed as workforce cost, i.e. the cost of hiring the skilled workers needed to run the facilities in question. The workforce is pretty footloose, being able to work anywhere in the system, and the more demand there is for their services the more they will generally charge for it. This applies the same everywhere, including wormholes. Even on the unknown edges of space, building stuff still requires people to run the machines.

Thus, the very basic pricing math is:

Let's break that down some.

Run cost is calculated per activity type (manufacturing, copying, Material Efficiency research, etc.), per system. That is, at a given time, the base cost for a given run will be the same everywhere in a given system. Multi-run jobs will obviously cost some multiple of this.

Price of output is based on the system used for calculating values in killmails, which is also used to manage bounty and Factional Warfare (FW) kill payouts. We're very aware of the risk of price manipulation, but we're pretty confident this system is robust in this regard. The one deviation we're making is that, just for the purposes of pricing jobs, blueprints are assumed to be worth 2% of the value of whatever they build, so research jobs don't end up being outrageously expensive.

To give an example, let's take an Abaddon, and let's say for the sake of easier math that it has a calculated value of 200 million ISK.

Fraction of global job hours is calculated as a moving average over the past 28 days, so it will be substantially “non-swingy”. We're taking its square root to create a bigger spread between more and less active systems. It should also be noted that, again, this is per job type, so we're comparing (for example) the number of copy-hours in this system over the last 28 days to the number of global copy-hours over the last 28 days.

For manufacturing, we took a snapshot a while back and the highest system had a fraction of 0.0253 (i.e., 2.5%), or 0.15 after you square-root it, and a more typical square-root value for a semi-busy system would be around 0.05, giving our Abaddon a base job cost of 10 million ISK. If you spread the hisec manufacturing load (~85% of total job hours in the snapshot) even across the whole of hisec, you end up with base job cost of 2%, or 4 million ISK.

 

Pricing modifiers

There are then a number of things that can affect pricing.

Team costs: choosing to hire a specialized team will come with a cost. This will be explained in the upcoming Teams blog, but for now all you need to know is it's a multiplier, and it's one of the two modifiers that can make a given price larger independent of system activity.

For now we'll not use a team with our Abaddon, so the cost is still 10 million ISK.

System facilities: stations in a given system make a job cheaper. We want to ensure that the landscape is lumpy rather than flat, and it makes sense that systems with more stations (and more factory or research stations in particular) are better places to do specialized work. Every station in a system has two facility multipliers -- one for manufacturing and one for research -- and the system's various multipliers are all multiplied together and then multiplied with the price. (We do a lot of multiplication with pricing, and we therefore wield large calculators)

For NPC stations, these multipliers range between 0.95 and 0.98, based on how well the station's activity (factory, testing facility, warehouse etc) is judged to be suited to building and/or researching things. Stations can have different ratings for manufacturing and research. These are not huge numbers, but because they multiply together they can have a big effect. In manufacturing, the current record-holder in empire space is Nonni, with a multiplier of around 0.48 - building things in Nonni will, all other things being equal, halve the cost of installing a job.

For conquerables and outposts, we wanted to keep things pretty competitive despite being limited to one per system, so their multipliers range between 0.5 (manufacturing in an Amarr outpost or researching in a Caldari one) and 0.8 (all jobs in a Refining conquerable).

A couple of things should be noted here. First, these bonuses apply system-wide, including to jobs installed in starbases. Second, keep in mind that this is still a smallish percentage of the total build cost -- it's not a 50% reduction in build cost, it's a 50% reduction in job installation costs which are typically (well) below 10% of build cost.

Let's put our build in a mid-range system, with a multiplier of 0.75. Our build cost is now 7.5 million ISK.

Some kind of starbase bonus: we're hoping to add a bonus for having multiple starbase structures at the same time, so removing slots doesn't just mean you only ever need one lab on your hisec research tower. We're still determining exactly whether or how we can get this into the initial release without causing performance issues. Wish us luck!

We're not using a starbase in this example, so we're still at 7.5 million ISK.

Multi-run discount: makes each subsequent run of a given job cost a little less than the last, mainly to give another small thing that industrialists can optimize for once they've got the basics under control. For each run, the job cost is multiplied by 0.99 raised to the power of however many hours (or fractions thereof) the job will already have run at that point. This is calculated at installation time and therefore the job doesn't actually change price over time. Rather, we do the math up front. We're looking to cap the maximum bonus of this using the old Material Efficiency skill, which will no longer be affecting waste (see previous blog).

Let's build five at once. With a build time of 4 hours, our average cost per run drops to 6.93m.

Outposts and FW upgrades: These are both places where, previously, you could get more slots. With slots gone and pricing serving a similar purpose, we're transitioning these bonuses mostly into pricing bonuses.

For each level of FW upgrade in a system, you'll get an additional 0.9x multiplier to job prices for manufacturing and industry, so level 5 gives a 0.59049x multiplier on top of everything else.

For each previously-slot-improving outpost research upgrade, you'll similarly get a 0.9x multiplier to research job prices.

For each previously slot-improving manufacturing-related Outpost Improvement, you'll get a 1% bonus to ME instead (we can do that now). This is different because the manufacturing slot upgrades in particular are pretty substantial right now, and installation costs are assumed to be a sufficiently small fraction of final item costs in nullsec that a cost multiplier here seemed underwhelming. We're still looking at the exact bonus here, and the relationship between Amarr and Minmatar outposts in particular, so this may change before it's released.

We're building our Abaddon in hisec, so this doesn't matter to us.

Taxes: NPC-owned facilities will levy a 10% tax on top of everything else. This will be at least absent in player-owned facilities, and if we have time, we will allow players to set whatever arbitrary tax rate they like on their own facilities, the proceeds of which (the tax specifically, that is) will go directly into their own (or their corporation's in most cases) coffers.

Finally, we're in an NPC station, so our build cost goes up 10%, to 7.62 million ISK per Abaddon.

 

This means the full formula is:

 

There's a fair number of terms there, but they'll rarely all apply at once, and the actual math is very straightforward.

And here’s a mockup of how we’re presenting this in-client:

Please note:

  • The “1% value” is a benchmark we’re using in the UI so we can show activity variation as a +/- percentage, it has no functional power.
  • All numbers are placeholders that I made up months ago. This was just created to show how we would lay out this tooltip, they may not be even ballpark-accurate in some cases!

 

Wrap-up and examples

And that's really it. There are a fair number of potential variables, to be sure, but they won't usually all apply at once, and they all just multiply together to get the final number. We think this meets our balance goals, introduces some interesting decisions for players to grapple with, and results in prices that are relevant without being overpowering.

On that note, let's look at some examples.

Manufacturing: The largest run price we generated from the snapshot we took was 15% of build cost in Saisio. 10th place is Juunigaishi at 8%, while 50th is Kakakela at 5%. Jita is in 106th place, at 4%. The highest lowsec system is <redacted> at 53rd and 5%, and the highest nullsec system is <redacted> at 147th place and 4%.

Copying: Max is 14% in Vuorrassi, 10th is 9%, 50th is 6%, and we drop below 5% at 95th.

TE: The same numbers are 13% in Nomaa, 9%, 6%, 90th.

ME: 10% in Abudban, 7%, 5%, 79th.

Invention: 12% in Nomaa, 9%, 7%, 119th.

Reverse Engineering: 35%(!) in Droselory, 17%, 6%, and there are sufficiently few systems doing reverse engineering when the snapshot was taken that the bottom one is still above 5% of output value.

If you've got feedback, comments, suggestions etc, please post in the comments -- we're expecting to continue tuning this all the way to release, so there's plenty of time for adjustments.

-CCP Greyscale, on behalf of Team Super Friends

Researching, the Future

Greetings space-labrats,

Let's talk about research!

Older blogs in this series can be found in the archive.

There's two major changes we're making to research: Copying is going to become way shorter, and we're changing how Manufacturing Efficiency (ME) and Production Efficiency (PE) work.

Copying

The headline here is that, during EVE’s summer 2014 release, we're going to change base copy-time on all blueprints to be the same as base build-time. With Industry giving a maximum 20% reduction in build times, and Science giving a maximum 25% reduction in copy times, this ends up meaning that (with maxed skills) copying takes 6.25% less time than manufacturing from a given blueprint.

The primary reason for this is to try and unify T1, T2 and T3 manufacturing around being dominated by build-from-copy rather than build-from-original. This gives a more unified experience and allows us to make more liberal assumptions about how much risk people are prepared to make with their build jobs. To give a concrete example, this makes us much more comfortable about removing the ability to build from a starbase using a blueprint in a station - when you're only risking the copy, this is a much smaller concern than when you're risking a BPO.

For comparison, currently the trend is that T1 blueprints take 20x longer to copy than to build, and T2 blueprints (for those lucky few BPO owners) take 100x longer to copy than to build.

Speaking of T2, this change is obviously very relevant to invention. We've had a good look at the numbers here and are currently of the opinion that this ends up being much less significant than it at first looks. The majority of invention work currently seems to be of the invent-to-build variety rather than invent-to-sell-blueprint, and on a character with the same number of possible research and manufacturing jobs, the bottleneck is pretty much always in the build time rather than the copy or invention time -- and frequently there's a further bottleneck in that invention anyway takes longer than copying. Unless this leads to a major expansion of invent-to-sell, the actual throughput of invention should not significantly change as a result of shorter copy times.

 

ME and PE

First of all, we're changing the name of PE (Production Efficiency) to TE (Time Efficiency), on the grounds that it's then much clearer what it actually does. ME is now called ME (Material Efficiency) everywhere, rather than sometimes being "Material Level" instead.

The major change underpinning most of the work done here is to move blueprint research to a more skill-training-like system, with a fixed number of researchable levels with identical bonuses but increasing research time.

The current system is interesting and flexible but also pretty unintuitive and with some core accessibility issues. Right now every level of ME or TE for a given blueprint takes the same amount of time to research, but gives fairly sharply diminishing returns: The first level is worth 50% of the total available bonus, the second level takes you to 66%, the third 75% and so on, so that by level 9 you already have 90% of the total available bonus. You can then go off and research into infinity to close off as much of that last 10% as you can stomach; in reality you reach "perfect" at the point where the potential savings round to zero, but this is a seven-digit number for battleships.

The major reason for changing this system is that the current relationship between ME/TE level and actual savings is difficult to understand without wrapping your head around some reasonably non-trivial math, which adds fairly substantially to the mental barrier of entry for industry and generally makes the system more opaque than it really needs to be.

 

No more waste

We are removing the concept of "wastage" from the system. With the reprocessing changes we no longer need to be quite so careful about build requirements dropping below reprocessing returns (which are now 50% rather than 100% of build materials), so we're removing the current system of taking "perfect build" requirements, adding waste on top and then removing it again with ME.

In the summer release, all base build costs will be increased by 11%. ME will then reduce build costs by 10% of that new base value, which brings us back to where we started. The rest of this blog is working from that new, higher base.

Production time already uses this dynamic, so no changes are needed there.

The Material Efficiency skill will be repurposed, stay tuned for more information on that in a future blog.

(The reason we’re going up by 11% is that we’re multiplying the new base by 0.9, so we want to divide the old base by 0.9 so the two cancel out. 1/0.9 = 1.1 recurring, so the actual multiplier we use will be 11.111111…%.)

 

The new system

Blueprint research will then be moved to a ten-step system. Each step of ME research will reduce material requirements on that blueprint by 1%, and each step of TE research will reduce manufacturing time on that blueprint by 2%. These values will be displayed as their actual percentages, rather than their step numbers, so a blueprint that has been researched six times in each will show as ME 6% and TE 12%.

Research times will follow essentially the same curve as skills, with the additional five steps interpolated between the existing skill steps, and blueprint "ranks" multiplying the research times for more advanced blueprints.

For a "rank 1" blueprint, such as T1 ammo, the unmodified research times will look like this:

Level Seconds Approx Total
1 105 1m 45s
2 250 4m
3 595 10m
4 1414 24m
5 3360 56m
6 8000 2h
7 19000 5h
8 45255 12h
9 107700 1d
10 256000 3d

Skills and other bonuses will then reduce times as they do currently.

Negative ME and TE levels work pretty much as you'd expect in this sort of system, being converted into direct percentage values. TE -4 will thus now be shown as TE -100%, and all the various decryptors (and related code) will be updated to match.

This gives us a pretty clear system that is easy to wrap your head around, works for pretty much everything, and provides a point at which blueprint research is "done" for a given blueprint and needs no further work.

 

Details

What we're doing with non-standard blueprints

We would like to unify everything around a clear, consistent set of numbers, which means rooting out and eliminating as many of the anomalies as possible. This will for example mean moving Warfare Links to the same ME 10%/TE 20% system as everything else, removing the weird outsized TE bonus on fuel blocks (I'm pretty sure that's my fault and I'm pretty sure I did it by accident), and generally eliminating most of the other quirks, except where the blueprint or product is sufficiently unique anyway that it's justifiable to keep its oddball status.

How we're selecting ranks

T1 ammo will be the Rank 1 baseline. These blueprints all currently have a base research time of 6,000 seconds (i.e., 1h 40m). To determine ranks of other blueprints, the current plan is to simply divide their research times by 6,000, maintaining the research ratios currently present. This means T1 modules are generally rank 2, T1 frigates/cruisers/battleships are 20/40/60, and the highest current rank is Titans at 3414 (good luck maxing that out!). This is pretty easy to further adjust, and we may for example want to pull ships up or down a little.

How we're going to turn old blueprints into new blueprints

Obviously we need some way to remap old blueprint research values into new values, and equally obviously we're not just going to turn an ME 120 blueprint into an ME 120% blueprint.

Our current line of thinking is to do the math such that no currently researched blueprint gets any worse in terms of the bonus it provides (weird anomalies like fuel blocks getting a general TE nerf notwithstanding).

This would mean that ME/TE 1 become ME 5%/TE 10%, ME/TE 5-9 become ME 9%/TE 18%, and anything over ME/TE 10 currently move to ME 10%/TE 20%.

This has the advantage of everyone's blueprints staying the same or getting better, but the drawback that people with blueprints researched to really high levels will find that, while their blueprints are still generally getting better (i.e., will be actually perfect rather than just a reasonable approximation thereof), other blueprints which were less-well researched will have caught up with them.

We're very aware that some of you will feel that you've lost your previous advantages gained by researching blueprints for a really long time, and this is one of the areas we're preparing to focus the most on in terms of receiving feedback and making adjustments or additions to smooth the transition. Everything is on the table in terms of finding a reasonable solution that meets everyone's legitimate concerns, so please approach the feedback in terms of telling us what you'd like to see rather than simply expressing frustration with the changes as described here. We're not done with this yet!

For transitioning negative ME blueprints, we're just multiplying by 10, while for negative TE we're subtracting 1 and multiplying by 20, which keeps both values roughly the same before and after for the reasons outlined above.

 

Wrap-up

That covers pretty much all the changes to research. The functioning of the system is pretty solidified design-wise, but all the numbers are very easy to adjust. We're anticipating making further balance changes in response to feedback, so, please let us know in the comments if there's anything here you see as especially problematic -- and why -- and we'll try and address as many concerns as possible!

Cheers,

-CCP Greyscale, on behalf of Team Super Friends

Researching, the Future

Greetings space-labrats,

Let's talk about research!

Older blogs in this series can be found in the archive.

There's two major changes we're making to research: Copying is going to become way shorter, and we're changing how Manufacturing Efficiency (ME) and Production Efficiency (PE) work.

Copying

The headline here is that, during EVE’s summer 2014 release, we're going to change base copy-time on all blueprints to be the same as base build-time. With Industry giving a maximum 20% reduction in build times, and Science giving a maximum 25% reduction in copy times, this ends up meaning that (with maxed skills) copying takes 6.25% less time than manufacturing from a given blueprint.

The primary reason for this is to try and unify T1, T2 and T3 manufacturing around being dominated by build-from-copy rather than build-from-original. This gives a more unified experience and allows us to make more liberal assumptions about how much risk people are prepared to make with their build jobs. To give a concrete example, this makes us much more comfortable about removing the ability to build from a starbase using a blueprint in a station - when you're only risking the copy, this is a much smaller concern than when you're risking a BPO.

For comparison, currently the trend is that T1 blueprints take 20x longer to copy than to build, and T2 blueprints (for those lucky few BPO owners) take 100x longer to copy than to build.

Speaking of T2, this change is obviously very relevant to invention. We've had a good look at the numbers here and are currently of the opinion that this ends up being much less significant than it at first looks. The majority of invention work currently seems to be of the invent-to-build variety rather than invent-to-sell-blueprint, and on a character with the same number of possible research and manufacturing jobs, the bottleneck is pretty much always in the build time rather than the copy or invention time -- and frequently there's a further bottleneck in that invention anyway takes longer than copying. Unless this leads to a major expansion of invent-to-sell, the actual throughput of invention should not significantly change as a result of shorter copy times.

 

ME and PE

First of all, we're changing the name of PE (Production Efficiency) to TE (Time Efficiency), on the grounds that it's then much clearer what it actually does. ME is now called ME (Material Efficiency) everywhere, rather than sometimes being "Material Level" instead.

The major change underpinning most of the work done here is to move blueprint research to a more skill-training-like system, with a fixed number of researchable levels with identical bonuses but increasing research time.

The current system is interesting and flexible but also pretty unintuitive and with some core accessibility issues. Right now every level of ME or TE for a given blueprint takes the same amount of time to research, but gives fairly sharply diminishing returns: The first level is worth 50% of the total available bonus, the second level takes you to 66%, the third 75% and so on, so that by level 9 you already have 90% of the total available bonus. You can then go off and research into infinity to close off as much of that last 10% as you can stomach; in reality you reach "perfect" at the point where the potential savings round to zero, but this is a seven-digit number for battleships.

The major reason for changing this system is that the current relationship between ME/TE level and actual savings is difficult to understand without wrapping your head around some reasonably non-trivial math, which adds fairly substantially to the mental barrier of entry for industry and generally makes the system more opaque than it really needs to be.

 

No more waste

We are removing the concept of "wastage" from the system. With the reprocessing changes we no longer need to be quite so careful about build requirements dropping below reprocessing returns (which are now 50% rather than 100% of build materials), so we're removing the current system of taking "perfect build" requirements, adding waste on top and then removing it again with ME.

In the summer release, all base build costs will be increased by 11%. ME will then reduce build costs by 10% of that new base value, which brings us back to where we started. The rest of this blog is working from that new, higher base.

Production time already uses this dynamic, so no changes are needed there.

The Material Efficiency skill will be repurposed, stay tuned for more information on that in a future blog.

(The reason we’re going up by 11% is that we’re multiplying the new base by 0.9, so we want to divide the old base by 0.9 so the two cancel out. 1/0.9 = 1.1 recurring, so the actual multiplier we use will be 11.111111…%.)

 

The new system

Blueprint research will then be moved to a ten-step system. Each step of ME research will reduce material requirements on that blueprint by 1%, and each step of TE research will reduce manufacturing time on that blueprint by 2%. These values will be displayed as their actual percentages, rather than their step numbers, so a blueprint that has been researched six times in each will show as ME 6% and TE 12%.

Research times will follow essentially the same curve as skills, with the additional five steps interpolated between the existing skill steps, and blueprint "ranks" multiplying the research times for more advanced blueprints.

For a "rank 1" blueprint, such as T1 ammo, the unmodified research times will look like this:

Level Seconds Approx Total
1 105 1m 45s
2 250 4m
3 595 10m
4 1414 24m
5 3360 56m
6 8000 2h
7 19000 5h
8 45255 12h
9 107700 1d
10 256000 3d

Skills and other bonuses will then reduce times as they do currently.

Negative ME and TE levels work pretty much as you'd expect in this sort of system, being converted into direct percentage values. TE -4 will thus now be shown as TE -100%, and all the various decryptors (and related code) will be updated to match.

This gives us a pretty clear system that is easy to wrap your head around, works for pretty much everything, and provides a point at which blueprint research is "done" for a given blueprint and needs no further work.

 

Details

What we're doing with non-standard blueprints

We would like to unify everything around a clear, consistent set of numbers, which means rooting out and eliminating as many of the anomalies as possible. This will for example mean moving Warfare Links to the same ME 10%/TE 20% system as everything else, removing the weird outsized TE bonus on fuel blocks (I'm pretty sure that's my fault and I'm pretty sure I did it by accident), and generally eliminating most of the other quirks, except where the blueprint or product is sufficiently unique anyway that it's justifiable to keep its oddball status.

How we're selecting ranks

T1 ammo will be the Rank 1 baseline. These blueprints all currently have a base research time of 6,000 seconds (i.e., 1h 40m). To determine ranks of other blueprints, the current plan is to simply divide their research times by 6,000, maintaining the research ratios currently present. This means T1 modules are generally rank 2, T1 frigates/cruisers/battleships are 20/40/60, and the highest current rank is Titans at 3414 (good luck maxing that out!). This is pretty easy to further adjust, and we may for example want to pull ships up or down a little.

How we're going to turn old blueprints into new blueprints

Obviously we need some way to remap old blueprint research values into new values, and equally obviously we're not just going to turn an ME 120 blueprint into an ME 120% blueprint.

Our current line of thinking is to do the math such that no currently researched blueprint gets any worse in terms of the bonus it provides (weird anomalies like fuel blocks getting a general TE nerf notwithstanding).

This would mean that ME/TE 1 become ME 5%/TE 10%, ME/TE 5-9 become ME 9%/TE 18%, and anything over ME/TE 10 currently move to ME 10%/TE 20%.

This has the advantage of everyone's blueprints staying the same or getting better, but the drawback that people with blueprints researched to really high levels will find that, while their blueprints are still generally getting better (i.e., will be actually perfect rather than just a reasonable approximation thereof), other blueprints which were less-well researched will have caught up with them.

We're very aware that some of you will feel that you've lost your previous advantages gained by researching blueprints for a really long time, and this is one of the areas we're preparing to focus the most on in terms of receiving feedback and making adjustments or additions to smooth the transition. Everything is on the table in terms of finding a reasonable solution that meets everyone's legitimate concerns, so please approach the feedback in terms of telling us what you'd like to see rather than simply expressing frustration with the changes as described here. We're not done with this yet!

For transitioning negative ME blueprints, we're just multiplying by 10, while for negative TE we're subtracting 1 and multiplying by 20, which keeps both values roughly the same before and after for the reasons outlined above.

 

Wrap-up

That covers pretty much all the changes to research. The functioning of the system is pretty solidified design-wise, but all the numbers are very easy to adjust. We're anticipating making further balance changes in response to feedback, so, please let us know in the comments if there's anything here you see as especially problematic -- and why -- and we'll try and address as many concerns as possible!

Cheers,

-CCP Greyscale, on behalf of Team Super Friends

Corp Hangars on ships and You

So, we're changing Corp Hangars on ships in Retribution.

Why?

 The short version is that the current technical implementation is an unnecessary maintenance burden; and we don't feel that the complexity of the design is justified by the value it delivers.

On the technical side, the same code is handling corp hangars in stations, starbases and ships. Given that ships in particular are clearly not the same thing as stations, it should not be surprising that there is a lot of horrible special-casing in the code to make this work. The end result, in this case, is a chunk of code that's broken in lots of different interesting ways; the fixes for which are generally mutually exclusive; many of which are effectively unfixable; and for which any potential changes are a QA nightmare to validate.

On the design side, the specific functionality that corp hangars are providing - allowing you to control ship access using corp roles - is overkill for the large majority of use cases; doesn't work consistently (the role checks are only applied to players from your corp); has serious issues with NPC corps; places hidden design tripwires everywhere (who owns the contents of a corp hangar - the pilot or the corporation?); and are in aggregate increasing the complexity of the game in a manner that we do not feel is justified in this case.

 What's changing?

 Corp hangars on ships will be transformed into fleet hangars:

  • The total volume will stay the same
     
  • Divisions and all reliance on corp roles is gone
     
  • Only the pilot will be able to open or remove containers in fleet hangars, although any pilot can drop items onto them to place them in the container
     
  • You will now be able to set "allow fleet usage" and "allow corp usage" independently for both fleet hangar and the ship maintenance bays (on ships only, not on starbases at this time)
     
  • These settings will now be stored per-ship on the server, so a given ship will always keep its last settings

In this image you can see the "fleet" and "corp" buttons next to the Ship Maintenance Bay and Fleet Hangar, which are used to set access permissions on each

 Additional changes related to this:

  • We're adding a range of new non-compressive containers to the "freight container" line (volumes in m3 are 1k, 5k, 10k, 50k, 250k)
     
  • All special bays on ships that are not your main cargo will now behave like your main cargo when it comes to ship scanners and loot drop chances; this includes fleet hangars, ore holds, fuel holds and so on. Specifically, they will all allow their contents to show up on scanners, and they will all have a chance to drop their contents as loot. Ship maintenance bays are somewhat special: they will be scannable (ie, ships but not their modules or cargo can show up in results), but they won't be dropping assembled ships as loot
     
  • Ship and cargo scanners will no longer randomize the stack size/number of modules they return: for any stack or module that they successfully detect, they will report the correct size/count
     
  • Blockade Runners are being updated to be immune to cargo scanners, and as such will always show up as empty on scans
     
  • Freighters will have most of their special-case restrictions removed: they will now be able to perform cargo operations in space, including moving items into and out of containers, moving things to and from containers in space, and jettisoning items
     
  • We're removing the restriction on simultaneous users for *all* ship fitting arrays, both on ships and on starbases: an unlimited number of pilots will be able to refit at a single ship or structure

 Additional changes that are largely unrelated but seemed like a good idea given that we were looking at the code anyway:

  • Starbase forcefield passwords are now stored per-character on the server, so you'll always have the most recent password you entered set until you enter a new one
     
  • The "lock/unlock" setting on audit log containers is now stored per-container on the server, rather than per-character on the client

Why are you removing divisions? They're useful!

 Yes, they are. However, we're currently of the opinion that they're not *necessary*, we don't feel that they're adding a lot of value in the most common use cases, and as such we're treating them as a case of unnecessary complexity.

 The changes to container behavior in fleet hangars, the new containers, and existing inventory features such as filters, should allow most (but not all) of the current functionality to be replicable in the new system. There will, though, be some cases in which the new system is less useful than the old system. We acknowledge this, and we understand that the changeover will be frustrating for some people, but we need to get the complexity of EVE under control and doing so is going to require functionality downgrades in certain areas. This is annoying but unavoidable.

 My Orca-hauling backbone!

Yup. The immunity of corp hangars (and other special bays) to scans and their inability to drop loot was a neat workaround, but it was also essentially unfinished functionality, rather than an intentional feature. We recognize the need for secure hauling in the current environment, hence the scan immunity on blockade runners, but feel that the way it's being provided currently is unintuitive and clunky, 
and that the "safe hauling" capacity on Orcas is unnecessarily large. Blockade runners should pick up the slack on high-value, low-volume items, while for higher-volume shipments, we're leaving it up to players to figure out how to handle the new situation.

 (We're not making any changes to plastic wrap right now, but it has significant technical issues which will likely see it being reworked at some point down the line.)

 

 

New to EVE? Start your 14-day free trial today.
Returning pilot? Visit Account Management for the latest offers and promotions.

Corp Hangars on ships and You

So, we're changing Corp Hangars on ships in Retribution.

Why?

 The short version is that the current technical implementation is an unnecessary maintenance burden; and we don't feel that the complexity of the design is justified by the value it delivers.

On the technical side, the same code is handling corp hangars in stations, starbases and ships. Given that ships in particular are clearly not the same thing as stations, it should not be surprising that there is a lot of horrible special-casing in the code to make this work. The end result, in this case, is a chunk of code that's broken in lots of different interesting ways; the fixes for which are generally mutually exclusive; many of which are effectively unfixable; and for which any potential changes are a QA nightmare to validate.

On the design side, the specific functionality that corp hangars are providing - allowing you to control ship access using corp roles - is overkill for the large majority of use cases; doesn't work consistently (the role checks are only applied to players from your corp); has serious issues with NPC corps; places hidden design tripwires everywhere (who owns the contents of a corp hangar - the pilot or the corporation?); and are in aggregate increasing the complexity of the game in a manner that we do not feel is justified in this case.

 What's changing?

 Corp hangars on ships will be transformed into fleet hangars:

  • The total volume will stay the same
     
  • Divisions and all reliance on corp roles is gone
     
  • Only the pilot will be able to open or remove containers in fleet hangars, although any pilot can drop items onto them to place them in the container
     
  • You will now be able to set "allow fleet usage" and "allow corp usage" independently for both fleet hangar and the ship maintenance bays (on ships only, not on starbases at this time)
     
  • These settings will now be stored per-ship on the server, so a given ship will always keep its last settings

In this image you can see the "fleet" and "corp" buttons next to the Ship Maintenance Bay and Fleet Hangar, which are used to set access permissions on each

 Additional changes related to this:

  • We're adding a range of new non-compressive containers to the "freight container" line (volumes in m3 are 1k, 5k, 10k, 50k, 250k)
     
  • All special bays on ships that are not your main cargo will now behave like your main cargo when it comes to ship scanners and loot drop chances; this includes fleet hangars, ore holds, fuel holds and so on. Specifically, they will all allow their contents to show up on scanners, and they will all have a chance to drop their contents as loot. Ship maintenance bays are somewhat special: they will be scannable (ie, ships but not their modules or cargo can show up in results), but they won't be dropping assembled ships as loot
     
  • Ship and cargo scanners will no longer randomize the stack size/number of modules they return: for any stack or module that they successfully detect, they will report the correct size/count
     
  • Blockade Runners are being updated to be immune to cargo scanners, and as such will always show up as empty on scans
     
  • Freighters will have most of their special-case restrictions removed: they will now be able to perform cargo operations in space, including moving items into and out of containers, moving things to and from containers in space, and jettisoning items
     
  • We're removing the restriction on simultaneous users for *all* ship fitting arrays, both on ships and on starbases: an unlimited number of pilots will be able to refit at a single ship or structure

 Additional changes that are largely unrelated but seemed like a good idea given that we were looking at the code anyway:

  • Starbase forcefield passwords are now stored per-character on the server, so you'll always have the most recent password you entered set until you enter a new one
     
  • The "lock/unlock" setting on audit log containers is now stored per-container on the server, rather than per-character on the client

Why are you removing divisions? They're useful!

 Yes, they are. However, we're currently of the opinion that they're not *necessary*, we don't feel that they're adding a lot of value in the most common use cases, and as such we're treating them as a case of unnecessary complexity.

 The changes to container behavior in fleet hangars, the new containers, and existing inventory features such as filters, should allow most (but not all) of the current functionality to be replicable in the new system. There will, though, be some cases in which the new system is less useful than the old system. We acknowledge this, and we understand that the changeover will be frustrating for some people, but we need to get the complexity of EVE under control and doing so is going to require functionality downgrades in certain areas. This is annoying but unavoidable.

 My Orca-hauling backbone!

Yup. The immunity of corp hangars (and other special bays) to scans and their inability to drop loot was a neat workaround, but it was also essentially unfinished functionality, rather than an intentional feature. We recognize the need for secure hauling in the current environment, hence the scan immunity on blockade runners, but feel that the way it's being provided currently is unintuitive and clunky, 
and that the "safe hauling" capacity on Orcas is unnecessarily large. Blockade runners should pick up the slack on high-value, low-volume items, while for higher-volume shipments, we're leaving it up to players to figure out how to handle the new situation.

 (We're not making any changes to plastic wrap right now, but it has significant technical issues which will likely see it being reworked at some point down the line.)

 

 

New to EVE? Start your 14-day free trial today.
Returning pilot? Visit Account Management for the latest offers and promotions.

Happy Safe Fun Time

Hi everybody,

Today I'm going to talk about how to fly safely in Retribution! We are adding a couple of new features to ensure that, when you inevitably lose your ship in a very silly way, it is very definitely 100% your fault.

SAFE LOGOFF

This system is pretty straightforward: if you are not doing anything dangerous, you can now opt to "Log Off Safely". This will give you a big on-screen timer showing you how long until you log out. When the timer runs out, your ship is immediately removed from space and you're informed that you successfully logged out.

You will also notice here that there is a button marked "Abort". If, while you're in the process of logging off, you see some dastardly pirate slash noble upholder of justice delete as appropriate flying over to end your ship's meagre existence, you can abort the process and defend yourself. This should ensure that you'll never (again) die because you logged out a minute too soon and got podded while the client was closed.

You cannot be safely logging off while:

  • You have active modules
  • You're ejecting from a ship
  • You have aggression from players or NPCs
  • Your ship is exploding or self-destructing
  • You're issuing movement commands
  • You're launching or jettisoning objects
  • You're joining a fleet
  • You're deploying or reconnecting with drones
  • You have a target lock or are targeted
  • You're warping
  • You're decloaking or under gate cloak

You can't initiate a safe logoff while any of these things are happening, and if they happen once the countdown is running, it'll be aborted.

SAFETY SYSTEM

The Safety System is sliiightly more complex. Masterplan explained in an earlier blog that, in Retribution, there will be two levels of illegal behavior: "suspect" and "criminal". The safety system ensures that you cannot commit illegal behavior without deliberately switching off your safeties first.

Your new safety system has three states: enabled, partially disabled and disabled.

  • While ENABLED, you cannot commit any kind of illegal act
  • While PARTIALLY DISABLED, you can commit acts that will get you a suspect flag, but not those that would get you a criminal flag
  • While DISABLED, you can do anything you like, up to and including criminal acts

Your safety settings can be adjusted using this cunning new button on your HUD:

Clicking the little round button brings up the safety settings options, where you can select your desired state. Going UP the list (ie, moving to a less-safe setting) requires confirmation; going DOWN the list does not.

Changing your safety setting happens instantly, but moving to a safer setting will not clear flags that you've already incurred.

If you try to attempt an action that's prevented by your safety level, you will simply not be allowed to do it (this is enforced both on the client and on the server). These commands are all highlighted in the UI - in red or yellow, depending on their severity - and if you try to click one of them, the safety button will blink to remind you where you need to change your settings.

The upshot of all this is that you can never just do something illegal by accident: you always have to deliberately go and disable your safety settings first. On the other hand, if you're out to cause trouble, you'll never be bothered by last-minute pop-ups again: if you're on a lowsec roam and you turn your safeties off, you're in full free-fire mode from that point forward. And, pilot beware, if you fully disable your safeties in hisec then you're just one button-press away from a visit from CONCORD. Use at your own discretion :)

New to EVE? Start your 14-day free trial today.
Returning pilot? Visit Account Management for the latest offers and promotions.

Happy Safe Fun Time

Hi everybody,

Today I'm going to talk about how to fly safely in Retribution! We are adding a couple of new features to ensure that, when you inevitably lose your ship in a very silly way, it is very definitely 100% your fault.

SAFE LOGOFF

This system is pretty straightforward: if you are not doing anything dangerous, you can now opt to "Log Off Safely". This will give you a big on-screen timer showing you how long until you log out. When the timer runs out, your ship is immediately removed from space and you're informed that you successfully logged out.

You will also notice here that there is a button marked "Abort". If, while you're in the process of logging off, you see some dastardly pirate slash noble upholder of justice delete as appropriate flying over to end your ship's meagre existence, you can abort the process and defend yourself. This should ensure that you'll never (again) die because you logged out a minute too soon and got podded while the client was closed.

You cannot be safely logging off while:

  • You have active modules
  • You're ejecting from a ship
  • You have aggression from players or NPCs
  • Your ship is exploding or self-destructing
  • You're issuing movement commands
  • You're launching or jettisoning objects
  • You're joining a fleet
  • You're deploying or reconnecting with drones
  • You have a target lock or are targeted
  • You're warping
  • You're decloaking or under gate cloak

You can't initiate a safe logoff while any of these things are happening, and if they happen once the countdown is running, it'll be aborted.

SAFETY SYSTEM

The Safety System is sliiightly more complex. Masterplan explained in an earlier blog that, in Retribution, there will be two levels of illegal behavior: "suspect" and "criminal". The safety system ensures that you cannot commit illegal behavior without deliberately switching off your safeties first.

Your new safety system has three states: enabled, partially disabled and disabled.

  • While ENABLED, you cannot commit any kind of illegal act
  • While PARTIALLY DISABLED, you can commit acts that will get you a suspect flag, but not those that would get you a criminal flag
  • While DISABLED, you can do anything you like, up to and including criminal acts

Your safety settings can be adjusted using this cunning new button on your HUD:

Clicking the little round button brings up the safety settings options, where you can select your desired state. Going UP the list (ie, moving to a less-safe setting) requires confirmation; going DOWN the list does not.

Changing your safety setting happens instantly, but moving to a safer setting will not clear flags that you've already incurred.

If you try to attempt an action that's prevented by your safety level, you will simply not be allowed to do it (this is enforced both on the client and on the server). These commands are all highlighted in the UI - in red or yellow, depending on their severity - and if you try to click one of them, the safety button will blink to remind you where you need to change your settings.

The upshot of all this is that you can never just do something illegal by accident: you always have to deliberately go and disable your safety settings first. On the other hand, if you're out to cause trouble, you'll never be bothered by last-minute pop-ups again: if you're on a lowsec roam and you turn your safeties off, you're in full free-fire mode from that point forward. And, pilot beware, if you fully disable your safeties in hisec then you're just one button-press away from a visit from CONCORD. Use at your own discretion :)

New to EVE? Start your 14-day free trial today.
Returning pilot? Visit Account Management for the latest offers and promotions.

Upcoming Tutorial Revisions

PART ONE: WHAT'S GOING ON

It's always been a core principle of EVE that the more active, engaged players we have, the better the game will be. EVE is a deeply social game at its core, and having more people to interact with gives more opportunities for interesting outcome (see: Metcalfe's Law).

One of the major benefits to EVE of DUST514's upcoming launch will be the increased awareness of and interest in our shared universe, and we're expecting an influx of new players as a result of this, which is great (see above). And then someone said "yeah, but won't they all have to play through the tutorial?", and we all thought back to our own experiences playing the EVE tutorial at various points over the years, and went "uhhhhhhhh... yeah..."

In *totally unrelated* news, Team Five 0 was recently tasked with a one-month mission to improve the tutorial as much as possible. This is the story of that mission.

 

Stage One: Analysis

The first thing we did was to look at the overall problem and determine scope and goals. Our data experts rolled out their graphs, we pored over them and asked lots of questions, and it quickly became clear that the biggest pain point right now is the initial tutorial arc, which loses an awful lot of people before they've even begun to play. The career path missions aren't perfect either, but players who've got to that point have usually already decided that they enjoy the game and want to keep playing.

Confining ourselves to just this initial tutorial string gave us some useful limits on our work. Based on our knowledge of previous tutorial adjustments, we quickly came to the conclusion that rewriting it from scratch wouldn't yield good results in the time available, so we added the further constraint that we didn't want to change the actual tutorial missions more than strictly necessary. This gave us a clear framework to follow, while giving us the flexibility to make adjustments within that framework.

With those goals and restrictions in place, we next pursued two avenues of research. The first was to dig into the existing metrics for tutorials to look for obvious statistical issues. Here, for example, is a graph of the existing tutorial string, showing approximately how many people quit after each tutorial stage.

Tutorial quit graph
This graph shows, for each tutorial stage, how many players quit after starting that stage but before starting the next one.

 

As you can see, the current tutorial string has some good spots (most notably fitting and the bit where you're blowing things up), and some bad spots (most notably the bit right at the very start where we try to teach the skill queue before you've even undocked). Data like this gave us a pretty good sense of where our trouble spots lay.

While this data-gathering was taking place, we were also spending time digging into our other avenue: playing the tutorial. Alongside this, we also printed out every page of the tutorial and storyboarded the entire string in one of our meeting rooms. The notes from our playthroughs were then stuck onto the storyboard, so we could get a clear visual sense of where we were identifying lots of issues, and what was problematic at each stage.

Storyboard

 

Stage Two: Planning

With both our own analysis and a big stack of data in hand, we quickly collected a pretty long list of assumed problems with the current tutorials. From this, we began sketching out the major changes we wanted to make. Some sections needed to be moved or broken up, some dropped entirely, and additional teaching needed to be added in some cases. We decided to try and focus the tutorial as much as possible on teaching you how to use the game client and the core tools (piloting, fitting, skill training and so on), relying on the career paths to teach more specific skills.

The end product of this was a lot of additional post-its on our storyboard outlining the changes we wanted to make, and then a short written task-list of things to change. These tasks were split up among designers and programmers, and then we got to work.

 

Stage Three: Implementation

Everyone put their heads down and worked through the task-list. This is the unglamorous bit of game development!

 

Stage Four: Evaluation and adjustment

Once we were done with the main implementation work, we went through several rounds of user-testing with external volunteers. As you'd expect, we learned an awful lot from this, and came away from each session with long lists of adjustments to make.

A key example of this is how we teach in-space commands. We'd assumed initially that using visible UI functionality would be better than relying on context menus, so we endeavoured to teach with the Overview and Selected Item as much as possible. Repeated user testing showed that new players were far more comfortable right-clicking on everything, to the point where later tutorial steps that forced players to rely on Selected Item were tripping them up because they had no idea how to use it. This experience led us to rework our teaching throughout the tutorial to use right-click and the context menu, which subsequent testing confirmed as a much smoother experience.

 

Stage Five: Release it and see what happens

These changes will be released as part of Inferno 1.2, at which point we'll get to see what actually works in practice, and whether there are any trouble-spots that need further improvement. We've beefed up our logging capabilities as part of this work, so we should be able to see very quickly if there any problems, and react to them as needed.

 

PART TWO: WHAT WE'VE CHANGED

Overall Approach

  • Voiceovers are gone for now. We really like them, but as soon as the text stops matching up with the audio it's incredibly distracting, and it's not feasible to continually re-record them as adjustments are made. Until such time as we can get a really good text-to-speech implementation (which we are actively looking at), they're out.
  • >We're now attempting to teach everything one way (right-clicking stuff where applicable, for example), and reinforcing that method as often as possible.
  • We avoid teaching keyboard shortcuts. We use icons and pictures where applicable.
  • We highlight important things in the text. We always ensure that we have a clear header describing what's on the page.
  • We always have a line at the bottom telling you when to click Next.
  • We've removed automated progression and progression limits entirely from the initial string, and tied all the tutorials together in a single string: you can now use Back and Next to page through the entire string with no breaks or restrictions.

 

Tutorial Structure

  • At the start, we now tell players roughly how long the tutorial will take and what they'll get out of it.
  • We no longer teach Incarna-specific functionality, as right now it's not necessary to play the core game.
  • We've split skill training up into two sections, moved it to later in the tutorial, and are no longer attempting to teach the skill queue interface.
  • We now teach camera controls outside the station (where there are lots of other players to see) rather than on your own at an acceleration gate.
  • We've removed the first acceleration gate from the first mission, as the double gate in that mission was confusing our playtesters.
  • We've removed the huge stations from the end of the first mission, as they were making it very hard to locate the cargo rig objective.
  • We're more careful to teach basic UI stuff like closing windows you don't need.
  • We now explicitly teach the Overview, Selected Item and brackets.
  • We've adjusted shield regen on Rookie Ship a little, so that tutorial NPCs no longer have any chance of killing them.

 

Changes to Tutorial UI

  • The tutorial window has been completely overhauled:

Tutorial window

  • The look and feel is all-new, and now relies on a nice green hue rather than bright yellow everywhere.
  • The tutorial window now auto-resizes for each new page, to eliminate scrollbars. This can be disabled by manually resizing, and re-enabled using the settings button on the window.
  • The tutorial can now be minimized.
  • The tutorial now has its own button on the Neocom; if you close the tutorial, this button will re-open the tutorial at the point you left off. As a result of this, we've also got rid of the "are you sure" pop-up and replaced it with a (closeable) tooltip on the Neocom button explaining how to reopen it. The Help button on the Neocom is now a big blue question-mark; the old "Aura" icon is now used for the Tutorial button.

Neocom buttons

  • The pointers have had a visual overhaul, bringing them in line with the new tutorial look; they also now have a shimmer effect to draw visual attention.

Pointers

  • We now have dead-sexy in-space pointers that we can attach to things like ships and acceleration gates to help players locate them. They attach using a pretty cool bungee effect, and also highlight the item on the overview so you can find it there too.

In-space pointers

  • You can now drag tutorials into chat for other players.

Tutorials in chat

 

Supporting UI Changes

  • Constellation chat is no longer active by default.
  • Overview is now sorted by distance by default, rather than by icon.
  • Hybrid Charges are now referred to as Charges everywhere ingame, rather than as Ammo in some places.
  • You can now talk to agents using a button, rather than having to right-click.

Start conversation

  • You can now get information on mission objectives using a handy panel in the HUD, allowing you to warp to locations without having to rely on the Journal or context menu.

Mission info

  • Module tooltips have been substantially revised to show just useful information that isn't already clear from the module icon. (And yes, these include module and charge damage, and work with turrets, missiles and other ranged modules such as EW or remote repair.)

New tooltips

  • Full Speed and Stop Ship icons on the HUD are now + and - rather than two triangles; this does not strictly describe their function, but should make them much more easily discoverable by new players.

New HUD

  • You can now warp/jump to the next stargate from the Route panel in the HUD

Next system

 

PART THREE: WRAPUP

Most of this should be on Singularity as we speak; we're continuing to make minor adjustments as small issues come up, but at this point we're pretty much done. Please go and experiment, and give us any feedback you can think of!

-Greyscale