Forum Replies Created
-
Posts
-
Agree with most of the suggestion mentioned, but would add
Construction costs increased – building train/tram lines is an investment, far to cheap at the moment.
Maintenance cost redone – Locomotives should make up about 95% of the cost of running the train, cartridges should cost far less to maintain, thus encouraging people to use either longer trains or smaller/cheaper locomotives to pull shorter trains.
Increase Map Size – The scale between acceleration, object size, and distance is completely off. The TFV can’t even get to top speed on a small map, and making a set off high speed cross switches can take half a typical journey. I suggest increasing all map sizes by 100% without adding any new towns or industries.
Map Generation – Population centre’s should be split into “Cities”, “Towns”, and “Villages”. A small map should consist of about 1 city, 3 towns, and 5-8 villages, with larger maps multiples there of. Each should act like they would in real life, eg villages are 95% houses, while cities have much larger retail areas. Raw resources should spawn in or near a village, while manufactories spawn in or near towns, just as you would expect in real life.
Track/Road Building – The system needs changing to help produce less errors, such as altering near-by track and moving supports to allow you to build rather than just telling you, you can’t do something. A good example is building double track over a river at a 45 degree angle, the first line will go over no problem but the second always tries to build the sloop into the water.
do you have a scroll wheelless mouse? I mean I didn’t know you could still buy those!
Yes you can, they not as common anymore but you can still get them. And I’m not sure there is a keyboard shortcut for it, bit of an oversight really.
MY VERSION IS 4246 WINDOWS 8 64 BIT
Turn updates on in steam, some of the patches are really useful.
I wasn’t suggesting that the game should be re-implimented in .NET or anything, I was merely using it as an example that people are more familiar with. I was simply pointing out that a temporary fix could be to use something like threadpool or something similar, to handle the newly created threads while they optimized them properly. As you yourself stated,
You need a solid solution splitting the mathematical equation into smaller parts and across more cores
which is exactly what I was suggesting, but it takes time, and not everyone is willing to wait that long.
However, their Beta testing was obviously not up to scratch
Beta testing is a pain, you can spend lots of time and money on it, but it don’t guarantee results. To give you an example, I had an app beta tested and I’d fixed the problems they’d found, passed it to my gf to try and within 5min she found a major bug that they’d missed. Nothing is 100%, but I agree that it should have been picked up on and at least had a statement or two.
Ok, First off, ALL software has bugs. It’s expected, no about of development or beta testing can find them all.
Second, every seems to be mixing bugs with “bad design”. A bug is something that happens that the developers did not intend eg flying cars. “Bad design” is something that is as designed, but doesn’t work well eg performance.
Thirdly, As eis_os stated, programming modern software is not easy. Asynchronous programming is probably the hardest thing to get right, so it’s no surprise that a small company like urban games opted for synchronous/parallel threads instead.
It’s going to take many hours, if not hundreds of hours, of programming to improve the performance. However if I was in their shoes, I would create a tempory fix by splitting the threads into 4 threads, and maybe use the .NET threadpool to help manage them. It would at least let people with 4 logical cores to benefit while a permanent solution was worked on.
Coujou is right, the devs do need to comment, the only way forward for a small company is to utilise the community and to listen. They need to be on here posting and letting people know that there not being ignored.
Well it’s good to hear that the game does use some threading at least. But I, at least, was talking about asynchronous threading and not the synchronous threading described by eis_os.
But at least it’s a start, which means that it shouldn’t be such a huge job to improve performance.
I agree that the cargo system as it stands needs work.
But I don’t agree with your idea of price being based on speed, as some other posts have pointed out a steel mill don’t care if it’s iron ore arrive in 1 hour or 5 hours, just as long as it arrives. I think that each raw material industry should display an “offer price per unit” which is based on “As the crow flies” distance to the nearest user. It would then be upto you to ship the required amount to the factory at a profit, regardless of whether you use trucks, trains, or a mix of both. I do agree though that “Goods” sold in towns should be based on a supply/demand based price, but again speed should not be a factor.
In order to make the cargo system better though, more of the cargo needs to arrive at the station. At the moment a factory can produce 200 units of goods but only 100 might turn up at the station, the percentage of what turns up seems to be based on frequency of the service. I think the whole lot needs to wait at the station (for a set period of time), thus making longer less frequent trains achievable.
@coujou , I wouldn’t say the game is “badly” coded. From what I’ve seen in the game and how I’d assume it would be put together, the code is pretty decent. You can only ask a single core to do so much work no matter how good the code is.
With regards to multi-threading, it’s a hard thing to learn, so don’t give the dev’s to much stick if they don’t know how. When you make a multi-threaded program you can actually make things SLOWER if you don’t get it right, because multi-threading has significant overheads when it’s compiled.
However, if the dev’s can’t do it themselves, then they need to hire someone to do it. If it doesn’t get done things are only going to get worse the more stuff they add to the game.
Ok, firstly the only reason you would need to rewrite the code from day one, even to implement multi-threading, would be if the code was bad in the first place.
Secondly, implementing multi-threading is pretty easy. The difficulty comes in trying to get the threads to work together and not crash the program.
Without knowing how the game has been coded it’s impossible to know how big a job it would be to implement multi-threading. Also, you can only optimize a code so much, so the game really does need to be multi-threaded to get the performance people desire. A comment from the devs would be nice on this topic.
+1
On the condition that’s it’s an optional variable at game start, maybe Fast, standard, long, and extra long, like with map size and start year.
@synchronos I would totally agree with your last post, never did the timings myself but I did notice it froze for longer on the faster speeds.
However I think it’s more to do with total pop, rather than pop growth, but I could be wrong.
I think the algorithm would still need to be run monthly though, but improving the algorithm is something the devs are probably working on already. I still think that most of the performance issues in the game could be fixed with good multi-theading, but that’s if the devs have experience with it??
@synchronos , I have the same problem and it is getting unplayable. But I disagree with the “No. of trains” idea. My map only has 24 trains and 200(ish) trams and it’s pretty bad.
I have noticed it got a lot worse when I rebuilt my tram routes through my main city, and I’d sold 80 trams to do that, but it started to get worse when I deleted stops and rebuilt the routes. So I think the Lag might be part of the pathing system, or passenger generation, or possibly city growth, or maybe a mix of all of them being done at once.
It’s already been suggested.
A “Track planning” mode where you can create a track, double-track, triple ect… and then go along the line and “grab & drag” to change it’s path, and maybe “shift+drag” to change it’s height.
And while it’s a great idea, it would be a lot of work for the dev’s to rewrite the code while there are bigger issues such as performance and balance.
Performance for me has changed. The game use to have “jump lag” every couple of seconds, now it just has one huge lag at the end of every month.
It does seem to be getting better slowly, but I think they need to hire a good multi-threader to split the code up, there’s only so much optimization you can do when limited to 1 core.
