Home Artists Posts Import Register

Content

Hello illustrious patrons! O ye who sip the tea and sit upon the patio of the sausage factory, considering the makers in their work. We come bearing the straight dope.

Things are, obviously, insane now, with some stupid amount of money raised and a nearly-as-staggering number of backers. 25k+ people is a lot, but consider these are the people who believe now when the evidence is the most thin. So you gotta imagine there’s probably MORE people out there ready to believe once the game is real. Something major is happening here and I think it Bodes.

But we can’t get too celebratory, we got a game to make. THEN we can celebrate. And this is that! Yesterday was our first full day back at work since our holiday. I had obviously been thinking over the break “how are we gonna DO this?” And I thought “We should use sprints.”

Sprints are a term from software development (many of us came from Video Games) which are a solution to a universal problem. The problem is “this is a really complicated project with many moving parts and dependencies, how do we NOT get overwhelmed?!”

In other words, sitting here at the starting line, it looks like this project is a marathon. And marathons are exhausting and punishing. So you take the marathon and you break it up into a series of sprints! Same distance, different process.

That was the problem I wanted to solve. An RPG like this is a BIG problem set. Much larger than a boardgame or a card game and it can be intimidating. The real problem is: you get ‘lost’ in the schedule. There’s always a couple of tasks you need to be working on “now,” future tasks that depend on those tasks, so they’re in your mind. And then previous tasks that now need to be revised based on testing.

For instance, you folks can play the game now! And we’re already getting feedback! And we will CONTINUE getting feedback for the next couple of weeks! Well, guess what? All that feedback means we need to revise the core rules. And that takes time. But we ALSO have to build out the rest of the game! 

These tasks compete with each other for our time, but they all need to be done. And before we can start on any of them, we need to identify each task. And then THAT becomes a task. If you treat this giant bucket of competing tasks, and tasks to determine all the tasks, like they're something obvious and you'll just ":figure it out?" You end up lost and overwhelmed and you often have different parts of your team working at cross-purposes. 

Sprints come from this software development philosophy called AGILE, which no one I know has ever taken very seriously, we just steal the ideas we like and they’re all sort of obvious anyway. So you may see people in the comments saying “THAT’S NOT A SPRINT!” but whatever, call it whatever you want; this is how we’re organizing our development.

So, “sprints!” A sprint is a specific period of time, in this case we picked six weeks where we identify “what should we be working on, in this six weeks?” Everyone in that department is in the sprint meeting and your goal is to make a list of what you think should be in this sprint.

As you talk you write your ideas on the whiteboard and over the course of the meeting you realize some of these tasks are dependent on others, and there ends up being more stuff you WANT to do in any given sprint than you have time to do, so you just move those to the next sprint. Some tasks get kicked down the road several times! That’s fine, because the main thing is you are tracking them. They will get done.

You don’t want sprints to be too short, because then you don’t get enough done to feel like you’re making real progress on the whole game, and you don’t want sprints to be too long because that defeats the purpose of sprints. Then, at the end of the sprint, you can look back and see “did this work? Did we get this all done? If not, why not?” And then each sprint becomes more reasonable, because you’re not just making the game, you’re learning how to sprint, so to speak.

So you don’t get too worried about “are these the right tasks for this sprint?” That’s part of the process of sprinting: learning what you can do in six weeks, and what makes a good sprint.

Giving everyone on the team a clear vision, written down, of “what are we all working on this sprint?” is hugely useful, it’s good for morale. It makes everyone feel like “we can do this!”

You do not try to pack as much into a sprint as you can. That is the opposite of a sprint. That is running a marathon in 10 minutes. You want everyone in the sprint meeting to feel two things.

1: Yeah I can absolutely get all this done without crunching, and I am excited to get started.

2: If we get all this done in six weeks? We will have gotten a lot done!

But how do you know what goes in a sprint? How do you know what goes in the FIRST sprint? Well, if you’re a team of people who have literally never worked on a game before…you don’t! You’re going to spend a lot of that first sprint meeting brainstorming and arguing and you’re gonna get it wrong. You will come out of that meeting THINKING you know what that first sprint’s task list should be, and a couple of weeks later, or even a couple of sprints later, you realize “we fucked up that first sprint.”

But realistically, this is not how game dev works. SOME people in the meeting might be Literally New Developers, but not the whole team! And certainly not this one. I can’t summarize 30 years of game dev experience here, you just learn how games are made over time.

So you start the first sprint with a pretty good idea what kind of thing goes on the list, and then you literally just talk about it and brainstorm. You don’t get too precious. You think “should THIS be on the list?” And someone says “Write it down!” You can always move it or edit it later!

For instance, some tasks we thought should be in Sprint One, we wrote them down, then later once we were getting closer to the end, Lars said “I think we can move these to Sprint Two.” So we did! Even before we finished planning out the first sprint, we had an idea of what would be in the second sprint.

So, enough about what a sprint is…let’s look at the first sprint! :D Holy shit this is how we’re gonna get this game done!

The First Sprint

Hell, let’s just show you the sprint.

Obviously this is not designed for a mobile device. :D We’re all on PCs! This is the actual first Design Team Sprint. There may be sprint meetings for the production team or the art team, it is unlikely I will be posting those, I might not even be in those meetings.

This is everything Matt & James need to worry about for the next six weeks! You will notice; not everything on here is a design task. Not all of it is Matt & James! There’s a Geoff task on there! Well, that should really be two tasks; Geoff schedule the next Patreon Q&A, and then Matt & James (And Dael hopefully!) DO the Q&A.

