Which features do we want for "Carthage"?

[Quintillus]

In the original proposal, "Carthage" had the following items:

• Launch screen
• Save and load
• Select mods
• Prototype combat
• Main screen UI
• Credits
• UI file conversion
• Prototype unit media

I'm wondering, are these the things that we want to add next now that we're close to that point? We've been a little loose with the Babylon items, which suggests we thought some changes made sense; notably Prototype Combat is already in progress, but Tile Visibility is not.

I've put the features from most of the milestones into GitHub projects at https://github.com/C7-Game/Prototype/projects, for reference.

My thoughts on these:

• Keep these:
  • Save and load. While not important now, it's only going to get more complex to implement if we add more and more things. Makes sense to have it early.
  • Prototype combat, if not wrapped up for Babylon.
• Questions/skeptical about these:
  • Main screen UI. We already have a main menu from Aztec. What else do we need to add?
    • Eventually we will want our own background, and probably a different UI layout. Maybe it's a good time to look at involving an artist or two and starting to ship some content, but I don't think we should be making major programmatic changes here yet. We also might need to nail down branding first, since IIRC C7 isn't yet chosen as the final name.
    • If we just want something that isn't the Civ background, I saved a pre-adding-the-Civ-title version of my custom background back in 2008 that can serve as a proof-of-concept.
  • Select mods. We can already load BIQ files, and I added a Babylon card for loading C7 JSON. Beyond being able to load C7 JSON mods, I think more definition around "what is a mod in C7?" is needed before this can be added.
    • I think part of the goal here was allowing multiple mods to be enabled, e.g. maybe I want to play Lord of the Mods but I also want to have Rick's Water Pack enabled. I'm torn between "it's too early for that" and "the goals need to be more precisely stated." We could spend a lot of time around this that could be spend getting to a playable game sooner.
• Remove these:
  • Launch screen. Aside from allowing the user to point to their Civ3 assets if they can't be auto-detected, I'm not sure why we need one.
  • Credits. It's probably a good idea to keep notes of contributions, and we can modify the prototype credits scene from pre-Aztec if we want. But I don't see a reason to make this fancy at such an early stage.
  • UI file conversion. We've already done a lot of this. And we can do the rest as needed.
• Add (some of) these:
  • Unit combat from "Dutch". What does this entail? I'd suggest a goal of Ancient Age land mechanics. Basic combat, bombardment, maybe defensive bombardment too, retreat probability. That's probably enough for one milestone, although Experience Levels (from "Maya") could be a good stretch goal.
  • City production, and City yield and population, from "Egypt". Allow the player to choose what their city produces via the end-of-turn popup (leave the queue for later, just the first thing is fine for now), and have citizens cause real tile yields, though probably assigned by the AI for now. This adds interactivity, without being as big of a chunk as what "Egypt" proposed.

What didn't quite make my cut, but might make the following one?

- Worker actions, from "France". I'd like this to be relatively early, as it adds a good amount of interactivity and strategy, but real city yield, by actual citizens, has to come first or you're just adding irrigation and mining graphics. This also bundles with road movement implementation, and the AI/pathing for that.
- City screen, from "Egypt". That can be added after the mechanics.
- Resources, from "Japan", specifically strategic ones. This depends on Worker Actions, but should be a relatively early strategic priority.
- Research, from "Hittite". A key component of the game, but we need a few more basic mechanics first.
- Buildings, closest match being "Wonders" from "Hittite". Same basic deal as research.

These are the ones I'm most on the fence about though.

As for the other Dutch candidates to move up, which aren't already mentioned:

- City capture. I'm open to adding this one at any point after we have combat, it should be pretty easy.
- Unit orders is already prototyped, and I think these should be added individually as needed. Add bombard when we add catapults, but don't add precision strike until we have stealth units.
- Unit media - this is basically done, aside perhaps form newfangled formats, but IMO we should have a playable game before we start going in that direction.
- Unit file conversion - same as unit media? Or if it means to a newfangled format, ibid.
- Prototype cities. Already done in Aztec, with improvements in Babylon.

 

[Flintlock]

In general I think we should prioritize making the game playable so I agree with ignoring the launch screen and credits for now. The main screen UI, which I'm guessing refers to the in-game UI, should be built as necessary. For example, the ability to select tiles for unit commands like go-to or bombard would be nice but it's not really necessary. Same goes for the minimap. On the other hand, I think a right click menu would help a lot right now, both to select a unit from a stack and shift + right click to select city production. I'm planning to start working on that next.

Enabling workers to build roads would be nice, that's an easy self-contained feature that would immediately improve the gameplay. Other worker actions don't matter right now like you mentioned. Also having roads lets us start thinking about implementing a trade network. Tile visibility would be relatively easy (I hope... famous last words) and self-contained but I don't see it adding much to the gameplay so I'm okay with putting that off for later.

