[Dev] 0.1 "Babylon" Progress Thread

Discussion in 'Civ3 Future Development' started by Quintillus, Nov 1, 2021.

  1. Quintillus

    Quintillus Archiving Civ3 Content Moderator Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,212
    Location:
    Ohio
    It turns out that moving takes a lot of time, and this weekend I moved again. I think that gets us up to 4 moves this year for the 4 primary programmers on C7; does moving make it more likely that you'll take up C7 as a hobby? I don't know, but while I thought I'd have some down time to check CFC or work on C7, I didn't have Internet until this morning, and didn't touch C7, Civ, or any other games until last night. There is still a lot of unpacking to do and I'm still a bit tired, so progress will likely be slow from my end for several days yet. Now at least I've gone from "get the basics set up" to "do I put the snow tires on my living room floor in storage, or put them on the car first and put the summer tires in storage?"

    But I have started on the forest/jungle graphics. Large jungles are displaying; I realized that I don't know when to use large versus small jungle graphics. Presumably it's something along the line of how much neighboring jungle, or maybe water, there is. Part of the question is, has anyone already figured this out? Without Internet last night, I couldn't check beyond that I did not figure out the distinction for my editor. If you do know the answer, you've probably got a day or so to answer before I start investigating it. Maybe more.
     
  2. WildWeazel

    WildWeazel Carthago Creanda Est

    Joined:
    Jul 14, 2003
    Messages:
    7,210
    Location:
    %CIV3%\Conquests\Scenarios\
    I don't have the answer, but I'm guessing someone did at some point. One of the terrain artists or scenario makers might have cracked some of this esoteric stuff.
     
    Quintillus likes this.
  3. Flintlock

    Flintlock King

    Joined:
    Sep 25, 2004
    Messages:
    870
    Antal1987 labelled most of the methods inside the map renderer so it's easy for me to look things like this up. In this case the rule is surprisingly simple: if any of the NE, NW, SE, or SW neighbors are coast, small sprites are used; if either the NE or NW neighbors are hills, mountains, or volcano, small sprites are used; otherwise large ones are. The same rule applies to forests, jungle, and marsh.
     
    WildWeazel, Quintillus and Puppeteer like this.
  4. Quintillus

    Quintillus Archiving Civ3 Content Moderator Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,212
    Location:
    Ohio
    Awesome, thanks for the answer Flintlock! Perfect timing too, as I added pine forest before dinner. Sounds like perhaps I need to find Antal's thread and make a few bookmarks for reference.

    Although in the short term, I'll ask two questions that I am 90% sure about but could be wrong about. For Marsh, is it correct that the "Forest" graphics are never used, only the "Jungle" ones? I'm pretty confident about that as someone crossed out the jungle ones in the PCX file and all my marshes look regular - was that me or Firaxis who crossed them out - but maybe there's some edge case I haven't seem yet. Related to that, has anyone ever seen a pine marsh? They look sort of cool, but I don't think I've ever seen one, and recent attempts to invoke one in Firaxis's editor have been unsuccessful. I'm strangely tempted to try setting the "pine forest" flag on a marsh though... which would be an interesting feature for my Civ3 editor if it works.

    UPDATE: I patched my editor to make all new marshes be pine marshes. Alas, both the Firaxis editor and Civ3Conquests crash upon encountering pine marsh. So, no dice there on the legacy front, and those graphics must be unused. Though that doesn't mean that C7 couldn't support Pine Marsh.

    -----

    Semi related, I tried generating the SAV file (1234567 seed) in the Firaxis editor for reference as I add terrain, and while I could get very close, there were slight differences in mountain ranges. So I downloaded the latest version of Civ Intelligence Agency III, and verified that the map gen setting matched - they did. Next I played some more turns in-game (very sub-optimally, heavily focused on exploration), and found that the C7 code was right; with the map explored, CIA3, Civ3, and C7 all agreed. My most plausible explanation is that there are some differences between the random map gen in the Firaxis editor (version 1.03) and the Civ3 Conquests game (version 1.22). Maybe some changes were made in a later Civ3 patch that didn't get into the last Firaxis editor patch.

    I've attached the save game with a good chunk of the continent explored here, in case anyone else finds it useful for comparing C7 and either Civ3 or CIA3 side-by-side in the future. It might be useful for things like resources and rivers, too.
     

    Attached Files:

    Last edited: Dec 9, 2021
    Flintlock and Puppeteer like this.
  5. Quintillus

    Quintillus Archiving Civ3 Content Moderator Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,212
    Location:
    Ohio
    Small forests/jungles have been added, following the method Flintlock described. It looks much better now.

    Still have the plains/tundra variants to add; going to add them tomorrow.

    After that, I'm thinking I might add support for the "z" key for zoom. My main mouse went missing during my move, so I've been using a mouse that's nearly as old as I am, and doesn't have a scroll wheel. It's good for my page up/page down key usage, and makes me appreciate the scroll slider, but also makes me miss quicker zoom changes. It also makes me glad my computer still has a PS/2 port.
     
  6. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    Heh, glad the slider is still of use. I've thought about yanking that toolbar entirely, but it doesn't seem to be bothering anyone at the moment.

    That reminds me: there are still some zoom scenarios that don't work. I can't immediately recall, but it was either my Windows laptop trackpad pinch zoom and/or the Windows laptop touch screen pinch zoom that doesn't work. Two-finger scrolling doesn't zoom on the Mac trackpad (three-finger scrolling works as expected).

    So many zoom and scroll gestures. I've been tempted to try to export to Android or iOS and see what works, but I just don't imagine C7 realistically being targeted to mobile as it more or less requires a keyboard. (Raspberry Pi isn't officially supported, and the unofficial builds don't seem to have mono.)
     
  7. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    Uh...a quandary: I've added a dialog on MainMenu to select a Civ3 Home, and I'm putting that in GlobalSingleton. Buuut...

    Now I need to use that value. The path getter functions are static functions in Util and thus can't reach GlobalSingleton. So I could:
    • Refactor all calls to the Util functions to pass Civ3 Home path as well as other parameters
    • Move the Util path functions into GlobalSingleton (I was afraid of wanting/needing to throw more and more in there)
    • something else?
    As a side note, I used to have the GetCiv3Path() and Civ3MediaPath() in QueryCiv3 but moved it into C7 because I wanted to move as much file-related levers out of QueryCiv3 as possible to lower attack vectors as I want to expose those classes to user scripts. But I don't like them being in the Godot code, either, as C7GameData might need them. In face I was recently thinking of moving them there, probably into ImportCiv3.

    Hmm, maybe a combination of the above: Move GetCiv3Path() and Civ3PathFromRegistry() to C7GameData/ImportCiv3 and refactor the now-many functions tossing around media paths...maybe have stubs for them in GlobalSingleton...I dunno. As for Civ3MeidaPath(), I'm not sure it needs to move out of the Godot project as that's the only place we're accessing media.

    I guess tossing around Civ3 Home as a parameter is the cleanest functional code design; it just feels clunky to have to type that every function call as it never changes once it's set. Putting stub / convenience functions in GlobalSingleton may make less typing, but it feels icky every time I add something to GlobalSingleton.

    On the other hand, maybe Civ3 Home belongs in C7Engine? That feels more correct. Like with opening a save, I could stuff the selected path in GlobalSingleton just to pass it to C7Engine generated once we enter the game, and from then on all path references pull it from C7Engine.

    I'll have to think through all these flows. And maybe Civ3 Home doesn't belong in C7Engine after all; it's only needed for importing Civ3 data (a one-shot process during conversion) or using Civ3 media files (repeatedly done throughout a session), and that's not C7Engine. That's C7GameData/ImportCiv3 in the former and Godot code in the latter.

    Ok, I'm concluding that
    • Civ3 Home needs to be in GlobalSingleton - We need to access it from multiple scenes, but we really don't need it elsewhere except for ImportCiv3, but we're already calling that with a full path from the Godot code
    • The Util path finders don't need to move out of C7 for similar reasons
    • Let's refactor all path finder calls to pass Global.Civ3Home - It's some parameter repetition, but putting pass-through convenience functions in GlobalSingleton is just too icky and opens the door for multiple code paths to exist to get a file path which is bound to cause issues
    Edit: On a different note, I may change the Civ3 home dir-selector dialog to exist in the scene. This will persist the last-browsed folder in the scene file across runs which is a PITA for dev-time (because git and different devs having different folders) but will be handy for users. Actually, come to think of it, I should really just persist the path itself outside of the dialog.... Any ideas on how to avoid MainMenu.tscn updating in git every commit while allowing users to persist their folder selection? My only idea is to add MainMent.tscn to .gitignore and just remember to manually add any intentional changes. (Edit to the edit: Oh, clean filters are a thing that might do here, but unsure how that works cross-platform and cross-tool.)
     
    Last edited: Dec 9, 2021
  8. Kyriakos

    Kyriakos Creator

    Joined:
    Oct 15, 2003
    Messages:
    66,289
    Location:
    The Dream
    Some terrain animation would be good to have. Even a few frames can liven things up ;)
     
  9. Vuldacon

    Vuldacon Dedicated to Excellence Supporter

    Joined:
    Nov 14, 2001
    Messages:
    7,034
    Gender:
    Male
    Location:
    USA
    I agree... a few animated terrain tiles such as a Waterfall or Billboard as I placed in EFZI2 Elite add a nice touch to Games. Immobile Units were used but it would be Great to be able to add such animations as simply animated Terrain so the AI would not go after them as Units. In order to prevent the AI from going after Terrain Units, they need to be set on Impassable Terrain and that can also cause problems such as if pollution appears on them, it cannot be cleaned.
     
    Kyriakos likes this.
  10. Quintillus

    Quintillus Archiving Civ3 Content Moderator Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,212
    Location:
    Ohio
    More animation could be nice, although it's probably getting ahead of the programming as we only have proof of concepts of animation so far, and none enabled in C7 yet.

    I think Vuldacon may be on to something with the waterfall/billboard examples as well - that would be a smaller stepping stone than a whole terrain set with animation, and could be implemented as resources. For what it's worth, animated resources are one of the things that stands out as a nice thing in Civ V to me as well. Those adorable foxes representing furs? It almost made you not want to build a trapping hut.

    The way I implemented Settings/Preferences in my editor would provide another option, and one that I've been happy with over the years with the editor, even if it might not be the most preferred route in all cases.

    That is, having the settings themselves be static. The thinking is that a setting is static, and you'll only ever have one instance of it per copy of the editor that is running. If they are static, any area that needs to know what the user's settings are can do so quickly and easily, without any awkward work-arounds.

    (Technically, the editor only partially does this. In some places it uses a static reference to a Settings object instead. But what I described above is what I found worked best, and newer parts of the editor, and subsequent non-Civ projects, work like what I described above)

    An example from another project, in Java:

    Code:
    public class Settings {
        public static int CONSOLE_WIDTH = 80;
        public static int CONSOLE_HEIGHT = 25;
        public static int PAGE_DOWN_MARGIN = 2;
        public static String LINK_STYLE = "External";
    
    It may be less "clean" in theory, and is less functional, but to me the resulting code is cleaner and simpler than passing a static variable (in the example, Global.Civ3Home) everywhere. As long as there is one source of truth for the variable's value (Global.Civ3Home), in practice I prefer the simpler API of pass in what's relevant to the Util methods, and have them go use Global.Civ3Home themselves.

    I'm also increasingly favoring persisting settings locally, because of the different dev folders issue you mentioned. It's already getting old re-setting the home directory on the SAV import script. I took the 1993 approach in my editor and saved the preferences in the local directory, in an INI file. A more "sophisticated" approach would be to store it somewhere in the user directory; the old "AppData? Roaming? LocalLow? My Documents?" question. *shrug* Almost any option would be better than having local folders be synced across Git. Which, come to think of it, wouldn't the local folders in MainMenu.tscn cause it to not work for the general CFC audience for the "Babylon" preview?
     
    Kyriakos likes this.
  11. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    Actually...

    I find that two modders showing an unprompted interest in animated terrain highly interesting. And it's not on the road map, but unlike a lot of other ideas, the framework to implement this is already in-place.

    Let's start an Animated Terrain Discussion thread!
     
    Kyriakos likes this.
  12. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    (That is from the Aztec thread, but replying here.) Ok, I'm going to do this now. There is a flurry of interest in C7, so I think having sporadic builds between named releases will be of interest to some (and help keep the interest going). I'm adding automated release to my mental to-do list...maybe I should put it in the project board.

    I have an idea for this involving .gitattributes clean filters. Or maybe in this case it's a smudge filter. I already want to filter out specific changes to MainMenu.tscn at dev time, and if that works a similar process may work for managing whether music is on.

    Alternately the build or (future) release action script can flip the music switch on.
     
    WildWeazel likes this.
  13. Quintillus

    Quintillus Archiving Civ3 Content Moderator Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,212
    Location:
    Ohio
    I'm up for trying out the Git filters. Just not always awake enough to understand new-to-me Git features when I come across them :). I vaguely recall getting something of that sort working around 2014, but it's been long enough that how my team at the time did it no longer comes to mind.

    Work is slowly progressing on forest graphics for various base terrains. I realized we don't actually have tundras yet (only the graphics of tundras), so I'll be adding that. Post-move tasks are still taking up a lot of time, but it's finally starting to look like a normal apartment instead of a supply depot.
     
  14. WildWeazel

    WildWeazel Carthago Creanda Est

    Joined:
    Jul 14, 2003
    Messages:
    7,210
    Location:
    %CIV3%\Conquests\Scenarios\
    Edited to rephrase.

    We could adopt a config hierarchy with different files taking precedence. Start with reasonable values in code. Override those from a global default config, similar to conquests.ini, under source control with settings for release builds. Then override those with an optional local config, for now at a static path ignored by git. Later on the local config could become part of the mod structure, so that mods can tweak global settings.
     
    Last edited: Dec 10, 2021
  15. Quintillus

    Quintillus Archiving Civ3 Content Moderator Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,212
    Location:
    Ohio
    I've finished up the forest work; there's a PR out there for it now. Going to refactor our terrain type (dummy coding) debt before adding marshes.

    I'm also probably going to, at least locally, change how Quick Start works to load via ImportCiv3 and a BIQ rather than the JSON C7 save. One of the stumbling blocks I kept running into was forgetting to re-generate the JSON, and wasting time investigating why the MapView wasn't working correctly when the problem was not the MapView, but the data. The JSON is useful as a placeholder new map, particularly for the distribution, but from a dev cycle standpoint, working on something where ImportCiv3 is being enhanced, it's been more of a pain than a benefit. I'd rather have Quick Start/New Game just bring up the Load dialog so I have to choose a Civ3 SAV and can't accidentally forget that step.

    It also seems not right to me that I'm regularly having commits that have thousands of lines of changes, simply due to the JSON. My merge request has 26,000 net lines changed, but only about 200 of those are "real" changes. Sometimes it does make sense to commit data files, but the frequency of it is making me question whether it makes sense here.

    One other change of note is that I renamed Tile's terrainType to baseTerrainType (there is also overlayTerrainType). This was due to another repeated stumbling block, in both code I was writing and at least one place someone else had written it - using terrainType where overlayTerrainType was intended. I think it was too easy to see "terrainType" and think "what the tile will be on the map", whereas that is actually overlayTerrainType. Hopefully, the base/overlay distinction being specified in all places will significantly reduce confusion and using the wrong one going forward.

    --------

    The config hierarchy sounds potentially useful, although I question if settings should really be set by mods rather than users. One of my GOTM pain points is that Civ3 remembers settings in saves, so whenever I start playing a GOTM I have to go in and change all the settings that the scenario creator sets differently than I prefer them. To me it seems like mods should change rules, and users should change settings, with sensible defaults provided by the application.
     
  16. WildWeazel

    WildWeazel Carthago Creanda Est

    Joined:
    Jul 14, 2003
    Messages:
    7,210
    Location:
    %CIV3%\Conquests\Scenarios\
    There's also git update-index --assume-unchanged <file> if you just want to ignore your own changes to a file until it changes upstream, but then you have to reset and redo it.

    On big change sets, meh. I work on projects with generated code that changes often and it's still checked in. You can tell git to treat the files as binary so they don't show line changes, but then you can't merge them.
     
    Quintillus likes this.
  17. Quintillus

    Quintillus Archiving Civ3 Content Moderator Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,212
    Location:
    Ohio
    Neat, --assume-unchanged works well for the file path in Program.cs in the _Console project. Now I won't accidentally commit my local directory for that.

    I guess on the projects I've been on, we've treated large artifacts that are generated based on our code as something that should be generated in the build or deploy process. I don't really feel like arguing the point right now, so if it's not bothering anyone else, I'll just adjust my local configuration to sidestep the issue.

    I've added "real" terrain types from Civ3, automatically converted when you open a file, with the tiles pointing to the imported terrains. This wound up simplifying the ImportSav code a fair amount, and means we now have "real" flood plains, sea, and ocean, as well as the dummy terrain types we had before. I believe this sidesteps the sea/ocean support as well, as we now get that for free with the file ID/index, and them being imported for real. PR: https://github.com/C7-Game/Prototype/pull/51

    Remaining World Map Terrain tasks:

    - Marsh
    - Rivers
    - Flood plain graphics along rivers
    - Potential bonus stuff that I know less about how to do, such as waterfalls and deltas
     
    WildWeazel and Puppeteer like this.
  18. Quintillus

    Quintillus Archiving Civ3 Content Moderator Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,212
    Location:
    Ohio
    After getting the forests working, and a few non-Civ-related items, I decided to chase something shiny. Terrain should count in theory, but maybe because I'd already done terrain once before, it wasn't proving shiny enough to keep me maximally engaged.

    Thus, I went off on a tangent and added prototype city production. Shields and food are added to cities each turn, at a fixed rate, and a simple production chain of Warrior/Chariot/Settler has been added, with different shield costs per unit. The city label has been updated to accurately reflect city size, production, and the number of turns till growth, and units are created when appropriate. This means you can get more units, and with the Settlers, build more cities. See the screenshot below.

    upload_2021-12-12_3-38-54.png

    Next it probably speeding up the AI turn times - this is probably the first time I've played 36 turns in one game of C7. That ought to be very easy to speed up, at least!

    It does have me thinking about what would be necessary to have a basic gameplay experience. You can now built units (and will, whether you want to or not), but there isn't much to do with them. So, I'm thinking it would be kind of nice to add some barbarian movement, and super simple barbarian interactions. Although that also seems to be getting ahead of our initial milestone list. So maybe not yet. On the other hand, we're already blurring the lines there a bit.

    In the shorter term, I might look at updating the terrain in the status area to be accurate, instead of always staying Grassland. I also need to figure out why forests are currently free in terms of movement points, and am starting to think about importing real unit data from Civ3. One particular goal of that would be the differentiating land and sea units, since right now our land units can all walk on water, and that really isn't supposed to be the case.

    Hopefully, this is a virtuous cycle, as being able to do more things seems to be generating enthusiasm for adding yet more things to do.
     
    Puppeteer likes this.
  19. Quintillus

    Quintillus Archiving Civ3 Content Moderator Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,212
    Location:
    Ohio
    I have updated the progress status in the first post. Place cities is now Done. World map is still In Progress, but is a lot farther along. Prototype Mods is In Progress; I am pretty sure Puppeteer has shored this up lately, particularly with regards to search paths for custom graphics, though I'm not sure it's Adequate/Done yet.

    I am reminded that we should probably add support for moving units with the mouse. I made sure my laptop had a NumPad when I bought it, so I'd kind of forgotten that item as NumPad movement works. But mouse movement should work. If we support long-distance movement, that could add some interesting mechanics with movement over multiple turns, and end-of-turn processing moving units.

    Map visibility is the big thing for Babylon that we haven't added. I am somewhat wondering if it should be in Babylon. Flintlock's unit animation work falls into Carthage/Dutch, yet seems more like an early feature to me. I could see Unit Combat also being an earlier one than map visibility. Although, map visibility is one of the 4 X's in 4X (eXploration).

    I suppose the other reason that map visibility is bringing up the tail end of Babylon is that not having it has been beneficial, at least for the World Map objective. Seeing everything makes it easier to see if unusual features such as volcanos are working.

    Thoughts? Is Map Visibility a Babylon item or should it be traded for a Carthage/Dutch item? @Puppeteer might be the most relevant person to this, since IIRC he has worked with it before on CIA3, and thus would have a better idea than I do as to the complexity and effort involved in it.
     
  20. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    It's not yet, but it's close. It may be trivial; I've just been derailed. I'm looking for where the mod path is; I think it may be in the SAV before the BIQ. There is a path in the BIQ, but it's not right for at least some of the PTW-included terrain mods which is weird.

    It should be trivial to just not draw the undiscovered tiles. I don't seem to have the value coded in QueryCiv3 yet, but it just needs to be ported over from my other languages.

    If we want it "just like Civ3" we'll need to figure out the fog of war graphics to enable tile peeking, but in the near term I think just not drawing undiscovered tiles is adequate.

    Oh, also, I never coded for a "live" game. I just read the save file. If we're moving units around and plopping new cities, clearing fog of war is a thing to be coded for C7.
     
    Quintillus likes this.

Share This Page