[Dev] 0.1 "Babylon" Progress Thread

I happened to spot that unit combat branch on GitHub this afternoon. Definitely an exciting feature, although I only glanced over it at the highest level since I was mainly there to make sure my code was separated into different PRs by what it did, which it wasn't yet at the time. That will complement the basic opponent work nicely, since one of the big problems with the basic opponent work is the AI rapidly fills the map with Warriors (and a few Chariots). Cheap units + lots of cities + no combat = pretty soon every tile has units on it.

Yeah, I agree, "distanceTo" works well there. I tend to err on the side of adding to much detail than too little, but it's quite clear what it's referring to there from the parameters.

I agree re: Babylon; what is open as a PR plus perhaps wrapping up a small amount of in-progress stuff is definitely enough for a release. The "other in-progress stuff" being:
- Flintlock's combat work
- My first step of Rivers work, which is pretty much ready for a PR
- I have one more iteration of AI improvements on top of the one already out there. Was thinking of adding one more commit to it (to fix the AI not being able to walk around water when the fastest-route-as-the-raven-flies route is across water), but that's not critical.
- If there's time, I'll wire up Load Scenario to default to BIQs, but that's not critical.

Map visibility, I was starting to think about it with the Settler AI and Explorer AI, it could be useful to have that feature so the AI would only work based on what it knows about tiles (I'm pretty sure from what I've read that the Civ AI always uses full knowledge of the map, but with some improvements to the Explorer AI, the Settler AI could rely only on what the AI knows, and we could have the AI play on equal footing form a tile-visibility standpoint). And of course that would add one of the 4X's.

But I agree that we should not wait on that to make a release. We've added a lot of visible progress since Aztec, and map visibility is not going to be quick like wiring up Load Scenario would be.

Prototype mods I also agree, that's a big chunk which could lead to a lot of discussions. I'd probably kick that down past the following release as well, unless someone has the enthusiasm to chase it. I think we'd get better value, and bring the project closer to long-term viability, by adding in more mechanics first.
 
Load Scenario is now wired up in the BIQ PR.

One more thing I thought of for a Babylon release, I think we should set the zoom to 100%, and the grid to turned off, as the defaults. The grid is helpful for development, especially when adding terrain and rivers, but I believe most players play with it off most of the time (or maybe I'm the only one, I haven't done a scientific survey on it yet). The zoom shows that we can zoom, but if you don't know the "Z" key shortcut, it's hard to zoom in to a level that doesn't have the able-to-see-through-the-terrain effect.

It's probably also time to retire the "End Turn" button at the top-left. On the other hand, I use the sidebar menu on the right pretty often to go back to the main menu and be able to load something else without a full restart, so I'd favor keeping it in for now; it's also pretty unobtrusive starting out collapsed.
 
Quintillus said:
It's probably also time to retire the "End Turn" button at the top-left. On the other hand, I use the sidebar menu on the right pretty often to go back to the main menu and be able to load something else without a full restart, so I'd favor keeping it in for now; it's also pretty unobtrusive starting out collapsed.
Click to expand...

Both are from very early on in development and were always temporary placeholders. I'm surprised they lived this long.

I forgot the sidebar can return to the main menu; that would be handy. I haven't used the sidebar in ages (of commits and PRs), but my original drive to keep it in there (but unobtrusive to keep the target off its back) was to ensure scrolling and zoom controls were accessible in cases where we don't have a scroll or drag gestures coded or otherwise don't have scroll or zoom on a particular configuration.

Touchscreen gestures, trackpad gestures, and mouse gestures are all distinct. And some trackpads emulate mouse wheel scrolling and/or have their own gesture API. It's been a while since I checked, but I'm not sure pinch zooming works on touchscreen laptops even now. But literally nobody including me has complained so far.
 
It might be that no one has complained because no one is testing with the hardware. I, at least, don't have any touchscreen laptops. I'm not sure that I've tried touchpad zooming, either, since the first thing I do when I use a laptop for development is connect and turn on a mouse. But I do know that my laptops' touchpads emulate mouse wheel scrolling quite well for every other application I've tried, so I'd be surprised if it didn't work. They're the traditional scroll-on-the-side method though, not the fancy multi-finger mouse gestures types. The older laptop does support fancy gesture with a specific driver, but I prefer the traditional method.

It is probably worth making sure those work at some point. But if no one's complaining about it, I wouldn't try to stuff it into Babylon if it turns out it doesn't work on every type of hardware.