We should start thinking about mods since mod support needs to be built into the architecture. Like multiplayer, it would be very difficult to patch in after the fact. For example, if we add roads & railroads we could start thinking about multiple road kinds and limited railroad movement, not as built in features but as examples of things our mod setup should allow modders to do. In C3X I was able to patch limited railroad movement into the game by overriding the function that determines the cost of moving a unit between two tiles and overriding the definition of one full move in terms of movement points (i.e. the road-movement-rate field in the BIQ data). C7 should allow for modders to do that or something equivalent. I don't know if it's practical to do that using events somehow, but that's the kind of thing we should start experimenting with.

 

[WildWeazel]

Let me just say again that all roadmap items are open for debate.

At an even higher level, here are a few things I'd like to focus on during the next iteration:

• A more structured approach to game data, how it will be represented in our own formats and stored in memory. So far it seems like we've mostly been mirroring our own understanding of how things work in Civ3, which will eventually just paint us into the same corners. This especially goes for data that we know we want to make more general, like terrain types and tile improvements. Mod files in general will need some level of specification.
  
• Likewise, some real effort (probably by me at least at first) to massage the code into the desired architecture and start laying out the component-event framework. This will be important to keep things organized as we start getting into actual game mechanics like combat.
  
• Cleaning up the repo and project branding with respect to "Civ3" references and data. I've been getting more paranoid about 2K. I don't think there's a case to be made, but that doesn't stop corps from throwing their weight around. If we keep the main project very clean of anything Civ-specific, including file formats, brand it as a new 4X platform inspired by classic Civ (which is not wrong, if we're taking the "superset of Civ3" design approach), and just happen to also create a separate Civ3 conversion library (you're free to do the same for other games too!) with no content derived from Firaxis, it would look pretty innocent.
  
• Increasing our visibility a bit among the Civ and indie gaming crowds, now that we have something interesting to show off. Especially to attract more devs, and have a clear path to get them involved. I'm thinking stick to fairly specific communities for now like Civ3 General Discussion or r/4xdev. This kind of contradicts the point above, so we should work on messaging before reaching out.

Some clarification on the original items:

• Launch screen: I was actually referring to the main menu which we already have. A custom background might be nice, and some project/version info at the bottom.
  
• Save and load: Using our own save format, which will take some file specification. If we're using JSON, that's naturally extensible.
• Select mods: Again, from our own format. Like you said this asks "what is a mod?" If mods can be used in combination, does that force a distinction between a mod (package to be enabled) and a scenario (game config selected to play)?
  
• Main screen UI: as in the world map screen, even if not fully functional. Minimap, unit info, menus, the various action buttons.
• Credits: I mostly listed this for the sake of hitting all the UI, but it'd be nice to have a visible log of contributors, and also a place to display any open source licenses. This could just be a text file dumped onto that scene.
• UI file conversion: Assuming the one-time-conversion approach in the Civ3 media layer. This goes along with mods, since you'd have <whatever format> images included in the mod structure. But we're not really doing on-disk conversions yet anyway.
  
• Prototype unit media: Being able to convert/import/whatever unit ini, animations, and sounds and play them correctly (with civ colors, shadows, and the HP/status UI) in a demo scene, even if it's not all hooked up in-game. Think something like FLIICster.
  
• Prototype combat: Simulate basic unit battles, maybe with animations or maybe not, using unit stats and raising at least some of the events, again with a demo scene that can be isolated for testing.

 

[Quintillus]

I like the idea of roads as the first worker action.

Game data... I somewhat agree that we've somewhat been imitating the way things are done in Civ? Probably because it's the common reference point for all of us, and we also aren't at the point where we have any features that Civ doesn't have. Although we have taken steps to make sure we won't paint ourselves into the 512-city-limit (or other arbitrary limit) corners. I'm guessing it's extensibility corners that are the main concern?

If so, I have mixed feelings on it. It probably is time to start some prototype mod work, and in areas where we want greater flexibility, we should think about that as we go. But I also want to create a game rather than a game framework. More extensibility will in general mean more development time, which is the limiting factor, so I would prefer to be judicious and focus the extensibility on where there's demonstrated demand for it. Flintlock gave one example with transportation; a couple others are flexibility with bonuses for buildings (which should be straightforward), and perhaps additional terrain overlays (a little more complex). Event scripting is probably the most difficult that comes to mind. Which does tie into the event-driven architecture... admittedly an area where I think having a few examples of it in the code base would help tremendously towards having it proliferate, and one where I don't really think I understand the vision well enough (at a low technical level in particular) to implement it first. But at the same time, as we get farther along, it will be tougher to add that architecture in.

