These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Market Discussions

 
  • Topic is locked indefinitely.
Previous page12
 

URAIL STATUS?

Author
Zaxix
State War Academy
Caldari State
#21 - 2012-01-23 20:38:50 UTC
Dezolf wrote:
RedFrog is a good courier service, no doubt, but the fact that you might have to wait up to 4 days for your package to reach its destination is what URAIL would do differently.

Your numbers are incorrect (http://red-frog.org/status.php) and mischaracterize our service. It's worth noting that our longest historical wait times were mostly in the midst of war decs and Xmas holidays (sometimes both). In our history, we've been wardecced in excess of 100 times (it's probably closer to 150) and have spent, on rough average, 50% to 60% of each year of operation under dec (in the last rolling year we've been decced 80% of the time). That said, **** happens.

To the topic at hand: (tl;dr--hauling is harder than it looks; recruiting is key; RL logistics models don't translate well to EVE)

It has been our experience that the hardest part of running a courier service is the recruiting. Almost no haulers are pure haulers. They’re a mix of industrialists/traders looking to maximize freighter value and PvP alts looking to pay the bills, and the latter outnumber the former. PvP alts are looking for AFK, low maintenance ISK streams--the more AFK, the better. Industrialists are looking for supplemental income and they generally prioritize their own project time over hauling since they make more ISK on production.

The most critical test of an “immediate” or FedEx model (I assume that is dispatch + hub model) courier service in EVE is whether it can do so long term. As mentioned above, few pilots are hauling for the love of hauling. Services looking to recruit pilots to do immediate service or the FedEx model will have to overcome the AFK obstacle. The service would be asking someone to be ATK and waiting for orders to do work at the command of another player. That's something few EVE players are willing to do. And whether the pilot is ATK or AFK, if the pilot is on a run, they can't do any other runs, so the queue will eventually grow beyond the total number of pilots. Once the queue exceeds the total number of pilots, the service is no longer immediate.

The same goes for a dispatch model, but it ups the stakes and the complexity by forcing someone to take the role of dispatcher, a role that must be filled 24/7 without exception. It also further complicates things by making all deliveries dependent on at least two people (the hub hauler and the final delivery) and 3 with a dispatcher. If any link in that chain is weak, the whole system suffers. Pilot retention and happiness would become an overriding concern. One bad actor in the chain could seriously mess things up. Since some deliveries will be max volume and thus incompatible with multiple deliveries in a single load, it will be a recurring problem that one or more links in the chain will be unable to maximize efficiency by cargo consolidation (which is the only value of a dispatch model in EVE, since fuel costs are not a concern). That will require route redundancy (more pilots on the same routes) to pickup up the slack if the aim is to keep delivery times down.

I won't bore you with all the contracting and wallet issues that must be dealt with in a dispatch model, but we've actually gone through the process of creating a prototype dispatch model and doing some theory crafting. It was an absolute nightmare problem, and one that companies pay millions to solve in RL (http://en.wikipedia.org/wiki/Travelling_salesman_problem). Among the litany of issues to deal with are: who provides initial collateral; how to pay everyone when the courier contract system is built on single payer, single hauler; who pays the dispatcher; how do you calculate fastest routes; how do you calculate package volumes at the same time you’re trying to optimize routes; how do you factor in total collateral with the route and volume; who will do the inter-hub hauling and how will he get paid; what happens when your inter hub hauler isn’t available; what about when your end route hauler isn’t available; what happens when a hauler with 15 separate contracts disconnects for 8 hours; and, perhaps most critically, any solution to these problems is going to involve a programmer.

Burnout and turnover are constants no matter what model you use. I can’t even count how many haulers have worked for Red Frog since I first started. But out of all of them, few did it for more than 3 to 4 months, fewer still for 9+ months, and maybe 10 or so for a year or more. It’s very difficult to keep people when what you’re offering is a real job in a virtual world. That’s one of those things that doesn’t find its way into the conversation very often. Red Frog and other couriers are service industry jobs. Unlike producers and traders, who can work on a schedule and stop or start their overall business at will, service industries have to provide continuous, high quality service. Forever. That’s a lot to ask for in a game.

Does any of this mean you shouldn’t try? Absolutely not. If you can do it successfully, you’ll have my genuine admiration. But there are reasons we do things the way we do. While you're theorizing solutions, don't ever forget that much of what works in RL business works because of the threat of getting fired or going bankrupt. Not so in EVE. Its incredibly difficult to build complex business structures when you can't be sure if the linchpin is ever going to log in again (or if he is about to rob you blind).

Bokononist

 

Alain Kinsella
#22 - 2012-01-24 10:41:15 UTC
Zaxix wrote:
I won't bore you with all the contracting and wallet issues that must be dealt with in a dispatch model, but we've actually gone through the process of creating a prototype dispatch model and doing some theory crafting. It was an absolute nightmare problem, and one that companies pay millions to solve in RL (http://en.wikipedia.org/wiki/Travelling_salesman_problem). Among the litany of issues to deal with are: who provides initial collateral; how to pay everyone when the courier contract system is built on single payer, single hauler; who pays the dispatcher; how do you calculate fastest routes; how do you calculate package volumes at the same time you’re trying to optimize routes; how do you factor in total collateral with the route and volume; who will do the inter-hub hauling and how will he get paid; what happens when your inter hub hauler isn’t available; what about when your end route hauler isn’t available; what happens when a hauler with 15 separate contracts disconnects for 8 hours; and, perhaps most critically, any solution to these problems is going to involve a programmer.


One other point with the dispatch model - the routes and their times are clearly visible to everyone. Including gankers. This was the number one reason I had no interest in it, despite my usual shipment sizes being much better suited to URAIL's varying shiptypes (it irks me sometimes to have RF move a 'small' but pricy cache of PI mats, just because I don't have my own freighter).

I would like to see URAIL give it another shot, but would recommend you 'tweak' the dispatch model such that its within certain timeframes (by TZ ranges, by the 'shift' model, or something else). That allows you to both have a 'set time' to work with, and prevents an 'actual' time from being published (OpSec). It should also allow you to have multiple pilots take loads during each timeframe to simulate one shipment time.

BTW, if a buyback occurs (and you intend to continue) I'd be interested in some of those shares.

"The Meta Game does not stop at the game. Ever."

Currently Retired / Semi-Casual (pending changes to RL concerns).

Dezolf
DAX Action Stance
#23 - 2012-01-24 14:23:20 UTC  |  Edited by: Dezolf
Alain Kinsella wrote:

One other point with the dispatch model - the routes and their times are clearly visible to everyone. Including gankers. This was the number one reason I had no interest in it, despite my usual shipment sizes being much better suited to URAIL's varying shiptypes (it irks me sometimes to have RF move a 'small' but pricy cache of PI mats, just because I don't have my own freighter).

I would like to see URAIL give it another shot, but would recommend you 'tweak' the dispatch model such that its within certain timeframes (by TZ ranges, by the 'shift' model, or something else). That allows you to both have a 'set time' to work with, and prevents an 'actual' time from being published (OpSec). It should also allow you to have multiple pilots take loads during each timeframe to simulate one shipment time.


This was already in the system, pilots were told to include buffer-time in their routes, such that the written "dispatch" time was the earliest possible (customers were allowed to put up contracts 'till that time, so..), and the written "arrival" time was the latest (that is, customers were to expect that time of arrival).

_________
I will most likely come with a lenghty reply to you, Zaxix, here. A few initial things: I know of the TSP, I have studied it as part of my education. There are a lot of things that need to be worked out. And indeed, recruitment is the key. With URAIL (at least our current method of operation) keeping pilots is also necessary, because of the routes which were set up by pilots themselves.

Edit #1: FML, I need to remember to copy/paste stuff into notepad. I'll make a reply later. x.x
Zaxix
State War Academy
Caldari State
#24 - 2012-01-24 15:36:24 UTC
Alain Kinsella wrote:
One other point with the dispatch model - the routes and their times are clearly visible to everyone. Including gankers. This was the number one reason I had no interest in it, despite my usual shipment sizes being much better suited to URAIL's varying shiptypes

I don't think the previous URAIL model would qualify as a dispatch model. The most direct correlation I can think of isn't a freight model, but a bus/train/plane model. A dispatch model generally involves a central coordinator who is empowered to direct pilots to achieve the greatest efficiency. For example, pilot A is flying from Hek to Jita and while in transit a Dodixie to Jita contract goes up. The dispatcher does the math on volume, collateral, etc. then diverts the pilot to pick up. More like a bike messenger service. All of these models are somewhat muddled in the context of the game though.

and yes ctrl+A and ctrl+c everything on these damn forums.

Bokononist

 

Oxianes
Universal Railways
#25 - 2012-01-27 14:06:14 UTC  |  Edited by: Oxianes
Sorry for the late reply. School starting up again and then I got hit by illness.

Edit: Also, I want to thank Block Ukx for making this thread.

Alain Kinsella, re-reading your post, I missed a lot of your point. You're right, it seems like a good idea to have a "block"-time to simulate one shipment.
Shipment sizes were up to pilots, so more of a bi-product than actually intended. I'll keep that in mind, though.


Zaxix, you're right, my numbers are off. It was merely a worst case scenario, based on the values of which you ask your customers to put expiration- and completion times. I should have specified this, and for that, I apologise.

(edit: tl;dr, I know it's a tough nut to crack, but if it can work, efficiently, I want to make it work!)

I am aware that hauling is a side-activity, and the problem with asking people to be ATK while doing it is a big one. This was why people were to set up their own routes - so it fit best with their schedule. The problem, however, is that they couldn't just come on, do a contract and hop off again. However, with pilots setting up their own routes, we hoped to allow them to AFK as much of the route as they wanted. Whether or not this was the case, I cannot say.

Another reason we let them set up their own routes was so that they were as independent as possible, that is, we were trying to reduce the overhead. This was partly to avoid having a bad link in a chain, which would make the service crack. This, however, might also have lead to the service cracking - as we tried to push the responsibility on the pilots. By this, I mean that, if their route was full they were to communicate with the customer. Besides this, we asked pilots to actually do their routes, to notify us of absence, to do this and that.

Route redundancy is something that's bound to happen, for the reason you specify. But this is a problem that comes with a greater amount of pilots. We didn't mind having several pilots running e.g. Jita > Rens, but we did ask them to put up routes when there weren't any other routes. However, the aim is not to keep delivery times down per say, it's to keep delivery times consistent and on schedule. The system should cater to people who are dependent on their packages coming at a specific time - allowing people to plan around it, instead of sitting around waiting for a courier to arrive.

Please do bore me with the contracting and wallet issues. In fact, tell me all about the theory crafting you've done! I'd love to hear about it, especially since you've pointed out problems I hadn't considered to be problems. Then again, this is the main reason I'm calling out to hear if people wish to help start URAIL up again. We have to consider many things - even things that might not seem to be a problem as it is now.

It is a job. But again, that was the reason we asked pilots to set up their own routes - to better fit their schedule. Again, the problem is that they couldn't just log on, do a contract and log off again whenever they had the time.

A way to solve the "route full" problem would be to have an automated system where customers can see how much space is left on any given flight. A system like this was planned for development, along with a lot of other neat information for customers.

This is not an easy system to put into EVE. The fact that it's hard just draws me to it. But again, it's a problem that needs more minds thinking about it. If it can work in EVE - and work efficiently - I want to make it work. But I want to give it the best possible shot, and this is why I need more people to help me out. I don't want to see the project crumble because I didn't think about what would happen when a pilot didn't log on.

I might think about more later, but then I'll make a new post. (or an edit! :D)
Ave Volta
Perkone
Caldari State
#26 - 2012-01-27 21:40:49 UTC
One other point worth mentioning, is that the pain points and challenges that Zaxix describes are exacerbated by offering "express" or "on demand" delivery services.

Scalability and consistency is difficult as it is using the Red Frog model, and relies heavily on recruiting and maintaining a sizable fleet of active pilots as Zaxix so clearly pointed out. Express services would by necessity require an even greater pool of available active pilots who want nothing other than to haul, or to wait until a contract comes in. Not impossible, but not an easy thing to achieve by any measure.

Black Frog Logistics - Lowsec/Nullsec Logistics Services. Join ingame channel 'Black Frog' for more info.

Previous page12