|
anselm_eickhoff posted:Amazing discussion here again, soon I will also chime in regarding multiplayer. One thing that might be nice would be for the new zoning brush to snap to the width of nearby zones, like around 2:43 in the video where you make an industrial zone next to the commercial zone. That would make it easier to keep everything the same width, or to paint a given zone (say, residential) in two separate steps.
|
#
¿
Jul 10, 2014 00:05
|
|
|
|
| # ¿ Apr 19, 2024 09:40 |
|
|
anselm_eickhoff posted:But just getting the drat cars working is hard enough for now! I say this as a software developer who's been doing it long enough that I feel old when I think about when I started: you're doing exactly the right thing, and never let anyone convince you otherwise. (Just don't forget that it's always fine to throw out code that's outlived its usefulness.)
|
|
#
¿
Aug 9, 2014 05:23
|
|
|
KillHour posted:To each his own. When I'm doing a big project, rewriting the same code over and over is what kills it for me. That's the biggest reason I don't code any more. The real problem is that you're often not 100% sure of the requirements when you write the first version of a thing, so you'll end up rewriting it no matter what. Might as well make the first version as simple as possible so you don't waste your time. Avenging Dentist fucked around with this message at 06:28 on Aug 9, 2014 |
|
#
¿
Aug 9, 2014 06:22
|
|
|
Baronjutter posted:I know I'm always going on about how essential it is to include parking in any city sim, and how it's probably the #1 or #2 factor that influences how a city looks and develops, but here's some urban planners upset about it too. Wow, somehow this blog post seems even more petulant than when a nerd just starts getting into computers and gets a big hate-on for stuff like Hackers because it's not "realistic". But yes in this case I'm sure it's all a conspiracy against urban planning!! At least in the Hackers case the nerd is probably like 12 years old and will hopefully grow out of it soon.
|
|
#
¿
Oct 11, 2014 17:28
|
|
|
As a developer who gets paid to write Javascript but vastly prefers C++, I think you made the right choice. C++11 (and even moreso, C++14) is vastly improved over C++98, and I find it a lot more comfortable to use than Javascript, even ignoring that C++ is miles ahead in terms of performance. C++ (and other compiled languages) makes it easy to reject obviously-wrong things early since they just plain won't compile. I do recommend hooking up a scripting language pretty early on, since it makes it a lot easier to iterate on small behavioral changes. Lua's pretty common in gamedev, although I've been meaning to check out Julia one of these days, which seems much more to my liking. (Julia is designed to be a high-level language appropriate for scientific computing, so it should work pretty well in gamedev too.)
|
|
#
¿
Feb 1, 2016 22:20
|
|
|
anselm_eickhoff posted:I'd rather get the main advantage of scripting languages (fast iteration and nice syntax) going in C++ and then have everything written in just one language - the only disadvantage is that now you need tooling for modding, but I plan to also make this as painless as possible. That might not be possible. One of C++'s biggest weaknesses is that compilation times are much higher than other languages. Compare to something like GOAL which lets you edit game scripts and run them without even restarting the game.
|
|
#
¿
Feb 2, 2016 00:41
|
|
|
Cache lines are probably not the best thing to be looking at so early, especially since things are likely to change a whole lot as you continue development; micro-optimization is particularly fragile to changes in your codebase. I'd recommend looking at ways to reduce algorithmic complexity first, since performing fewer operations in the first place is usually a better strategy than making each operation as micro-optimized as possible. Since you're making a game, your simulation doesn't actually have to be perfectly accurate; it only needs to look accurate. Making some simplifying assumptions can drastically reduce the amount of computation required; for instance, you could use aggregate traffic computation for any district of the city you're not currently looking at. People wouldn't notice the difference, simply because they're not observing it. (However, this does require that your aggregate traffic model be pretty accurate.) This probably wouldn't significantly reduce the amount of data you need to store (each citizen would still have their own internal schedule, workplace, favorite shops, etc), but it would make it easy to instantiate each citizen on the fly: if you know it's 8:33 AM and aggregate traffic downtown is bad, you can predict where Alice Anderson's SUV should be and then simply create it when the user is looking at that area. It's important to remember that games - even simulation games - have soft real-time constraints and are made for entertainment. At the risk of oversimplifying matters, a good contrast here is Doom 3 vs Half Life 2. Doom 3's rendering engine had a very advanced (for its time) lighting model that's significantly more "accurate" to the real world. However, Half Life 2 looks much better because they saved a lot of GPU resources by making simplifying assumptions, especially about lighting.
|
|
#
¿
Jul 18, 2016 19:44
|
|
|
|
| # ¿ Apr 19, 2024 09:40 |
|
|
Nition posted:I don't know, having a simplified model for non-viewed areas and an agent model for viewed ones is a great idea performance-wise in theory, but I can also imagine it being a never-ending nightmare reconciling the two and making them match. Traffic modelling is a pretty well-studied field in applied mathematics, and in fact the mathematical modelling course I took in university focused on traffic modelling in aggregate (the textbook was Richard Haberman's Mathematical Models: Mechanical Vibrations, Population Dynamics, and Traffic Flow). Academic research would be a great way to get started with aggregate models, since real-life traffic modelling must be accurate, or it's not useful. To help confirm that your model matches the game's actor-based simulation, you could construct automated tests of your aggregate model: run the full simulation on some interesting test cities and see if your aggregate model accurately predicts the results. In fact, if you found yourself completely unable to use existing research on traffic flow, you could probably do something clever and design a neural network that learns how to approximate the traffic by feeding it all your test data. Then you just need to ship the neural network's internal state along with the game. I don't think this would actually be necessary, and it's probably excessive overkill for this problem domain, but I'm pretty sure it would still help large cities. (The best is probably to use real-life research though, since smart people have already done it.) While using aggregate models is a bit lacking in conceptual elegance (it's fun to watch higher-order patterns emerge from a system like this), I think it's a compromise worth making, since good simplifying assumptions could drastically increase the maximum size of the simulation. Of course, I don't have access to any of the code here, so I can only make guesses. In any kind of optimization, measurement is extremely important, and I'd urge Anselm to at least look at the feasibility and scalability of performing aggregate traffic modelling vs a full actor-based simulation.
|
|
#
¿
Jul 19, 2016 06:19
|
|