I've approved Flintlock's merge request; I'll probably start merging my unreviewed/changes-made-but-not-re-approved ones that have reached 5 days at some point today if no one has looked at them. Having things sit for months isn't good.

Edit: This one: https://github.com/C7-Game/Prototype/pull/77 is the bottleneck. I've made some changes suggested by @WildWeazel, so I think it's probably okay to merge, but it hasn't technically been approved. Flintlock already said the BasicOpponents one is probably okay to merge, but it depends on 77, so merging it first would just increase the size of 77.
 
After the backlog we got in December, which stopped progress for more or less a month, I don't think we're ready for required reviews at this point. I think @Caro-Kann 's proposal of "if no one reviews it within 5 days, you can self-review and merge" is much more appropriate given recent project history. Requiring reviews now would carry a significant risk of stalling the project again, and I've already mentioned that I'm unlikely to return to active development if that happens; a post Puppeteer "liked", and Flintlock mentioned that he isn't going to be a solo dev on this project.

If we get into a rhythm where reviews are pretty consistently happening within that 5-day window, and it's not just one person (in December/January, that person was me) doing all the reviews other than their own, I could be convinced that we're ready for that step. But we've had less than a week of somewhat decent response time on pull requests, which IMO is not nearly enough to conclude we're ready to mandate it after how December went.

I also don't think mandating reviews will help with waiting on each other... even if it wasn't enabled in GitHub in December, we were essentially requiring it, and we spent a lot of time waiting on each other.

Things that I think could help us get to that point:

- More people participating in reviews/approving PRs (has been happening during the past week but let's see if it continues to)
- Smaller PRs so it's not a huge time commitment to review it (also has been happening. This is why I've split up my AI work, am splitting up rivers, etc. But again, I'm not sure we're there consistently)

We're also at a point where the negative outcome of a regression slipping through is not very impactful (the "prototype" repo name is still fairly accurate), and most/all PRs are coming from established contributors. I'm thinking of adding more tests to provide some guardrails around the most-impactful potential regressions (failing to open SAVs we previously could open, for example). But overall, I'd rather have us make a few mistakes along the way than stifle our velocity with too strict of requirements.
 
I just found, after seeing that you did it, that you can approve/disapprove PRs anyway. I thought that was tied to the branch protection rules. So disregard for now. (But also, you can approve your own merges.)

Smaller PRs are good! I'm much more likely to actually review it if it's small. Tests are also great.
 
Ah, yes, it is possible to approve/disapprove without it being required. Although I do not seem to be able to approve my own merges. In the cases where they have been sitting a long time without review (mostly in December/January), or before we were trying to review them in November, and I'd self-review them, I'd leave a comment indicating that I'd taken another look at it after letting it sit long enough to have some fresh perspective.
 
Quintillus said:
Flintlock already said the BasicOpponents one is probably okay to merge
Click to expand...
I'll go ahead and tick off the box, but if anyone wants to do a thorough review, don't let that stop you. One more remark, about that code that iterates over surrounding tiles (in findSettlerLocation), I see there's a comment there indicating it's provisional and I agree it's pretty awkward. I've already written some code to do the same thing as part of C3X. C doesn't have fancy things like HashSets so I had to write basic for loops over tile coords. But as a result it should perform close to optimally, and I've verified that it works, so we should port it over to C7 when the time comes to revise that code.
 
I've continue to make progress towards the last things I'd like to have in Babylon, and have opened two more PRs, which build on BasicOpponents (which in turns builds on UnitPrototypes), and make some strides towards improved settler AI.

