Author Topic: Announcing a year of *full-time* development on URR!  (Read 14272 times)

UltimaRatioRegum

  • Rogueliker
  • ***
  • Posts: 318
  • Karma: +0/-0
  • Username says it all, really.
    • View Profile
    • Ultima Ratio Regum
    • Email
Announcing a year of *full-time* development on URR!
« on: July 05, 2014, 12:38:05 PM »
Well, it's finally happening! I'm going to get the chance to code URR full-time for a year without messing around with a Kickstarter. I'm hyped beyond words. I've written in much more detail about it here on my blog (I was going to post the entire entry here rather than the link, but the images are colossal):

http://www.ultimaratioregum.co.uk/game/2014/07/05/the-big-announcement/

Bear

  • Rogueliker
  • ***
  • Posts: 308
  • Karma: +0/-0
    • View Profile
Re: Announcing a year of *full-time* development on URR!
« Reply #1 on: July 05, 2014, 08:17:44 PM »
URR has truly inspiring scope.  Congrats on all your work and on having an utterly cool vision to work on.

I'd really appreciate it if you could talk about the architecture.  In your blog you've talked about all kinds of content, but you haven't really talked about the design of the code and how to tie all this content together so it plays nice with all the other kinds of content and so that different parts of it don't dominate the other parts. 

You've got literally dozens, possibly hundreds, of interlocking systems that a given town, trader, road, etc, will all be serving a role in.  How is the underlying code organized so that the effects emerging from all these systems can be used to decide things, and keep track of all the decisions made in all these separate systems to find a solution that works with them all? 


guest509

  • Guest
Re: Announcing a year of *full-time* development on URR!
« Reply #2 on: July 06, 2014, 12:44:41 AM »
Yay!

Krice

  • (Banned)
  • Rogueliker
  • ***
  • Posts: 2316
  • Karma: +0/-2
    • View Profile
    • Email
Re: Announcing a year of *full-time* development on URR!
« Reply #3 on: July 06, 2014, 08:56:52 AM »
In your blog you've talked about all kinds of content, but you haven't really talked about the design of the code and how to tie all this content together so it plays nice with all the other kinds of content and so that different parts of it don't dominate the other parts.

My guess is there is no deeper gameplay, it's just building a huge world and hoping that it will create the gameplay by itself.

I've also "worked" full time during the years I was unemployed, but it really doesn't mean it's going to help a lot when you have a big project.
« Last Edit: July 06, 2014, 08:58:53 AM by Krice »

UltimaRatioRegum

  • Rogueliker
  • ***
  • Posts: 318
  • Karma: +0/-0
  • Username says it all, really.
    • View Profile
    • Ultima Ratio Regum
    • Email
Re: Announcing a year of *full-time* development on URR!
« Reply #4 on: July 06, 2014, 09:44:37 AM »
URR has truly inspiring scope.  Congrats on all your work and on having an utterly cool vision to work on.

I'd really appreciate it if you could talk about the architecture.  In your blog you've talked about all kinds of content, but you haven't really talked about the design of the code and how to tie all this content together so it plays nice with all the other kinds of content and so that different parts of it don't dominate the other parts. 

You've got literally dozens, possibly hundreds, of interlocking systems that a given town, trader, road, etc, will all be serving a role in.  How is the underlying code organized so that the effects emerging from all these systems can be used to decide things, and keep track of all the decisions made in all these separate systems to find a solution that works with them all?

Thanks! And sure. The main reason I don't talk about code design/architecture is because I very much consider my blog to be a development and game information blog, less of a "my adventure in learning to code blog" - there's obviously nothing wrong with the latter, it's just not the kind of blog I want to write. However, let me answer your question. The game basically takes place at two scales: the world map scale and the "human" scale, i.e. when you enter a particular map tile. There's also what we could call the "abstract" layer of non-physical data, things like what nations like each other, different religions and their spread, flags, history, etc (though history is closely tied to the physical world).

The core of the game's information is stored on the world map scale, so each tile has information about climate, rivers, roads, buildings, etc. For generating a city district, for example, when the world is generated it will decide up-front what special buildings need to be in that tile, but if the player never visits that tile, those buildings will never be spawned; each particular map grid on the human scale is only created when you enter it for the first time, and that is created according to whatever algorithm is appropriate for that area, combined with earlier information about what *must* be on that tile (special buildings etc). When it comes to things like moving between tiles, there's a bit of code which makes sure to always update both human and world maps on certain actions. In the future, I know this will be even more important, like when handling NPCs moving between different areas. The later core gameplay mechanic of changing the historical record will require all these systems to integrate closely, and that will be tricky, but I'm trying to set things up now to leave me in a good position when it comes to that a little further down the line.

Then, saving/loading, only the map grid you're walking around on is loaded. In turn, the interiors of most buildings are only generated when you first walk into them, though some are generated along the map grid if they're particularly important, or complex, or if going into that building is the only reason you would ever visit that map grid. 0.7 (the release after this one) is going to need a big overhaul of the saving/loading system to make it much more efficient, but that's the basic gist. Does that all answer your query? :)

