Hello! I have enjoyed this game quite a bit. The best score I got (which I define as the week where my profit is inferior to the maintenance costs) was 19 weeks. The details of my opinions are down below, so feel free to stop reading here.
I really enjoy the using the colour gates and the stoplights in order to maximize traffic flow. I also enjoy how speedy the cars are. I like the obstacles, as they never feel intrusive and I feel like their removal would remove a lot of the difficulty and structure from the planning of roads.
I feel there could be a setting that allows different sized grids, so that way people could experiment how the game changes from small to large.
Here are some of my more critical opinions. Feel free to stop reading here as well.
First, I feel like the pathfinding with cars is pretty bad. I managed to deal with it all right after a few frustrating mistakes where traffic was completely clogged. But outside of that case, where it is completely my fault, I feel like it is quite difficult to reroute cars that have already spawned. I did read a comment talking about this, and you did mention performance issues. I'm sure there are some simple optimizations that can be made. That said, I don't know how much more time you want to spend on the game. I managed to implement one way roads by cranking up the timer on W/E and N/S type stoplights. I feel like you could use a similar idea to implement one way road pieces. My idea was to code a normal one directional stoplight, reskin it to be a one way road, and make it so the timer never counts down to zero.
Second, the maintenance costs are ridiculously high. I took a look at the formula, and increasing the cost by 25% every week (as well as the increase in roads) is ridiculous and prevents any sustainable infrastructure. You said this game was endless, but your formula for maintenance stops that idea in its tracks. I propose instead calculating the maintenance by summing the costs of homes, roads and businesses, each having a fixed price per unit. This would look something like this: a(#roads) + b(#homes) + c(#businesses), where a is the maintenance cost per road, b the cost per home and c the cost per business. By adding businesses and homes into the calculation, we also add an in-built way for maintenance costs to increase gradually based on the number of weeks (since, naturally, the number of homes and businesses increases with time). Now, you may not like charging the player for the maintenance of homes and businesses, whose numbers they cannot control (I would argue the players also cannot control the 25% increase, but that's not the point). Therefore, the formula is simplified to this: a(#roads). This formula however, doesn't increase the maintenance costs based on the number of weeks. My solution to this is the logarithm. You used square roots in your original formula, which in my opinion, was to balance for the fact that players won't be able to increase their income as much. Logarithms have a similar shape to square roots (you can use desmos.com to verify this) and, in my opinion, feel more natural when dealing with situations involving growth, which this game is absolutely about (feel free to use square roots if you really want to). Hence, we would multiply the maintenance cost of roads by a logarithmic factor. Personally, I chose a factor that felt natural to me: ln(#weeks). Hence, the resulting formula would be: (1 + ln(#weeks)) * a(#roads). The logarithm of 1 is zero, so it doesn't apply any change during the first week, just like the original formula. Now considering the initial growth rate of 25%, this formula is even more ridiculous. For example, 1 + ln(2) ≈ 1.69 (noice), which is a staggering 69% growth! Thankfully, this can be easily fixed by scaling the logarithm by a factor of b, where b is the percentage by which you scale the logarithm. Following the initial formula, we would like the initial increase for week 2 to be equal to 25%: 1 + b*ln(2) = 1.25. Hence, b = 0.25/ln(2). This gives a b value of approximately 0.36. Hence, we get this final equation for the maintenance cost: (1 + 0.36*ln(#weeks))*a(#roads) or (1 + 0.25/ln(2)ln(#weeks))*a(#roads).
Whew! Thanks a lot for making this game!
P.S. Considering the game is free, I would really appreciate it if you made the game open source, especially if you don't have the time to work on it.
1. Whole path is set when car starts. If we change roads during it's journey it will stop and mostly will stuck. Sometimes it regenerates path but mostly stay at position. If we add some roads near - it may try change path. I need to create 2 separate paths (new and old) and wait if all will drive by new path, than can delete old one.
It should regenerate path if cannot move because there is no road (from calculated path).
Thanks for the comments. Unfortunately, it kills performance if stuck cars constantly check for new paths. I tried to strike a good balance between quickly-adapting AI and performance.
Also, one might argue that quickly adapting to new routes is somewhat unrealistic. Drivers that have set out to work already have their routes in mind (or programmed into GPS). Yes, people certainly take other routes when stuck in traffic - but they usually don't do it instantly.
I haven't played so much time. Right, it may kill the performance, but maybe it should check new route only if car stuck - this means, that not moving for some time, but have other free path/road to go. So it will check for path for first stuck car and move it, then next time for next one. The last one - will wait, but after some time all cars can go. Additional one or few cars (if many tracks changes for last day) won't need additional performance. Now it is impossible to check new solutions without stopping the source point.
I'm glad you like it, thanks! One-way roads is a little hard with the current car pathfinding, unfortunately. If I ever revamp that aspect, it's a possibility, though.
Placing roads would work nicely with touchscreen, but I'd have to rethink all the the other controls (e.g. SPACE to pause, ctrl-clicking, etc.) to make everything else work on such a device. Maybe in the future, though.
Your pathfinding implementation doesn't properly check whether a stoplight is never going to be green when approaching from a certain side, as demonstrated in this screenshot: https://i.imgur.com/xvqKPSY.png
Right, the pathfinding actually ignores stoplights. This is because it's built on squares either being "on" or "off," while a stoplight adds a directional aspect to it. If I generalize the pathfinding to allow for directed graphs (it would be a serious generalization), then it could allow for permanently blocked stoplights and even one-way streets.
Turning undirected Dijkstra/A* to directed should only be a few lines. Especially in this case it's feasible to just hack in a specific check for permanently blocked stoplights and skip if true.
← Return to game
Comments
Log in with itch.io to leave a comment.
Hello! I have enjoyed this game quite a bit. The best score I got (which I define as the week where my profit is inferior to the maintenance costs) was 19 weeks. The details of my opinions are down below, so feel free to stop reading here.
I really enjoy the using the colour gates and the stoplights in order to maximize traffic flow. I also enjoy how speedy the cars are. I like the obstacles, as they never feel intrusive and I feel like their removal would remove a lot of the difficulty and structure from the planning of roads.
I feel there could be a setting that allows different sized grids, so that way people could experiment how the game changes from small to large.
Here are some of my more critical opinions. Feel free to stop reading here as well.
First, I feel like the pathfinding with cars is pretty bad. I managed to deal with it all right after a few frustrating mistakes where traffic was completely clogged. But outside of that case, where it is completely my fault, I feel like it is quite difficult to reroute cars that have already spawned. I did read a comment talking about this, and you did mention performance issues. I'm sure there are some simple optimizations that can be made. That said, I don't know how much more time you want to spend on the game. I managed to implement one way roads by cranking up the timer on W/E and N/S type stoplights. I feel like you could use a similar idea to implement one way road pieces. My idea was to code a normal one directional stoplight, reskin it to be a one way road, and make it so the timer never counts down to zero.
Second, the maintenance costs are ridiculously high. I took a look at the formula, and increasing the cost by 25% every week (as well as the increase in roads) is ridiculous and prevents any sustainable infrastructure. You said this game was endless, but your formula for maintenance stops that idea in its tracks. I propose instead calculating the maintenance by summing the costs of homes, roads and businesses, each having a fixed price per unit. This would look something like this: a(#roads) + b(#homes) + c(#businesses), where a is the maintenance cost per road, b the cost per home and c the cost per business. By adding businesses and homes into the calculation, we also add an in-built way for maintenance costs to increase gradually based on the number of weeks (since, naturally, the number of homes and businesses increases with time). Now, you may not like charging the player for the maintenance of homes and businesses, whose numbers they cannot control (I would argue the players also cannot control the 25% increase, but that's not the point). Therefore, the formula is simplified to this: a(#roads). This formula however, doesn't increase the maintenance costs based on the number of weeks. My solution to this is the logarithm. You used square roots in your original formula, which in my opinion, was to balance for the fact that players won't be able to increase their income as much. Logarithms have a similar shape to square roots (you can use desmos.com to verify this) and, in my opinion, feel more natural when dealing with situations involving growth, which this game is absolutely about (feel free to use square roots if you really want to). Hence, we would multiply the maintenance cost of roads by a logarithmic factor. Personally, I chose a factor that felt natural to me: ln(#weeks). Hence, the resulting formula would be: (1 + ln(#weeks)) * a(#roads). The logarithm of 1 is zero, so it doesn't apply any change during the first week, just like the original formula. Now considering the initial growth rate of 25%, this formula is even more ridiculous. For example, 1 + ln(2) ≈ 1.69 (noice), which is a staggering 69% growth! Thankfully, this can be easily fixed by scaling the logarithm by a factor of b, where b is the percentage by which you scale the logarithm. Following the initial formula, we would like the initial increase for week 2 to be equal to 25%: 1 + b*ln(2) = 1.25. Hence, b = 0.25/ln(2). This gives a b value of approximately 0.36. Hence, we get this final equation for the maintenance cost: (1 + 0.36*ln(#weeks))*a(#roads) or (1 + 0.25/ln(2)ln(#weeks))*a(#roads).
Whew! Thanks a lot for making this game!
P.S. Considering the game is free, I would really appreciate it if you made the game open source, especially if you don't have the time to work on it.
Hi! Is there possibility to get source code of this game? I have some ideas how to enchance it.
第13周堵死了啊
i made everything road for ,max flow ratio
Good Game :)
Hope your doing fine
I've played much and found some issiues:
1. Whole path is set when car starts. If we change roads during it's journey it will stop and mostly will stuck. Sometimes it regenerates path but mostly stay at position. If we add some roads near - it may try change path. I need to create 2 separate paths (new and old) and wait if all will drive by new path, than can delete old one.
It should regenerate path if cannot move because there is no road (from calculated path).
Thanks for the comments. Unfortunately, it kills performance if stuck cars constantly check for new paths. I tried to strike a good balance between quickly-adapting AI and performance.
Also, one might argue that quickly adapting to new routes is somewhat unrealistic. Drivers that have set out to work already have their routes in mind (or programmed into GPS). Yes, people certainly take other routes when stuck in traffic - but they usually don't do it instantly.
I haven't played so much time. Right, it may kill the performance, but maybe it should check new route only if car stuck - this means, that not moving for some time, but have other free path/road to go. So it will check for path for first stuck car and move it, then next time for next one. The last one - will wait, but after some time all cars can go. Additional one or few cars (if many tracks changes for last day) won't need additional performance. Now it is impossible to check new solutions without stopping the source point.
This reminds me of mini metro. I really like the game
Thank you! I've played Mini Metro as well; I like it.
Three-way traffic lights would be nice too.
That might work well; it's a possibility in the future as well.
Could you add one-way roads? (Love the game, btw - I've spent way too many hours playing it!)
I'm glad you like it, thanks! One-way roads is a little hard with the current car pathfinding, unfortunately. If I ever revamp that aspect, it's a possibility, though.
(Little late) but it would be nice if there was like a one-way gate system instead of a true "one-way road"
Could you make a speedup feature?
I think I could give it a go.
fix the fullscreen please
The fullscreen button is more of an itch.io thing, but I'll see if I can do anything about it.
versionthat works on ipad plz
Placing roads would work nicely with touchscreen, but I'd have to rethink all the the other controls (e.g. SPACE to pause, ctrl-clicking, etc.) to make everything else work on such a device. Maybe in the future, though.
Your pathfinding implementation doesn't properly check whether a stoplight is never going to be green when approaching from a certain side, as demonstrated in this screenshot: https://i.imgur.com/xvqKPSY.png
Right, the pathfinding actually ignores stoplights. This is because it's built on squares either being "on" or "off," while a stoplight adds a directional aspect to it. If I generalize the pathfinding to allow for directed graphs (it would be a serious generalization), then it could allow for permanently blocked stoplights and even one-way streets.
Turning undirected Dijkstra/A* to directed should only be a few lines. Especially in this case it's feasible to just hack in a specific check for permanently blocked stoplights and skip if true.
This is certainly something I would consider generalizing in the future.
I've implemented a change (v1.1.2) that should address this somewhat.