Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Reelya]

I had an interesting idea. If you have a simulation growth-model but you want to generate other towns then you'd need a procedural approach to render those from abstract data. It can be very hard to make the simulated version at all similar to a manually proc-genned version.

But ... these days what you could do is run different simulation runs through a machine-learning algorithm, so you could get a procedural version that had many of the properties of a simulated town.

To make your simulation work better with the procedural thing for other towns, I'd recommend using a type of fractal / hierarchical structure. It would work best if high-level stuff didn't have dependencies on lower-level stuff.

[mko]

I had an interesting idea. If you have a simulation growth-model but you want to generate other towns then you'd need a procedural approach to render those from abstract data.

No, I am far more realistic/lazier. Other towns will not be rendered at all and exist as bunch of integers and statistics for emigration, trade etc.

And initially will not exist at all.

---

And in case of progressing into simulation of multiple cities, I will simulate them separately (multi-threading should work well here).

[Reelya]

That doesn't seems like a useful thing to multi-thread actually. Breaking it down like that, by towns, wouldn't actually be that beneficial. One of the reasons I say that is that you'll have a lot of simulation information that's shared between towns, global information and the like, data-tables defining generic stuff, and all towns will have to access that.

What would be a good thing to multi-thread for example would be a detailed weather model. That can run off its own data and put on a separate thread, and only export the need-to-know "weather forecasts" when required.

Another thing that's often put on a separate thread is path-finding. If you for example go look at the game Dungeon Keeper, you'll notice that the imps won't move for a while after you create new jobs, but after a while they'll speed off to the job. That's because the path-finding algorithm is happen asychronously with the updates (whether or not its on the same thread), so the path-finding code is given a task-list and returns paths, then pulls the next task from the list. The units request a path, and wait until they get the instructions back before moving off.

[bloop_bleep]

Multiple towns sound like a perfectly great thing to multithread, if the only way they interact with each other is through a set of several numbers for every town, like suggested.

[Reelya]

Multiple towns sound like a perfectly great thing to multithread, if the only way they interact with each other is through a set of several numbers for every town, like suggested.