Yay!

itshappening.gif!

My guess is there is no deeper gameplay, it's just building a huge world and hoping that it will create the gameplay by itself.

Yep, you're right as ever Krice ::). Not like I have a massively detailed gameplay plan or anything.

I've also "worked" full time during the years I was unemployed, but it really doesn't mean it's going to help a lot when you have a big project.

Well, I guess the results will speak for themselves, won't they?
« Last Edit: July 06, 2014, 09:50:43 AM by UltimaRatioRegum »

Bear

  • Rogueliker
  • ***
  • Posts: 308
  • Karma: +0/-0
    • View Profile
Re: Announcing a year of *full-time* development on URR!
« Reply #5 on: July 06, 2014, 01:36:50 PM »
Well, it doesn't, really.  I was actually asking about code organization and how different parts of your program communicate with each other. 

When your program generates, say, a library at a given tile, it has to know a bunch of things that were decided by different subsystems; it has to know the local architectural style and construction materials, it has to know what city district it's in, it has to know what area of the world is close enough for it to cover in detail, it has to know what "legendary" or game-important information was supposed to be stored there, it has to access the current version of the history of that area (which, whenever it changes, can change any of the other things), it has to know things like the current set of alliances and enmities of the kingdom its in and possibly the faction that built and/or maintain it, and so on. 

What I'm interested in is how all of these different systems put their information together in such a way that the code generating the library can access all of it -- I mean, is there just a checklist where it has to run down all the possible information sources and then resolve possible conflicts at generation time?  If it finds conflicts, do those percolate back up to the information sources so that they can un-conflict themselves?  Or do they communicate with each other to prevent conflicts from arising? 

And if they do communicate with each other to prevent conflicts from arising, how do you prevent that from, as a meta-effect, forming the all-encompassing "Divine Perception" which would prevent your "Berkeleyan Idealism gone berserk" substitution-of-history game mechanic from working?

« Last Edit: July 06, 2014, 01:39:53 PM by Bear »

UltimaRatioRegum

  • Rogueliker
  • ***
  • Posts: 318
  • Karma: +0/-0
  • Username says it all, really.
    • View Profile
    • Ultima Ratio Regum
    • Email
Re: Announcing a year of *full-time* development on URR!
« Reply #6 on: July 06, 2014, 01:59:37 PM »
Ah, got it. Misunderstood.

Your second paragraph is very accurate - there's a lot of data it needs to process. The overwhelming majority of the data is stored in a single thing called the "tracker", which contains dictionaries for civilizations, religions etc, and in turn each entry of those has information, as you say, about architectural styles, building materials, histories, conflicts, blah blah. To answer your question, then, there's basically two parts.

Your checklist suggestion is very accurate. When generating a grid it basically opens up all the relevant information and then "figures out" the best course of action from that. A good example of this is religious districts where, in 0.6, it will spawn an appropriate number of buildings of appropriate size for each religion with a presence in that city. This means it needs to take account of how many there are, then think about a sensible way to lay them out in the district, then pick up all the different religious building styles. This information is generally conflict-free - whenever changes are made, it is stored in all appropriate places. For example, the [family] class stores what civ it belongs to, and the [civ] class stores important families. It means a tiny amount of duplication of ID numbers, but means the game can always check in both places to make sure it's not making a mistake. If it is, an error gets raised (in debug) and I find what caused it. In the rare case where a conflict will still be found, it will default to whichever is considered "more important" - currently this means the information at the lowest resolution is more important, so if you have (in later versions) an instance of an NPC who thinks they belong to Civ X, but Civ X disagrees, the NPC will be the one the game will take. But, again, I try to ensure these conflicts never happen at all, and right now there should be nothing in the game where these conflicts can arise, but as complexity increases, the need for these kinds of checks will increase. One good example is spawning nomadic civilizations - they have a minimum size, so the game has to reject tiny crappy ones. What that means, though, is deleting a lot of data when tiny crappy ones are generated and starting again because the generation algorithm is dealing with other stuff at the same time. It works, and it's fine, but that's probably the best example at the moment.

You've described the game's core very well in your last paragraph, but I'm not sure what you mean by the question, though I know the concept of Divine Perception. Could you describe what kind of error you envisage happening there? If I understand correctly, though, you mean - how can you avoid there being a "true" version the game always checks against? EDIT: or, rather, when there has to be a true version of the game to check against, how can I have the idealism idea? How can the game know "which reality" to choose?
« Last Edit: July 06, 2014, 02:38:16 PM by UltimaRatioRegum »

Bear

  • Rogueliker
  • ***
  • Posts: 308
  • Karma: +0/-0
    • View Profile
Re: Announcing a year of *full-time* development on URR!
« Reply #7 on: July 06, 2014, 03:43:01 PM »
Well, in this case, "Divine Perception" would come about as a meta-effect where history cannot in fact change because you've spread knowledge of (or knowledge derived from) history around to all these different subsystems and so reached a state in which any change would be rejected (or repaired/undone immediately) by the part of the code that's tasked with maintaining consistency.

