Multiplayer mode - second hand vehicles

[VS]

An interesting idea appeared in Czech board (link): Vehicles removed by one player could be bought again, by any player, for a new price.

There are many possible ways to go about this. On one hand it could be a complicated exchange, on the other something with literally no interface. Your opinions?

note: Native speakers, please suggest some better title for the thread

[vilvoh]

I like the idea, although I've doubts about how much complexity would it add.

A possible solution: vehicles removed by a player can be bought by others through their headquaters or closest depots. Vehicles should be cheaper as they've been already used.

PD: alternative tile...pre-owned vehicles shop

[uktrain]

That sounds nice because there's a lot of transportation corporations uses old vehicles from other corporations.The new price should be lower than that of the brand new ones.I think we can do so by clicking other player's depot(and it would show a number near the vehicle indicates how many vehicle in the depot;others can purchase by clicking on it)It would defiantly saves others money to buy vehicles.

PS.I think the title should be "secondhand vehicles" rather than the existing one

[vilvoh]

I don't remember if players can interact with other player buildings. At least, you as public service can't access to other players depot although you click on them..

[jamespetts]

This is an excellent idea, and one that I had considered before. The implementation that I suggest is this: in a multiplayer game, when selling a vehicle other than to other players, one should receive only its scrap value - perhaps 2-5% of its purchase price. Any vehicle in a depot could, however, be put up for sale. Any player could buy the vehicle through any depot, just as if he/she were buying new vehicles. There could be a simple option to show secondhand vehicles and/or to show vehicles currently up for sale: when the option to show secondhand vehicles is selected, instead of all the vehicles that are within their introduction-retirement date range being shown in the depot window, all the vehicles put up for sale by other players would be shown. The selling player should be able to set the asking price. The selling player would be able to withdraw the vehicles from sale at any point before they were actually purchased (in case of network lag, a purchase would take precedence over a withdrawal from sale).

This option would work very well with the option of disallowing the purchase of obsolete vehicles that has recently been introduced in the Standard nightlies. It would create a fascinating internal market in secondhand vehicles, which might, in some cases, even be better (at least, in some respects) than vehicles that can be bought new.

[VS]

Yes, complexity was a concern to me, too. The way I thought about it was the simplest possible - with no interface at all

Since in Standard there are no effects of ageing, old vehicle is no different from new, except for price. Thus it is always in the interest of player to sell vehicles as soon as possible, if not needed. On the other hand, when (hypothetically) re-buying, older vehicles are better because their price already dropped.

So, selling could happen exactly as now, and buying would get you a second-hand vehicle for a lower price, if available.

To prevent cheating by buying/selling vehicles to fill the second-hand "pool" and waiting for price to drop, set price for re-buying = selling price + 10%.

[jamespetts]

VS,

the problem with a "no interface" approach is that one might be playing a game in which purchasing obsolete vehicles is disabled - that should not apply to secondhand vehicles. And how would the sale price be set in "no interface" mode?

[VS]

James: Well, in my model, price would not be set by player...

Myself, I started this topic here and not in ext. requests mainly to see the possible visions, not to actually request anything That, too, is the reason I didn't put my idea in the first post, so as not to steer the discussion somewhere...

The difference between our two approaches actually correlates well with our approach to the game, I think _{(I am interested in knowing both)}

[prissi]

Old versions had this by accident: YOu could drive into other players depot and the ownership changed ...

[skreyola]

I think it's a great idea to allow selling of vehicles.
The player who sells it should get some price for it, and it should go to a third-party reseller. The vehicles offered by this reseller would appear best, I think, in a special "Pre-owned" tab of every player's depots, which tab would always be visible in multiplayer mode and would not filter its results by obsolescence (but perhaps by vehicle age?). The vehicles for sale here would be cheaper than new ones, but each one would keep its original age data, so that its age could affect any factors based on it (and make any future or experimental age-related cost factors more feasible).
:support:

[jamespetts]

Skreyola,

out of interest - what advantage do you see in mediating through a third party?

[Ashley]

This is a good idea, I remember this was a good feature of games like Imperium Galactica, where you could pick up second hand starships from other players.

[skreyola]

Skreyola,

out of interest - what advantage do you see in mediating through a third party?

