Assembling the team

That is great news! Welcome aboard! And welcome to CFC! :band:

I agree that we should probably be adding what we're working on re: kanban boards. I've been tip-toeing around units, kind of wanting to improve them a bit, but afraid I'll step on Flintlock's toes - e.g. I was thinking, "it'd be nice to add support for showing which unit is selected", and less than 24 hours later he'd added an indicator for that purpose.
 
That first one is the original. The others are new and old style respectively at the org level. Seems like the middle one gives us the most options to work with- new features, and can span multiple repos. I vote for that one, after seeing that you can still view it in kanban mode.

I suggest writing up anything that can be worked on soon as a note in Todo, which can be converted to an issue later as needed. Assign yourself and move columns as you start working.

After playing around with it a bit more, I'm somewhat leaning towards the first one. The reason being that it's easier to add issues (you have to select a repo for the project-level ones, which will probably always be Prototype), it's easier to add a description (the Add Note functionality on the repo-level ones includes an area for a description by default), and that it's easier to view the description (click on the title of an item, and the description and other info appears in the sidebar; in the project-level one it opens in a new tab if you click the name of the issue).

But I'm also not really aware of what the new features are in the new one.
 
The one thing I recall about the kanban board we tried a few months ago was that it seemed we had to make an issue to add any comments which was weird to me compared to Jira, Trello, and others I've seen. My memory on a few months ago is fuzzy, though.

I guess my point is to mock a task through to completion before going ham on preemptively creating tasks.
 
There's a fourth option which is the new style board at the repo level. Puppeteer makes a good point, let's try a few and see what sticks.
That said it seems that projects are intended to be disposable. We can use whatever works for the first milestone and then trash it for a different kind. Issues at least are preserved, not sure about notes.
 
"C7 Development" Discord: https://discord.gg/uwxUuWhM89
Nanuk offered a Discord channel, but I found it was very simple to create our own that we can expand later. It's good for quick chats and real-time collaboration. I'm leaning towards making this public at the same time as this forum, given how prevalent it is with MP players and gamers in general. (That's already a public link, but I thought we could start using it internally for now)

Speaking of this forum, are there any sticky threads we need to create or other changes before letting everyone in?
 
Last edited:
Stickies... probably not. Going forward, if we post the dev diaries/latest binaries here (versus the main C&C forum), they should probably be stickied.

Other changes, not that I'm aware of. I know someone mentioned an e-mail or two may have been shared, so I'll defer to others on that, but I'm pretty sure I only shared that info off of the forums.

I'll probably figure out how to set up my username on Discord next week (right now it's using a name from another Discord). Coincidentally I was thinking of chat rooms today, after my hosting provider sent out an e-mail talking about how they'll be launching a new IRC offering soon. Not sure how often I'll be signed on though, the only IM service I've used much in recent years is AIM Phoenix.
 
Ah, got it! I now have the proper name. Will sync the avatars later.

I remembered what else I was thinking of re: prototype the other night. I've been somewhat taking an approach of "the first thing of a type (unit button, popup, etc.) is a prototype. It gets revised and polished on the 2nd, 3rd, etc. of them.

Which I suppose is part of why I'm favoring continuing from this code base. The first popup didn't have great code quality. It's still not great, but it's getting closer with each additional popup. But there is the caveat that I've only really been following (and iterating upon) the code I've added.
 
I'm getting antsy about opening the forum as soon as we have an update, so I quickly skimmed through all of the old threads to see if there's anything we need to purge. There are some IRL comments, but nothing obviously sensitive. The one reference to contact info was already removed.

@Puppeteer and @Quintillus talked a bit about their summer activities and locations
@Ozymandias and @Vuldacon both mentioned ongoing health issues, and Oz some career details

Nothing that would seem too out of place on the Meet the Modders thread but I'll let you each decide if you'd like to edit anything out. I can point to specific posts if you want.
 
I remembered what else I was thinking of re: prototype the other night. I've been somewhat taking an approach of "the first thing of a type (unit button, popup, etc.) is a prototype. It gets revised and polished on the 2nd, 3rd, etc. of them.

Which I suppose is part of why I'm favoring continuing from this code base. The first popup didn't have great code quality. It's still not great, but it's getting closer with each additional popup. But there is the caveat that I've only really been following (and iterating upon) the code I've added.
To the contrary, I started referring to it as a prototype as in "rapid prototyping" where you explicitly make throwaway demos just to validate your technology. But, there's no rule saying you have to throw something away once you call it a prototype. If the prototype does work out, as ours has, I suppose it really comes down to whether it's easier to make it sustainable or start over. There's surely some cleanup and refactoring to done, but it doesn't seem like anything is broken or nightmarish. I'm mostly concerned with whether it's structured in a way that supports building on it with a clean design, or if it's going to lend itself to a Big Ball of Mud. (btw, that's not a judgement, just what I'm looking for)

I would insist on migrating to a more appropriately named repo and rethinking the directory structure, at least. :)
 
Last edited:
Okay, this is the official task board for Aztec: https://github.com/C7-Game/Prototype/projects/1
I consolidated cards from the other boards, so please update as needed.
Everything that you're working on, plan to work on, or realize someone should work on for the first milestone release should be represented here. Cards are fine if it's not well defined.

Also let's try to get into the habit of doing all the work in branches. Make a branch when you start a new feature and merge it back into Development when the task is done. A pull request linked to an issue is great if you'd like to get more eyes on it. The board is semi-automated, so if you use issues and PRs it will add and move things for you.
 
It probably does make sense to start using branches now that we're talking about sharing a version with the larger community. As cool as it was to see new features show up almost every time I did a pull, it could be challenging to find a point at which to make a build to share given how much in-progress-and-definitely-not-ready things we have had.

I realize I was somewhat combining rapid prototyping and more specific prototyping in my thoughts. Perhaps because the rapid prototypes I've done tend to involve pretty rough prototypes of the specifics?

One of the places I worked had a soft rule that you should throw out the rapid prototype and start over. I never fully bought into it, although I was on one very small team where we made a small rapid prototype to test that we could consume another team's brand-new API and get the data we needed quickly, so that if it turned out there was an issue, they could start looking into it sooner rather than later. It turned out it worked as intended, but we still started over with a more robust version. But I was on other teams at the same company where there was a prototype that was continued into the "real" version (I still kind of wish that one JavaScript project had started over with TypeScript, but React + JavaScript wasn't too bad). In the end it came down to a question of whether we'd get enough value from starting over for it to be worth it. I'm leaning towards "no" here, since it does seem to be working out (especially on the "is Godot going to be an appropriate engine for this project?" question), as well as since it's a purely volunteer project where the motivation comes from enthusiasm.
 
I went ahead and created three new project boards for the next three milestones - Babylon, Carthage, and Dutch. Including descriptions of the tasks contained in each one. Initially I just created a Babylon one and was throwing a few not-for-Aztec things in there, but some of them really belong in later milestones.

I don't expect us to go linearly through each one, but it should help keep us pointed in the general high-level direction that we have planned, as well as have a good idea of when we're approaching a milestone. We'll still need to populate them with cards, however, and of course there will be various sub-tasks to the high level goals that won't all be predictable now.

Link: https://github.com/C7-Game/Prototype/projects

The remaining Aztec ones can probably be closed or moved as well.
 
Yeah, in a sprint iteration the backlog just gets moved to the next sprint, so I think that pattern here is fine. Milestones aren't sprints, but the task rollover would seem to work well.

And since we're self-motivated and not profit/goal-motivated we'll end up working on things across several milestones at once.
 
Top Bottom