For example, if the map of a territory that version A of history marked "Lower Iran" shows up in version B of history as "Uqbar", the duplication of information between subsystems causes disagreements, where some parts of the code (say, some books still in the library that was generated twelve turns ago) still know it as "Lower Iran".   If the tracker is to keep things consistent, it has to reach down into all kinds of things and change some of them to make sure they agree, and do you have any real control over whether "Lower Iran" or "Uqbar" wins out as it resolves these inconsistencies? 

So, from the player's perspective, can history, version A (Lower Iran) ever actually give way to history, version B (Uqbar)? Especially given that when you introduce history version B, the shortest path to consistency, the one that would be selected by every consistency-checker I've ever heard of, is to simply revert it?


UltimaRatioRegum

  • Rogueliker
  • ***
  • Posts: 318
  • Karma: +0/-0
  • Username says it all, really.
    • View Profile
    • Ultima Ratio Regum
    • Email
Re: Announcing a year of *full-time* development on URR!
« Reply #8 on: July 06, 2014, 11:08:54 PM »
I see what you mean. Well, when I implement the history-changing mechanic, it will basically consist of an algorithm that "freezes" the game and looks through all the information and changes everything that needs changing before ever running the "check for inconsistencies" code. That might seem like it would require a loading screen or similar, but some very basic experiments show that information is indexed well enough it only takes a small portion of a second to check for every mention of X in the game's records, and from there it's only a small jump to have it change all the appropriate information, have it mark down what needs re-generating, etc.

Now, your example raises a question. There are two models - either there will be an "infinite" number of possible realities, where small portions can be changed at any time, or I will go for a model where there are only two realities - the pro-Uqbar and the "original", let's call them - and you can switch regions of the world between them. I am not going to go with #2 just because it would be simpler to code - I'll go with whichever I think will be better, but I'm still deciding which I think will be the more interesting option and mesh more closely with my design goals.

As for whether I have control, yes, absolutely. History can only be changed at set points, and at those points, the game will be programmed to ignore the consistency checker until the changes have been made (and the old version has been stored in case it comes back later). Changing history will be a specific, deliberate gameplay action, and you'll have a reasonable idea before you do it how it will "resonate" and what it will change, chaos-theory-wise, but there will always be some unexpected outcome due to the complexity of the connections within the world.

Really enjoying this conversation, btw. Although I'm still a little bit off implementing this mechanic, I have a very clear idea of how it's going to work both gameplay-wise and coding-wise, though as I say I remain unsure about the infinite-realities vs two-realities options. I see a lot of strength to each - the former would allow you to perhaps more accurately configure bits of the world to your advantage, whilst the latter could make for an interesting "two worlds"-esque gameplay mechanic based on which areas have been Uqbarified and which have not...

Bear

  • Rogueliker
  • ***
  • Posts: 308
  • Karma: +0/-0
    • View Profile
Re: Announcing a year of *full-time* development on URR!
« Reply #9 on: July 07, 2014, 03:11:16 AM »
I sort of envisage a totally consistent version of it as a really extended world-generation system, where you have "undo" that goes back to a point of divergence and then forward with a different possibility for a choice made at that point in history generation - but that wouldn't get the kind of subtle, gradual effects you're looking for; Nor would the new "reality" take into account the previous actions of the player. 

The history substitution mechanic is the really new ground; that's what's got my attention most of all the stuff you're planning for the game because it's very original.


UltimaRatioRegum

  • Rogueliker
  • ***
  • Posts: 318
  • Karma: +0/-0
  • Username says it all, really.
    • View Profile
    • Ultima Ratio Regum
    • Email
Re: Announcing a year of *full-time* development on URR!
« Reply #10 on: July 08, 2014, 01:56:51 AM »
That's definitely a possible model! As I say, I know exactly what I want the core mechanic to be, but the specifics of the core mechanic are still something I'm working on. There's so many possibilities and I want to make sure I choose the one that's going to get the gameplay effect I want. I'm very glad you like the sound of the history manipulation mechanic, anyway. Still doing the planning on it, but it really seems like something I need to plan beforehand to make the implementation as efficient as possible...

Bear

  • Rogueliker
  • ***
  • Posts: 308
  • Karma: +0/-0
    • View Profile
Re: Announcing a year of *full-time* development on URR!
« Reply #11 on: July 08, 2014, 03:05:28 AM »
Still doing the planning on it, but it really seems like something I need to plan beforehand to make the implementation as efficient as possible...

Fixed that for you....  ;)


UltimaRatioRegum

  • Rogueliker
  • ***
  • Posts: 318
  • Karma: +0/-0
  • Username says it all, really.
    • View Profile
    • Ultima Ratio Regum
    • Email
Re: Announcing a year of *full-time* development on URR!
« Reply #12 on: July 08, 2014, 07:07:53 PM »
Still doing the planning on it, but it really seems like something I need to plan beforehand to make the implementation as efficient as possible...

Fixed that for you....  ;)

Ha! You raise a good, and fractionally concerning, point...