"Slightly Improved AI" (https://github.com/C7-Game/Prototype/pull/86) allows the AI to build settlers progressively farther out, theoretically as far out as the end of their continent, although due to some shortcomings they often only get partway. It also causes the AI to fortify units in its cities.
"BFS Pathing" (https://github.com/C7-Game/Prototype/pull/85) builds on PR #86, and implements Breadth-First-Search pathing as an improvement over the greedy as-the-crow-flies pathing used previously. This allows the AI settlers to reach everywhere on their starting landmass. It's worth noting that more sophisticated pathing algorithms will be needed later for the AI to take sensible actions, but in our current state with no roads and moving 1-movement settlers, this simple algorithm is adequate.

That means the only remaining item I'd like to try to get into Babylon is my rivers code, which is probably also about ready for a PR. At that point, I'll start considering everything else I do as towards the next milestone, whether that's Babylon II or Carthage.

Flintlock said:
I'll go ahead and tick off the box, but if anyone wants to do a thorough review, don't let that stop you. One more remark, about that code that iterates over surrounding tiles (in findSettlerLocation), I see there's a comment there indicating it's provisional and I agree it's pretty awkward. I've already written some code to do the same thing as part of C3X. C doesn't have fancy things like HashSets so I had to write basic for loops over tile coords. But as a result it should perform close to optimally, and I've verified that it works, so we should port it over to C7 when the time comes to revise that code.
Click to expand...

Ah yes, the infamous ring city search. I don't expect it to stick around, that was a "first thing I thought of that worked" solution. I am sure there will be a time to revise it, and would welcome an improved version whenever the right time is.
 
I've done some work towards making volume configurable via an INI file. In the process, learning more about Godot's audio system, which uses the decibel system rather than percentages to express volume. The goal of this work is to allow us to ship Babylon with sound enabled, while being able to disable it locally if we don't want to be serenaded with the main menu music every time we start C7.

There's a pull request for this one at: https://github.com/C7-Game/Prototype/pull/112/files
 
Quintillus said:
Land/sea difference is factored into movement
Click to expand...
  • Shouldn't "Air" be in there, as well? (Perhaps some post-biplane Tech might allow some Air Units to pass over Mountains, which could be impassible to Land Units.)
  • Also, accommodating "Hybrid" Unit Types would be great (Helicopters having some properties from both Air and Land.)
BTW, great stuff, all around :)
 
Ozymandias said:
  • Shouldn't "Air" be in there, as well? (Perhaps some post-biplane Tech might allow some Air Units to pass over Mountains, which could be impassible to Land Units.)
  • Also, accommodating "Hybrid" Unit Types would be great (Helicopters having some properties from both Air and Land.)
BTW, great stuff, all around :)
Click to expand...

Eventually, yes. But air units are well beyond the scope of Babylon!

Hybrid would be interesting. But they're also beyond the scope of Babylon. Although what is not-so-far beyond the scope would be converting the current code to be more flexible about asking for valid neighboring terrains to move to, rather than more hard-coded items such as terrain named "Sea", "Coast", or "Ocean", for example. Issue #58 is one I want to do soon to address the first part of that, but beyond that, if we make it so that instead of selecting a unit class, you select valid terrains a unit can move on (with unit classes being shortcuts for common configurations), then you could modify a "Land" unit to add "Coast" to make it an amphibious vehicle, for example. And that's something that shouldn't be difficult (famous last words),and would fit in with the "make things more flexible for modders" goal. It would also provide a "proper" way to limit units beyond the hacks we've had to use over the years by making units as "wheeled" to prevent them from going across certain types of terrain.

And thanks! It's fun seeing more things come together.
 
I just merged the Sounds-Configuration-Via-INI-File change that WildWeazel approved, into Development. Be aware that if you merge Development into your branch, or make a new branch from it, C7 will now play Main Menu music. You may wish to mute your speakers if you are in a library! You can change the volume by opening the C7.ini file it creates (in the C7 sub-directory of Prototype) and changing the "musicVolume = 100" line to "musicVolume = 0". Or set it to any other value for louder or quieter music. Just be aware that if you set the music's power level to be over 9000, you may experience clipping.

Tonight the branch I pushed is the one that will allow non-English-language BIQs/SAVs to be imported and have the terrain function correctly. Although I consider this to be part of the "World Map" feature, it can also be considered the first issue that works towards Internationalization (I18N) support.
 
Got a new screenshot tonight!

upload_2022-3-6_1-48-46.png


As long as I've committed everything correctly, you should be able to see it for yourself in the "CustomMenuBackground" branch.

The background is based on the one I made for Civ in 2008, based on a Eugene Delacroix painting. The fonts aren't as fancy, as I had a trial of Adobe Fireworks then which made it easy to make the fonts fancy, and I was just using Krita tonight (after a less successful attempt with the GIMP). The background works out to a 500-some KB JPG, which is in Git; I also have a 24 MB Krita file with layers and the ability to change the fonts locally. They're SVG-based so in theory we can make them do anything an SVG font can do.

It's all subject to change... do we want to brand it as WildWeazel's, like Sid Meier's or Jon Shafer's? The C7 name is probably a placeholder. And I added Babylon both so it will be easy to tell which milestone someone is using, and since it looked a bit empty without it. C7 takes up a lot less space than Civilization, even in 192-point font.

