|
|
Post by Gmr Leon on Oct 3, 2014 21:54:52 GMT
This is a somewhat interesting read that 22Cans tweeted out awhile ago: Case Study: Why 22Cans used Perforce for Godus.Interesting to see how they've got it organized, if I'm reading right it's approximately: -Short feature branches (incremental experiments that may turn into small updates, I'd imagine). -Mainline code branch (this appears to be the live environment/launch area, what we're/they're playing with, all source art is kept here rather than duplicated across all branches). -Short feature integration branches (those that are to actually be implemented, I think). -Long feature branches (as it says, major feature experiments). ~Long feature integration branch? (similar to short feature integration branch, I would think would exist). -Audio code branch (where main audio code is worked on, actual audio assets distributed throughout branches). Which just says to me that, excluding finishing up the features to be compiled into the main branch, they've things organized to where they could use the opt-in more frequently. All that stalls it from what I can discern through this would be disorganization/divided focus preventing features from being complete within a reasonable timeframe/hesitance to release before running thorough QA. Provided some of the bugs we've encountered in the opt-in builds, I can't imagine it's all in QA concerns, so I can only attribute it to divided focus and potentially some disorganization that results from this. Not sure how well it'd work, since I don't know how they mix opt-in into this, but I'd say go with the below, where possible: Opt-in: -SF/LF integration branches. As vv's suggested over on Steam, highly unstable branch would be: -SF/LF branches. Main branch: -The compiled results of the above experiments. |
|
|
|
Post by earlparvisjam on Oct 3, 2014 22:32:14 GMT
This is the first I've seen and a lot of this directly contradicts things we've been told. I'm going to have to go back and look at all the previous conversations about their methodology so I can quote specifics but section 7 alone brings back large chunks of the discussion about monitoring from back when the BFE was initially announced.
Section Two pretty much describes standard practice. "Short feature branches" are nothing more than the branch a developer makes while working on a feature up to the point where it's completed and merged into main or dropped because it's no longer viable or necessary. If 22Cans is actually treating these branches as individual actualized "release branches", it's no wonder they're moving glacially. Each one has to be tested separately and run through QA and they're likely spending the lion's share of their development in the integration stage rather than in actual implementation. None of which even starts to address the concept of the "long feature branches". Cripes, it must be a nightmare to finally get everything into Main at the end of their sprints. The whole thing sounds like a spider web organization with sections strongly stuck in silos until the end.
This is the sort of organization information I'd been trying to discuss with people months ago. The organization seemed a bit wonky back then and it's even more so now. I think I need to look into Perforce a bit more since I'm less familiar with it than the rest of what they talked about. I've worked with Jenkins, Jira, and Git and have a good idea what they're talking about for that area, less so with Perforce...
|
|
|
|
Post by Gmr Leon on Oct 3, 2014 22:39:39 GMT
I suspect some of this has changed as they've been developing, slowly crystallizing into what's described here. That would explain the apparent contradictions, though I may be mistaken. Some clarification on whether they consider these release branches would help here. My first inclination is to say I don't think so, as I think it's more of a testing area for different ideas than anything close to a release branch. It only comes close to a release branch when it shifts to the integration branch, but even that could slow down production if they get stuck at the experimental level and can't figure out what to move on to integration branches, completion/mild polish, shift to main release or opt-in release branches. I'll probably be double posting this part to Steam, but I think the analytics are as described before. Mobile has more extensive analytics in place than PC, with PC from what we've heard seeming primarily reliant on Steam's analytics data (not explicitly said, mind, but from the brief description provided by Monkeythumbz). |
|
|
|
Post by Danjal on Oct 3, 2014 23:37:50 GMT
Well isn't the whole deal about Q&A that its supposed to be done before a feature goes "live" (i.e. main branch only)
And not necessarily so much applicable to the test/opt-in branch(es).
Though as they've explained it, it seems that the major reason why things aren't pushed out faster is because they exclusively exist compartmentalized on each individual developers PC.
They are working on a tiny part of the game and it needs to be put together and compiled before they can release it at all.
They may have the individual components working to a certain degree during testing, but not a "complete game".
And apparently can not easily keep updating these test builds on-the-fly.
Atleast, thats what I understand on why they can't or won't use opt-in more frequently.
That and not wanting to show unfinished features cause they're afraid of critics.
|
|
|
|
Post by earlparvisjam on Oct 4, 2014 0:59:31 GMT
I suspect some of this has changed as they've been developing, slowly crystallizing into what's described here. That would explain the apparent contradictions, though I may be mistaken. Some clarification on whether they consider these release branches would help here. My first inclination is to say I don't think so, as I think it's more of a testing area for different ideas than anything close to a release branch. It only comes close to a release branch when it shifts to the integration branch, but even that could slow down production if they get stuck at the experimental level and can't figure out what to move on to integration branches, completion/mild polish, shift to main release or opt-in release branches. I'll probably be double posting this part to Steam, but I think the analytics are as described before. Mobile has more extensive analytics in place than PC, with PC from what we've heard seeming primarily reliant on Steam's analytics data (not explicitly said, mind, but from the brief description provided by Monkeythumbz). Because I don't want to force people to experience the Steam forums if they don't want, I'll repost this to here for whatever commentary the peanut gallery wants to make: If that's the case then 1/7 of their design process isn't applicable to the pc version. This alone brings up a ton of questions about how they are handling the pc version since it doesn't fit their model. Oh, and speaking of model, let's discuss Godus and Feature-Driven Development. The Wikipedia[en.wikipedia.org] entry does a pretty good job of laying it out. Let's see a few aspects so we can mesh it with what we're experiencing. FDD Overview: Develop Overall Model Build Feature List Plan By Feature Design By Featuere Build By Feature I'm really curious how the planners can explain Godus' adherence to the first two on that list. Beyond that, who knows since the foundation seems sketchy. At best, what's talked about in the article sounds like it primarily applies to the binary assets (images and audio) rather than actual code. If their focus is mostly toward making it easy for artists, it's no wonder that the rest of the code base is so rough. |
|
