First off, there have been some major changes in the schedule since CCP Bro's blog due to unfavorable conditions. The new schedule looks like this:
What and where
The New Eden Open was held for the first time a year ago and provided a tournament for players to enter as a team rather than as an alliance. That way everyone that was interested in competing in a tournament live on Tranquility could. Over the course of three weekends Asine Hitama's Team was victorious and placed first, winning the first cash prize ever for an EVE Online tournament. All of the matches were streamed live and due to the fact that we utilized a double elimination format from the get-go, all of the matches mattered and were filled with exciting explosions and tactics.
If you are interested in taking part in the second New Eden Open, you only need to gather a team of pilots and sign up! The entry process is explained in the next section, but you do not need to be in an alliance or even in a corporation! You must only be willing to risk some ships in glorious space fighting, follow the rules, and most of all have fun. The prize pool is a total of 25 thousand dollars, so there is a lot to win.
The entire tournament will be streamed live by us on CCP's twitch.tv channel and we encourage participants to utilize the streaming integration that was released with EVE Online: Rubicon 1.0.8 if they want to!
Signup details and silent auction
Signups will start on Tuesday the 7th of January. The cost to sign up will be 5 PLEX, which need to be reverse redeemed by the captain of the team. The captain then logs into account management, creates the team on the New Eden Open page, and can invite pilots into his team. Those invites will go out via EVEmail and the invited pilots need to accept in order to be placed on the team. If your team does not make it into the tournament these 5 PLEX will be refunded to the captain.
On January 20th after downtime we will announce the final number of teams that signed up and begin the silent auction for the 28 spots in the tournament. Your bids should be sent by your team captain to the character CCP Alliance Tournament with the name of your team included in the mail. Remember that your initial 5 signup PLEX will be a part of this amount. You can update your bid for the two days it is open as you see fit but no bids will be made public by us. At the end of the auction on January 23rd the teams that did not secure a spot in the tournament will have a chance to get one of the remaining three spots via a raffle. If Asine Hitama’s Team choose not accept the final spot, it will also be dispensed at this time.
Classification of a 'player' in this tournament
To provide clarity on what constitutes a player in the tournament and to prevent gaming of the system the following rules will apply:
Teams can field up to eight pilots on the battlefield.
Fights are limited to 10 minutes. If a fight reaches time, it will be stopped and whichever team has the higher total points value will be declared winner. See "Victory Conditions", below.
Intentional pod killing is NOT allowed and may result in the offender being punished. All podkills will be reimbursed.
The match simulation is taken as is. Teams are advised to spend the pre warp-in time to verify that their ships are completely operational.
A player found breaking any rules can be penalized to various degrees, depending on the severity of the offence. All penalties are incurred at the tournament referee's discretion. Decisions are final. Penalties may be levied against a player or team and may include but are not limited to:
The referees can call a match null and void or declare a result if they believe that one of the teams is not competing. This tournament is designed to showcase the talents of pilots and should be entertaining.
The format of the tournament will be a modified double-elimination setup which will culminate in a best-of-5 match final. The third place will go to the loser of the final Elimination bracket match.
Place & Tactics
Captains must be online and available 45 minutes prior to the match to make their ban choices. Further details on bans can be found in the subsection Ships and bans.
Participants should be prepared, in their chosen ships and in a fleet, 20 minutes before their scheduled fight time. Teams will be brought by a GM to a solar system in uncharted space and designated as team 1 and team 2. If you are not ready within this time allocation you will be disqualified from this match and the opposing team will be given an automatic win.
There are eight beacons in the system which serve as start off points. Four beacons are marked for Team 1 and four marked for Team 2. Teams will be moved to the beacon of their captain's choosing. Once the teams are in system, all instructions will be given by the referee in local chat. You must keep an eye on that channel at all times once in system.
Once the word is given, teams warp in to the arena beacon specified, at a range of their choosing, up to a maximum of 50 km. Team members are allowed to warp in at different ranges.
The arena will measure 125 km radius around the central beacon.
The host will begin a countdown. When the countdown ends, the host will break target locks of all ships in the arena.
If a player warps out/leaves the arena, his/her ship will be destroyed. This includes disconnection emergency warps. This rule is in effect before and during the match.
Warping within the arena is NOT allowed.
Boarding a ship during the match is NOT allowed.
Dropping cargo containers or other anchorable items is NOT allowed. Dropping regular jettison containers is allowed.
The following restrictions are in place after teams warp to the arena beacon, until the match begins:
Ships & Points
Each team has 70 points with which to select their ships.
Each team may have up to 8 ships on the battlefield.
Teams may field no more than 3 of a given ship. This applies to specifically named ships only and not ship hulls. For example, 3 Merlins, 3 Hawks, and 2 Harpies would be legal.
Teams may field no more than 1 logistics ship, or 1 tech one support cruiser, or up to 2 support frigates.
Teams may field no more than 1 marauder.
Ship point values are as follows. Ship types not listed in the table are not allowed.
Marauder - 25
Battleship, Pirate Faction - 20
Battleship, Navy Faction - 18
Battleship - 17
Black Ops Battleship - 17
Command Ship - 16
Strategic Cruiser - 16
Recon Ship - 14
Battlecruiser, Navy Faction - 14
Battlecruiser (Including Gnosis) - 13
Logistics Cruiser - 13
Heavy Assault Cruiser - 13
Cruiser, Faction - 12
Heavy Interdictor - 11
Tech 1 Support Cruiser - 10
Cruiser - 6
Electronic Attack Frigate - 6
Frigate, Faction - 4
Assault Frigate - 4
Tech 1 Disruption Frigate - 4
Interdictor - 4
Bomber - 3
Interceptor - 3
Destroyer - 3
Tech 1 Industrial Ships - 3
Frigate - 2
All T1 and T2 modules are allowed, with the following exceptions:
All Remote Armor Repair modules and Remote Shield Transfer modules are NOT allowed, EXCEPT on ONE of: a Logistics Ship, a Strategic Cruiser, a Tech 1 Support Cruiser; or on up to TWO Tech 1 Support Frigates.
Remote Energy Transfer modules are NOT allowed.
Faction, COSMOS, deadspace and officer modules are NOT allowed.
T1 Rigs are allowed. T2 Rigs are NOT allowed.
All T1 and T2 ammunition, missiles and charges are allowed. Faction ammunition, missiles and capacitor boosters are allowed.
All drones are allowed, including Logistics drones and Augmented drones.
Attribute Enhancers that give bonuses to anything other than perception, intelligence, willpower, memory, and charisma are NOT allowed.
Genolution "CA-" implants are NOT allowed.
With the exception of leadership Mindlinks, ONLY Hardwirings that have a name ending in "1", "2" or "3" are allowed.
All Leadership Mindlinks (including navy mindlinks) are allowed.
Boosters (drugs) are NOT allowed.
Cloaking is NOT allowed.
Cap Boosters are allowed.
Micro-jump drives are allowed.
The Ancillary Shield Boost module will be restricted to one module per ship for those pilots who wish to fit them.
Once a team has lost a Marauder class ship during the tournament, they may not field another Marauder class ship for the duration of the tournament.
During a match, a team scores points for each enemy ship it kills, equal to the tournament points value of that ship. The team that has scored the most points at the conclusion of the match, or that destroys the entire opposing team, is the winner.
If a team chooses to field less than 70 points, non-fielded points count towards the opponent's score.
If a fight is tied after 10 minutes, time dilation will be used to progressively speed up the tournament solar system and encourage a prompt end to the match.
In the very unlikely case that a fight is tied after 15 minutes, the victory will be awarded to the team that had more collective potential team DPS at the beginning of the match, as measured by the tournament automated “attack bar”.
Ships and Bans
Banning of ships will occur during all matches.
Team captains must be online and available to conduct ship bans 45 minutes before the start of each match. At 44 minutes before each match if the captain is unavailable their team’s bans are forfeit.
Each team gets two bans.
The way the banning phase works is as follows:
The team which starts the banning phase is decided randomly.
All ships that are eligible for competition are eligible for banning.
Bans are done in 1 – 2 – 1 order rather than the 1 - 1 - 1 - 1 that we saw in the first New Eden Open. For example Team A will take the first ban, Team B will take the second and third ban, and Team A will finish the banning phase with the fourth ban.
Each ban has a time limit of one minute; if no ship is selected within that timeframe the ban is forfeit.
Once the bans start, a drop down menu will appear where you select the ship to ban. You can type the name of the ship to speed up the process.
Please be aware that banning a ship will not remove it from the list. Selecting the same ship type twice is a wasted ban.
Each ban targets a specific ship type and not a ship class or other hull. For example, banning the Harpy would not exclude the Hawk or frigates in general.
Teams should endeavor to have multiple ship setups available as bans may impact your primary team setup. No additional time will be given if teams do not have eligible ships available.
During the final day of competition, some matches will require teams to be ready within 15 minutes after the completion of banning. We expect that many teams will find this time limit challenging. The best teams in New Eden will be the ones that can adapt quickly.
This time CCP will be handling the payments from start to finish, so we will have time to prepare everything that our victors will need to roll around in sweet sweet currency (or PLEX). On the downtime following the end of the tournament, every member of the winning teams will receive an email to the account’s registered email address directing them to a digital form. Winners will have the option of accepting their prize by bank transfer or by PLEX equivalent in game (we are working on potentially getting a paypal option). Everyone will get two shots to enter bank details (try to limit transfers that involve 3 banks) that will work, and if we can’t get a transfer that will work we will pay out prizes in the PLEX equivalent. We intend to have every prize paid out within 2 months of the end of the NEO.
Please note, unlike last year we are paying out to individual characters on the team (if you have 2 characters on the team, you get two shares of the prize). That means that the day after the conclusion of the NEO, whatever email address is assigned to the character will receive the email for payment. Please ensure that your account details are up to date, and that your account is 100% secure.
Please also note that the recipient of any prize money is liable for any income taxes or VAT payable in their home country and, that the responsibility for declaring this income is that of the recipient of said prize and CCP will not be liable in any way.
Further details will be announced as we come closer to the signups starting, but feel free to join us in the tournament forum and ask questions there.
Let the theorycrafting begin!
- CCP Gargant, on behalf of the tournament team.
New to EVE? Start your 14-day free trial today.
Returning pilot? Visit Account Management for the latest offers and promotions.
While this is traditionally a time to reflect and acknowledge just how far we have come together, it’s also been an exciting time to share our vision of the future.
2013 has been a watershed year -- the start of our Second Decade for EVE as a shared universe. Connecting DUST 514 to TQ began the next phase of EVE's evolution as a single shard universe as both EVE capsuleers and DUST mercs collaborated and conspired towards greater deeds than either group could do alone.
While DUST 514 continues to evolve, most recently with exciting new changes coming to Orbital Strikes from EVE pilots, we were also blown away by the community and industry reaction to a tech demo put together by a small CCP team in their spare time. What started out as a humble incubation project has emerged as EVE: Valkyrie, the third game in the EVE Universe, which has rapidly become one of the most highly anticipated games launching in 2014.
At Fanfest, we shared a future vision of EVE Online, a vision of Capsuleers wresting more control from the Empires, of venturing out and exploring the hidden reaches of space and staking claim in new frontiers. This journey started with our Odyssey and Rubicon expansions, and will ultimately lead to the promise of capsuleer-controlled stargates hurtling you into the unknown.
This is going to be one hell of a journey, and we're thrilled to have you with us.
Without the support of the EVE community we would not be in the position we are today, growing year over year and being able to do what we love, weaving together the fabric of the world's largest gaming universe. You are an amazing, dynamic, talented, creative, cutthroat, generous, hilarious, maddening, brilliant group of people from all around the world.
Let's take a moment to appreciate just a few of the awesome player-driven events that have made 2013 so memorable: the simple mistake that led to the battle of Asakai, the epic Fountain War, the battle at 6VDT (the largest space battle in the history of humanity!), the FWeddit/Subdreddit Capsuleer and Mercenary alliance, all capped off with an amazing outpouring of support for the victims of Typhoon Haiyan in a record-setting PLEX for Good campaign..
Now, as 2013 draws to a close and our Second Decade begins in earnest, it's time for a little surprise.
Icelandic folklore tells of 13 mischievous 'Yule Lads' who come down from the mountains to spread seasonal cheer, and some things not so cheerful, to unsuspecting residents in the run-up to Christmas. This year, they have extended their area of operations to include the inhabitants of New Eden.
So whether you have been naughty, nice or a bit of both, be sure to head over to www.eveonline.com/holiday2013 and find out what's in store.
On behalf of the team here at CCP, we wish you all a wonderful and peaceful holiday season. Fly safe, and prepare for an epic 2014!
\ CCP Pokethulhu
New to EVE? Start your 14-day free trial today.
Returning pilot? Visit Account Management for the latest offers and promotions.
On November 8th 2013, a Typhoon of catastrophic proportions struck the Philippines leaving an incomprehensible trail of destruction in its wake. Today, the death toll for this catastrophe stands at more than 5,900, with more than 1,700 still missing and over 12 million people affected directly by the devastation.
Along with the rest of the world, CCP followed the devastating impact of Typhoon Haiyan (known locally as Typhoon Yolanda), and the development of increasingly dangerous living conditions for the people of the Philippines.
The reaction to these events from the EVE Online community has been simply staggering; with hundreds of our players calling for CCP to once again host PLEX for GOOD. The deep concern for the wellbeing of those affected and such a strong, united will to assist those in need exhibited by our community has been both a humbling and heartwarming experience for everyone here at CCP.
On November 20th, 2013, we answered calls from the EVE Community and opened donations via PLEX for GOOD, in an effort to allow our Community to assist in raising funds for the Icelandic Red Cross efforts in the wake of such a devastating natural disaster.
As PLEX donations began to arrive, the Community Team brainstormed ideas on how to further expand on previous PLEX for GOOD drives, and what quickly followed was the announcement of the PLEX for GOOD Charity Live Stream, which was hosted on December 7th.
By the time December 7th arrived, the EVE Community already had a myriad of fundraising initiatives in place within New Eden that had raised a total of 4251 PLEX, or $63,765 US, smashing the totals from any previous PLEX for GOOD drives.
We began the live stream with our heads held high, and deep sense of pride in what the community had achieved so far.
What followed was simply astonishing.
By the time 16:00 arrived, less than two hours into the Live Stream, the community had donated a total of 8482 PLEX, or $127,230 US. Much to our amazement the donations continued to flood in for a further five hours, and when the lights went out at the end of the live stream, the entire team involved was left speechless at the sheer scale of the generosity displayed by the EVE Community.
By the end of the stream the community had donated 12345 PLEX, for a total of $185,175 US, and as we began to pack away equipment the donations didn’t stop.
On the morning of Sunday, December 8th, we returned to the office to tally up the final number of PLEX, and were once again left shellshocked by the level of generosity that the EVE Community has shown.
In total, the EVE Community raised 12,726 PLEX. This equates to the following:
1060 YEARS of gametime.
7,634,000,000,000 ISK (approximately) at current PLEX prices on board Jita IV- Moon 4 – Caldari Navy Assembly Plant.
To put this achievement into perspective, our largest previous PLEX for GOOD drive was in 2011, in the wake of the Tsunami that struck Japan, which raised 2549 PLEX, equivalent today to $38,235 US.
In total, before this drive for the Philippines, the EVE Community had raised approximately $108,000 US for charity in total from all our previous PLEX for GOOD drives combined, and approximately $150,000 US for charity in total since 2003 including all Fanfest silent auctions and associated fundraisers.
Today, that total has almost doubled, and now stands at an unbelievable $340,000.
Yesterday, all those involved in the fundraiser and the live stream had the pleasure of taking a trip to the headquarters of the Icelandic Red Cross to meet with their leaders, and the President of Iceland. We presented them with a check for $190,890 US on behalf of the players of EVE Online.
(Click To Enlarge)
In a speech given by the President of Iceland after the check was accepted, he acknowledged that through online gaming communities such as ours, and through the strength of international cooperation via virtual worlds, a new age is dawning in terms of collaborative fundraising for good causes, as borders across the world are broken down and online communities band together as a formidable force for good.
While EVE players may explore the limits of “morality” in all different directions while they play and the more unforgiving and hardcore side of EVE often shows up in media stories, the EVE Community have demonstrated their immense strength and capability as a force for good over the course of the last two weeks, and has established itself at the forefront of this new breed of fundraisers.
Here at CCP Headquarters, we are finding it extremely difficult to choose words to express the profound level of gratitude that we wish to convey to what is, without a doubt, the finest gaming community on Earth.
From everyone at CCP Games, we wish to convey or most profound gratitude, and our deepest and most sincere thanks for your unbelievable generosity,
EVE Community Manager
On Behalf of the PLEX for GOOD Taskforce
If you aren’t familiar with streaming or Twitch, let me explain quickly. Streaming is a way of broadcasting media of your choosing (anything from EVE Online to your favorite political protest) live via the magic of the internet to as many viewers as you can attract to your channel. Game streaming has been growing rapidly in popularity over the last few years as people get their hands on better hardware and streaming services like Twitch keep improving. If you aren’t familiar with twitch.tv specifically, it’s a web-based streaming service focused exclusively on games. At any time of day there are more than 100,000 people watching other people play games on Twitch and there are hundreds of people streaming.
What does this have to do with EVE you might say? Until now, streaming meant getting ahold of software to actually manage the stream output from your computer, which can be costly and/or confusing. By integrating an SDK created by twitch.tv into EVE, you can now completely bypass the 3rd party software and stream directly from the EVE client. Amazing!
Here’s how it works: First, you will have to go to twitch.tv and create an account. This should be fairly painless and you only need to do it once. Next, just load up EVE and then look under the "social" tab in the root of the Neocom and you should notice a new “Twitch Streaming” option. It looks like this:
You can access Twitch options from the root, but I recommend dragging it into the Neocom bar because the Neocom icon lets you know when your stream is active at all times. When you open the Twitch Streaming window you will see a set of options that looks like this:
From here you simply need to enter your twitch.tv login information that you created earlier (or use the conveniently located link in the window to sign up at this point) and set up some basic streaming options including a title, resolution and frame rate, and then with the push of one button your stream will be active and viewable on twitch.tv at your default page which will be www.twitch.tv/USERNAME. While the Stream is active, the options window and the Neocom icon give you feedback to let you know you’re streaming which looks like this:
You might wonder if streaming EVE is actually a terrible idea that could only lead to your own suffering, and at first I wondered about this as well. Not only did I discover that streaming even the most dangerous and intel-sensitive combat I could find was actually incredibly fun, but the more EVE streams I watch the more I value I think this feature has. Teaching corpmates to d-scan, giving an EVE-UNI lecture, streaming the eyes of your scout for your gang, following around huge fleets in a cloaky Tengu and playing questionable techno or even streaming market trading (which I spent an hour watching the other night and had a really good time) are just a few of the potential reasons to stream. You can also set your stream to private on the Twitch stream page if you like. There's a lot of possiblities and we're hoping the easy access means more new applications pop up.
Twitch offers a lot of functionality through their web interface that you should make sure to check out. Probably the most important is stream chat, a simple chat room attached to your channel where your viewers can give you questions, offer feedback on the stream or simply tell you to ヽ༼ຈل͜ຈ༽ﾉ Drink the Water ヽ༼ຈل͜ຈ༽ﾉ. A second valuable feature is that Twitch will archive your live streams and allow you to set new titles and highlights for them. Make sure to look into these features and also visit Twitch's rules of conduct while you're there.
If you are already a streamer and find your streaming software useful in setting up a more personalized broadcast, we don’t expect you to switch to the integrated option. While we would love to add features like overlays, information filtering (such as location or social information) or delay (which is currently only available through Twitch as a partner) we want to hold off for now and see how this is received and work on spaceships in the meantime. I also have to mention that sadly, if you are a mac user, this feature will be disabled for you. There is a technical block related to the way we emulate EVE on macs which we are investigating but don't have a fix for at this time.
Please visit us in the feedback thread for this blog and let us know how you intend to use this feature, or how you might want it improved in the future. And even if you aren’t going to be streaming yourself, make sure to head over to Twitch's EVE Online page and see what your fellow capsuleers are up to and always keep an eye on our official CCP Twitch page.
Thanks, and may you all become space famous!
- CCP Rise
New to EVE? Start your 14-day free trial today.
Returning pilot? Visit Account Management for the latest offers and promotions.
Most people might not realize Battleclinic predates EVE Online by several years. Waaaay back in the year 2000, games like Mechwarrior 4 and Deus Ex were on top of the gaming world. SghnDubh, the founder of Battleclinic, was playing a game called Starfleet Command, a multiplayer game based on a Star Trek-related boardgame. While playing it, he wondered how he could extend his enjoyment of the game beyond the game itself. Eventually, in November 2001, he put up a forum and ship fitting page for Starfleet Command.
BattleClinic was born. In the beginning, he asked people to e-mail him their loadouts and he would transcribe them into HTML by hand. This quickly became tedious, so he reached out to his burgeoning community and was answered by MrCue, who came onboard as his developer.
In late 2003 and early 2004, a large portion of the Starfleet Command community was migrating to a promising and ambitious game called EVE Online. The notorious learning curve for EVE was well known even in those days, creating demand for BattleClinic's ship loadout functionality. It was an instant hit with EVE.
Along the way, MrCue worked out a way to parse killmails into a killboard. In 2005, the site added a new player guide, regional chokepoints, and a variety of other tools. This boosted the site's popularity, also driving up costs. In 2006, they opened the BattleClinic Deep Space Supply, an official EVE GTC reseller. That small revenue stream helped them improve the site and add additional features for the community. They were also able to give EVEMon a new home after the original developer moved on.
In 2007, they purchased Griefwatch.net as a way to improve their killboard support for players, with more than 10000 Griefwatch killboards existing today. They hauled a huge trade-show booth to Fanfest in 2008, ran a booth side-by-side with EON Magazine at Fanfest 2009-10, and exhibited their own booth at the 2010 Game Developer Conference, attracting the attention of Curse.com.
In late 2009/early 2010, they invested in new site architecture with the goal to support additional games. Currently, they are working on improving their killboard design and loadout functionality with the aim of releasing it early next year.
Behind the Scenes
It might surprise people to know that BattleClinic has no full-time employees. Instead it is built and maintained by staff between their family, work, and game time.
MrCue is their lead web developer. He creates and maintains the core functionality of the site, as he has for almost 14 years. Unsurprisingly, he is also a web developer professionally.
Jimi is the head of EVEMon development, while Tonto Auri is the unsung hero supporting it.
The current community manage is Anabaric. Despite also running an alliance and an EVE-related blog, he has managed to do a fantastic job in the role.
The senior moderators are Widdershins and Reisenkaze, who have been joined by a number of volunteer moderators. They have resolved disputes, deleted trolls, and dispensed valuable advice over the years.
On top of the heap is SghnDubh, the original creator and maintainer of the site. In real life, he is a corporate learning and development executive. BattleClinic has proven to be incredibly relevant to his job, as EVE players tend to be highly motivated, deeply competitive, and thrive on complexity. He pays attention to what players use and ask for and why they're asking. Analyzing that data helps him guide better learning interventions in the real life corporate world.
BattleClinic has grown steadily for almost 14 years, much like EVE Online. It currently boasts over 277000 active users and is approaching a million posts. Players post thousands of loadouts every month, they process more killmails than any other site, and are the top PLEX reseller in partnership with CCP. By those standards, it can easily be seen how much the community uses and values BattleClinic.
But these results mean little compared to the emails and posts they receive from players all over the world who tell them they enjoy EVE Online more because of BattleClinic being around to help them out. When SghnDubh look at the quality and dedication of other fansites, the big persoanlities, the in-game organizations dedicated to player education, and even the competition from rival killboards, he is humbled to be included in such good company.
As mentioned above, BattleClinic is revamping their killboard interface and expect to release it in the first part of 2014. They're also pursuing strategic partnerships with other fansites. There are plans for a redesign of the loadouts section as well. Additionally, the EVEMon team is designing a Windows Phone mobile version of the popular tool!
SghnDubh says EVE Online is utterly remarkable, its vision and scope are breathtaking, and it redefines the definition of MMO gaming. BattleClinic is proud they've been fortunate to add their contribution to that vision and are humbled that so many use and enjoy the service. SghnDubh counts many members and associates as some of his closest friends.
And if you haven't been to BattleClinic before... Where have you been for the past decade?]]>
These changes will go live on December 10th, at the same time Uprising 1.7 comes to DUST 514.
As it stands right now in EVE, if you wish to provide an orbital strike it's a pretty passive thing. You go to the location, wait somewhere safe till you get the call, and when told warp to the district, and perform you do the orbital strike, then warp out. Not as engaging an experience we hoped to provide, but a sort of placeholder first step as we introduced the system. This set of changes will hopefully bring us towards a more engaging experience.
The first change is that DUST players no longer earn orbital strikes through accumulating war points. Instead orbital strikes are now up to you capsuleers. Orbital striking as an EVE pilot is easy enough: fit your favorite ship with the proper orbital striking ammunition (Tactical Laser S, Tactical Hybrid S, Tactical EMP S), warp to the planet district where fighting is occurring, orbit the beacon for three minutes while you begin to get a lock on the battlefield below, and hope no one else notices the district satellite on their overview from anywhere in the system and warps in to ruin your plans.
The best way to find a battle will still be to communicate with DUST players and find out where they are fighting--or yourself if you are "dual-screening". However, this is something we hope to improve upon in the future.
Since we are making you put your orbitally striking ship at a bit more risk, we decided you deserved a bit more in terms of rewards. To start with, if you are part of a militia in Factional Warfare, when you actually complete an orbital strike in the warzone, we will reward you with a tidy sum of 3,000 Loyalty Points (LP) with your militia. This LP will be divided between anyone connected to the district from your militia, with a limit of 10 pilots per side connected at once. The LP is also modified by the Tier of your militia, so that’s 3,000 LP at Tier 1.
LP is nice, and I am sure that is all the reward you guys want right? Well, even if it's not it is more of a reward than killmails ever would be right? No one in their right mind would hold a killmail more valuble than something that can actually be traded for ISK…. Right?!
Well just in case some of you find value in killmails we have gone ahead and added them for orbital strikes that result in destruction and/or casualties. These will be generated when firing on both Faction Warfare and Planetary Conquest battles.
When an EVE pilot connects to a district they will also now be added to the team text chat and can join the team voice chat if they wish allowing for better communication between EVE and DUST players. The team text and voice chat has all the DUST players for your side in that match in it. See this screenshot for an example of how this will look:
One final change, because we like to keep you guys on your toes, is we have renamed the orbital strike ammo, It was called orbital bombardment ammo before. In DUST however we called it orbital strikes. To try and make things more consistent we have renamed the EVE ammo to orbital strike ammo.
For full details on all these changes and more, check out the DUST dev blog here.
CCP FoxFour, on behalf of Team True Grit]]>
Hello everybody, my name is CCP Prism X and I am a Libra!
This summer we saw a welcome influx of players with the release of EVE Online: Odyssey. On occasions as such we usually celebrate our great success by pulling out the champagne and our $1000 Japanese pants, and having ourselves a great big pillow fight. However, this time around the influx of people was so dramatic that it worried us; Empire Space was burning. There were so many people in New Eden, doing so many things, that the actual CPU cores (reffered to as "nodes" hereafter) running the Empire Space systems were under extreme load. This was causing Time Dilation to affect the various, and disparate, portions of Empire Space. Time Dilation is all well and good when you‘re blobbing with your space-friends in Nullsec. But when you‘re just running a mission in some dead-end system, all alone in local, and suddenly everything starts going all bullet-time on you: you get frustrated.
Empire Space should really have such predictable load† that Time Dilation should never kick in there. If it happens, our Static Cluster Premapper should at least be able to avoid a reoccurence. That is because we track an estimated load fingerprint of all solar systems and assign systems to different nodes, based on said estimated load, during startup. As long as that estimate is correct-ish and the premapper is functioning as it should, things should run fairly smoothly. But the same systems were consistently starting up on nodes with too many other systems assigned to them. Things were not running very smoothly at all and we weren‘t quite sure why.
† Assuming that no social engineering takes place that diverts load to new, unexpected, places.
Example: Announcing an upcoming LP offer from a corporation that only has a single good agent in high-security space will result in a lot of new load in that agents system which the premapper cannot in any way anticipate.
Above I omitted a fairly important fact about this premapping of solar systems: systems within the same constellation want to stay on the same node. They want it so bad that they‘ll do so at the expense of balanced load distribution as they‘ll ignore the, load wise, most optimal node assignment if their preferred node is only 20% more loaded than the optimal one. This behavior causes a huge deviation between the load of different nodes whereas we‘d rather want the premapper to spread the load as evenly as possible over all the nodes available to it. Furthermore this behavior doesn‘t extend above the constellation level so effectively a node can run two whole constellations, but one is located in the Deep North and the other in the Deep South. So a fleet fight in the Deep South could enforce Time Dilation on the other constellation located in the Deep North. That‘s frustrating for the Deep North pilots!
Here is visualization of the clustering of systems to nodes in the old systems (Note, this is 3D data badly projected on a 2D plane so there‘s some skew). Systems of the same colour reside on the same nodes. You‘ll quickly notice that this is just a jumble of colours with little consistency. I‘ve drawn red circles around two clusters which all belong to the same node to show the distance between the two:
And to top it off this isn‘t even a good load distribution. The difference between node load is fairly staggering as you can see on the standard deviation values here:
But why were we clustering systems on the constellation level? Because a long time ago it was theorized that inter-node stargate jumps were more expensive than intra-node jumps. Presumably, that is due to the assumed overhead introduced by network latency. Now we know that this assumption is completely wrong and inter-node jumps are actually cheaper than their counterpart. A stargate jump requires the removal of the player from one system, and his introduction into another one. Splitting that work between two nodes spreads load better than doing it all on the same node.
Realizing this, we just decided to remove any such node affinity behavior from the premapping logic as a first step. Systems would just be assigned to nodes on the basis of the most loaded, unassigned, system being assigned to the least loaded node. That resulted in an amazingly well balanced cluster and the load problem was solved! But even though we‘d made a very balanced cluster the Time Dilation problem was now even more pronounced. Systems had just been semi-randomly assigned to nodes with no respect to locality and so we still had people in the Deep North affected by fleet fights in the Deep South. Revert the changes and put the thinking cap back on!
So we needed a way to split load between nodes whilst ensuring that all systems on a node belong to the same space-neighborhood. As a secondary concern we really did not want to increase the time premapping took, and we used the opportunity to completely nuke the old T-SQL code and recreate it as a Python module. That last decision, unsurprisingly, turned out to be the most important one as a procedural language with a large supporting ecosystem of available tools is much better geared to solve a procedural problem than a highly limited relational language.
With Python at our side we initially arrived at a fairly simple and approachable solution. As we‘re attempting to split up a cluster of stars with defined coordinates so that both halves are adjacent and equally weighted; why don‘t we just do that? If you split any coordinate system in half with a plane, both halves will be adjacent to each other and that solves the problem of proximity. That leaves us with a way of ensuring that both halves are close to equal in their load. As we keep track of each systems load this just becomes a matter of tweaking the split line iteratively in some sensible manner. That‘s not more complex than using the properties of Binary Search! We just have to move the split line a given distance towards the more heavy of the two halves, and then half the distance we‘ll move it on the next iteration. Theoretically we should bounce between both sides of the optimal split line for a while until we hit it. I say theoretically because we‘re not trying to find the optimal solution here, only a good enough solution in the least amount of time.
Here is a graph to help you visualize this process. Imagine the circle stands for the entire cluster of stars we want to split up. The stars themselves are not shown because they're not important, all that matters is that the split will not mix stars from the two distinct halves between them and that the load is as equal as possible.
Once we’re done splitting the initial universe into two clusters, we’ll pick the heavier of those two and split it again. Then we’ll pick the heaviest of those three and split it again and repeat the process on the four resulting clusters of stars. We’ll repeat this until we have as many clusters as we have nodes at which point we commit the mapping to the database and continue on with startup.
To visualize this properly I’ve provided some visualization, using this method, run against the same dataset as the graph above. However, the first three steps are the split of Empire Space only due to the inner workings of the new method and only serve to describe the method better. The last picture is the final allocation of the entire universe (on the same data) and can thus be compared to the similar graph above.
Initial Empire Space step:
First Empire Space split. Note the size difference of the two halves due to the fact that not all systems are equally loaded:
Seventh Empire Space split (that grey blob is two hues of gray):
End result of entire universe. Note how much more uniform the color distribution is:
That’s how we initially pushed out the new cluster premapper a few weeks before Rubicon was released. We did so understanding what the more Computer Sciency types out there might already have realized from the above; this results in a balanced load spread if, and only if, the number of nodes available for allocation are a whole power of two. Anything else will result in a fairly unbalanced load spread as we’re always splitting load into two halves, creating a sort of a Binary Tree. For a perfectly equal split we must have enough nodes to fill the leaf level of that imaginary tree or we’ll have nodes on level leaf-1 with double the amount of load on the nodes on the leaf level.
Here is a very simple picture displaying the whole power of two issue with 3 nodes as opposed to 2^2=4 nodes. Please keep in mind that this is a perfect world example. We do not actually expect all load splits to be perfectly equal.
This resulted in a too uneven of a split. The statistics below do look better for Nullsec but in Empire we’re still looking at a fairly large standard deviation between nodes. But at least the CPU Minimum isn’t zero here. Sadly the memory stats just got plain worse, but we’re really balancing primarily for CPU.
Obviously the optimal split here is 33% of the load allocated to each node but you can see how the nice and simple algorithm outlined above completely fails here. But since we know this works optimally if we divide the load by a number of nodes that is a whole level of two we just need to force that behavior! We could of course constrain ourselves to always have a whole power of two number of nodes for solar systems but that feels like a rather silly artificial constraint. Especially if you know that any number in base 10 (decimal number system) can be represented in base 2 (binary number system), then this just becomes a matter of rearranging the binary tree above into branches of whole number of two nodes and running the algorithm detailed above on those branches.
Using a bit more complex example than the three nodes above, we can visualize this in action as thus:
This is easy enough to achieve with minimal alterations to the code used in the initial solution. That solution already relies on a method of splitting coordinate systems in two equally loaded parts. Altering it to split it into two X/Y parts is no big deal.
Using this new approach on the exact same dataset as the examples above we end up with this pretty picture of a balanced universe within which space-friends shoot other space-friends in their respective faces:
And now the CPU standard deviation has dropped drastically! We're hoping to have this code out by tomorrow Wednesday, December 4th.
Then do it again. This is the second version of this Dev Blog. I’m pretty sure nobody would have enjoyed reading the first one. Sadly I couldn’t reuse a lot of stuff from that first attempt, like I could with the code. It simply had too many mentions of water carriers, aqueducts and Beyonce Knowles. Probably wouldn’t have made a lot of sense to anybody!
So there you have it; our recipe for a Balanced Universe. Perhaps you can find some way of applying it to your own lives! I’m thinking those fancy colored dot charts could probably substitute for a Rorschach test. But in case you just read through my entire blog and do not feel like you’ve gained much from it I’d like to present you with this cool island song as a peace offering (Don’t browse at work kids!).
That’s it folks! If you’ve got some further questions I’ll be looking at the comment thread regularly.]]>
On behalf of the team at CCP, I would like to thank everyone who has donated to the PLEX for Good campaign so far. With your help, we have already raised over $43,000 to help the victims of Typhoon Haiyan! This really goes to show what the EVE community is capable of doing when it bands together to do something good.
With this charity drive already shaping up to be the biggest we have ever done, we wanted to do something special for the occasion to both show our support for the cause, and to show how much we value the effort of the community surrounding this. Therefore, we will be doing an eight-hour charity livestream marathon with all your favorite CCPers to keep you company for the last part of the charity drive.
The charity livestream will take place from 13:00 UTC to 21:00 UTC on the 7th of December at http://twitch.tv/ccp
We will have a packed schedule for the stream, and here are some examples of the activities we’ll have:
But this wouldn’t be a charity marathon without pledges, would it? Our team has gotten together and promised to do some pretty amazing things should we reach specific fundraising goals.
I would also like to use this opportunity to ask you, the community, to make your own pledges on the forums to help encourage people to donate during the charity drive. It could be anything from doing an event to taking out a very expensive fleet if we reach a certain goal.
The sky is the limit and I fully trust you in the community to make something amazing happen. If you are planning on hosting an event to help this charity drive in any way I encourage you to let us know by filing a petition to the community queue so we can help you spread the word.
We are also looking into possibilities to provide the option to donate directly to the Icelandic Red Cross through Paypal, this way players and their friends who don‘t have an active subscription but still want to be a part of this amazing gesture can contribute to the cause. So keep an eye out for that donation button during the stream.
We are looking forward to a day of fun with all of you and we hope you join us for what is shaping up to be the most fun streams ever streamed. (Apart from this passionate EVE player serenating CCP karkur: http://www.twitch.tv/sirsqueebles/c/3257159)
Returning pilot? Visit Account Management for the latest offers and promotions.
Back in 2010, there were several EVE podcasts, but they were not quite what Alekseyev was looking for. Many were not regularly released and there were none truly dedicated to PVP and the 0.0 experience, outside of some who lightly explained them for new playes. He had been listening to podcasts of various sorts quite a bit over the previous few years and decided it was time to fill the void he saw.
He began by teaming up with fellow Noir. Mercenary pilot Jimer Lins, with the occasional third pilot joining them. As they began to grow more established, they started to bring on guests from a variety of sources, including other podcasts, blogs, notable FCs, and the like. The show did quite well for quite some time. They received plenty of positive feedback in the form of mails, donations, and waves in local.
However, all good things come to an end and eventually, Jimer decided to leave EVE behind. As Jimer had been the person who edited the final product, this left Alekseyev in a bind. Learning how to do post production was something he simply did not have time for, so the podcast sadly went on a hiatus.
Luckily for us, his interest in doing a podcast never waned and he decided to pick it back up. He still did not have an editor that could turn around episodes quickly, which led to an erratic release schedule, until he was joined by NinjaTurtle. He was extremely committed to keeping the episode content relevant by having a fast turnaround without sacrificing quality. The team was able to record every other week and release within a week, frequently much quicker than that.
They also moved servers in this time. Originally hosted on a community site that provided free webspace for EVE blogs and podcasts, the host suddenly went MIA and Declarations of War lost much of their old content. Though it has since mostly been recovered, they were still left out in the cold. Thankfully, the Noir. website received an upgrade, allowing them to begin hosting their work there.
Then Alekseyev was elected to CSM7. He decided to begin a segment on each cast which provided updates on the CSM and the issues they were handling. Soon after, he decided to give the podcast its own site, complete with commonly requested features such as an iTunes page, comments section, and a guest page. Shortly after, he was able to secure a sponsorship from EVE Time Code, which continues to sponsor them to this day.
Once his term with the CSM ended, he talked with CSM8 and got Ali Aras to join the podcast full time as the third broadcast member.
A long-running podcast like Declarations of War has its process finely tuned. For an average podcast, Alekseyev looks to book guests 1-2 weeks in advance if possible; if he can't find anyone, he checks his buddy list for people to ambush with a microphone. A Google Doc contains show notes for all the hosts to access and add story ideas in between shows.
The day of the recording, Alekseyev goes in and fleshes it out, then does a final check with the guests to see if there's any topic they want to discuss. This helps give each podcast a bit of flavor.
To record, they utilize Teamspeak. Every member of the podcast makes their own recording and then uploads it to a server. NinjaTurtle then takes the best quality recording and cleans it up for release using Audacity, though he is learning Ableton Live 8 Into. This takes an average of 3-6 days to complete.
About the Team
Every member of the Declarations of War team is either a member of Noir. or has been in the past. Alekseyev himself is the executor of the corporation. The primary host of the Declarations of War podcast, he holds many hats in EVE, from diplomat and mercenary to FC and CSM representative.
NinjaTurtle, the co-host of the podcast since joining the team, is a former director and FC of Noir. He currently flies with AQUILA INC. In addition to co-hosting, he edits and produces the podcasts.
JaredC01 is Noir.'s IT mastermind and currently flies with Black Legion. He maintains the Declarations of War website and provides technical support.
Ali Aras is the newcomer to the podcast. Currently a member of CSM8, she was a former client of Noir. when she was a director for Of Sound Mind. She recently joined the podcast to provide a continued link to the CSM and subsequently joined Noir. itself to start a new life of subsidized ship violencing.
Declarations of War is one of the best EVE Online podcasts out there. If you're interested in PVP or the goings on in 0.0, they an excellent source of information and entertainment. With professional-quality editing, they are always a joy to listen to if you want to keep up with the goings-on in EVE. You can check them out on their official website or subscribe to their iTunes feed.
Alekseyev wanted to end things with a "thank you" to each and every fan of the show. In his words, "you guys are awesome."]]>
Our first set of sessions, on PVP, was held from mid-October to the week before Rubicon's release and culminated in a large PVP roam attended by roughly 200 players! The participants (including us, the organizers!) learned a lot from the entire set of sessions and now we're ready to kick off our second track. With the release of Rubicon and the addition of ghost sites, we've decided to focus this track on Exploration.
As before, the sessions will start off fairly broad to help new players learn about the more general aspects of EVE, such as how to fit ships and get from point A to point B without difficulty. But past that, we aim at to teach players about using scan probes, finding exploration sites, showing them how to manage escalations, and even get into the dangerous unknown of wormholes! And once again, we'll cap it off with a CCP-led fleet.
This time, we will be holding sessions on the weekends in addition to during the week. This will allow us to provide the sessions to more players, not only those who are based in Europe. The full schedule can be seen below.
Modules - Nov 27 at 17:00 UTC
Fitting Your Ship - Nov 30 at 17:00 UTC
Making ISK - Dec 4 at 17:00 UTC
Piloting Your Ship - Dec 7 at 17:00 UTC
How to Scan - Dec 11 at 17:00 UTC
Data, Relic, & Ghost Sites - Dec 14 at 17:00 UTC
Ore, Gas, Ice - Dec 18 at 17:00 UTC
Combat Sites & Escalations - Dec 21 at 17:00 UTC
Wormholes - Dec 23 at 17:00 UTC
Exploration Fleet - Dec 27 at 17:00 UTC
How to Join
The New Player Training Sessions can be attended by joining the channel "New Player Training Sessions" in game. The channel exists 24/7 and is open for questions when a seminar is not being held. The previous set of sessions can be found on the EVElopedia and a full list can be found in this thread.
We hope all our new players will be able to attend and learn all about EVE Online!
Returning pilot? Visit Account Management for the latest offers and promotions.
Along with the rest of the world, we at CCP have been following the devastating impact of this force of nature. For the people of the Philippines, the situation remains critical. Even as aid starts to arrive from hundreds of locations across the world, more can always be done.
In the wake of this tragedy of almost 4,000 lives lost, over 12,000 injured, more than 1,100 people missing and three million displaced, it has been a heartwarming experience for us to see so many calls from our community to once again host PLEX for GOOD.
The community has spoken, and we will answer.
Beginning today, Wednesday November 20th, 2013, through Saturday, December 7th, 2013, CCP will be accepting PLEX for GOOD donations from our players. For each PLEX donated during this period, CCP hf. will contribute USD $15 to the Icelandic Red Cross to fund their aid efforts in the Philippines.
To make your PLEX for GOOD donation:
• Contract one or more PLEX to the "CCP PLEX for GOOD" character on a 14 day item exchange contract.
• Contracts will be accepted within 24 hours of submission, though usually sooner than that.
Please ensure the receiving character is the one named above, and double check the character is in the C C P Corporation to avoid contracting PLEX to the incorrect character. CCP cannot guarantee the return of PLEX contracted to the wrong character.
We cannot thank the EVE Community enough for the support, encouragement and dedication that you have shown to the PLEX for GOOD initiative over the past three years. Previous PLEX for GOOD initiatives have resulted in donations totaling over $100,000 US Dollars to those in need during natural disasters in Haiti, Japan, Pakistan and the United States. In total, the EVE Community has raised donations totaling more than $150,000 US Dollars for charitable causes since the first collection in 2004 following the Indian Ocean earthquake and Tsunami.
As a gesture of thanks, for each PLEX you donate CCP will give you two virtual in-game Sisters of EVE Food Relief “'Humanitarian' T-shirt YC115” t-shirts (one male and one female) for use in EVE to show your support for PLEX for GOOD. These t-shirts are currently being designed, and will be distributed on Tuesday, December 10th.
(Click To Enlarge)
CCP Bro will also have another Dev Blog lined up for you next Wednesday, November 27th, with more details of a surprise that will hopefully make this the most successful PLEX for GOOD drive to date.
To learn more about how this program works, please check out this FAQ for more information. You can also learn more about PLEX here. Please note that your contribution to PLEX for GOOD is not tax-deductible. For information on the Icelandic Red Cross (Rauði Krossinn á Íslandi), please visit their website at http://www.raudikrossinn.is/ or contact them at: Efstaleiti 9, 103 Reykjavík, telephone +354 570 4000, email@example.com.
- The EVE Community Team
Please note that CCP regards any scamming attempts surrounding PLEX for GOOD to be morally reprehensible, and any attempts at scamming relating to this program will be met with the harshest and swiftest action at our disposal.]]>
This is CCP Fozzie once again bringing you a dev blog covering our oh-so-close at hand EVE Online: Rubicon expansion which releases tomorrow (!) November 19th. This blog goes over the large variety of ship and module rebalances that will be hitting your hard drives tomorrow.
Like the similar blogs we produced for Retribution, Retribution 1.1, Odyssey, and Odyssey 1.1, this will be a summary blog that covers all the balance changes in the expansion. All of these changes have been discussed extensively on the forums over the past few months and if you have been reading Features and Ideas every day and/or flying on our Singularity test server nothing here will be a surprise to you.
As most of you know, rebalancing is a constant project in our development of EVE Online. We rebalance ships and modules every expansion for a variety of reasons.
We have been very happy with the results of our rebalancing initiative over the past year and a half, and we know many of you have enjoyed the results as well. We’re hoping that with your help we can continue this success well into the future.
And now without further ado, let’s look at Rubicon’s changes!
I’m mentioning these changes briefly here because they affect much of the ship balancing in Rubicon, but you should read CCP Masterplan’s recent dev blog to get the whole picture.
In Rubicon we are changing the way ships accelerate and decelerate while in warp, which will have the significant effect of making warp speed matter much more. The result is that small fast ships will warp faster, larger slower ships will warp more slowly, and tech one cruisers and large hold industrial ships stay the same. Like I said, nobody explains these changes with as much style as CCP Masterplan does.
The Interceptor class is receiving some very significant changes in Rubicon, the first and foremost being the large advantage they gain from the warp speed changes. All eight Interceptors are also receiving a role bonus that makes them immune to warp disruption bubbles in nullsec space. Combined these two changes make Interceptors the undisputed champions at their core role: mobility. Interceptors can screen and scout for fleets, hunt down and catch fleeting enemies, or dive deep into the vulnerable underbelly of a sprawling nullsec empire before the defenders can respond in force.
Beyond the class-wide changes, each individual Interceptor has also received a complete balance pass, with several of them getting dramatic updates.
Overall we’re very excited to see the new and improved Interceptors in your hands tomorrow with Rubicon, and we hope you are too. Zoom zoom.
Electronic Attack Ships have been underutilized since their introduction years ago and in Rubicon we wanted to give them a much needed shot in the arm. The whole class is receiving significant upgrades, especially in the range at which they can operate.
Every Electronic Attack Frigate gets a bit of extra hitpoints, some higher lock range and a very significant increase in capacitor recharge rate. We expect these ships will see much more use after Rubicon releases, and we can’t wait to see how you players make use of their new strengths.
Interdictors are a crucial class of ships for nullsec warfare, as they drop the warp disruption spheres that prevent enemies from fleeing the field of battle en masse. They are receiving significant changes in Rubicon, with vastly increased survivability, improved damage output, and a new mechanic for using their namesake interdiction sphere launchers. All four interdictors will also arrive on their targets much faster thanks to the Rubicon warp speed changes.
The Interdiction Sphere Launcher is having its reactivation delay removed, and replaced with a three bubble magazine, five second cycle time and a long 60 second reload time. The launcher will also be limited to one fit per ship. This change provides new fitting options for Interdictor pilots who no longer need to shoehorn on as many bubble launchers as possible and allows new interesting tactics involving the three bubble magazine separated by the reload time.
All four Interdictors are receiving upgraded resistances and a new 10% per level reduction in Microwarpdrive signature radius penalty to significantly increase their survivability and begin to change their reputation as flying coffins.
As an interdictor pilot myself, I know firsthand how good it can feel to drop a perfectly placed bubble on your horrified opponents. We hope these changes will help many more of you enjoy that feeling in the weeks and months after Rubicon.
The Marauders are some of the most dramatic changes were are making for Rubicon, and so it’s fitting that these are the changes that have garnered the most passionate feedback from our community and the changes where our designers have made the most adjustments to the plan to ensure that we send you the best possible result.
Marauders are seeing their role reimagined, with the new ship split into two roles that it can change between at will.
In normal operation the Marauders gain a new bonus to Micro Jump Drive reactivation delay, allowing them to jump about once a minute. They keep their old active tanking bonuses, and the Kronos and Paladin swap their stasis webifier bonuses for damage projection bonuses.
The most visible and dramatic change comes when the Marauder pilot activates their new Bastion Module. When in Bastion Mode, the Marauder cannot move. However in exchange it receives a catalogue of new advantages including immunity to electronic warfare, vastly improved defenses, and further increased damage projection to hit hard at long ranges. The Bastion Module has a cycle time of only one minute, but the Marauder cannot use stargates or dock for a full minute after the Bastion cycle ends.
The result is a ship that can quickly jump 100km in any direction, enter a special mode for increased range and tank, and then jump again a minute later. The new Golem, Kronos, Paladin and Vargur will excel even more at their old role in player vs. environment content, as well as being open to whatever other creative uses we know you players will find for these open ended mechanics.
These new ship additions in Rubicon have been thoroughly covered in CCP Rise’s recent dev blog, so I’ll be brief here and heartily recommend that you read his blog for all the details.
In Rubicon we are proud to release two special new ships, the Astero frigate and Stratios cruiser. These ships are produced by the Sisters of EVE faction and are built with exploration and long-term deployments in mind. They can both use covert ops cloaks, they both use drones as their primary damage method and they both sport stout armor tanks. They also have bonuses to scan probing and hacking. All in all they are excellently well rounded ships that can engage in many kinds of activities, including being perfectly suited for the new Ghost Sites that are also releasing in Rubicon.
These ships are available only from loyalty point stores from the Sisters of EVE faction and we know that many of you are eager to get your hands on them. Only one day left!
Another hotly discussed set of changes are our new series of Rapid Missile Launchers. We are releasing the new Rapid Heavy Missile Launcher in Rubicon, and at the same time introducing a rebalance and refocus to the Rapid Light Missile Launchers. These launchers shoot missiles that are one size smaller than the ships that use them and are therefore especially well-suited to targeting smaller ships with precision.
The new paradigm for Rapid Missile Launchers is the ability to deal large amounts of damage to a wide variety of targets in a very short period, followed by an extended pause to reload. They essentially provide the option to frontload damage, which should be especially useful for clearing smaller ships as part of a mixed fleet.
Check the discussion thread for all the numbers and details, and let us know what you think once you try out these launchers for yourself!
As a follow-up to the successful Command Ship balance changes made in last summer’s Odyssey 1.1 release, we are also making a cosmetic change to four of our eight Command Ships. The goal is to move them over to hulls that match the Tech One combat BC that shares their weapon type, creating some more variety, opening up options for our art team in the future, and making the differences between the command ships more intuitive.
As part of these changes:
These changes do not affect the performance of the ships in any way, although they do change the base tech one blueprint used to invent them.
Thank you all for journeying with me through our Rubicon ship and module balance changes. We are very happy to be able to release these updates to you as part of the expansion tomorrow, and we hope you will enjoy using these ships and modules as much as we enjoyed designing them.
This marks the end of my pre-Rubicon dev blogs, so I wish you all a wonderful last evening of Odyssey, and I’ll see you ingame tomorrow as we welcome Eve Online: Rubicon together!
Returning pilot? Visit Account Management for the latest offers and promotions.
One of the most popular if Pyfa, a long-standing tool which is popular throughout the community.
Pyfa was originally created by Sakari. A member of EVE's Linux community, he was rather disappointed in the lack of fitting tools for EVE which were native to Linux. There was the popular EFT, which had to be launched via Wine, imposing severe functional penalties at the time, or Quickfit, which had been abandoned and had several major flaws. He thus decided to take matters into his own hands and create a new one from scratch.
Originally, he wrote one using gtk+ for the user interfact. This was known as pyfa0 to the current developers. Shortly after it was initially released, Kadesh Priestess noticed the project. Having had the same concerns as Sakari, he hopped onto the IRC channel. He became involved in minor testing and offered suggestions for the program. Later, Darriele and Aamrr joined the effort and began helping out.
Aamrr tested and did suggestions, while Darriele became the became the primary UI designer. He developed the user interface which is still used by Pyfa today.
Eventually, they created a new version of Pyfa from scratch. Since then, they have maintained the program and added several new changes. Kadesh became the primary person involved in fixing bugs, maintaining the databases, and updating it. After a few years, Kadesh went on a year-long hiatus, and when he returned found that much of the team had gone missing. Thus, he took over the project completely. He continues to update it for major expansions, as well as doing research and development for future improvements.
A look at Pyfa
Pyfa is coded entirely in Python, a choice heavily influenced by EVE. Kadesh has several personal and work-related projects he has worked on as well. However, those are projects where he primarily does coding, not design, and none of them are as complex as Pyfa.
The biggest issues faced in developing and maintaining Pyfa have always been technical ones. If everything has not been planned properly, it may hit hard later. A good example of this is Pyfa's fleet system, which works, but was implemented as a set of dirty hacks. They do not affect most of the cases of how people are using Pyfa, but it makes Kadesh unhappy, to say the least. For such issues, he tends to take a problematic module and rewrite it from scratch rather than trying more hacks. So far, this has worked quite well.
Of course, the biggest issue with any open-source project, especially small ones like Pyfa, is a lack of people who can devote time regularly to help it. This is the one problem the team has yet to solve, so if you're familiar with programming in Python and are interested in helping, send Kadesh Princess a message! You could be of great help.
Though Pyfa is already a fully functional program and is incredibly useful to any player, that does not mean that development on it has ceased. In addition to constant updates when changes to ships, modules, or other things come to EVE, much backend work is still ongoing.
In order to make sure that future improvements to the calculating engine that fuels Pyfa can continue to be improved, the Pyfa team has been working on a project codenamed Eos. It is a general-purpose fit calculation engine, with a focus on maintainability and performance. Though it is still in development, a tremendous amount of progress has been made on it. Kadesh says it is currently 1000 times faster for the majority of real use cases, which will allow him to implement several interesting features once it's finished and integrated into Pyfa.
About the Developer
Kadesh Princess is the primary developer for Pyfa. In EVE, he is a fan of frigate-class solo PVP. The Interceptor and Stealth Bomber are his two favorite ship classes to fly. Besides that, he loves participating in PVP tournaments for their hardcore and fun nature, so any time his alliance Hydra puts together a team, he assembles.
In real life, he lives in Russia and works in QA for a major telecommunications company. Coding is one of his hobbies, but Pyfa provides him plenty of motivation and spends most of his spare time on it.
Kadesh would like to offer thanks to Entity for providing advice and assistance with Pyfa. Whenever Kadesh has a question about Python or EVE, Entity knows the answer. He's also looking for anyone who is experienced in developing UI in order to complete the Eos update. Anyone interested in helping out should drop him an e-mail.
Pyfa is a powerful tool for anyone wanting to put together a ship fitting (it's even used internally for putting together fits for dev roams, live events, and our rookie training sessions). If you want to theorycraft your ship or create a ton of fittings to play around with, check it out in its official thread here.]]>
Today I'm going to talk a bit about some of the math behind the warp speed changes coming with Rubicon (and I'm going to do it using graphs, which are vital to any good dev blog!) With the Rubicon expansion, there are going to be noticeable changes to your ship's mobility as you warp around New Eden.
For a long time, the options available for us to balance how ships warp around have been rather limited. The only really variable we could tune was the top speed. However, as I'll show later, changing this value only has a minor impact on the overall travel time of fast ships vs slow ships. Now that the ship rebalancing train has reached the Interceptor class - ships whose defining characteristic should be their ability to quickly get on top of a target - it was time to take the opportunity to do something about this. With these changes, we should see a more meaningful role for fast tacklers and scouts to be able to snare targets for their larger (and slower) friends.
Firstly, I want to make sure we're all aligned regarding what this does and does not cover. For the purpose of this blog, I'm talking about everything that happens in a warp AFTER your ship's velocity has reached the alignment threshold of 75% of its maximum speed, in a direction roughly oriented towards the destination. Before this point, your ship is simply aligning, not warping. Nothing we're changing in Rubicon affects this alignment phase, only what happens after you see the warp kick in.
A warp is split in to three phases - Acceleration, Cruise and Deceleration:
During the Acceleration Phase (as the name implies) your ship's speed is increasing, up to its maximum warp speed (measured in AU/s).
Once the ship has reached maximum warp, it will spend a period of time in the Cruise Phase. Here, it will cruise at its maximum speed, until it is time to begin decelerating.
The Deceleration Phase is mostly the opposite of the Acceleration Phase - The ship is slowing down from its cruise speed until it drops below its sub-warp maximum velocity. At this point, the ship exits warp, and everything returns to normal.
This graph shows the three phases for a cruiser hull performing a 30 AU warp. Acceleration takes almost 9 seconds, it then spends another 9 seconds cruising at 3 AU/s. Finally it spends nearly 22 seconds decelerating. All ships follow the same pattern, but with higher or lower top speeds according to their class.
For various gameplay and technical reasons (something to do with hamsters and nanites), ships in EVE don't follow the physical acceleration models that we might be familiar with in the real world (or whatever your favourite digital simulation of real-life might happen to be) - specifically Newton's 2nd Law. Instead we describe their motion during acceleration with the following pair of equations:
x = e^(k.t) and v = k.e^(k.t)
where x is the distance travelled (in metres) at time t (seconds), v is the speed (m/s) at time t, and k is a constant (sort of - see later).
For the deceleration phase, the equations are similar, but with a negative time coefficient (and an offset to handle the time/distance elapsed during acceleration and cruise).
So, what value does k have in these equations?
In the old warp behaviour, k=3 (acceleration) and k=-1 (deceleration) FOR ALL SHIP TYPES. Those caps are there because that is important! All ships, no matter their top warp speed, would accelerate at exactly the same rate. This means that for the average warp, the majority of the time is spent following that same curve whether you are in a freighter or an interceptor. Let's illustrate this with another graph...
Here is a graph showing the speed of the same cruiser from earlier, along with an interceptor doing exactly the same warp. Note that even though the interceptor has the ability to reach a top speed 4.5 times higher than that of the cruiser, it only completes the warp a few seconds earlier. This is the ultimate problem that we've tried to solve with the changes in the Rubicon expansion:
For most warps, faster ships should be noticeably quicker at covering distances than slower ships, so that we can have meaningful differences between ship class mobility.
Remember that constant k I mentioned earlier? Well here's how we've changed things. For any ship, k is now a function of that ship's maximum warp speed. This means that ships that have a higher speed will reach that speed sooner than a slower ship reaches its own (lower) top speed.
For the acceleration phase, k is equal to the ship’s maximum warp speed (in AU/s).
For the deceleration phase, k is equal to the ship’s maximum warp speed (in AU/s) divided by 3, but with a maximum value of 2. This maximum is in place to prevent ships with excessively high warp speeds from decelerating out of warp so quickly that they transition from "in warp, many AU away" to "next to your battleship and firing up tackle" in less time than the server, client and player can reasonably handle.
Here's a comparison with the same two ships as they will warp post-Rubicon:
Observe that even though the interceptor's maximum warp speed has been reduced from 13.5 AU/s to 8 AU/s, it still manages to beat the cruiser to the finish line in less than half the time.
The current design has the fulcrum set on T1 cruisers. If you're flying a T1 cruiser with no modifications to your warp speed then you will not notice any difference warping in Rubicon. Every ship that warps faster than a cruiser will see their acceleration increased (and therefore see significant reductions in overall time warping) and every ship larger than a cruiser will see their acceleration decreased (and therefore spend more time in warp). The small ships are being sped up by a larger degree than the big ships are being slowed down, so the average warp speed across the classes of ships is getting faster. These numbers are shown in the following table:
(Click To Enlarge)
Those are base numbers for each ship class. If you need to go even faster, then you have a few options:
Fleet warps will continue to work in the same way as before - all ships will use the warp profile of the slowest ship, so remember to Stay Aligned and you will arrive together! Similarly, acceleration gates will slingshot your ship using the same warp acceleration as a manual warp.
These changes are already on the Singularity test server, if you're keen to try and see how they feel. I hope you found this interesting, and that you enjoy everything coming in Rubicon.
Last one to that stargate buys the first round!
- CCP Masterplan and the Five 0 team
Returning pilot? Visit Account Management for the latest offers and promotions.
My name is CCP Fozzie and I’m here to bring you another dev blog covering our fast approaching EVE Online: Rubicon expansion, landing in just a few days on November 19th! Today I’ll be discussing two of the numerous medium sized changes that will be gracing our patch notes for Rubicon. These two changes are near and dear to my heart, as well as the hearts of many of you, our most passionate players. Both these changes are linked through a connection to Starbases, as well as by the role that our player-elected Council of Stellar Management played in helping us prepare them for you all.
Our most dedicated forum-watchers will probably already have guessed the two changes I am talking about:
New Ship Maintenance Array wreck and loot mechanics
Strategic Cruiser subsystem refitting in space.
I will be discussing the details of both of these changes, as well as providing some insight into the processes and journeys that led to where we are today. Firstly however I want to quickly discuss the Council of Stellar Management and their crowdsourcing efforts in particular.
The Council of Stellar Management (CSM) is our player-elected council that represents the needs and desires of our player community to CCP and advises us with the shared goal of making the best possible decisions for the quality of EVE Online. They are elected every year and we fly them out to our Reykjavik headquarters twice a year as well as constantly discussing the future of the game with them over forums and online chat.
The CSM undertakes a number of initiatives to help collect your feedback and convey it to us here at CCP. These range from actively reading the forums and passing us notable threads, to running live town halls like the one being hosted this upcoming Saturday, and organized crowdsourcing efforts like their “Reasonable Things” initiative.
The “Reasonable Things” initiative this last summer was intended to source a prioritized list of changes that are desired by the EVE community. CCP could then do an internal pass to determine how feasible the items were and incorporate the list into our expansion plans. The crowdsourcing used the same Wright-STV voting system that is used for the CSM elections to allow players to vote for more than one item and list their preferences in order. A total of 4090 votes were cast and the results were published this last August.
CCP has been looking for opportunities to incorporate this feedback into our expansion plans, and although some of the suggestions have proven infeasible, several will be reaching the EVE client in Rubicon and beyond.
Several of the items on the “Reasonable Things” list were already strongly on the radar of our gameplay teams, including the two changes this blog is covering.
(Click To Enlarge)
Ship Maintenance Arrays (SMA) are Starbase structures that allow players to store and refit their ships. They are common sights in many starbases, especially in uncharted wormhole space where stations are not available as a ship storage alternative.
The saga of the SMA loot drop starts a little over a year ago, in late 2012. At that time a destroyed SMA would eject all the ships it contained into space where they could be easily boarded or picked up by an Orca or Carrier. This provided a valuable conflict driver as players could expect the possibility of obtaining valuable ships as a reward for the effort expended attacking their neighbors.
This system however had one fatal flaw, in that ejecting the contents of a SMA into space separately could potentially mean hundreds or even thousands of ships entering space at one moment. Evidence from related situations had demonstrated that this kind of rapid ship ejection could cause extreme server load and even threaten crashes, which was completely unacceptable. A programmer was tasked with quickly correcting this defect to ensure that it did not cause any harm. The solution reached at the time was to simply delete all ships contained in a SMA when the structure is destroyed, therefore preventing them from ejecting and causing instability. It was acknowledged as an extremely suboptimal solution but it was deemed far better than the potential alternative.
When players (especially those living in wormhole space) noticed the change there was a fair bit of consternation displayed on the forums. We knew internally that we wanted to develop a more complete solution but fitting in the design and implementation of that solution into our busy release schedule was easier said than done.
The CSM was a key ally in this regard. Several CSM members (including but not limited to the wormhole dwelling delegates) were proactive in filtering and communicating the player feedback on this issue. They helped lobby to ensure that a good chunk of development time was dedicated to implementing a complete solution to the issue, in the earliest possible time slot. They also helped us validate our designs as they progressed, giving us valuable player feedback during stages of the process when we were not ready to announce the project in public.
In the end, the solution that has been implemented and will be releasing next week in Rubicon is as follows:
When a SMA is destroyed after Rubicon, it will drop a wreck. The wreck will contain ships dropped from the destroyed SMA, with each ship having the same 50% chance to drop that governs normal loot drop mechanics. That wreck will have special functionality that allows players to eject the intact ships out into space, where anyone can board them. You will also be able to fly up with a carrier or orca and drag ships directly into your ship hangar.
The act of destroying a SMA will now also provide a full killmail listing what ships and modules dropped and were destroyed.
It will not be possible to add ships to the wreck, and you can't board ships directly from the wreck since that would mean placing your current ship into it. We have also removed the multi-eject options from all SMAs and SMA wrecks to avoid node crushing volumes of ships entering space. You must eject ships one at a time.
The SMA and X-L SMA wrecks will have much higher hitpoints than normal wrecks, but can be destroyed, in which case their content disappears just like a normal wreck. They can only be salvaged if there are no ships left inside them.
This solution provides a far better user experience than the original behavior while also preventing any adverse effects from large numbers if ejected ships entering space at once.
We had been working on the design since earlier this year and it was an official part of the Rubicon release plan since August. This may cause some of you to ask the following question: why did we choose to keep the project a secret for so long? I want to address this question and hopefully provide some insight into our ongoing communications in the process.
The most important step in keeping your promises is to be careful what you promise.
It may seem like a truism, but this simple fact is very easy to forget and ignore. When most people break their word it’s not caused by a desire to maliciously deceive, but by recklessly overcommitting.
In game design this challenge is especially difficult, as player are just as passionate about the game as we are, and therefore can easily misinterpret a discussion of future ideas and options as commitments. As Devs we see the benefit of bouncing ideas off our community and sharing exciting (and often unproven) ideas for the future, but the nature of the game development means that priorities must be able to rapidly adjust to new realities and to bypass unforeseen roadblocks. This means that we must be careful not only what we promise, but also how early we share our plans with the community. If we had run into an unforeseen problem that blocked the implementation of this SMA change after announcing our designs it would have caused unnecessary anger and distress among segments of the community. This is why we elected to keep the plans away from the public eye until they were completed and to rely on the CSM with their non-disclosure agreements to provide player feedback.
Many of you will have already noticed that CCP developers tend to be very tight lipped about our plans for specific features and issues. This does not mean we are not working on those areas or that we don’t have an internal plan. It simply means that we are endeavoring to be responsible with how we set expectations. For issues that have especially strong emotional connections to segments of the community we will tend to wait until very late in the process before making announcements.
(Click To Enlarge)
Strategic Cruisers (Tech 3 Cruisers) are a special class of ships that can be customized by switching any of their five types of subsystems for alternatives with different bonuses. Introduced in the Apocrypha expansion, these ships have proven extremely popular. One of the most common player requests we have received over the years has been for T3 Cruisers to gain the ability to switch their subsystems while outside of a station hangar.
This has been a change we have desired to implement for a long time, but it faced a number of challenges along the way. Originally the idea of allowing subsystems to be switched directly on a piloted ship in space (when within range of a fitting service) was investigated and eventually discarded as infeasible due to issues updating the ship model dynamically.
During the development of the summer expansion, EVE Online: Odyssey, we once again attacked the problem, this time as part of a package of Starbase usability improvements. The design that was attempted for Odyssey was intended to bypass the original problem by allowing pilots to store their T3 Cruiser inside a ship maintenance bay and switch subsystems through a right click menu in that location while the ship was unpiloted and out of open space. This implementation was not only suboptimal from a user experience perspective, but also ran into its own hurdles and was eventually bumped from the Odyssey release.
During the development period of Rubicon, we took another crack at the problem, this time attempting to solve the original challenge of letting T3s refit while piloted and all the associated side effects. I’m happy to say they were successful and this functionality will be releasing on November 19th with the rest of the Rubicon expansion.
Below I will include CCP Paradox’s explanation the details from the feedback thread:
I'm happy to announce that with Rubicon, you will be able to refit your subsystems on your Tech 3 cruiser in space.
This change will apply to any fitting service in space, supplied by SMA, a capital ship with a fitting service (like the Orca) or even the new deployable the Mobile Depot.
Fitting the subsystems works just like in station, you can drag and drop to the fitting window to refit. Any modules that need to be unfitted will be returned to your cargo hangar. The replaced subsystem will return to the destination that the new subsystem was taken from. For example if you decide to use a new engineering subsystem from an Orca fleet hangar, the subsystem you currently have fitted will be placed inside the Orca fleet hangar.
While we are placing modules from your ship into your cargo hold, you can overload your cargo this way. It is important to remember this, and make sure you can safely store away the modules which were removed.
These changes should be especially advantageous to wormhole dwellers who had previously needed to travel to known space just to swap their subsystems. It is also an excellent change to release alongside Rubicon’s new Mobile Depots that will make refitting in space much more accessible to the masses. There are still more changes to Strategic Cruisers that will make their customizability really shine (dealing with the interaction between subsystem refitting and static rigs for example), but those will need to wait for our more comprehensive Strategic Cruiser rebalance at a later point.
We want to give a very special thanks to all the players who discussed these issues with us, and to the CSM for their continued work to help make EVE Online the best possible version of itself.
If you want to help make your voice heard through the CSM process, there are a number of ways to do so. The first and most important is to vote in the CSM elections. We run CSM elections once per year and they are open to all subscribing accounts. When it comes to having your say on how CCP gets advised nothing is more important than casting your vote. Never trust anyone who tells you your vote won’t matter, as they’re usually just trying to prevent you from voting to increase their own power (this kind of deception is both clever and within the spirit and rules of EVE, but that doesn’t mean you need to fall for it).
You can also communicate with the CSM directly through events such as this weekend’s CSM town hall that will be hosted on EVE University’s public mumble server and broadcast live over EVE Radio.
We here at CCP are very happy to be releasing EVE Online: Rubicon to all of you in just a few days on November 19th. We hope you enjoy these two changes as well as all the other hundreds of changes and features that combine to make an EVE expansion.
If you want to find out more about what’s coming your way in Rubicon, make sure to tune into the CCP live stream at 19:00 UTC tonight broadcast on our twitch.tv page. We’ll be discussing and demoing new features as well as hosting the world premiere of our new Rubicon trailer. I can’t wait to see you all in stream chat!
Thanks as always for everything you all do to make working on this game universe such a rewarding job.
Returning pilot? Visit Account Management for the latest offers and promotions.
We had some other goals prior to deciding anything about the event. We wanted to have the event story be more flexible and player driven, to act as something of a counterpoint to the more scripted story section of The Battle for Caldari Prime. We wanted to use social media to flesh out our event characters and allow people to obviously pick sides, though this goal ended up being put on the back burner due to time constraints. Finally, we wanted to run an event in more than one system at once to mitigate some of the participation problems that Caldari Prime ran into.
Our first brainstorming session yielded some positive stuff. The basic premise was that pirates were reverse engineering and "jailbreaking“ certain new technologies (mobile structures, warp enhancement, etc), some of which made the Empires very nervous. Once the Empires found out about this, they needed to put a stop to it, particularly before a certain new faction of independent spacefarers started looking any deeper into it. They would put out a call to raise a capsuleer militia and take them to the pirates' front door to obliterate their laboratories and hopefully destroy the research contained within. We decided that to flesh it out, we would use news articles and a chronicle. From here we worked out a route, some flavorful items for the pirates to hold, some more details on the story components, and the shape that we expected the event to take (of course, this latter part is very like predicting the Icelandic weather more than 15 minutes in advance).
On the day of the event we had our target systems reinforced, our developer volunteers in their pirate ships all ready to defend their precious research against untold numbers of capsuleers, and we were ready to go! We put out a news item giving those who wanted to fight for the pirates a direction to head in, both to give the actual pirate faction sympathizers a place to go, and to provide a way to get involved in the event for the criminally-minded of you who could not enter high sec. Players started flooding into the staging systems of Sarum Prime and Meves well in advance of the event, time dilation kicked in, and it quickly became clear that we needed to start moving some of the eager participants out early. The problem was, if we couldn‘t control the movement and make it more gradual, we ran the risk of running into more severe issues. We decided to reinforce Ihal and make a few broadcasts on Twitter and other social channels to direct people paying attention to these towards Ihal. This trickle effect worked well and helped deal with server load.
The Empire representative actors logged in and started to interact with people, forming them up and telling them where to go. Both fleets started to move towards pirate space, though this had not been made clear to everyone in the fleets due to the covert nature of the operation. Meanwhile, pirate actors were marshaling their forces in Utopia and FD-MLJ, ready to provide a stern resistance to the Empires and their affiliates. Some of the capsuleers turned away at the entry to low security space, unwilling to risk their clones for the Empires. More baulked at the idea of entering null sec, the area of space where pirates and alliances of capsuleers rule the roost.
Thanks to Maximus Aerelius for the screenshot! (Click to enlarge)
The force led by the Gallente and Minmatar jumped into Syndicate and the target system was announced – 8V-SJJ. They reached their target and began fighting the Vindicators of the Serpentis Corporation, who were backed up by their motley crew of capsuleers from FD-MLJ, among others. They succeeded in taking down the Vindicator forces, but were unable to destroy the mining outpost-turned-laboratory before the Daredevil getaway crew of the pirates managed to salvage the last materials there and set detonation charges to ruin any chance the Empires had of gathering any evidence. The pirate support fleet made short work of the remnants of the Empire affiliated capsuleers.
The Amarr-Caldari mustered-militias from Sarum Prime and Ihal had a tougher time ahead of them. Beset by time dilation and infiltrated by rogue intelligence gatherers from capsuleer alliances, they progressed along their route through low sec, oblivious to what lay in store just a few jumps along the route. With a ready supply of intelligence from the fleet, several alliances had set up a wall of warp interdiction bubbles inside the gate that led to Doril. Word of this got back to the Empire forces and they sat outside the gate, pondering the possible fate of those who had joined them. In the end, the need to destroy their pirate laboratory target was too great and they ordered the fleet to jump into the gate camp. Though this spelled certain death for a portion of their fleet, they hoped to get enough people through to reach their final destination and stop the pirates research. They failed. The coordinated forces of the interdicting capsuleers were able to pick off much of the fleet, though the Empire representatives did manage to get through Doril alive and muster what remained of their army. They reached their destination RMOC-W, but again were thwarted at the hands of the defenders who, as their counterparts in 8V-SJJ had done, gathered their materials, set their detonation charges, and fled.
In the aftermath, battle raged on. Pirate Dramiels and Daredevils sought their escape, many meeting their end on the journey, and their mysterious cargoes of Blue Boxes were lost to the pirates (though the purpose of the box is not yet known).
Now you‘re up to speed with what happened, we would like to address some frequently asked questions surrounding events in general, and some on the event last week. That being said, we know you will have many more questions and the team will be on hand to answer them in the comments thread. It‘s alright to be negative, but please remember to keep your feedback constructive.
Q. What was the expected outcome of yesterday's event? Was more than one result considered? Did things go to plan?
A. While there was an outcome that we anticipated; we wanted to leave the event as open ended as possible. We expected the Empire forces to successfully destroy the structure, interdict the pirate frigates who were trying to salvage what they could, and "win", so to speak. The actual outcome was different - the pirates won and got away with their research, and although the destruction of the structure was inevitable, the story impact of the actual outcome takes things off in a different direction than we had initially expected, which is cool!
Q. There has been talk in the past of better tools for live event teams. Is there any progress on this?
A. While the development priorities of the EVE project have not resulted in development of tools to improve the facilitation of live events at this time, the team has come up with some ideas to mitigate some of the limitations that the client and environment lend to the running of events. For instance, actor-driven storyline exposition may be contained to moderated chat channels in future so that players can follow the thread of the event without confusion developing through local chat. Ultimately, the old adage “a bad workman blames his tools” rings true once again, and working with the tools we do have to be as varied and flexible as possible in our events is the primary focus of the team. We learn more each time!
Q. High player interest is great, but causes Time Dilation bottlenecks. Can you foresee a way to deliver a more optimal live event experience?
A. We always strive to engage people and the participation figures at our larger events show that they aren’t just a niche experience. Balancing this with ensuring adequate server performance is tricky. We can control the size of events by controlling the information flow, but that creates the problem of having to be constantly up to date with what is happening where. For the larger events we use more large scale advertising, and this obviously pays off as we can see from the participation in this event and the Caldari Prime event, but this doesn’t always pair up well with ensuring a consistent experience for everyone and while there is an ongoing internal effort to improve cluster performance, it also forces us to be a little creative in our staging of events. We don’t have the magic recipe yet, but we’re getting better at engaging more people and we learn lessons on how to optimize the experience with every event. Different types of events can also be used to engage many people without causing undue load, for instance the Sanctuary Image Contest that we ran earlier this year, though these come with their own costs too.
Q. Are concerns about favoritism a barrier to running smaller, more specific events?
A. Favoritism is something we are extremely conscious of in the events team. We both seek to provide interactive content shaped by the players to add flavor to the EVE Universe, and to get involved where we can to enrich player created content. Obviously we can’t be at every event we are requested to be, so guidelines and rules have to exist to ensure we aren’t giving certain groups more attention than others. It is important for us to remember that the squeaky wheel shouldn’t always get the grease – just because there are particularly active or interested parties doesn’t mean they inherently deserve more of our time and attention than parties that are quieter but just as interested, or curious but not the type to ask for our help/time/participation. It’s also important to make sure we don’t show up where we aren’t wanted, hence our reluctance to run events in player owned null sec space, or wormholes (though there are plenty of logistical reasons in there too).
Q. Is it considered a pre-requisite to be conversant with large fleet doctrine in order to enjoy live events?
A. Absolutely not! While this event in particular had a focus on large fleets, and getting into null sec is obviously going to result in some fleet warfare, there are and have been plenty of event possibilities that would need no fleets at all, or small gangs, or can be interacted with solo. For the larger events, it is likely that they will trend toward being in fleets, but not necessarily utilizing the strict doctrines you see at high level play. One lesson we have learned through this event is that we should keep our actors out of fleets. While this is a concession to immersion for some people, it is also deemed necessary to ensure as level a playing field as possible. Therefore it is important for us to develop other ways than a fleet to keep people informed and able to participate. That being said, there are always plenty of player run fleets at events and many of these are well managed and openly joinable.
Q. Are there plans to host live events for those who enjoy different playstyles?
A. Experimenting with new things is definitely something that we are very interested in as a group. As outlined above, this event ticked a few boxes for us, but there are many more left un-ticked! We have an idea for an arc that has resource gathering mechanics in it to put our more industrial inclined players to the test, but we don’t have a timeframe for running it so I won’t go into more details at this time.
Q. Why did you use Twitter to get information to players about locations rather than using in game channels
A. This refers to us asking players via Twitter and other social communication platforms to move from Sarum Prime to Ihal. At the time, Sarum Prime had over 1000 players in it and was spiking heavy time dilation. Asking people to move using in game channels would have caused a mass move of players and that could have had impact on the health of the cluster. The safest approach to ensure a trickle rather than a flood of players was to use channels that would only reach certain amounts of players at once. For all intents and purposes, this worked well. That said, it would have been unnecessary if we had reinforced the staging systems correctly, which was an organizational mistake on my part.
Q. Why was Doril on the route despite it being a staging location for an ongoing war?
A. We wanted to get into Curse with minimal jumps to our target systems, and going through Derelik was the best way to do that. The other ingress to Curse that doesn’t involve going through player owned space is the Great Wildlands, which would have added a very large number of jumps to the route as well as making us stage from Gallente or Minmatar space for both events. We did not thoroughly research each system on the route, so we were unaware that Doril was a staging system until it was past the point of being able to do anything about it. That said, activity fluctuates and it’s reasonable to expect the space we want to use for events to also be getting used for other purposes, so whether these considerations should even be a part of event planning is a subject up for discussion.
Q. Movement and fleet coordination quickly became a problem. What would you do in future to mitigate these issues?
A. On the movement side, we would like to try using titans to bridge people to an event destination. That's certainly something we could see being very advantageous as well as giving people a chance to do something and see something they normally wouldn't in their usual gameplay. We did discuss that, during the event, there were problems with people falling behind due to being in different ships, or having to wait to jump through gates. This is regrettable and definitely not something we would like to happen again as it has many knock-on effects to the enjoyment of the event. The fact that some people left on time and still missed the event is something we are really sorry for, but sadly there was nothing we could do once the event had started. In terms of fleet coordination, it is likely now that we will move to an entirely player-driven fleet system, so this would be out of our hands. We will look into providing good intel channels for those who need to strategize at a high level. Ultimately, there are many people better suited than us to run these fleets and there were several examples of this on the day. To those who stepped up and ran great fleets, well done and we thank you.
Q. Why were the routes so long?
A. So that we had routes to collect more people on, and that felt like they came from the heartland of the empire. Also the longer travel time gives us exposition time for the story and casual RP while travelling tends to make the time go quicker. Unfortunately we did not account for time dilation in this calculation and they ended up being too long. This is something we will improve on in future.
Q. Will there be more wrap-up/post-action blogs like this for future events?
A. Yes. During the retrospective following this event the team identified that one thing we want to do is to have a wrap-up blog that catches people up with the whole story of an arc. That way if you only dip in and out, or if you aren't familiar at all with what goes on with events/story, you will have one place to go to access that information. Right now info tends to be scattered in a few different places and this is something we want to change. We are also looking into having an introductory dev blog prior to large scale events that catches people up with the story so far and gives them clear instructions on how to participate in the event, as that was clearly lacking here.]]>
The Rubicon expansion is all about control; taking it away from impersonal NPC systems and handing it over to you, the players. Rubicon is also the first direct steps towards our medium-term vision for the future of EVE. If you aren’t familiar with the goals we are working towards in this vision, I highly recommend checking out this update written by EVE Online’s Senior Producer, CCP Seagull. We’re not going to realize that entire vision overnight, but Rubicon is a significant first step in many ways.
One of the key ways we are working to realize our vision of engaging space colonization and shifting control into the hands of the players is through structures that can be built in space. Over the past months the programmers of Team Five 0 and Team Superfriends have been hard at work on breaking ground for a new space object framework that will be the foundation of our future space structures. This framework will open up some exciting options as we move forward, and is being used in Rubicon for the release of our first four Mobile Structures!
These structures all do very different things, but were all chosen for the same reason: to allow individual players more control over their local environment. These first four Mobile Structures also have several common features, which I will cover before going into the details of each structure’s function.
Unlike Starbases, these Mobile Structures belong to individual pilots, not to corporations. This means that players need not belong to a player corporation to deploy them, and that their services generally apply either to the single character that deployed the structure or to everyone equally. It is very likely that we will add more Mobile Structures in the future that require and interact with corporation membership, but for now we’re starting from an individual perspective.
Previous structures in EVE have required several steps to fully activate in space. You would right-click on the structure in your cargo bay, launch "for corp" or "for self", right-click again to anchor the structure, right-click again to online it.
With the new Mobile Structures we have cut all the fat from the structure deployment process. You can still use the right-click menu if you prefer, but I expect most people will enjoy simply click and dragging the structures straight from their cargo bay into space.
Once in space, the structures will automatically start their activation process. The amount of time required varies depending on the structure, but all of them use the same easy to read circular display to show how much time is left in the activation. It's worth noting that this activation time is affected by time dilation, so the structures do not become more powerful in larger fleet fights than they are in other situations.
Once the activation delay has completed, that’s it! Your personal Mobile Structure is ready and working in space beside your ship. If you are using one of the modules that allows re-use, you can scoop the structure instantly whenever you want through the radial menu, or right click menu.
The flipside of mobile structures being light, inexpensive and available to all is that they also need to be easily attacked. When a pilot shoots any of these four mobile structures, the most severe penalty they will ever receive is a crimewatch suspect flag, making them free targets for all other players for 15 minutes. CONCORD will never retaliate against a player for shooting these structures, and shooting them will never result in a security status loss. This means that Mobile Structures must be defended either by active pilots or by deploying away from the beaten path. The Mobile Depot does benefit from a special version of the reinforcement mechanic that allows a regularly active player to keep their Depot alive; more on that later.
Destroying any mobile structure will always provide a killmail and there is a chance of loot dropping from any mobile structure that has a cargo bay.
Now that we have the common threads covered, let’s look at each of our first four Mobile Structures in a bit more detail!
(Click To Enlarge)
The Mobile Depot is the most fundamental of Rubicon’s Mobile Structures. It is intended to provide a simple home base that can be placed anywhere in deep space and used for item storage and ship refitting. Depots will be the least expensive of all the Mobile Structures, falling well under 1 million isk worth of materials. They deploy with a one minute delay and require no skills to use. They also fit into almost all ships, taking only 50m3 of space when inside cargo holds.
Once deployed, the Mobile Depot provides 3000-4000m3 of cargo space and a fitting service, both of which are only accessible to the pilot that owns the structure. They can be deployed almost anywhere, with the only exceptions being too close to gates, stations or starbases. A Depot is also restricted from being deployed too close to another Depot (of any variety). This restriction on being deployed close to other item of the same group is common to all the new structures, with different ranges for each group.
Although it only has 17,500 effective hitpoints, the Depot is the only one of these four Mobile Structures to enjoy a reinforcement timer, and this reinforcement follows rules that are slightly different than other structures. When shot to 25% shield the Depot enters an invulnerable reinforced mode for exactly 48 hours, after which it once again becomes vulnerable. When it exits reinforced mode the Depot will have 0% shields. The shields will recharge naturally. As long as the shields remain below 25%, the Depot can be damaged into armor and then structure with no further reinforcement. If the shields reaches 25% charge, the Depot will once again be capable of entering reinforced mode. The twist is that at any time while reinforced the Depot can be scooped into cargo by its owner, allowing an active Depot owner to protect and move their Depot when it comes under attack. Scooping a Depot that contains items will cause those items to be first ejected in to a nearby can (this action is available regardless of the reinforcement state).
Fans of the Mobile Depot will also be enjoying two special upgraded variants available at the launch of Rubicon. Blueprints to manufacture the ‘Wetu’ Mobile Depot and ‘Yurt’ Mobile Depot will both be available only as loot in Rubicon’s new rare Ghost Sites. These variants will enjoy more cargo space and will be much harder for players to find using scan probes.
We expect the Mobile Depot will become a very common sight in New Eden after the Rubicon expansion lands, and that our industrious players will find many creative uses for refitting in space.
How will you use yours?
(Click To Enlarge)
The Mobile Tractor Unit is a simple device that nonetheless will have very significant implications for many EVE players. When deployed it automatically uses a built in tractor beam to retrieve wrecks and cargo containers within 125km and collect their contents into its gigantic 27,000m3 cargo hold.
The Tractor Unit only takes 10 seconds to deploy, and takes up 100m3 of space when stored in cargo. Like the Depot, it can be deployed anywhere away from Gates, Stations and Starbases, which means that it can be deployed inside missions (where NPC pirates are not interested in shooting it), asteroid belts, or on the field of your big fleet battle at the Infrastructure Hub. Like the Mobile Depot, if you scoop a Tractor Unit that contains items, those items will be placed in a temporary container in space that you can loot at your convenience.
The Tractor Unit has 50,000 hitpoints, and does drop loot when destroyed so vigilance is advised while using it. The speed of tractoring has been tuned to ensure that a friend in a Noctis or Orca is still both more effective than the structure, in addition to providing more stimulating conversation.
We’re very excited to see how people use these new Tractor Units, be it for PVE, PVP, or creative animated wreck art (I know you were thinking about it).
(Click To Enlarge)
The value of a disposable Mobile Cynosural Inhibitor will be immediately obvious to many pilots living in low security space. When deployed, this structure prevents all normal cynosural fields (but not covert cynosural fields) from activating within 100km. This allows groups of players to shield themselves from hotdrops, control how their opponents can deploy capital ships, and generally influence the low and nullsec battlefield in ways that have never been possible before.
The Mobile Cyno Inhibitor takes two minutes to activate, and lasts one hour in space. Unlike the previous two structures, the Cyno Inhibitor is a one-time use item that cannot be scooped back into cargo. Once it has been deployed it remains in space until either one hour has passed or someone pew pews it to death, whichever comes first.
The Cynosural Inhibitor has been tuned to be most useful to small and medium gangs, as the vast majority of its 160,000 effective hitpoints come from structure rather than shield or armor. This ensures that large fleets of logistics or capital ships cannot keep the structure alive under large scale fire. The Cyno Inhibitor also cannot be deployed in any location where its area of effect would overlap with another identical module.
The Mobile Cynosural Inhibitor is also the first of these mobile structures to require character skills in order to deploy. If you think blocking cynos is something you’d love to do after Rubicon releases, you should start training the Anchoring skill to level 3 so that you can be ready to go on day one.
(Click To Enlarge)
No EVE Online feature would be complete without opportunities for thievery, deception and backstabbing; and Mobile Structures are no exception. The new Mobile Siphon unit is designed to be secretly deployed near a hostile starbase tower where it will quietly intercept some of the moon minerals or reaction results heading to that starbase’s silos. The Siphon will not alert the owner of the starbase nor be automatically shot by that tower’s guns, meaning that the owners of the starbase must actively check on their territory in order to protect it.
Like the Cyno Inhibitor, the Siphon Unit is a one-time use item, and requires the Anchoring skill to deploy. Its cargo hold also has the unique feature of being accessible to all pilots, meaning that even the siphoners themselves will not be immune to theft.
CCP SoniClover has already released a separate dev blog covering the Siphon Units, so I will pass you to that blog for further reading.
Sharp readers will have noticed that I have been referring to all of these Mobile Structures as the “first four”. That is because we intend this to be just the beginning of our adventures with the Mobile Structure concept and our new space object codebase. Team Five O is already hard at work on another set of Mobile Structures planned for Rubicon 1.1, and we are investigating options for converting some existing objects (such as Mobile Warp Disruptors) into the new system and expanding the kinds of functions that the new style of space structures can employ.
Over the summer we asked the Council of Stellar Management to help us brainstorm a big list of potential future Mobile Structures, and that brainstorming session produced some good ideas. Now we want to open up the floor to all of you.
I’ve created a new thread in our Features and Ideas forum where we are asking you to suggest what kinds of Mobile Structures you would like to see in the future. We will take the best ideas from that thread and add them to the list we are already working from to help produce a roadmap for the future of these structures. We don’t want to limit your imagination, but also remember that some ideas may be more or less feasible than others so we ask that you understand that we cannot promise to implement every idea in the thread, even if those ideas may be very exciting and garner much support.
All of these four structures are live and working on our Singularity test server, along with the rest of the Rubicon expansion. We want to express a very special thanks to all of you who have helped us test the structures so far, as we have already made usability changes based on test server feedback. If you want to get your own sneak peek into the future of EVE, check out this page with information on how to set up your very own test server client!
I have been reading all the feedback on these structures in our Test Server forums multiple times per day and if any of you wish to let us know what you think after testing them, that is the best place to do it.
The first four Mobile Structures are coming your way in under a week in November 19th’s EVE Online: Rubicon expansion. I know I speak for all of us on teams Five O and Superfriends when I say that we are extremely excited for you all to try out these new structures and to see the amazing creative uses that our players will discover for them. We believe that Mobile Structures will be a dramatic positive change to EVE Online, both in Rubicon and beyond.
Thanks and I look forward to seeing you all in our Rubicon livestream on November 14th, in game and on the forums!
Returning pilot? Visit Account Management for the latest offers and promotions.
Like the name suggests, the ISIS is a tech tree system to identify ships in EVE. It presents all ships in the game in a visual and interactive way and illustrates clearly the skill requirement progression path for unlocking ships while giving players the high level information they need to decide which faction, ship group and ship to progress towards. The tree is dynamic and shows which ship groups and ships you are training for and will give you a clear indication when new ships have been unlocked or your ability to use them effectively has changed.
When you have Rubicon up and running after November 19th you should look for this icon in the Neocom root (the EVE “task bar”):
You will also have a way to open up the ISIS through a button link at the bottom of all Show Info windows for ships. It will then open up the ISIS centered on the ship of the Show Info window you opened it from. New players will get the faction of their selected character for the first time they open up the ISIS, but once you have selected a different faction and close the ISIS, the selected faction tree will persist next time you open it up.
(Click To Enlarge)
Goal-setting is an important part of playing a game like EVE Online. We measure “progress” by the skills we acquire, our wealth in the form of the in-game currency, the items and ships we own and last but not least we measure it by our ability to be effective in the activities we like to do. We saw a need to have a way to visualize progression in a centralized location. We defined the following goals for the feature:
We started with a concept of a visualization tree which would give players high level information at a glance regarding the different roles and purposes of factions, ship groups and ships in the game. One of the first things we did was create icons for the ship groups in the game. This will exist in the ISIS only to begin with, but if these icons prove successful in giving quick feedback on ship groups, we don't see why they couldn't be used in other areas of the game.
(Click To Enlarge)
In order to make the ship progression path clear we identified that we had to do some changes to the progression path itself. The first step was to change the skill requirements for numerous ships in the game to make the progression path make sense when presented in a visual way. This was covered in great detail in July 2013 by CCP Ytterbium in the blog The Great Ship Skill Changes of Summer 2013.
The next step was to make a complete overhaul to our Certificate system. Again, CCP Ytterbium released a dev blog about the matter in September called License to kill: Certificate overhaul where he explained how Team Game of Drones had been overhauling certificates as well as adding mastery to help players understand what to train next and have a better overview of how well they can fly and fit ships. Please read the blogs if you want more details about ship skill changes or the certificate overhaul, but they deserved to be mentioned here since that was a key component in making the ISIS what it is and having it meet its goals.
The changes made to certificates only covered those related to ships for the time being. We want to cover the other ones too and have plans to create a similar tree for progression in industry using the industry specific certificates. We have also had a good discussion with the CSM about expanding the use of certificates so that corporations and alliances can create their own set of certificates which they validate for certain roles and tasks. These corp certificates would include whatever skills corp leaders decide are valuable for their members to train. More on these things later, but we wanted to mention it to get the discussion ball rolling.
The certificate blog did cover mastery as well but since it's a part of the ISIS feature it deserves to be mentioned again. There is much more to flying a ship than just training the required Spaceship Command skills - while certificates make sense to represent the general evolution of your character, we wanted to introduce a metric to clearly make this point. The mastery of a ship is a collection of all certificates of the same level that are assigned to a specific ship. For example, the Megathron Mastery level 3 consists of all the certificates level 3 assigned to this hull, which are:
These mastery levels are then shown for each ship in the ISIS so you can keep track of your mastery level for each ship in the game.
Deciding what faction to progress within or what type of ship to fly or what variant within that type you want is something we have all thought of at some point. We wanted to assist players making those choices by giving high level information about each of these things so that drilling down to the exact ship you are looking for could be done in a more structural and conscious way.
We are introducing new icons to represent the high level characteristics and attributes of factions, ship groups and ships.
(Click To Enlarge)
The info bubbles will display the skills you still need before unlocking a ship group. Once you have unlocked it those skills will not be displayed in the info bubble and instead it will display the skills that affect bonuses of the ships in the group. This way you are getting contextual information without cluttering it with information that isn't relevant to you at each time. Of course if you still want to know what skills you have already trained to unlock the group, you can always open the Show Info.
(Click To Enlarge)
Once you have unlocked a ship group the info bubble will focus on displaying the skills that affect bonuses for the ships in the group. It also gives you high level info about the main attributes and characteristics of the group using the high level icons mentioned earlier in the blog.
(Click To Enlarge)
(Click To Enlarge)
Each ship will have its own Info Bubble consisting of high level icons which represent the core roles of the ship as well as all bonuses for the ship. The icons serve the purpose of giving players a high level understanding for what role the ship is meant to fill, but of course there is never a single “right way” to use ships and this is primarily meant as a base guideline.
We re-authored all bonuses in order to be able to reformat the layout for them. The old format which is used in the Description tab of Show Info windows had everything together in one field, which made it very hard for us to make any drastic changes to the layout and visual presentation of key information. With the re-authoring of all ship bonuses information we now have the ability to display the information in a way that makes it more efficient to read the key information about each ship. This will also make the process of changing individual values much easier since each bonus is authored as a separate entity. We hope you like the new formatting, if it gets good feedback we would also like to update the format of the description tab in Show Info windows.
Don't worry about the stats, it's just a mockup, the bonus to Medium Energy Turret damage isn't changing to 1000% :-)
Pirate faction trees will work a bit different from the 4 main factions because well, pirates are different. All pirate ships are engineered with technology from two of the main factions. To message this to our players we have a link to each pirate ship group to the relevant race. If the related ship group has been unlocked in the linked faction, the line will indicate it and the faction logo will be more visible. If it hasn't been unlocked however it will have a lower opacity. By clicking on the faction logo you can navigate to the linked faction and see your progression state in relation to the linked ship group. The linked ship group will pulse to give you a clear indication which group you are looking at. You will always be able to go quickly back to the previous viewed tree using the back button on your mouse, if you are so lucky to have one of those. The pirate ships all use skill bonuses tied to each of the two factions their ships derive their technology from and since they are both equally important we simply list both skill bars.
(Click To Enlarge)
When you open up the ISIS after having unlocked a new ship group, acquired a new skill that affects ship bonuses or reached a new Mastery level, you will get a highlight feedback on those areas that have changed. This draws the attention to the new and shiny things which you can now fly or fit in new ways. We look forward to hearing about your efforts towards mastering all the things. Here is an example of a tree that has been completely mastered to Elite.
(Click To Enlarge)
We are removing all functionality concerning certificates from the API (actually we will make all the functions return nothing and then remove them sometimes in the future) and instead we will add a certificate.yaml file to the SDE which includes all information about the certificates. Also the typeIDs.yaml file shipped with the SDE will contain two new fields for ship types, certificateRecommendation which lists all certificates that are recommended for that ship and masteries which is a list of certificates for each level of the masteries for that ship. We will make the new format accessible in the coming days, so watch the EVE Technology Lab forums for an early link to the new SDE for EVE Rubicon.
Where do we see this feature going in the future? The current information is mainly geared towards helping players decide where to progress to and what ships to pick for certain tasks based on your current ability to use them. In the future we would also like to give you more contextual stats related to your play style. So if you care about racking up the most kills or being resilient in a scouting roam or even be the most efficient at logistics you can be then seeing how ships have done in those situations would be helpful. Seeing historical data for the ships in the game can help you decide which ship has the most chance of being successful in certain situations.
That’s all for now, let us know what you think in the feedback thread and we hope you will enjoy the ISIS when Rubicon arrives on November 19.
Returning pilot? Visit Account Management for the latest offers and promotions.
CCP Fear reporting from Team Kuromaku. Our team is delivering a beautiful new character selection screen for Rubicon, the newest EVE Online expansion which will be arriving on November 19th. It will provide you with a great first impression of EVE as well as being more user-friendly than ever. Moreover, it will load super-fast, allowing you to quickly get to the good stuff of making ISK and blowing stuff up!
Fast and loose!
Two of our most important goals on this project were fast loading and an improved user experience. These are among the criteria we set ourselves, and they played a large role in how we defined and structured our work. Setting and maintaining clear, explicit goals is one of the prime design practices, as doing so helps us guide the project from day one and gives us a point of convergence for all our crazy ideas so that we are consistently moving in the right direction.
We believe in the importance of being able to immerse yourself in EVE without delay, hesitation or long waiting times. All work was optimized to make everything load quickly, and all designs we decided on had to take speed into account.
For instance, during the initial concept phases of the project we explored the idea of showing characters in full – something many of you have requested in the past on the forums, at Fanfest or at the many player gatherings around the world. However, once we started digging into it we just couldn‘t justify the amount of client load we would cause as we want to get you into the action as quickly as possible. The concept conflicted with our main goal, and had to go. We need to make decisions like this all the time, and goal-oriented design is incredibly helpful in keeping us focused.
(Click To Enlarge)
Simplicity is key!
Improving the user experience was another of our top priorities. To begin with, we streamlined the whole screen, ensuring that not only were all characters of equal proportions but that they were unquestionably the most prominent thing on your screen. We also felt that along with the actual portraits of your New Eden personas, the most important part of your view was the information displayed on each of them. You will now be able to see information about all your characters instead of just one at a time, providing you with a much easier way to decide which character to enter the game with.
In tune with our emphasis on fast loading, your choice won't take long, either. Each character’s information is more visually recognizable and structured than before, which allows you to get an immediate at-a-glance view. Icons are presented in a more minimalistic fashion, and hint at any changes since your last log-in.
As the screen is also now the first impression of the game client we wanted it to be themed by our great artists. We've incorporated tools so that the artists can change the entire color scheme to fit alongside whatever background we're using at any given time. This means we can have a dramatically different screen with each expansion.
The redeeming system has gotten a well-deserved makeover. If you have any items to redeem, you'll see at the bottom of your screen a panel that can be expanded to reveal them. Each item can then be drag-and-dropped on top of a character to place it in their respective hangar, and the same rules as before will continue to apply – the character needs to be docked, and items you place in the redeeming system can only be accessed in that particular station.
(Click To Enlarge)
Lastly, we have included timers for those on PLEX, ETC or trial accounts which will show the days remaining on your subscription. This is also available for multiple characters in training.
You can try out the new selection screen on our test server, SinguIarity right now or wait until Rubicon hits Tranquility on November 19th.
On behalf of Team Kuromaku I hope you will enjoy our new screen. If you have any questions, we have a forum thread here to provide the answers.
- CCP Fear
Returning pilot? Visit Account Management for the latest offers and promotions.
Kyle Yanowski has long been listening to EVE Podcasts. Being married with children, he found there were many times when he had chores or child-rearing tasks. He doesn't recall exactly who introduced him to EVE podcasts, but he quickly realized he could help relieve the boredom of tedious tasks. Mowing two acres of lawn with a push mower wasn't nearly as bad if he had four hours of Lost in EVE to listen to.
He naturally listened to a number of different podcasts, such as Bringing Solo Back, Lost in EVE, Fly Reckless, Voices from the Void, and Broadcasts from the Ninveah. When the former-kil2 became the much-beloved CCP Rise, Kyle decided he wanted to fill the void and create a podcast of his own.
He recorded the first one with his loving, indulgent wife and a gaming friend who did not play EVE. With his wife jokingly referring to EVE as “the other woman”, the first podcast covered dealing with avoiding the everpresent problem of “spouse aggro” and the much-beloved passtime of drinking. It wound up being quite a chaotic mess. Luckily, Connal Tara of the Fly Reckless podcast gave Kyle some editing tips which helped save it.
Even with these self-critical remarks from Kyle, the first episode was well-received by his fellow members of Red vs Blue. Random McNally, a fellow RvB member, took mock offense to a comment Kyle made and subsequently declared Kyle would forever be stuck with him on the podcast. Random is a former broadcaster and had wanted to get involved in a podcast in some way. Offering his services to Kyle was a natural move.
Zao Amadues similarly declared the show needed a beard (and, less importantly, a solo PVP expert) and joined up to provide his own segment. As the show continued to mature, they also brought in Zealot Comadrin, a real-life rookie, to talk about his experiences. They also eventually pulled in Ashterothi, a director of Aideron Robotics, programmer, and writer for TheMittani.com, to round out the High Drag panel.
Since the podcast has started, the response has been incredibly strong. The panel gets shout outs in local and EVE mails from fans. They work with other podcasters and bloggers to improve each others' work and make everything much better. The show has evolved from a podcast that celebrated the balance of life and EVE to much more. The show has hit a fantastic stride and the entire tea is excited to see where it and EVE take them.
About the Shows
Currently, the High Drag Cast records every two weeks, on Wednesdays at 01:00 GMT. Prior to recording, Kyle sends out a working document to the cast to help develop a theme for the show, as well as a list of topics of interest. The theme is a big part of every show and they try to tieall their discussions back to the theme in some fashion. For instance, Episode 21 was the “angry” episode.
Though Kryle has the final say, the entire group has ownership of the discussion and is able to edit the pre-show document. Because no plan survives first contact, often other ideas are brought up that are unexpected. Some of these are shelved for later dates.
Once everything has been brought to a good state, they meet up in Skype and finalize the outline, discuss things such as introductions and music, and remind Ashterothi to let other people get involved in the conversations.
Their recordings are uniquely broadcast live on twitch.tv, either on Fintarue or Zao Amadues's streams. This enables them to get immediate feedback and suggestions as the show is recorded. They record over Skype, but have been exploring more stable platforms such as Google Voice.
They have experimented with a few different editing programs, such as Sound Forge, Audacity, and Adobe Audition. Random and Kyle take turns editing, but are looking to normalize the process in the future.
In all, they estimate it takes roughly two weeks for one podcast to be “completed”. They must coordinate with guests, build content for the show, and collect enough topics to discuss. Then once the audio has been recorded, they have to begin the task of editing. Random estimates that for a two hour podcast, it takes him anywhere from six to eight hours of editing to get right.
The biggest challenges the show faces have been coordination. In order to make sure everyone can make it to the recording sessions, especially since they are streamed live on twitch, they have had to add a whole host of contingency plans in order to ensure they are streaming on time. In order to manage this, they have to have two streamers.
They also realize real life always comes first, which means sometimes people cannot make it. This is especially challenging when it comes to guest members of the panels. A single new panel member requires coordination of times, vetting questions beforehand, working on transitions, and much more. Going live can be difficult and the guests need to be made to feel at home and fit in.
Sometimes they make the same mistakes over and over. Some are even enough to ruin an episode or make editing especially difficult. In order to minimize them, Kyle created a checklist for all panel members to follow, such as turning off cell phones, no angry typing, don't say anything you'll regret, don't eat your microphone, and remember to let others speak.
Even editing can be difficult, as setting aside six to eight hours on busy weekends can be tough. Most of the panel members have family and family comes first.
About the Team
The High Drag podcast is put together by a dedicated team of six.
Kyle Yanowski is the founder and “boss” of the podcast. In game, he is a former RvB member and currently a director in the Gallente FW corporation Aideron Robotics. He pursues aspirations of being a dirty, filthy space privateer. Out of game, he is currently serving in the United States Army and dotes on his wife and young son.
Random McNally is the work horse of the podcast. Nicknamed the “Curmudgeon”, he is the oldest member of the podcast and has tried nearly every career in EVE. Random is currently a member of Red Federation and has a whole host of alts that provide ships to lose. Out of game he is a father of two teenage boys, has been marrier for over 20 years, and works for an elementary school as the head engineer.
Zao Amadues is the solo PVP guru. He is an evil pirate in a corp called the Rifterlings. He also livestreams and is an expert on fits, tactics, and smack talk. He is also a shoutcaster for the Syndicate Competitive League. Out of game, he is retired from the Navy and is currently a full-time student. He has a wife and children.
Zealot Comadrin is the podcast's “noob centrist.” He is a member of Aideron Robotics. In the real world, he is in the United States Army and splits his EVE time with his girlfriend.
Ashterothi is the resident walking game encyclopedia. He's a director in Aideron, is experienced in many EVE careers, and is a contributing writer for TheMittani.com. Out of game, he is a programmer and has a wonderful wife and newborn baby.
Fintarue acts as a crisic backup. He is a livestreamer and pirate in the Rifterlings. He carries the podcast live when Zao is unavailable.
The High Drag podcast is a great podcast that is only growing! Now that it's been featured with a Community Spotlight, it's already too late to be cool enough to have been listening before anyone else, but that doesn't mean you shouldn't start! The group behind it loves EVE Online, but they love the community even more. As long as people keep listening, they'll keep cranking out new episodes.
Kyle also wants to clarify what “High Drag” means. It's a play on an American soldier idiom for cool, “High Speed, Low Drag”. Since popular fan lore for EVE posits that warp drives create considerable drag on ships (accounting for the “submarine” physics of ships), he shortened the phrase to “High Drag” for the podcast.]]>