We put all this stuff on the list, including writing patreon posts! Because otherwise what inevitably happens is; you fill the six weeks with design tasks, and then you fail to get everything done because we all had OTHER tasks to do. So we make sure “everything” we need to do, every meeting, blog post, whatever, is on here.

The goal, remember, is me and James look at the list and say “yeah we can do this!” And we don’t feel stressed, we feel excited. So let’s talk about the list!

This list broadly shows you the order in which we thought of stuff. It’s not exactly that order, but basically. We want to pick a class, probably the Tactician, and brainstorm all the stuff a tactician should be able to from levels 1 to 10 and about what level we think they’ll be able to do it.

This would include all the subclass abilities! But this is just an outline / brainstorming meeting. Now, “outline some classes” is not one meeting, it’s probably one meeting for each class. This isn’t the production schedule, it’s just a list of tasks. Some are more notional than others.

Then one of us will take that list and actually design the first three levels of Tactician. We could do this without an outline of levels 1-10! But the outline gives us some idea, going into the actual design, which powers happen at which level. So you don’t end up designing a level 3 power that should have started as a level 5 power. You already have an idea (which might change!) of which powers you get at what level, so actually designing the first three class levels is…it’s not easier, it’s just closer to final.

Now, the good news is; we’ve already had that meeting, and I think we’ve had it TWICE. Twice before in 2023 we thought “ok, the core rules seem to be working, let’s…” But we decided to hit the breaks on “more design” and polish the rules we had so we could get a packet to our testers, and then a packet to…you! :D

Now the core rules are definitely going in the right direction, so it’s “safe” to build out our first “for real” class. We picked the Tactician just under the principle that the “warrior” class is traditionally the most boring and if we can make THAT fun and exciting, we’re really on to something.

You can see we’re gonna meet and talk about the six stats. Back in January, I valued design that I knew worked and was uncontroversial, but now that we have a working prototype it’s a good time to go back and review some of those decisions and your character’s Stats is the only one I am a little suspicious of. “What are stats for? Is there a better way than the one we chose?” is the thrust of the meeting. I have no idea if the answer is yes or no, this is not an invitation to solicit ideas. Wherever we land, it will be a result of our ideas and experience.

You can see James put a task on here “Upbringing.” This means James is ready to design the prototype for the second thing you do in character creation. Remember the order of operation is: Ancestry, Upbringing, Career/Past, Class. And then at some point Subclass.

Upbringing is just “who raised you?” And James already did some work on that early in 2023. We think it’s mostly just “skills & languages” so it won’t be the most exciting part of your character, but necessary and flavorful.

We hired some freelancers early in December to write some short adventures for the testers to use, and convert a bunch of FM monsters to our new game, so we’re going to review them later this month. That is PROBABLY also going to be the first “what makes a good MCDM RPG adventure?” meeting.

That’s something we’re learning. You can’t just assume that a generic d20 Fantasy adventure works “as in” in this game. That’s something we’re learning from patron feedback and our own experience. That’s something we’ll probably spend SEVERAL sprints trying to dial in. I wish I could tell you more, but we don’t really know enough yet, so…stay tuned! 😀

I also put a Running The Game video script on here, as I already have one in-progress and if I don’t put it on here, it won’t get done! Other things would out-compete it for my time.

Ditto the next Patron Q&A. Ditto our internal playtests. Ditto our regular Town Hall meetings with the Mod Team, and then the Tester Team.

We gotta review the Patreon Playtest feedback BUT! You’ve got like 2+ weeks before you need to fill the survey in, so we don’t gotta worry about that for a while. Phew!

Finally for me, I need to finish the Language & Literacy rules, and finish the prototype for the Elementalist, both of which I see no issues knocking out this sprint. I’ve already done some work on both of them. The Language stuff won’t be hard, but there are a lot of other things in the game that refer to them, so they are a ‘dependency.’ Meaning, other things depend on them, so before we can ‘unlock’ those things, we need to know how this works.

And that’s it! We had other tasks on here, but we thought they made more sense in the next sprint. So we’ve already started filling that bucket of tasks up!

Now, IF we get all these tasks done in six weeks, and we feel like the process is working? Then we will probably have a series of meetings in which we try to take the entire game and put every task into a sprint. So we can see the whole game’s development at once.

No plan ever survives contact with the enemy. Like I said before, tasks slip, tasks have dependencies, so even if you had time, you can’t work on Step Two before you’ve finished Step One. And it may be that after this sprint, we feel like we need one MORE sprint before we know if the system is working well. We’ll find out together!

I don’t really intend on sharing EVERY sprint with you folks. We might! But I want to see how this one goes first. Certainly many of these tasks will turn into patreon posts. But I wanted to show you HOW a sprint works, and by association how a big project like this gets done…and now I have! 😀 More sprint posts wouldn’t necessarily give you more understanding of sprints. But we gotta talk about SOMETHING so I suspect you’ll see more sprint posts in the future. 😀

But, we also want to write about the new classes, the new rules, the way the game is revising and that will be a lot. Either way you’re gonna get a lot of posts!

That's it folks! Lots to do but, as I think you can tell, we're super excited to get stuck in and start building out the rest of the game. And, as you can see in the sprint, we'd like to get you a new patreon post every week. Well, we wrote it down, let's see if it happens! :D

-MC

Comments

Roman Penna

I am very excited to see what comes from the stats meeting and whether they stay the same. Very curious

Zaphod

The sprints are very cool. Allows me to see exactly what I backed which is a lot more transparancy than I expected.

Tamwin

Big fan of sharing sprints! Always cool to get more of a peek behind the curtain, and know what sorts of things to look forward to.