[dev] Carthago Creanda Est: big picture tasks for 0.2

[WildWeazel]

Quintillus already has a thread for scoping the new features in Carthage, but I also wanted to call attention to some big non-functional, meta, and refactoring work to be done. And I wanted to use the pun.

So here let's hash out and agree on some high level plans, and identify tasks that can be assigned.

Code things

Refactoring: Basically implementing the layered architecture and components, especially figuring out how to cleanly separate Godot from mechanics from data, and organizing a new code repo around the results. This will be my main focus for this milestone, and I'll try to minimize the disruption to everyone else's work. Also, making better use of Godot as mentioned below.

Tools: In the code itself, we need to start adopting some standard tooling like logging and unit testing. There's been a bit of momentum behind log4Net and xUnit respectively, so let's plan to go with those. Some good starter tasks would be to convert console output to logging and add unit test coverage for the game core and data layers. Did I hear someone say CI? Unit tests are no good if they're not being run constantly, so let's set up some jobs to keep things running smoothly. I'd also like to see increased use of the Godot editor in the UI layer. We're doing almost everything in code, which is understandable given that we're all programmers and not Godot gamedevs, but in the long run using the tools at our disposal will save us time and make for easier customization.

Configuration: We've already hit a few things that should be configurable either at build or runtime, and I've thought of a few more. Paths, logging, debug/release, keybinding, etc. Let's think about how to have both checked-in defaults and local overrides, so there's no need to modify version controlled files for your own environment.

Meta things

Branding: As mentioned before and already begun, let's move away from presenting this as a "Civ3 clone" even though that's approximately what we're making. This mostly involves the verbiage in documentation and our promotional posts, but let's also be mindful of what we call things in the code and try to limit explicit Civ3 references to the Civ3 file conversion packages, which I'd kind of like to isolate in their own repo (as in, we can write converters for different games; here's an example for Civ3!) As we get this ironed out, we might start reaching out a bit beyond the Civ3 crowd and maybe attract some other indie devs and 4X fans.

GitHub organization: It's getting big enough to move away from the ad-hoc Prototype phase and start thinking ahead about how to structure our content. This will largely follow the architecture, but there are some other things to think about like whether to break up into submodules, or use an issue tracking repo for proposals, where to put docs and tests, and so on.

Documentation: Speaking of docs, we need them. User guides, developer onboarding guides, design docs, API docs....

Developer access: Quintillus and I have discussed this a bit and found some useful techniques. As we attract more attention, we need to standardize on how new people get involved, specifically with respect to GitHub permissions.

I'll probably think of more, and I'm sure you will too. It's not that all of this has to be done right now, but it's better to get on each of these sooner rather than later.

 

[Plotinus]

creanda, surely?

More importantly, I'm looking forward to seeing it all come together!

 

[WildWeazel]

I should have checked with our resident scholar first!

 

[Quintillus]

Yeah, I pretty much agree with this list. It will be a "chip away at it" thing rather than an "all of the above at once", but they will all help us be viable long-term, and the timing feels about right.

The only one I'm a bit unsure of is "increased use of the Godot editor in the UI layer". For secondary scenes, e.g., Credits, High Scores, that's probably viable, but we're doing enough custom logic in the main game scene that I'm not sure how feasible that is. Though this is a, "prove me wrong" type of thing, and someone with more Godot experience may be able to.

One small step for branding would be changing our sigs/avatars to not advertise our goal as creating our own Civ3.

 

[WildWeazel]

The only one I'm a bit unsure of is "increased use of the Godot editor in the UI layer". For secondary scenes, e.g., Credits, High Scores, that's probably viable, but we're doing enough custom logic in the main game scene that I'm not sure how feasible that is. Though this is a, "prove me wrong" type of thing, and someone with more Godot experience may be able to.

I don't have much experience, but it's advice I'm carrying over from Unity. Remember that a Godot scene is just a hierarchy of nodes, optionally with scripts attached: if you've used Unity at all it's more comparable to a prefab. A scene doesn't have to be a "game level" or even a whole screen. It could be something as simple as a reusable widget or layout pattern. For example some of the recent issues I created call for a scene of a styled button with label, and a scene of the unit state UI. Building it in the editor both saves tedious code and gives you WYSIWYG rendering, so it's easier to create and maintain the UI.

One small step for branding would be changing our sigs/avatars to not advertise our goal as creating our own Civ3.

I'm sure I have no idea what you mean.

 

[Quintillus]

I don't have much experience, but it's advice I'm carrying over from Unity. Remember that a Godot scene is just a hierarchy of nodes, optionally with scripts attached: if you've used Unity at all it's more comparable to a prefab. A scene doesn't have to be a "game level" or even a whole screen. It could be something as simple as a reusable widget or layout pattern. For example some of the recent issues I created call for a scene of a styled button with label, and a scene of the unit state UI. Building it in the editor both saves tedious code and gives you WYSIWYG rendering, so it's easier to create and maintain the UI.

Oh, interesting. I had been thinking of scenes as equivalent to game levels. It does make sense that it would be possible to write sub-components with the WYSIWYG editor, I've seen that elsewhere. But it hadn't occurred to me to try it in Godot. Maybe because I'm used to having to write GUIs by hand 90% of the time.

This is probably something that we should either document, or perhaps more appropriately link to documentation about, in our Wiki. I'm probably not the only developer on the project who hasn't used modern game dev tools before, not the only one whose experience with GUI builders has been rather chequered (although Godot is towards the upper end of those experiences so far).