15.x miscellaneous features requiring UI additions

[jamespetts]

I thought that it might be helpful to catalogue here the miscellaneous features (i.e., features other than the schedule features discussed here) in 15.x that require some additional UI work so that the UI development team (i.e., Ranran, Ranran and Ranran) can assist as necessary. I will update this as necessary.

Interest rate

In 14.x and below, there was a fixed interest rate for overdrafts of, by default, 10%. From 15.x onwards, there will be a variable base rate (changing over time as specified in prices.tab), with overdraft rates a fixed percentage (e.g. 2%) above that base rate. In 15.x, overdrafts will be the only use of the base rates, but, in future versions, it is planned to add other forms of borrowing with their own interest rates linked to the base rate.

It would be useful to have a graph somewhere showing interest rates.

Inflation

Similarly, many different prices change with time according to settings in prices.tab. It would be very helpful to have graphs showing the change of these prices with time.

Corporation tax

From version 15.x onwards, player companies will pay corporation tax. This will vary with time according to data set in prices.tab. Thus, players will need both to see a history of corporation tax rates and also to see how much that they have actually been paying in corporation tax, the latter in the finances window.

[neroden]

James... uh... I really wouldn't try to implement this for 15.x.  The money situation is so full of bugs right now which need to be fixed.

I've got a very good sense of how to implement interest and borrowing stuff (modelling money stuff is my bread and butter) but simutrans is tracking the money so poorly right now that I don't think it's a good idea to add stuff on top of a system which really needs severe rewrites.  Consider pushing this back to 16.x. 

What we need to do for money right now is to focus on getting the bookkeeping right.  First, tracking asset ownership and value for ways, piers, bridges, tunnels, and possibly even land properly.  Having cities have ownership. Making the "unowned" stuff have ownership.  Second, eliminating the ad-hoc "book costs" calls which are all over the code (and sometimes missing) in favor of a single "acquire-and-pay" routine, along with a single "estimate costs" routine -- this would eliminate a huge list of recurring issues.  Finally, enabling a buy-and-sell system to transfer assets.

[jamespetts]

James... uh... I really wouldn't try to implement this for 15.x.  The money situation is so full of bugs right now which need to be fixed.

I've got a very good sense of how to implement interest and borrowing stuff (modelling money stuff is my bread and butter) but simutrans is tracking the money so poorly right now that I don't think it's a good idea to add stuff on top of a system which really needs severe rewrites.  Consider pushing this back to 16.x. 

What we need to do for money right now is to focus on getting the bookkeeping right.  First, tracking asset ownership and value for ways, piers, bridges, tunnels, and possibly even land properly.  Having cities have ownership. Making the "unowned" stuff have ownership.  Second, eliminating the ad-hoc "book costs" calls which are all over the code (and sometimes missing) in favor of a single "acquire-and-pay" routine, along with a single "estimate costs" routine -- this would eliminate a huge list of recurring issues.  Finally, enabling a buy-and-sell system to transfer assets.

The inflation, interest and tax features are already in the 15.x code. However, I do not think that this will significantly complicate the work that you suggest to fix the issues with bookkeeping (which are very sensible - the current systems are as inherited from Standard and only changed as necessary for Extended features), as, if I recall correctly now from >18 months ago, the inflation/interest/tax code is at least fairly modular and not scattered about great amounts of bookkeeping code.

More sophisticated borrowing (i.e. cost of capital) has not been implemented in 15.x, but is planned for the future, as is a significant improvement in the way in which land ownership is handled to go with the planned (post-15.x) system in which players can buy land and rent it out to model the way in which many Japanese railway companies (and also the Metropolitan Railway in London) run/ran their businesses. The improvements that you describe to bookkeeping will definitely be worthwhile for these purposes (and, yes, definitely we need to track the ownership of land).

Also, if you have good ideas as to how to implement the cost of capital feature for a post-15.x release, then that would be very helpful, especially given your experience in the area. In outline terms, what I am after is (1) players having to borrow money to start, rather than starting with free money (although starting with free money should remain a simuconf.tab option); (2) players being able to use either debt or equity financing, or a mixture of the two; (3) realistic constraints on the amount of financing and the cost of capital based on the player company's past performance, or, for new companies, other factors, perhaps such as the recent past performance of other companies; and (4) realistic consequences of equity financing, albeit without all of the complexity of a stock market (perhaps simulating private rather than publicly listed corporations). The effect that I am after of all this is to be able to have a meaningful measure of return on capital investment, and a realistic cost of capital to balance the game more accurately.