I should also note that the "C7" logo here is not a precise match to what WildWeazel did in the logo. We should probably document our design choices somewhere, as well as figure out how we want to store large source files such as that 24 MB Krita file. I went with a close approximation to WildWeazel's logo, but don't know exactly which font it uses (or if it's freeform).

Edit: Forgot to mention, this background also scales with the window size, which is a new feature. Make it fullscreen, the knights get bigger, the C7 gets bigger. Still have to make the menu options be anchored properly to the right side, but I wish Civ had scaling backgrounds! The native res is 2160x1350, so at high enough resolutions it won't be "native" anymore, but I still like it more than having borders around the edges.
 
LOL I hardly think it's mine to brand :) But I do like the idea of a version specific background, and now that you mention it why not a themed image too? Something like the Hanging Gardens or Code of Hammurabi. There should be plenty of nice public domain artwork for each of our milestones. I don't think I even saved the working file for the original logo. I just picked (two different!) fonts that fit together from the default GIMP list, assuming we'd get around to making something nicer.
 
I like that idea of a themed image. And indeed, I was thinking I probably wouldn't want that level of billing, either. As I recall Sid himself was hesitant and was only persuaded because marketing believed customers would be more likely to pick up Microprose's next product if his name was on it, since Microprose was known for (IIRC) flight simulators, and their next product was not very closely related.

I've opened a PR (https://github.com/C7-Game/Prototype/pull/126) to fix the horses-on-every-tile issue. This also moves in the direction of storing references to objects in the JSON, rather than embedded objects (namely resources) on tiles. In addition to saving 30KB on the static-json, this means you can update the resources more easily in the text file (and since the references are text keys, e.g. "Iron", it's easier to update than if you have to remember that Iron has resource index 2).

Unfortunately it appears as a roughly 250,000 line PR... it seems my update to .gitattributes to make it binary didn't work.

Code: 
# Super-long text files
C7/c7-static-map-save.json binary

Actual length is a few dozen lines.

Also of note to developers is the [JsonIgnore] attribute, which is the equivalent of Transient in Java when it comes to serialization, and belongs to the System.Text.Json.Serialization; namespace. It causes attributes to not be outputted to JSON when the data is serialized (and thus allows not embedding full objects). It's also the equivalent of [ScriptIgnore] in full-fat .NET (as opposed to .NET core), so if you see [ScriptIgnore] suggested somewhere, you can use [JsonIgnore] instead.
 
"Babylon" continues to wind down. The horses have been returned to their pastures; Flintlock's combat + animation will likely be merged tomorrow (3/13), and I'm going to self-review my last Settler AI item that's been awaiting review for 22 days and get it merged (we're not out of the woods on the review process yet). That one also adds a couple more AI opponents to make the world more alive.

What's left should all be fairly small:
- Main menu background. Poll here. So far it's looking like a landslide, and if that continues I might just go ahead and do it sooner rather than later. So if you have a particular preference, vote now.
- World wrap settings. Should be flipping a switch, although conditionally in the case of loaded Civ maps. Not a strict necessity but if it's quick I'd like to add it.

That's... probably it. Fixing the seams is too big of a change for this late, and is mitigated by the default zoom now being 100%. Bonus grassland and VS 2019 support don't affect the gameplay so it doesn't matter if they get merged by Babylon (although I might go ahead with the VS 2019 since that lets me try it out for real, which I'm going to do despite Rider being de-embargoed since I went to the trouble of setting it up). And the terrain type on the info box can also wait till Carthage, with the other World Map improvements. With the updates around currently selected units that will arrive with Flintlock's changes, I didn't want to update that one first.

I've kicked off the GitHub Action to build things to make sure it still works. But I'm feeling good about a release arriving in the near future.
 
You must log in or register to reply here.

Similar threads

Quintillus
[Dev] 0.1 "Babylon" Release Planning
2 3
Replies
44
Views
3K
WildWeazel
WildWeazel
Quintillus
  • Sticky
[Release] Carthage Preview 4
Replies
7
Views
2K
timerover51
timerover51
Quintillus
[Release] Carthage Preview 3
Replies
1
Views
1K
B-29_Bomber
B
Quintillus
[Dev] Early 0.2 "Carthage" Progress Thread
2
Replies
30
Views
903
Puppeteer
Puppeteer
Quintillus
[Release] C7 Babylon Release Now Available!
Replies
13
Views
2K
Vuldacon
Vuldacon
Top Bottom