[Dev] 0.1 "Babylon" Release Planning

[Quintillus]

Spinning off a separate thread for this so it isn't interleaved with development updates.

There seems to be general consensus from the posts in that thread that we have made enough progress to justify another release. We have all the items in "Babylon" listed in the proposal document other than tile visibility and prototype mods, and the first incarnation of combat is in progress, which was originally in the "Carthage" milestone. I'm of the opinion that once the open PRs are merged, and the first combat incarnation, we should make a release.

We released Aztec on December 7, 2021, a date which is now over two months ago, although the build date was November 29th. So, what have we added since then?

- Mountains, hills, forests, jungles, marsh, volcanoes... all the overlay terrains.
- Units are now animated
- Basic city production/growth
- BIQ/SAV data reading is now much more complete
- Mod media support (@Puppeteer is this still working? I had some unanswered questions about a suspicious change regarding it in the SAV Slurping update and suspect it isn't)
- Barbarians now move around the map, and spawn units and galleys
- Added AI civilizations, which build cities and send units out exploring
- BIQs are now openable (with some limitations), as well as non-square-map SAVs
- Performance improvements for PCX and FLC files
- Better error handling
- Zoom via keyboard

Soon, this will also include early combat and rivers displaying.

The highly questionable metric of lines of code also suggests we've added a lot since Aztec; we had 4676 lines of C# code (not counting comments and whitespace) at Aztec, and have 8000-8700 now, depending on which branch is examined. It will likely wind up being around double once the outstanding work is merged in.

There are a couple things I think should be tweaked or potentially tweaked for the release:

- Enable main menu music (we forgot to do this for Aztec)
- Bump the number of AI opponents up; I set it to 1 for testing, but would suggest at least 3.
- IMO we should default to 100% zoom, and turn off the grid, for first impressions.

But generally I think we're ready to cut another release.

 

[Puppeteer]

Mod media support (@Puppeteer is this still working? I had some unanswered questions about a suspicious change regarding it in the SAV Slurping update and suspect it isn't)

I'm pretty sure it's not working reliably if at all. It's been a while, but I think I only had it working when I hard-coded some known locations to search. When I went looking for paths in the sav & bic files...they just didn't make any damn sense and often didn't match their real location or name.

 

[Flintlock]

But generally I think we're ready to cut another release.

Agreed.

For my part, I merged in the MapView polish PR today, so now all that's left is the unit combat branch. It's in an okay place right now but I'm holding off on creating a PR for it until some more of Quintillus' work has been merged in since it will require some effort to reconcile with the combat branch. The combat branch is based off of the threaded architecture I put together last month for animations so, for example, AI units need to be made to move using the MapUnit.move extension method so they trigger animations and combat. I started on the reconciling by merging BasicOpponents into InitialCombat and watched the AI fight the barbs (the barbs won).

 

[Quintillus]

Well, that is quite the spectacle watching the AI and the barbarians! I don't think I've seen that much disorderly chaos since the time I played Chivalry: Medieval Warfare on an all-fisticuffs free-for-all tavern map. And while Greece survived the first game, Babylon got destroyed!

That does make sense about the merging. I had some periphery knowledge that the movement would have to change, but wasn't sure what the best way to go about that would be (going through the UnitInteractions.move method that also serves as the external interface made some sense, but not enough to make me confident).

Game two, the Greeks and I have spawned near each other. We'll see how this goes! Fortunately the SlightlyImprovedAI branch has not been merged in yet! ... and, Greece is defeated in 17 turns, including all units. Yeah, good thing that branch teaches them not to leave their cities undefended. Pretty cool seeing the catapult bombard units though!

 

[WildWeazel]

I generally agree we're pretty close to something releasable, even if it's not the "final" Babylon. (Which raises another question- if/when we start doing intermediate releases, should they fall under the previous or next milestone? In other words are we cutting a first draft of a milestone and then building on it, or building up to the milestone?)

I still haven't broken down the Babylon features so let's start that here. Again, not that all of these must be met.

• World map
  • The main game screen should include a working tilemap (scroll, zoom, wrap, laid out and drawn correctly) - something we largely had working already in Aztec.
  • All terrains should be drawn with the correct tiles, within reason
• Map visibility
  • Each player should have its own "view" of the world map with visible tiles, undiscovered tiles, and fog of war
  • Fog of war should preserve and render only certain items as of when it was last visible
• Movable units
  • Unit graphics should be drawn on map tiles
  • The player's units can be selected and moved in some way
  • Some kind of movement limit per turn
• Place cities
  • Some units can build a city
  • Cities are drawn on map tiles with associated UI

Finally, the prototype items. I listed one or two of these for each milestone, and the idea is to take some time to figure out designs and how to work with new big features before they're fully integrated into the game. This might include stubbing out some basic functions, or building standalone scenes to display or interact with things that might not yet appear in-game.

• Prototype mods
  • Some basic code for loading data from C7 mod files (JSON or whatever), such as unit data or game settings
  • Maybe a tool to parse a mod and print out the resulting game data
  • It's unclear at this point whether a mod is a replacement for a BIQ, a supplement to a BIQ, or an optional module that can be combined with others
• Prototype screen navigation
  • Transition between multiple "scenes" including the game screen with map, which may be additive (advisors, city) or mutually exclusive (main menu) - also mostly covered in Aztec

 

[WildWeazel]

It's also high time we made another Dev Diary, release or no. I think we'd originally thrown around the idea of doing them monthly.

 

[Quintillus]

That largely lines up with the breakdown I did a couple weeks ago. It sounds like in general the "maybes" I had mentioned are "no", e.g. resources aren't part of the world map yet, and moving-via-mouse wouldn't be required as you can already move in some way (via the keyboard).

And yeah, I don't know if the model should be "we finished Aztec so all releases are now styled Babylon", or "we haven't made it to all of Babylon, so intermediate releases are still part of Aztec". I'm kind of favoring the former, though. The analogy that comes to mind is the one used for Windows Longhorn, later renamed Vista. The intermediate preview builds were considered to be and branded as part of Longhorn, not as a continuation of Windows XP, and not using XP's codename of Whistler. The message was, "We aren't at the final version of Longhorn yet, but this is what we have so far."

I agree on Dev Diary regardless.

 

[Quintillus]

I put my project manager hat on today, and have been going through the Issues and adding new ones based on improvements I'm aware of for the future, as well as broken-down features. As part of doing that, I've roughly tripled the number of open issues to 30, and have assigned labels to all issues, including closed ones. That also means there are a few new labels - "low priority", "infrastructure", "AI", etc.

But perhaps as interestingly, I've been playing around with GitHub Milestones. They're not really like GitHub Projects, as an issue can only be assigned to one Milestone (versus multiple projects), and they don't have Kanban boards. But they could be useful in keeping track of progress regardless.

For now, I've created a few milestones, organized around features, at https://github.com/C7-Game/Prototype/milestones. It looks like this right now:

What I like about it is that, so long as we've broken down the sub-components of the features (hence all the new issues), it makes it relatively easy to see how close we are towards each of those features. It also makes it easy to figure out what's left to get to, e.g. where we want to be for the World Map, although it leaves the "In Progress" issues as "Open", unlike the "Projects" feature.

The Projects are still useful for being able to see who's working on what, and thus hopefully not stepping on each others' toes. They also give an overall estimate of project towards the "actual" milestone.

Logically, it might make sense to have "Babylon" be a milestone, and "World Map", "Place Cities", etc. be projects. But the obvious downside is that you'd have to check all of those to see which issues are in progress, at least via a board-style view. An upside would be that right now, there are some cards that could be considered part of multiple milestones, e.g. Tile Visibility and Settler AI. But I think those can often be split into smaller cards, e.g. teach the AI about tile visibilty, and then update the settler AI to use that information.

As the description for World Map indicates, I anticipate some of these will spawn subsequent "enhancement" milestones, if we decide to use the Milestone feature. We might have "[BBN] World Map" and later "[EGY] World Map".

Overall though, I'm finding this to be a useful feature to help organize tasks.

 

[Puppeteer]

So, GitHub seems to have just introduced a Projects Beta, and as a result when I click Projects, there are none! But there is a dropdown to select the old/current projects. Whew. So be aware of that.

 

[Flintlock]

That does make sense about the merging. I had some periphery knowledge that the movement would have to change, but wasn't sure what the best way to go about that would be (going through the UnitInteractions.move method that also serves as the external interface made some sense, but not enough to make me confident).

You wouldn't want to use the external interface in this case since, with the threaded arch, it now operates asynchronously. It just queues up a move message and returns immediately, whereas the internal MapUnit.move method actually does the move and doesn't return until it's complete. I'd like to remove these "interactions" methods completely since they aren't really needed internally or externally. Internally, they just indirectly call methods the engine could call on its own anyway, and even if the engine wanted to trigger something without waiting for the animation, that's just a matter of setting a boolean param to MapUnit.animate. Externally, they're just wrappers around new MsgWhatever(...).send(), which isn't much more verbose. The catch with deleting all the interactions methods is that some of them do things that I don't want to require a message for, like unit autoselection. So now I'm thinking some of the interactions should be kept around as helper methods for the UI.

 

[Ozymandias]

Viz. JSON - I like the idea of using it as some "general" form of tool, as it is "human readable" enough to not frighten off, too many non-coders.

 

[Quintillus]

You wouldn't want to use the external interface in this case since, with the threaded arch, it now operates asynchronously. It just queues up a move message and returns immediately, whereas the internal MapUnit.move method actually does the move and doesn't return until it's complete. I'd like to remove these "interactions" methods completely since they aren't really needed internally or externally. Internally, they just indirectly call methods the engine could call on its own anyway, and even if the engine wanted to trigger something without waiting for the animation, that's just a matter of setting a boolean param to MapUnit.animate. Externally, they're just wrappers around new MsgWhatever(...).send(), which isn't much more verbose. The catch with deleting all the interactions methods is that some of them do things that I don't want to require a message for, like unit autoselection. So now I'm thinking some of the interactions should be kept around as helper methods for the UI.

That all makes sense to me. Those interfaces were very much of-their-moment structures, with a primary goal being communicating with the engine from the front-end Godot area with a minimum of tying us to Godot. The new messaging style, I believe, accomplishes the same lack of being too closely tied to Godot. Although, I'll have to take a closer look to make a fully informed decision as to exactly which cases make sense to keep as which style.

 

[WildWeazel]

That largely lines up with the breakdown I did a couple weeks ago.

Wow, I'd somehow missed that post even though you tagged me. You did it better.
I wouldn't put much effort into including elements for the sake of completeness; I generally agree with where you drew the lines on world map and unit movement, but I'd probably exclude multi-turn moves as well.
My main concern with Fog of War is the data side: do we understand how to represent and update it for each player, and the implications for the UI?

Thanks for tackling the milestones! That's the kind of task breakdown I like to see. You're treating milestones like agile "epics" which is an interesting idea since we already have projects associated with releases.

Viz. JSON - I like the idea of using it as some "general" form of tool, as it is "human readable" enough to not frighten off, too many non-coders.

Being a simple standard, we/they could probably get pretty far with off-the-shelf editors to enter data, like so. And this is kind of a fuzzy idea, but with JSON being closely integrated into C#, we can write our data classes (common structures for unit, building, terrain, etc) in terms of a JSON schema to really simplify and semi-automate building an official mod editor, since we need to deserialize them from a file anyway.

 

[Ozymandias]

Being a simple standard, we/they could probably get pretty far with off-the-shelf editors to enter data, like so. And this is kind of a fuzzy idea, but with JSON being closely integrated into C#, we can write our data classes (common structures for unit, building, terrain, etc) in terms of a JSON schema to really simplify and semi-automate building an official mod editor, since we need to deserialize them from a file anyway.

This is precisely why I believe that as many of our "Starting Points," as possible, should be OO models:

• A complete set of these defines every function in the game in a "non-coder readable" format.
• Provides consistency of design/implementation, for both coders and non-coders.
  
• Lapses of "integrity" (definitions; functional & code interactions and dependencies) are clearly seen.

 

[WildWeazel]

This discussion kind of fizzled out. Let's start putting words together for a dev diary/release notes even if it's not quite there yet. Since I last pulled the game is crashing (+1 bug) so I haven't seen the very latest. Where do we stand now in terms of features in progress? Which of the big picture items are complete or at a good stopping point? The feature milestones range from 0 to 100% complete, but we also have a number of open PRs.

 

[Puppeteer]

I don't have anything of note since Babylon. Just a couple of minor fixes, and a couple of very minor enhancement PRs pending.

 

[Quintillus]

My development on the project has fizzled out lately as well. Got a lot done for a while but then kind of got burnt out on it.

This discussion kind of fizzled out. Let's start putting words together for a dev diary/release notes even if it's not quite there yet. Since I last pulled the game is crashing (+1 bug) so I haven't seen the very latest.

Hmm... what's your latest commit? I just tested development, and I don't see any crashes. Is it crashing for BIQs, SAVs, Quick Start? I do see that something didn't go 100% correctly in merging the JSON changes between Development and my terrain key branch, as there are now horses everywhere on the static-json map, but it still loads and BIQ/SAV files seem to be working.

I don't think my merge fixed it either? It wasn't supposed to at any rate. It could be a particular SAV/BIQ that you are loading as well; there are both known and unknown exceptions to SAV/BIQ support.

Where do we stand now in terms of features in progress? Which of the big picture items are complete or at a good stopping point? The feature milestones range from 0 to 100% complete, but we also have a number of open PRs.

World map I'd put at good enough. IMO, https://github.com/C7-Game/Prototype/issues/105 should be done quickly to enable wrapping, it looks like that should be quick and it's a significant step (where 98% of the work is already done, it's just not enabled). Fix the seams is kind of important but I wouldn't call it a showstopper. The terrain name matching up is a nice to have, and could definitely be moved into the "World Map Secondary Features" or elsewhere.

Of the other ones that are partway done, Settler AI is intended to be an incremental one. As we add more features, the Settler AI will gradually get improvements. Some of those, such as considering river yield in deciding where to settler, could be done now, but others, such as settling on other landmasses, require future features. I would say once https://github.com/C7-Game/Prototype/pull/119 is merged - it teaches the AI not to build cities where other AIs have already built them - it's in a good enough state for Babylon. I'd like to make more improvements to it (most notably teaching the AI it doesn't need to do Infinite City Sprawl every time), but realistically the other aspects of the AI should probably get improvements next (explorer, defender, maybe even some attacking AI).

Unit Pathing is similar. The next step will make it much better, but until we have other improvements (mouse-based pathing for humans; multi-movement point units or roads for the AI), it wouldn't provide any noticeable improvement.

Prototype Mods and Tile Visibility haven't been started. I've given Tile Visibility some thought and might pick it up next, although there are a few smaller/refactoring issues that also look tempting. But I think "it's been far too long since a release and we have a lot of updates" outweighs adding them.

----

I'll take the time to compose some release notes later.

 

[WildWeazel]

Hmm... what's your latest commit? I just tested development, and I don't see any crashes. Is it crashing for BIQs, SAVs, Quick Start? I do see that something didn't go 100% correctly in merging the JSON changes between Development and my terrain key branch, as there are now horses everywhere on the static-json map, but it still loads and BIQ/SAV files seem to be working.

I don't think my merge fixed it either? It wasn't supposed to at any rate. It could be a particular SAV/BIQ that you are loading as well; there are both known and unknown exceptions to SAV/BIQ support.

I pulled again today and now it works - but are there supposed to be horses on every tile?

 

[Quintillus]

I pulled again today and now it works - but are there supposed to be horses on every tile?

Nope, and that ties back into your post in the other thread about the save format. It works as expected (horses only on horse tiles) if you load the Civ3 SAV directly. But the JSON has a fully-fleshed-out resource object and terrain type object on every tile, and on tiles that don't have a resource the "none" resource in C# is written out. When imported from Civ3, C# object equality sees that this is the Resource.NONE object, and it doesn't display a resource; when imported from a SAV it sees each one as a separate object, so it thinks it's an actual resource, and displays icon #0 (horses) on the tile.

Along with object-equality problems, duplicating resource/terrain type data on every tile also results in a much larger save file.

Those both should be solveable by using references to terrain and resources types, which the recently-merged PR makes progress towards; the references will also be more convenient for modding (just put "resource" : "horses" instead of a big object on each horse tile).

 

[Flintlock]

I'd like to include combat in Babylon so anyone who tries it out will have something to do other than watch as the map slowly fills up. Aztec was an important milestone, but it only mattered to us, as I doubt anyone other than us has ever spent more than 2 minutes "playing" it. It would be pointless to put out another gameplay-free release. In fact we should add a couple more AI players for the release so there's more going on.

So... who wants to review a 1500 line PR? Don't all volunteer at once! Unfortunately PRs still aren't getting merged nearly quickly enough. I'm not blaming you guys for this, I realize I myself haven't been doing much to help. IMO we should adopt a "speak now or forever hold your peace" policy whereby if a PR has been open for 2 weeks or so, it gets merged in even if it hasn't been reviewed. If no one cares to review or comment on it, that apathy shouldn't be allowed to stall the project. For example, I've briefly looked at Quintillus' "AI Won't Build Cities" PR and didn't see anything wrong with it. It doesn't feel appropriate to approve it since I haven't done a real review, but the fact that I haven't commented means I have no objections. By the way, what's going on with that "Static variable in Util" PR that was approved a month ago but still hasn't been merged?