As to a buy and sell system - this would definitely be worthwhile, and is already planned for vehicles (such that players must either find a willing in-game buyer for a vehicle to be disposed of or sell it for only scrap value), albeit this would require a fairly substantial investment in UI coding to make work.

[Ranran]

Can I ask if miscellaneous features are planned to be implemented at the same time as recombination features?
That is, the recombination feature will be implemented in (maybe) 15.0, and other features are planned for 15.1 and later.

The recombination feature alone is a lot of work, and it takes a lot of effort just to make it work and test it properly, so I think it's better to complete each feature in stages.
Also, I think many players are looking forward to the recombination feature and are looking forward to its implementation.

When it comes to implementing the UI, it is likely that someone different from the person creating the functionality will help.
When dividing work, I think it will be more efficient to code the UI if you present a simple appearance using something like an Excel sheet in order to clarify what kind of functions and displays you want from the UI.
Unlike people who are thinking about functionality, people who are trying to assemble a UI do not necessarily have a correct understanding of the functionality.
Prissi says that the current UI design of simutrans is similar to editing Excel.
For example, this is what I used when I proposed it somewhere before.

Once it's clear what data members are, how they're arranged, and how they're used, UI coders can get to work quickly.


In a related thing, Ves previously created a vehicle manager, but I'm not sure how it worked and how it was planned to relate to 15.x.

[jamespetts]

Can I ask if miscellaneous features are planned to be implemented at the same time as recombination features?
That is, the recombination feature will be implemented in (maybe) 15.0, and other features are planned for 15.1 and later.

The recombination feature alone is a lot of work, and it takes a lot of effort just to make it work and test it properly, so I think it's better to complete each feature in stages.
Also, I think many players are looking forward to the recombination feature and are looking forward to its implementation.

When it comes to implementing the UI, it is likely that someone different from the person creating the functionality will help.
When dividing work, I think it will be more efficient to code the UI if you present a simple appearance using something like an Excel sheet in order to clarify what kind of functions and displays you want from the UI.
Unlike people who are thinking about functionality, people who are trying to assemble a UI do not necessarily have a correct understanding of the functionality.
Prissi says that the current UI design of simutrans is similar to editing Excel.
For example, this is what I used when I proposed it somewhere before.

Once it's clear what data members are, how they're arranged, and how they're used, UI coders can get to work quickly.


In a related thing, Ves previously created a vehicle manager, but I'm not sure how it worked and how it was planned to relate to 15.x.

These miscellaneous features are already implemented on the ex-15 branch. It is necessary to implement a number of features at the same time because the aim of the 15.x release is to allow for full cost balancing, which would be very, very major progress for the game; but realistic costs balancing requires a number of features not present in the 14.x release, including those mentioned above.

Your suggestion as to how to present the UI elements that need coding is very helpful - I will have a look at doing that when I have a few minutes to remind myself of the details of this code and its data structures. One thing to note is that these features are all passive features in the sense that they do not require any new UI that takes interaction from a player: just UI that displays what is happening in the background (rates of inflation, interest rates, tax rates, etc.).

[neroden]

OK.  Explaining what I think should happen....

So first of all, I already believe that we need to track value for buildings and hard assets like that, so that the player's net worth includes them, and so that we have sane values for buying and selling them, and to simplify the buy-and-sell rules.

So, we end up with the player owning a lot of things, and iterating through that list to sum things up in order to do financial calculations.

The player should also be able to own things which don't have a particular location -- intangibles or semi-intangibles.  (This could be used for trackage rights or for all kinds of things.)

So for a more complex money simulation... the player then also has a list of *liabilities* which they "own" (are responsible for).  Bonds issued.  Stocks issued.  These are full-fledged objects.

The financial system can then run through them and do whatever math needs to be done.  They can be essentially modular, and should be specified in the pakset.  So we'd have a "bond.dat" and a "stock.dat" and a "bankloan.dat".  They could become available during different years and become unavailable during different years, as they did in real life.

This would also later allow us to write code so that players could buy stock in each other's companies, if we wanted to (Railroad Tycoon style).  For one player, the stock is an intangible asset, while for the company which issued it, it's an intangible liability -- in each case it's just in a list of assets and liabilities controlled by the company.

So basically I believe a lot of this belongs in the pakset.  We should make a design which allows for financial asset and financial liability objects in the pakset, and then do the detailed tweaking of what's available at the pakset level.  This should be elegant.

[neroden]