I'm not sure which of the two or three directions I can figure you're coming from in asking this.
If you're asking whether there's a coding benefit to putting preowned sale data somewhere special, I'm not sure, though I suppose it could make it easier to only include such code in multiplayer compiles. Beyond that, I don't know enough about the code to say.
IF you're asking whether there's a gameplay benefit, I think the advantage would be that once player A has decided to sell that old loco, he no longer has to worry about it, and he already has his money, rather than waiting for player B to decide she wants it, and then have the funds transferred directly between the players.
From a refereeing point of view, it makes it easier for the adjustment of prices (and the lack of choice in asking price (I believe it should be calculated, rather than left up to the player)) to be rationalized.
I know both routes are used in the real world, but I think having each company handle its own legacy stock is not the most desirable model.

[jamespetts]

Wouldn't that rather take the fun and interest out of having a real economy build up in secondhand vehicles? If players can set their own prices, the price will depend on the actual supply and demand, which will be much more interesting than a precalculated sum. In any event - on what would the precalcualted sum be based? The existing vehicle costs are based on the cost of constructing the vehicle, but completely different cost considerations apply to secondhand vehicles - how would these be deduced?

[skreyola]

Perhaps the player should be given a "reasonable range" with a slider (to keep people from asking 1,000,000.00 for a horse) for the best of both worlds?

You'll have to come up with a formula, if the AIs are ever to offer their vehicles for resale, so I don't think this is an extra step. No clue about what should be in the formula, as I am not an economics expert.

[jamespetts]

Hmm... - but why shouldn't people offer 1,000,000.00 for a horse? The mechanism to determine whether that's reasonable is surely whether anybody is prepared to pay that?

[sdog]

This makes sense if multiplayer develops to an competitive environment with several different large companies, likely on a large map. If it is mostly cooperative play, or on small maps its not that usefull i think. The market is so small and has such strong sources that it would need an artificial drain, simulating resale to poor countries.
Afterall most of the time all players are expanding, most sales of vehicles will happen if a vehicle becomes obsolete or if a new model is considerably better. In both cases no other player will buy, the running costs are more dominant.

I think the always reducing resale prices of vehicles are quite good, realistic resale prices would be ruled strongly by depreciation of the investment.

[jamespetts]

This makes sense if multiplayer develops to an competitive environment with several different large companies, likely on a large map.  If it is mostly cooperative play, or on small maps its not that usefull i think.

I should hope that Simutrans's multiplayer gaming would allow for both types of play: a mix of competitive and co-operative play on a wide range of different map sizes to suit different people's tastes. That being the case, it does not make sense, I think, to develop a system that does not work well in cases where there is competitive play and/or larger maps.

The market is so small and has such strong sources that it would need an artificial drain, simulating resale to poor countries.
Afterall most of the time all players are expanding, most sales of vehicles will happen if a vehicle becomes obsolete or if a new model is considerably better. In both cases no other player will buy, the running costs are more dominant.

I'm not sure that it's right that players are expanding most of the time. There will come a point (and the more players compared to the amount of land, the sooner that it will come) when there is no room for further expansion. Consolidation will then be in order. Players will be upgrading their networks. A common form of upgrading is cascading, where new vehicles are introduced on major lines, the vehicles formerly serving those major lines being cascaded to secondary work,  the vehicles formerly undertaking that secondary work being cascaded to minor work, and the vehicles formerly undertaking that minor work being scrapped. Sale between players would allow cascading to take place between different companies as well as within them.

I think the always reducing resale prices of vehicles are quite good, realistic resale prices would be ruled strongly by depreciation of the investment.

The problem with the resale value as it currently works in Simutrans is that it bears no relationship to any other economic aspect of the game: a vehicle purchased longer ago is of no less actual value to the player than a vehicle of the same type purchased in the same month, so the depreciation is arbitrary. It would be different if, for example, maintenance costs increased with age, but they do not.

[sdog]

the vehicles formerly serving those major lines being cascaded to secondary work

This is something i never do, and i expect hardly anyone else will. The work to assign a large number of vehicles manually to a different line is just to much. To make it feasible some tool similar to your replacement tool or the withdraw all tool would be needed. (could be quite complex to use)

I should hope that Simutrans's multiplayer gaming would allow for both types of play: a mix of competitive and co-operative play on a wide range of different map sizes to suit different people's tastes.

oh, i do hope the same, but if it actually happens depends firstly on how complex and large maps can get in multiplayer over the net, the stability of long lasting persistant world games (both technical stability and economic*) and most importantly if the players actually like to play like this! Perhaps it would be wise to wait a bit to see how it actually develops?


