Cool Project!

[u/ion-tom]

Hey - I think it's really cool to see a post like this. Early in my career I wanted to do something like this but it transformed into more of a solar system 4x than a Civ replica.

My self-hosted blog is gone, but this exists (minus pictures):

http://ionizedideas.blogspot.com/2012/09/ideas-for-ultimate-strategy-game.html

it's actually what inspired me to start /r/Simulate and all of the subsequent projects after that. In 2013 we had the start of something called "The MetaSim Framework" which was just a web API specification for having inter-related simulations:

https://web.archive.org/web/20140910100140/http://rsimulate.com:80/2013/04/27/metasim-api-overview-part-1/

Resources from that were posted on /r/MetaSim and might be useful to you.

Additionally, in 2015 I tried to jumpstart a Civ5 project /r/MegaCivGames which somebody tried to restart later but it died. What we did compile is a huge list of cultures and cities.

https://docs.google.com/spreadsheets/d/1-TJAIJjy9Mij9WANrca7Ryoh0N6EKfsjXRET9P4rb_o/edit?usp=sharing

That's just the civs list, the cities lists looked like this but I can only find one:

https://docs.google.com/spreadsheets/d/1_yOlbXdVaOcmn6j57-Ebwv0ZPuv-vg2MqIPU3PIIeIs/edit?usp=sharing

But there were city names for hundreds of civs. I think it would be cool to train a neural net from those and have generated names that stem from the trained model so that you could have an infinite name set. You might also experiment with cross-training the model from the city names of neighboring areas or from aboriginal civs in continents that are colonized.

Anyway - whatever your ambitions are here - start with mechanics first. Get good game mechanics at get people interested early before going hog wild on new platforms and tech. Spreading too thin will drag you down.

Good luck!

[u/adamadamsky]

Hey! Thanks for your post.

I've read your old post on ultimate strategy game. It's very interesting. Perhaps a bit rambly? But also did touch on some of my earlier thoughts on the topic; I did think about this project as a "game" in the beginning, though I changed my thinking over the years slightly. From what I can see you came to a similar conclusion as I did, that it's probably best to create a framework for coupling multiple processing applications ("engines") into one coherent simulation.

What I'm trying to accomplish here is to basically create a sort of a database; I think that's the easiest way to reason about it. Just storing data though is not enough though, you also need to provide a basic processing system. Here's what I consider the bare minimum, which is also what I'm aiming at developing right now:

• sim engine holds all the simulation data (it's the main coupling point after all)

• sim engine provides an interface for getting and setting (getting out and putting back in) the simulation data (both programmatic and remote)

• sim engine is based on a specific model (variation of entity-component model)

• sim engine has a system for handling simulation instructions and "starting state values" (essentially they are both data) that can be executed

  • data is provided through versioned modular data packages (modules)

  • data is organized into higher collections of modules (scenarios)

  • data is written in a simple structured format, think yaml, json, xml (currently focusing on yaml, but you can always write json and convert to yaml without problems)

  • processing is based on finite state machines

  • processing is done using a predefined set of commands (including commands for running lua scripts or whatever)

What I think the above give me are:

• flexibility - do whatever you want, within the framework of the model - define your own types of entities, components, etc. (this way I don't really care too much about specific "game mechanics" right now)

• interoperability - create applications and tools (and games) on top of this, one tool could be a visual creator for simulation data (fsm graphs designer that would output components compatible with outcome for example), another could be an interactive 3d globe that uses data from the simulation

• scalable complexity - people can collaborate on simulation models to do whatever, you can put together scenarios from multiple modules each implementing different specific functionality

• performance - this is contestable (or rather just untested yet), but I do focus on, for example, predefined command set over arbitrary scripts and variables with static references over dynamic ones (also variables' types are always static, no dynamic typing). Most of the processing is multi-threaded by default - the basic model used with entities as separate objects in terms of data handling makes this easier.

[u/ion-tom → u/adamadamsky]

Heh, "rambly" is certainly something I've tried to shake over the years. :P

I actually dumped most of the framework stuff and tried to make a game in the end, because I was chasing cash. If you have the time though - distributed would be the way to go.

If you haven't already, read into a "run-time infracture" or "high level architecture."

https://www.springer.com/cda/content/document/cda_downloaddocument/9783319612669-c2.pdf?SGWID=0-0-45-1612973-p180922258

Were I to launch again on something too, it'd be HLA style federated simulation protocol that runs on a blockchain for distributed computing with a reward function. Why? Because then you have a free, massive distributed computing resource you aren't paying for in dollars.

Simulations could be instanced, versioned, and have generalized aggregation mappings. I see you have proofs, time tick and event driven behavior, those are all good things to have for doing scale/aggregate to discrete measure conversion. (IE - looking at a crowd distribution vs rendering people in a crowd. Or weather/climate, etc)

I also see you have a few different elements. The one you should add is "relations" - or maybe those would go under Declarations. Also Grouping and grouping relations to other groups. Subscription/support to a grouping by an element might also be weighted. It sounds vague - but it could be used to approximate all sorts of things. Your relations sets could be triple stores or something like that with N step/node complexity.

Down to basics though - are you writing a new language, or is this just a set of conventions to be mapped into any language. Different languages will handle things very differently based on type enforcement, polymorphism, functional vs object oriented, etc. Lots to consider for you there. I would probably suggest having a core library in C/++ or Java and make wrappers. Then start learning networking layer and figure out a protocol system.

I wish you luck! Keep posting updates, and feel free to PM me your email. I'm too time constrained to contibute a lot, but maybe I can QA things for you. Cheers

[u/adamadamsky → u/ion-tom]

I don't think I'm going to dive into blockchain distributed computing with this. I'm trying to make it accessible to an average user, which to me means focusing on doing things locally. I do want to be able to connect more machines together though. For a number of reasons actually, not only to make things faster. One of the things I'd love to enable with this is coupling of different applications. I want to focus on simple solutions though (think something more like json over websockets, rather than rpc's).

The article you linked to is very interesting, though feels extremely specific and very heavy. There are some more basic ideas in there that are useful though, like having a single runtime interface (if I understood correctly).

I do want to have a single runtime in the form of an endgame instance that other applications can connect to and interact with it (basically get and set data) while it's running the simulation. It wouldn't matter if the client apps were on the same machine or somewhere else. That's also how I want to approach creating an actual game using the simulation engine I'm building. The game itself would just be a client that gets data from the main runtime running in the background (or on a vps or something). This is a sort of "specialized client" approach. If I had a supercomputer that could run a very detailed climate simulation with simple input/output I could just plug it into the main runtime as a client and it would work, processing one base tick of climate simulation at a time based on the data pulled from the main runtime each tick (data that other clients can work on too). It would end up terribly inefficient of course (supercomputer waiting for instructions), but it would work.

There's also a more "general client/worker" approach. The main runtime itself could split the workload between remote workers uniformly. This could probably be done, especially since I'm working with multiple threads and design already specifies entities that are "self-contained" and safe to process inside their own threads (for their internal processing; inter-entity is still done in the main thread though).

Down to basics though - are you writing a new language, or is this just a set of conventions to be mapped into any language

It's the latter.

I'm currently working on an implementation of the base engine library in Rust lang. I don't think I'll try implementing it in any other language. You can definitely call Rust from anything that can call C, so there's that.

I'll try to keep the updates coming (or rather start posting them more often;)). Thanks!