These miscellaneous features are already implemented on the ex-15 branch. It is necessary to implement a number of features at the same time because the aim of the 15.x release is to allow for full cost balancing,

This is not possible.  Put it off until 16.x.  At the moment there are several major obstructions to this goal:
(1) The costs displayed in the preview menus are not the same as the costs which the player actually ends up paying
(2) Whether you can buy stuff while over your credit limit is wildly inconsistent
(3) Demolition costs are also very confused and even inconsistent based on METHOD of demolition
(4) There's no scrap value for dismantling a building; economically this is wrong
(5) Economically speaking, you can't balance the lending system until hard assets (piers, bridges, stations) have a value and can be borrowed against same as convoys can

You have to get this stuff straightened out before you can do a full cost balancing.  Period.

[jamespetts]

Thank you for that implementation overview - that is helpful. That is certainly a sensible thing to be looking into for the future.

This is not possible.  Put it off until 16.x.  At the moment there are several major obstructions to this goal:
(1) The costs displayed in the preview menus are not the same as the costs which the player actually ends up paying
(2) Whether you can buy stuff while over your credit limit is wildly inconsistent
(3) Demolition costs are also very confused and even inconsistent based on METHOD of demolition
(4) There's no scrap value for dismantling a building; economically this is wrong
(5) Economically speaking, you can't balance the lending system until hard assets (piers, bridges, stations) have a value and can be borrowed against same as convoys can

You have to get this stuff straightened out before you can do a full cost balancing.  Period.

I have to say that I don't quite follow this. May I ask what it is that you think is not possible? As I wrote before, the inflation, interest rate and corporation tax features are already implemented in the 15.x branch. That which has been done, by definition, is possible.

The cost of capital features I agree should await a later version, hopefully after the accounting improvements to which you refer.

Edit: Do you mean that the cost balancing is not possible until the 5 issues to which you refer have been remedied? Re-reading this, this appears to be what you mean: apologies, this was not clear on the first reading.

The difficulty is that it's not really possible not to rebalance the costs once we have the inflation feature implemented and all of the other features that affect costs such as splitting staffing and fuel costs, etc.. Keeping the existing balance is not possible in that instance. The aim is for the balancing to be based on historical costs - so it is not as if these will change when we fix the above five issues. The calibration of categories of costs as against one another may need adjustment - but that is a different exercise to putting in the individual values.

[neroden]

Edit: Do you mean that the cost balancing is not possible until the 5 issues to which you refer have been remedied? Re-reading this, this appears to be what you mean: apologies, this was not clear on the first reading.

That's what I mean.  This sort of thing has been tried before.  If you put in historical values for the vehicle costs and revenues but you don't have the fixed asset valuation structure right, the economics come out wrong, and you *will* end up with an unbalanced pak.  It *will not balance*.  You have to have all the pieces in at the same time before you can balance it.

Highly-paid teams making for-profit AAA games with economic simulations have run into this repeatedly.  (For us, it's just an annoyance: for them, it means real customers demanding refunds for the game they're selling.)  You *cannot* do this in the wrong order.  It doesn't balance.

If I ever get the endless infrastructural scutwork caught up, my top desire project for Simutrans is *still* to stop rotating the world so we can do rotated views in a multiplayer game.  (Also removes massive amounts of hairballs of code.)  And my other top desire project is eliminate the utterly bogus hack where meters_per_tile isn't actually changing meters_per_tile but is changing the game speed instead, which also removes massive hairballs of code.

But after those two projects, a possibly easier project is to track everything that each player owns (including land and buildings) and have a unified asset value tracking feature.  That might actually be easier than the other two projects I just listed.  There should also be an asset list for each city, and one for the "unowned" stuff.  An 'audit' routine would run through all the assets and add up the current maintenance costs as well as adding up the current values (for borrowing or selling purposes).