*it could be sensible to reduce the speed of the 'large' timescale (e.g. months and years) quite a bit, but retain the speed of the 'small' timescale on which vehicles move. The idea is to let it take a few weeks to get from 1900 to 2000 but vehicles should still move fast. Monthly infrastructure costs could be scaled up by the same (or allometricaly corrected) factor.

[jamespetts]

Sdog,

the asterisked point that you make is already a feature of Simutrans and has been for some time: see the "ticks_per_tag" setting in simuconf.tab. Increasing the number has the effect that you suggest.

In terms of cascading, the latest version of Simutrans-Experimental has an improved replacer tool that makes cascading much easier than it was even with the previous replacer tool - one can, for example, replace all convoys in line A with a new type, leaving the former vehicles of that convoy in the depot (having specified that the replacement should happen at the vehicles' home depot), then replace all the convoys in line B with vehicles including those discarded from line A, the vehicles left in the depot being the ones that would be used to replace the convoy rather than new purchases.

Economically, large maps and long timescales should work fine (although detailed fine-tuning would be needed after experimentation), as that is effectively what happens in single player games already. As to the technical challenges: the greatest problem would be when new players join, as they would have to download the whole map (effectively, the saved game) whilst the game was paused for everyone else. Thereafter, the only things to be transmitted over the network would be the individual players' inputs, so the size of the map, per se, should not make much of a difference to whether the network can handle the game: the number of simultaneous players would make all the difference. However, there is, of course, an element of uncertainty as to how the network multiplayer mode will work out in practice, and it does make sense not to implement any multiplayer specific features until a basic working multiplayer network game can be demonstrated.

As to whether players like to play in that style: I suspect that preferences vary. One thing that is clear is that the conventional model for online gaming (all players meeting together in an online environment at the same time to start the game, commencing the game when all are ready, and staying at their computers for the full duration of the game for several hours until the "end") cannot sensibly work for Simutrans, with its far longer timescales: players cannot possibly spend days on end at their computers!

Other online games with a long-term persistence exist in the commercial field, and tend to do better than equivalently in-depth games that require what I call the "conventional model" (as exists, for example, in multiplayer versions of Railroad Tycoon II and similar), although there are not a great many games of this genre that use persistent environments. World of Warcraft is perhaps the most famous persistent environment game, and it is enormously successful, but the genre is quite different. One of the most interesting attempts of late of making a builder/manager type game into a persistent online multiplayer experience was Cities XL with what was called the "Planet Offer": see the Wikipedia entry for it here. That was not a commercial success, as the uptake was significantly lower than expected, although the poor design of the basic game and the fact that players had to pay a monthly subscription fee to use the service were likely largely to blame, combined with the fact that the actual interaction between players in Cities XL was very limited: players would operate their own autonomous cities and only interact with others to trade items, which was ultimately a peripheral function of the game. Nonetheless, although less than expected, there were a large number of people who signed up for the "Planet Offer" service.

[sdog]

A very related example is open ttd, with a rather active multiplayer community. as i understand they are mostly playing cooperational though. This is in part caused by the economy being not too challenging, lot's of possibilities to saboutage other players and that people who like such network simulation games, or simulation games in general often prefer cooperative modes.

This doesn't mean i don't expect competitive play to happen, but the obstacles for competitive games are higher.

Multiplayer economies are very difficult to balance, having to do it in a changing economic framework, inherent for large timeframes, won't make it easier. I'm confident you can reach such a state, but it'll take several iterations in a 'live' environment. Greatly slowing down the progress of time should make it much easier, at least as a first step.

Does the ticks_per_tag also change the relation of monthly to 1/km costs and revenues? If yes, linearly?

I'll try cascading a bit, as soon as i got time for it.

[jamespetts]

Sdog,

I think that we're rather further ahead with the economy in Simutrans than they are in OpenTTD - they don't even have passengers with destinations there A number of features in Experimental - including the new routing - were designed at least partly with competitive multiplayer in mind; and there's much to be said for having multiplayer games with the public service player acting as a sort of referee to prevent abuses (and also playing as the national government with its own goals, to make the task of public service player fun enough for somebody to want to play it, rather than just a chore). That sort of system can work in a relatively small community such as we have with Simutrans.

Yes, the ticks_per_tag does indeed change all the monthly costs and revenues, and is (if I remember correctly) linear.

Do let me know how you get on with cascading!