With Sebastian starting to check in his performance improvements, and with 1.24 out and the OIC/TOE work underway with no obvious weed-whackers coming down the lawn, Gophur ran a production scheduling meeting on Tuesday. It felt darn good being reminded that there is life after TOEs. Don’t get your hopes up, I’m not spilling the beans…
(Update: There is some good comentary going on, I’ve made some rather lengthy responses – you might want to skip thru those comments before posting your own comments)
We’ve had quite a few projects tabled (US defn, i.e. scheduled for later discussion) and the way things are working, these have scuttled their way up the todo-list. Gophur’s taking a new approach for the next two dev cycles, trying to get us enthused about several related topics at once and putting them into “packages”.
For the longest time as a player I used to wonder why other players couldn’t see that a large part of CRS’s “not quite what I would have expected” development scheduling was simply down to the fact that a large team of different skills and specialities can’t all work on the same thing.
The actual todo list that Gophur pulled up was a couple of years worth of work :) So we selected various items that looked like obvious “needs” and “wants” for the next couple of releases, and then started culling/picking items based on their similarity and value to implement at the same time.
For instance, TOEs and OIC are going to introduce a lot of gameplay changes, and some of the items that were otherwise moving their way down the todolist suddenly become more significant. Example: Infield resupply.
This was also the first chance we’d had in a while to really talk about some of the many “hey we can do we this now” items that have been wallowing on the list. Some of them have been talked about in isolation before and been tabled for later or even much later, but as the meeting progressed we started seeing how those ideas gel and provide something meaningful to the short-term (next 6-8 months) development. Example: Two separate, so called, spawn at mission leader systems.
Gophur’s system is primarily about extending the MSP system to be mission-leader centric. The system killer/granik/myself advocate is more of a group cohesion system, which allows you to spawn at the mission leader once you hook up with him and as long as you stay within a range. These two ideas complement each other pretty well. When discussed in more detail they begin to sound reminiscent of the old, fixed, grid system that some players were particularly keen on (luminary?).
Why were we discussing these instead of other things those of you from Hull might be thinking of? Ah, that I can’t reveal :)
There was a lot of discussion I can’t go into here, and if you think “great, they’re talking about stuff I don’t care for”, take heart. The more major undertakings we were discussing have requirements that open the door to various spinoffs, and it makes sense in a meeting like that to discuss those spinoffs at that point so they get a foot in the door, and so that the door fitting doesn’t completely overlook the very next feature you’re likely want to embellish on it.
I think, in the past, CRS found itself having to focus like that. Focus on what’s being done, and don’t get distracted by what it’ll enable you to do. Doh. We forgot to allow for that, and now this new system makes it impossible. However, when they did loosen their focus, they found themselves in such a rapid spin cycle that they were continually future proofing everything over too wide a scope.
Take the multicrew system: If they’d called the shot when implementing it and said “its only going to be 2 players”, the multicrew system we’ve had for 5 years would have been a hell of a lot more robust. Instead, the focus of the development work was thinned out with devs independently future proofing their code for what they thought it might eventually be. None of it matches up and, as a result, all of that future-proofing is wasted. The polycrew support that exists in the code base more or less precludes any possibility of the current code ever doing polycrew.
One thing I was particularly pleased to see tabled for the next cycle is brigade selection via the map. About damn time :) Hopefully this won’t prevent me getting Ramp time to make the Brigade OIC a map tab that can be operated via the UI.
Not for 1.25, we have the chat system for now, but with non-HC officers (people who haven’t been explicitly trained in how our crocodillian HC ‘tools’ work) it’s going to be neccessary to prevent OIC from becoming the player’s worst nightmare…
Gophur has the hots for us trying to clean up multicrew – whether its removing the position restrictions or starting on polycrew (we actually have a sideline project which might escallate that). It’s on my “look at after TOEs” list, but there are some hardcoded chunks of code and systems that depend on it that really make that unduly difficult :/
Sorry for the rambling, and probably teasing, nature of this post. I’d love to spill more beans, but don’t even ask. I like what Gophur has rustled up, but I neither want to set expectations or force the teams hand by outing any of it. These discussions were still pretty early and we could easily find better things to add or focus on.
One thing I do have to share…
I moved offices on Monday; we had decorators in on the weekend any my old office is essentially in limbo, so I temporarily moved out of my 8×6 cubicle office (located in the acoustic center of all noises Doc) into the corner office. Woot! It’s pretty massive and I’m finally sitting facing out of a window.
Gophur wandered down to check on me today, and having realized he now has to walk a long way to my office, decided to discuss a couple of things that had come up in the discussions that he thought might warrant further talk in our next meeting. That’s where the spawn@ML discussion came up. But I also brought up something that’s been itching at my craw for a little while.
We’re overdue for some navy loving, and there was a section in Gophur’s list for the navy. Our current naval stuff has some cool elements that simultaneously excite and bore the crap out of most players. Their coolness combined with their tedium has, IMHO, been an obstacle to getting popular player support behind various naval tasks.
My particular beef is with the loading of freighters. It’s cool as shit to spawn a freighter, guide it to a docking position, get people spawning equipment in and loading it onto the boat – all that business with the cranes, etc. I spent countless hours doing that.
And then I stopped. Because it wasn’t fun. Oh, I loved it. But when you take 80 people on a boat ride that takes nearly an hour loading and coordinating people, and nearly an hour sitting waiting, its not fun for them. The coolness factor of your tank being winched over into the cargo hold of a freighter is nullified by 40 minutes of starting at cargo hold wall followed by the black screen of sinkage.
It’s cool as heck strafing all that equipment lined up on the deck of an enemy boat, haha, the dweebs can’t do a thing about it. Doh, wait. That’s not fun for them.
So I threw an idea out there for Gophur to use a world-object that provides freighters with a firebase like window onto a spawn list while serving as an MSP; i.e. they can spawn the lesser of either the source spawn list or their “crate” derived capacity.
Now we have players who’ll hate this because they won’t be able to get points for killing the poor buggers sitting on deck until the freighter deploys and people spawn in – I’m guessing very few people will actually take the whole ride, but the option is still there as a coolness factor for people who love it, and for scenarios/events/etc. But hopefully it would encourage more freighter journeys, more naval play generally, and it will make naval play part of the whole “reduced time to battle” movement. We can maybe make the load of the freighter have effects on things like speed and value. But, to my mind atleast, the freighter doesn’t get a free ride; he still has to dock and load up, so when you do sink one there is still some time-invested in the cost-of-loss equation.
Changes to the MSP system are definitely on the discussion table; we want to make MSPs target specific rather than brigade/mission specific. If your mission is to Antwerp, we want your ML to have the ability to choose any friendly MSP deployed near antwerp. That allows a mission on an army brigade to select a naval vehicle as an MSP, without having to do any kind of cross-branch mission hoohah. It will also allow us to put paratroop MSPs back on the design table (paratroops are cool but all that arsing about on the airfield makes it crap after your 3rd enroute strafed death).
Overall, it’s pretty great to see Gophur, Rafter, Killer, etc, with that happy buzz that I remember seeing them with 3-4 years ago when I was first on the team, genuinely excited about the projects that we’re starting to look at! Can’t wait to get OIC/TOEs out the way and be able to get involved in some of it myself.