At any given time, each building / pier / track / etc. type asset should have an initial construction cost (and initial value should equal that), a current value, a scrap value, and a demolition labor cost.  (Demo costs = demo labor cost minus scrap value).  Most of these should probably be computed from a more basic set of values.  (Scrap values and demo costs can vary independently and there's good reason to keep them separate under the hood.)  It should only be possible to demo things you own, so you should also have to buy the roads, buildings, etc. before demoing them.

Each building/pier/track should also have an owner and a jurisdiction (city), though the jurisdiction exists only for enforcing speed limits and the like.

Land should primarily have an owner and a value, though maybe it could be used to handle construction costs for earthmoving.

The confused calls to book_* which are all over the code need to be cleaned up.

book_construction_costs *has* to stop being used for anything but earthmoving.  Everything else needs to run through an object routine (whether it's "build me" or "destroy me" or "modify me").
 
It should be possible to call an asset to get its construction cost -- and its current deomlition cost -- and have that be accurate (for display purposes), and to call a separate single routine to say "book costs for me" which calls the same construction cost calculation routine.  Diagonal waytypes are an issue, of course, but I think we can solve it.

This honestly shouldn't be too hard, but it touches so much code that I really want to do it after getting all the pending patches from standard in.

The UI would need some sort of way to display the list of buildings owned by the player, and then another way to summarize the track/ways/piers owned, and another way to summarize the land owned (because we would not want to list all of that).

So then... the player also has another class of assets, which are also objects but don't have a location, for financial investments.  The UI will need to have a window where a list of these can be seen -- pure spreadsheet stuff.  And then a final class of financial liabilities, which would be one more spreadsheet.  As I envision it, the liabilities window would be sort of like a depot, only you would "issue bonds or stocks" from a selection of possible types, and then they would appear in your list of financial liabilities (with the cash being added to your account balance).  Same with financial assets.

[jamespetts]

That's what I mean.  This sort of thing has been tried before.  If you put in historical values for the vehicle costs and revenues but you don't have the fixed asset valuation structure right, the economics come out wrong, and you *will* end up with an unbalanced pak.  It *will not balance*.  You have to have all the pieces in at the same time before you can balance it.

Highly-paid teams making for-profit AAA games with economic simulations have run into this repeatedly.  (For us, it's just an annoyance: for them, it means real customers demanding refunds for the game they're selling.)  You *cannot* do this in the wrong order.  It doesn't balance.... [snip]

The trouble is, as I wrote above, I cannot simply leave it as it is because that would also not balance - the current interim balance will be very significantly affected by the features that are already in the 15.x code.

[neroden]

Just consider it an ongoing, interim unbalanced state.  My point is don't work too hard on balancing, because *you can't* until we get those other projects done.

[jamespetts]

Just consider it an ongoing, interim unbalanced state.  My point is don't work too hard on balancing, because *you can't* until we get those other projects done.

If I understand the list correctly:

(1) The costs displayed in the preview menus are not the same as the costs which the player actually ends up paying
(2) Whether you can buy stuff while over your credit limit is wildly inconsistent
(3) Demolition costs are also very confused and even inconsistent based on METHOD of demolition
(4) There's no scrap value for dismantling a building; economically this is wrong
(5) Economically speaking, you can't balance the lending system until hard assets (piers, bridges, stations) have a value and can be borrowed against same as convoys can

No. 5 is the one that appears potentially critical for core balancing, along with a cost of capital feature. The others may cause some trouble until rectified, but should not either alone or in combination with one another affect core balancing.

Given that balancing is the most fundamental aspect of a game such as this, there is much to be said for the view that things that are necessary to enable balancing are a higher priority than anything other than critical bug fixes.

[neroden]

If I understand the list correctly:

No. 5 is the one that appears potentially critical for core balancing, along with a cost of capital feature. The others may cause some trouble until rectified, but should not either alone or in combination with one another affect core balancing.

Given that balancing is the most fundamental aspect of a game such as this, there is much to be said for the view that things that are necessary to enable balancing are a higher priority than anything other than critical bug fixes.

I think getting the hard assets tracked properly should solve a bunch of the construction / demolition cost bugs and the cost display bug at the same time.  Basically, I think all 5 of these can be solved with one project.

[jamespetts]

Can I ask if miscellaneous features are planned to be implemented at the same time as recombination features?
That is, the recombination feature will be implemented in (maybe) 15.0, and other features are planned for 15.1 and later.

The recombination feature alone is a lot of work, and it takes a lot of effort just to make it work and test it properly, so I think it's better to complete each feature in stages.
Also, I think many players are looking forward to the recombination feature and are looking forward to its implementation.

When it comes to implementing the UI, it is likely that someone different from the person creating the functionality will help.
When dividing work, I think it will be more efficient to code the UI if you present a simple appearance using something like an Excel sheet in order to clarify what kind of functions and displays you want from the UI.
Unlike people who are thinking about functionality, people who are trying to assemble a UI do not necessarily have a correct understanding of the functionality.
Prissi says that the current UI design of simutrans is similar to editing Excel.
For example, this is what I used when I proposed it somewhere before.

Once it's clear what data members are, how they're arranged, and how they're used, UI coders can get to work quickly.


In a related thing, Ves previously created a vehicle manager, but I'm not sure how it worked and how it was planned to relate to 15.x.

As requested, here are some details on these new miscellaneous finance features in the ex-15 branch.

Inflation

The inflation system applies a percentage multiplier to prices charged to the player and revenues received by the player. The percentage multiplier is indexed by the year, and set in the new configuration file prices.tab. The prices.tab file has a "general" setting and then a number of specific settings for different types of prices, such as passenger fares, mail rates, vehicle purchase, vehicle maintenance, city land and country land. Where one of the specific rates are specified, this overrides the general rate for that type. Where no specific rate for the particular type of price is specified, the general rate prevails.

A rate of 100(%) is means that the price in the game will appear as it does now, without any inflation applied. The in-game price is simply multiplied by this percentage, interpolated between the nearest two specified years. So, if we have prices.tab that says, "1850,50,1900,100", the inferred rate at 1875 will be 75%.

Note that fuel and staff costs are separate to this system and are indexed in their own way in fuel.tab and staff.tab respectively. Unlike prices.tab, fuel.tab and staff.tab require the absolute price for a unit of a given type of fuel or the in-game monthly wage of a given type of staff to be specified for each year.

These rates are stored in karte_t::prices[]. This is a static vector of the rates as percentages. The actual prices then applied and shown in the game are passed through a method, sint64 karte_t::get_inflation_adjusted_price(sint32 monthyear, sint64 base_price, price_type pt) const.

The best way of showing this, I think, is through a feature that shows how prices have changed in the last X years (where X is the normal number of years used in graphs showing the history of things). A graph and/or table would suffice for this. How to format the table is an interesting question. Probably the most straightforward way of doing it would be to show the percentage of increase in the prices in the current year since the prices in each preceding year for the range. In the below example, "miscellaneous" equates to "general". The figures in the individual rows other than "miscellaneous" should be identical to "miscellaneous" where nothing is specified in the corresponding line in the prices.tab file.



This would be fairly straightforward to make into a graph, but I will leave it to your discretion as to whether a graph is required.

For the staff and fuel, I would suggest a different approach, since we know the absolute values. We should, I think, use the absolute values. We will probably need translation texts for the units of the fuel here:



The same principle can apply to staff, but the unit is fixed as per game month. We will need a translation text for each staff type, however.

Interest rate

The interest rate is made up of a base rate that varies over time, and a multiplier between that base rate and the overdraft rate. In future versions (after 15.x), it is planned to implement a more sophisticated borrowing system that will make more detailed use of the base rate. The base rate is set in prices.tab. It is accessed using the get_inflation_adjusted_price() method, using 100 as the base price and passing the relevant year as the first argument. The overdraft rate is accessed in the same way, and then multiplying by the return value of get_overdraft_percent_above_base_rate().

For now, I suggest simply showing the base rate and the overdraft rate, allowing for more nuance later:




Corporation tax

This works in exactly the same way as interest internally, and I suggest displaying the historical rates of corporation tax in the same way.

In addition, however, we are going to want to display the corporation tax actually paid by each player to be shown in each player's finances. Note that the 15.x branch already has code for booking and storing players' monthly corporation tax payments: see finance_t::book_corporation_tax_monthly(). This is stored in accounting_type_common[ATC_TAX].


**

I hope that this is helpful. Please let me know if you are unclear on anything or need any more information. Also, if you believe that you have a better idea for representing these data, please also let me know. Thank you.

[TransshipmentEnvoy]

If version 15.x is still a thing, could you add some debug options to allow players to obtain free money (capital) to keep their company standing...

I am no expert in accounting, credit/debit, debt/equity financing... this seems to be too much for me.

[jamespetts]

If version 15.x is still a thing, could you add some debug options to allow players to obtain free money (capital) to keep their company standing...

I am no expert in accounting, credit/debit, debt/equity financing... this seems to be too much for me.

15.x is indeed still a thing. I have not done much development since early 2024 as having extensive building work at home has made it too difficult to focus on the work necessary to progress properly with 15.x. I am hoping to be able to recommence development later this year. In the meantime, I have merged your bug fix.

In terms of free money, freeplay will remain an option in 15.x. Although this will be more complex behind the scenes, however, that does not mean that it will necessarily be harder to play profitably. Indeed, the more realistic the balance, the easier that it should be to play by doing what would probably work in real life without having to study the game mechanics in detail: that is the intention.