I don't think they actually would, because they're the same class of thing and there will be a lot of simulation data they share. Types of shops for example might be in tables, and all towns need to have access to the types of shops. You want to avoid shared data between instances. And for something like a "town" there will be so much complexity encoded in the data (if you're sensible enough to have a data-driven design) then that will cause problems with splitting out the tasks.

Also, consider that there might be a person database, and what happens if a person moves from one town to the other. Is the game going to move the person over to a different table of data to maintain the decoupling of data the different towns?

[bloop_bleep]

But there's nigh zero possibility of data races with shared immutable data, like types of shops probably would be. You don't need locks or mutexes for that. You only need to protect shared data that's mutable, to prevent one thread reading it while the other thread is not yet done writing it. The only shared mutable data, according to mko's design, would be small sets of numbers, which could probably only be accessed once an in-game year or something like that. 99% of the computation would be independent.

[mko]

Multiple towns sound like a perfectly great thing to multithread, if the only way they interact with each other is through a set of several numbers for every town, like suggested.

I don't think they actually would, because they're the same class of thing and there will be a lot of simulation data they share. Types of shops for example might be in tables, and all towns need to have access to the types of shops. You want to avoid shared data between instances. And for something like a "town" there will be so much complexity encoded in the data (if you're sensible enough to have a data-driven design) then that will cause problems with splitting out the tasks.

Also, consider that there might be a person database, and what happens if a person moves from one town to the other. Is the game going to move the person over to a different table of data to maintain the decoupling of data the different towns?

At this moment there are some heavy calculations that can be done without changing state. For example placing house requires pathfinding to ensure that it is possible to create path reaching it.

So "find good places to place buildings/road/railway" can be multi-threaded, then actions will be made on the main thread. Even in case of an action making some places invalid a reserve one may be used.

And "I constructed a new house, then motorway was constructed along it" is a thing that happens.

(though at this moment I am at stage of not even seriously planning multiple towns)

[McTraveller]

I'm remembering again why I dislike open-source software.  I want to build a tool.  It has these dependencies. Those dependencies have their own dependencies.  Or  I can get a package manager and install more junk.

The philosophy of dependency hell is not fixed by adding a package manager to let you keep having dependency hell!

I understand now why "closed" platforms like Windows and MacOS can prosper - if you have the SDK for those operating systems, you have all the dependencies already.

[Telgin]

I pretty much never build anything from source unless I have no other choice, for precisely those reasons.  Sometimes it's not difficult, but it usually does require installing crap I don't have yet.  GCC and all of the standard build tools are easy enough, but once you get into the frameworks for managing environments and configuration to make makefiles for your environment, or handle dependencies outside of the OS's package manager, it gets messy, fast.

That is indeed one big advantage for users on Windows and I assume Mac OS: the developers don't assume the end user has a build environment installed and know how to use it, so they usually provide binaries.

[Ziusudra]

if you have the SDK for those operating systems, you have all the dependencies already.

Except for the several versions of .Net you probably only need for one or two programs, but still have to have. Then there's the SxS folder that has to keep multiple version of all the other libraries and ends up taking up a few dozen GiB of hard drive space. All of which makes updating take forever. They haven't fixed dependency hell, just swept it under the rug.

[Reelya]

I don't think it ends up taking that much space up, at least not on mine. I have everything I want installed, total windows folder is 18GB. There's not room for a "few dozen" GB of SxS stuff in that.

But, code-dependency and run-time dependencies are sort of different issues too. You can have everything bundled into the one exe, and get a portable application: this is what .NET Core is about. Or, you can have a lightweight application, and you offload the responsibility to the OS to have the right components available. That's what .NET Framework is about.

Basically blame the people who made the tools, not Microsoft. Microsoft's job is to support whatever you decide to install on your system. This is a backwards compatibility issue rather than a dependency hell issue, too. That shit you're installing is old so of course, Windows 10 must accommodate you by having legacy stuff from previous operating systems in there so you don't fuck yourself. Thus this is almost like Windows being required to be one huge emulator that seamlessly tricks old apps into thinking they're running natively on the original Windows operating system version. That's the reason for SxS, and it's actually a pretty brilliant hack. The alternative is the lockdown philosophy of MacOS where if you don't get the very specific version of the application that's authorized to run on the very specific version of your operating system then your fucked out of luck.

If someone made a 1K tool but it uses .NET Framework 3.5.1 so you need to have that installed in your system then that's the fault of the tool developer for basically being lazy. It's still far better from a user's perspective (as in: getting actual things done which aren't time-wasting computer tinkering) to have to have .NET Framework 3.5.1 installed as an entire package then to have to hunt down a zillion obscure libraries then get them all to compile.

[McTraveller]

All I know is - wow there is way too much accidental complexity in what I'm trying to do right now.  The convoluted tree of documentation I've had to follow to even get where I've gotten now, only to be hit at just about every turn with another "error... something something something" or "this file isn't where I thought it would be" is really frustrating.

No wonder people can get paid so much for basic IT infrastructure maintenance.

Spoiler (click to show/hide)

 All I'm trying to do is set up one of my computers as an SVN server. I have been just using file:/// URLs locally, but I just got a new desktop and want to use that as the main SVN host for my projects. But holy crap... I feel like this is something that should be about 10 minutes of work and instead I've spent about 4 hours on it and am almost ready to throw in the towel.

I have been trying to do with Apache and WebDav, but geez.  Maybe I will just try svnserve instead...

[Telgin]

Not sure about SVN, but I remember setting Git up through Apache once and that was surprisingly hard to get right, at least on Windows.  I don't even remember what was hard about it, but it was complex enough I told myself not to bother again if I ever had to reinstall Apache.  Which I did, and I did not reconfigure it to host a Git repo that time.

[Reelya]

All I know is - wow there is way too much accidental complexity in what I'm trying to do right now.  The convoluted tree of documentation I've had to follow to even get where I've gotten now, only to be hit at just about every turn with another "error... something something something" or "this file isn't where I thought it would be" is really frustrating.

No wonder people can get paid so much for basic IT infrastructure maintenance.

Keep in mind that if you do something once, it's going to have a high overhead / learning curve. However once you know how to do it you can charge people money for you to do it over and over again, and that spreads the overhead out over multiple jobs. So, someone who specializes in doing whatever you're doing right now doesn't have to reinvent the wheel every time unlike a hobbyist who's goal is to only ever go through that process once.

[MorleyDev]

Nowadays I think I'd just install docker on the server or host a kubernetes cluster in the cloud and use that, rather than installing things manually. But I'm also pretty obsessed with automating as much as I can when it comes to servers so I'm already familiar with that side of the toolage.

Heck, I use Chocolatey on my personal windows computers because why would I download and install software myself like some kind of caveman?

As aside, SVN always reminded me more of VSS than it probably should. Doesn't play nice with loads of small branches and lots of merge issues when other developers sneeze near the same code as you.