On de-Civ3-ifying, I definitely agree on the branding, and have just done some work on that (will post in Babylon Progress shortly). What's interesting to me in @WildWeazel 's post is free of the file formats. We already have most of that in a "QueryCiv3" project (although the ImportCiv3 file is in C7GameData; we could make a generic ImportSomeOtherGameFile interface). Are you thinking of moving it into a whole different repo, and have it loaded as something like a DLL? I suppose we could even have it as a completely separate program that spews out a C7 save file; that's how my editor's decompression works, it's a completely separate program, not linked to the editor at all but invoked at the command line. Realistically though, unless someone comes along who's passionate about it, I don't see it as likely that any other conversion libraries are going to be written soon, since there's just so many other things to do, and I think it's important to include the conversion library since one of the main pitches to the community was, "you'll be able to play your old scenarios in C7."

But yes, it's a good idea to have C7 be able to stand on its own two legs (once we get a lot more art, at least), and to generally decrease the Civ3 branding and especially the "clone" part of that, favoring "compatibility" for the importing features. I don't think it's really necessary (see Open XCom, which appears to be complete and brands itself as a clone), but it's sensible.

 

[Quintillus]

Collating the last few posts, this is what I've wound up with. 8 main items, in alphabetical order.

 - AI Improvements
   - AI won't usually use ICS strategy
   - More intelligent city production, using game circumstances.
   - AI will put surplus units to good use rather than have them roam around randomly.  Defensive, if there's enough of them offensive.
   - Barbarians will try to pillage your roads or attack your units or cities.
 - Architectural improvements
   - Component-event framework (prototyped by WildWeazel)
   - Figure out what a mod will look like, ship one, even if it's super small.  Third type of road is a proposal of a sample mod.
   - Start shipping a default set of resources with the game.  Might not reach 100% of what we need yet, but we should start having our own.
   - Proposal/prototype of how we want to store some types of data that are hard-coded in Firaxis games.  Do we want to keep the same unit file structure (animations, etc.)?  Should we build all aspects of terrain information into the C7 save file?  Road/rail movement.
   - Implement a proper logging framework
 - City production Part I.
   - Player chooses what to build next.
   - Production rate based on actual tile yield.
 - Combat Part II.  To be defined, some possibilities:
   - Experience levels/promotions.
   - Healing when resting.
   - Fortify bonuses
   - Defensive bombardment.
   - Retreat probability.
 - Right-click menu.
   - Select unit from stack
   - Set city production
 - Road building.
   - Road movement bonus.
 - Save and load (in C7 JSON format)
   - This will likely not mean you can load Carthage saves forever.
   - Improve serialization.
 - Tile visibility.
   - Reveal tiles for player
   - Explorer AI improvements
   - AI will prefer to settle areas that it has explored.

That is a lot, so I wouldn't be surprised if we wind up bumping one or two (or parts of one or two), or adding an intermediate release. Still, this gives enough to start creating issues on GitHub corresponding to these tasks, which will give us visibility into progress, and mean we have "good first issue" issues in the event we get new contributors.

I'm also going to put "Tile visibility" solidly into Carthage; we're starting to get questions about updates from the community, and realistically adding more would push Babylon back even farther.

 

[Quintillus]

I've fleshed out five of the Carthage milestones at https://github.com/C7-Game/Prototype/milestones, with issues that should cover at least the basics of what is needed (I'm sure we'll discover more details as we go).

Those include AI Improvements, Architectural Improvements, City Production Part I, Save and Load, and Tile Visibility. Combat Part II, Right-Click Menu, and Road Building are not yet put into milestones. What I've already done amounts to 33 issues, whereas Babylon has 31. That appears to suggest we have too much stuff in Carthage, which we might, but we also were only just starting to use the Project Board for Babylon, so the numbers aren't wholly comparable.

The Carthage project board is also ready to go: https://github.com/C7-Game/Prototype/projects/3 . I moved the things that were already done to Babylon, since even if they had initially been planned for Carthage, they'll ship with Babylon. Thus we're back to 0% progress for Carthage.

 

[Quintillus]

I finished writing up issues for the rest of the milestones. We now have 61 issues for Carthage, including 5 that are already done, and 7 that are in progress. This also includes assigning the non-low-priority issues that @WildWeazel added to Carthage.

That compares to 33 for Babylon and 24 for Aztec, although it's worth noting that we weren't fully using the projects board on Babylon (probably 80-85%), and were even less consistent with it for Aztec. Still, Carthage has a lot more stuff in it than either of the previous two milestones.

You can view the progress towards the milestones at https://github.com/C7-Game/Prototype/milestones . Any that start with [CRT] are intended for Carthage.

I suggest we do not wait until all of them are done for our next release. Given that pcen has been making quick progress of late, including Go To support that is in progress, and Flintlock has already made very good progress towards the Right-Click Menu milestone, I'm thinking some time around Easter (mid-April this year) would be appropriate for an interim release if things continue at the pace they've been moving.

 

[Puppeteer]

some time around Easter (mid-April this year)

You write that as if it's not well within two weeks of now. But that is a commentary of time perception, not of release cadence.