Badass Space Dragon - GM Toolkit Development

games
1

Hi there. Maybe you played the Badass Space Dragon forum game I setup and maybe not. There’s been a lot of interest in continuing it in some form or another so I thought we should start a new thread.

First, let’s get this out of the way, I officially release the galaxy of Charybdis and related game system stuffs into to the public domain. I played the helllll out of Commander Keen and Wolfenstein 3D and this is a tiny way of giving something back… even though it’s kind of derivative :slight_smile:

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.

The Badass Space Dragon game allowed for a lot of world building and storytelling. The writing can be time consuming but it’s very creative and satisfying work for a storyteller and I want to keep that intact while eliminating the burden of copying data from a forum post into a spreadsheet and running scenarios. It will be much easier to GM with a true helper app in place of a hamfisted spreadsheet.

Helper-app or plug-in?

I think a plug-in to Discourse would be nice but it limits the game-play to Discourse and probably locks us into Ruby. On the other hand, a helper-app takes us away from the BBS and means a GM needs to do a bunch of copy/pasting. Trade-offs for both sides. If we can get support from the Discourse team and if people are generally happy with the state of the BBS, I’m leaning the direction of plug-in.

What does it do?

I think it makes the most sense to start with what we have and develop a GM helper for Badass Space Dragon but it would be incredibly cool if, down the road, it could become a more generic template for any personalized storytelling RPG. Werewolf Western!

The app/plug would track a player’s ship and captain stats, allow them to shop for repairs and upgrades and make selections of missions either right in the BBS or by using an easily parsed text format. The GM would have control over the story, items available to each ship and the mission setup. The system would run the scenarios and allow the GM to add comments or “flavor text” before publicly updating the results of a turn.

I felt like a two-day window worked best for turns because it allowed people in different time zones to get moves into the system. We probably wouldn’t want to restrict the frequency but I’d recommend creating something that works really well on a MWF, MTWThF or a Weekly schedule.

Mission support…

I had several types of missions and it would be fun to allow the GM to setup their own parameters. Combat missions, group combat missions, smuggling/commerce missions, stealth/hacking missions. Some missions had a bar to entry, like species or alignment.

Space isn’t just for dudes.

I don’t think my writing passed the Bechdel test on its own but thankfully there were some players who pushed it in the right direction. Whatever we create, I’d like to see it become a not-just-for-boys kind of game. I know it’s largely up to the GM and community to tell the story so maybe the best thing we can do is just leave gender and sexual orientation out of the stats and let the players develop their identities through their own writing.

Flexibility

I think it would work to have many different types of games using the same system I used. A GM could focus on resource/smuggling missions only and have a Catan type game with a set number of turns where money or GRIT are the stated objectives. Or a GM could have a PvP situation where the goal is to be the last ship alive. Or a GM could have a game where people are in different factions playing as teams… Coalition/Resistance… Gang A / Gang B.

Ok… that’s enough for my initial thoughts…

Let’s hear some of your ideas! We can get as pie in the sky as we want at this stage and then work to dial it back to something manageable and realistic.

2 Likes
2

I sing the song of summoning - LaaLaalaLaaaa!

@Slaal, @daneel, @penguinchris, @Donald_Petersen, @codinghorror, @sam, @CaptainPedge, @cha0tic, @bizmail_public

You all expressed some interest in keeping this rolling, here’s a place to talk about it.

1 Like
3

I am fascinated by the idea of a Discourse plugin for this, but am fairly tight on time. Would be more than happy to help with pointers and architectural advice.

I think the approach to building something like this would be to start very small, what are the areas that are screaming out for cheap automation? Stats and rolling dice seem like a great start.

A helper app may be more sane here initially. We already have an API so you could glue it all together automatically so there is no cut-and-paste going on.

3 Likes
4

Where’s the best place to get started learning the API?

5

There are a few examples there and it is being actively maintained, the whole Discoruse app is driven by a JSON API, its just a matter of adding a few more wrappers to get better parity.

6

If there were improved automation, the temptation might be to speed up turns, and I see that as a force to fight against.

The two, or sometimes three-day turnaround gave a lot of time and space to the players to think about their characters, create graphics, find links, converse with each other, strike deals, and generally make the game much more about THINKING about the game, rather than playing the game itself. This slow pace is wonderful and should be preserved at all costs.

It’s like a chess game by correspondence. Not only to make the moves, but to write notes, think about the plays, think about the opponent, research things, etc.

In our age of instantaneous firehose-amplitude communications, a slowdown like BASD is a treasure. You’ve created something different, Patrace, and I hope that whatever ensues, you stick to this original format as much as possible.

The reason not to move it off to another platform is that it needs to be universal. You want it to be all text-based and “in-situ” in the forum it spawns from. The only way to guarantee that is to keep it purely text-based.

To that end, a means of calculating battles and bookkeeping purchases and upgrade stats, should have a standardized printout of what the player chose to do. But then, the player has to paste that text back into the forum, untouched. The GM then simply needs to copy the player’s formatted text and paste that back into the GM console, which parses it into meaningful info.

Yes, yes, I know this is klunky. But I’m suggesting it because as soon as you have players using a system outside of the forum for the ACTUAL posting of their turn, you have just moved the game off the forum. And at that point, you might as well be hosting the game outside of the forum, in some kind of CMS website, like everything else. And the charm is gone.

To keep it in the forum, the players and the GM have to do their communications through the forum. A text-based tool that parses text is one way to do it. A prototype for this could be coded rather readily in PERL.

Later, that concept of parsing text in-the-forum could be adapted to a Disqus plugin, or a wordpress plugin, or something else. But to start with a low-hanging-fruit kind of time commitment, mock up a text-based version in PERL or Python or Ruby or something straight-up, no-frills.

Would love to hear other coders’ thoughts on this, esp if you have a different opinion. What I love about coding is there are always at least 2 ways to do the same thing. So, please, weigh in.

~C.U.

7

I’m not going to be much use as a coder, unless you want this written in Ada, which I guess is unlikely.

I agree with both you and @patrace, the slower pace of this allowed people to develop narratives & characters, which is why it was fun, so that needs preserving whatever, but I don’t see that it’s necessarily mutually exclusive to have a plugin/helper app that does the heavy lifting for the mechanism behind the game, leaving more time for the GM/players to concentrate on the fun stuff here.

I’m assuming we’re talking a generic system, rather than a specific BSD app, here. We’d need to define broad requirements of what we need - player management, mission types, stats, battles. I’d assumed that @patrace had been taking the mechanism from D&D rulebook or something, I didn’t realize he’d worked his own system out - kudos!

1 Like
8

The Underpants are right. Once or twice near the end, when the turnaround was longest, I found myself feeling a tad impatient for results. But that was when I thought I had one obvious solution in front of me, and I gave the missions short shrift… at first. And then, as more responses trickled in, I reconsidered and eventually altered my deployment. This added time to think and react more thoughtfully directly resulted in the ultimate destruction of the Flatulent Deity and the deaths of all hands aboard her, but it also resulted in what I consider a more subjectively satisfying conclusion, and a better game experience.

And yet I think we should streamline the GM’s workload any way we can. I think it behooves a GM to time the rounds according to best practices, but we shouldn’t feel we need to enforce that by making the job harder than it needs to be. My coding training began and ended with BASIC in 8th grade (circa 1983), so I won’t be any technical help there, but it seems to me that whatever could be automated in Discourse (stats management, combat rolls, basically any of the numerical stuff) would free up the GM to write such satisfying and entertaining results and color commentary as patrace was able to do, but without breaking his time commitment bank, as it were. Sure, an ambitious GM could handle a daily turnaround if he or she wanted to if we lighten the number-crunching load enough (and if he or she has enough daily free time and creativity to handle the non-numerical part of the job without neglecting the spouse and kids and day job), but with the global nature of the BBS audience, the 2-day turnaround really does give everyone a fair chance to play without having to stay up all night or miss a turn because of one unusually busy day.

9

Sitting at home in his pants watching a DVD cha0tic felt a bit queasy. As though his whole body had started to vibrate. Maybe he was having a stroke. He felt like he needed to throw up. He stood up and headed for the kitchen and the sink. Before he got there his whole world exploded in a ball of brilliant white light and the next thing he felt was a short falling sensation, before coming to lying on a what felt like a pine needle covered forest floor. He looked around and noticed he was lying in the middle of what appeared to be a circle of salt with candles set at the quarter points. A bloke with a beard was singing some awful tune and looking down at him.

Bloody hell @patrace a bit of warning would be nice. Have you got any clothes I can put on? And you better have some cigarettes and beer handy.

1 Like
10

One of the things I liked about BASD was the fact I was playing with people from all over the world. I think a two day turn around is plenty quick enough because of time zone differences. I was lucky that I’d got a slack period at work, so joining the Pacific Standard Tribe for a while wasn’t too much of a problem. It’s not something I could do regularly though.

I have absolutely no idea about coding. I’ve had problems just formatting for the BBS, even though I downloaded ‘Mou’. I could type stuff in that, but couldn’t make Cut and Paste work.

I think we all very quickly ‘got’ that we should post our orders in a format that was easy for @patrace to see what we wanted to do. Whilst at the same time including our flavour or story text. Maybe the first step would be to have a standard template for posting turn orders.

1 Like
11

The parts that make the most sense for automation are the purchases/upgrades between turns. Having a tool that allowed people to understand what they were purchasing, and verifying their math would have taken a lot of guess work out of what I was doing (I often had to decide what a player meant as opposed to what they said because math didn’t work out or requests didn’t line up with the state of their ship). I don’t think it would be hard to incorporate a database system to deal with that.

The mission results all started with a basic concept when the mission was written, but it was sometimes adjusted based on how people ended up. I think that flexibility is hard to program in, but allowing a GM to adjust when resolving missions based on intended outcomes is important and why automating that part is trickier. Often we would run a few test cases, and then adjust the formulas based on what would make sense before running ships through the missions.

There are definitely some tools that could help with the game mechanics, but I think the key to what made this successful was the storylines created both by Patrick and the players. And any tools developed need to be careful to not inhibit the creation of those stories.

1 Like
12

This article on io9 is good read about RPGs and is relevant to the BASD experience.

1 Like
13

1 Like
14

I agree that the critical piece that needs improvement was not calculating the turn, but is the interface between the player, the gm and the “system” of the game.

  1. An interface to facilitate the GM to set up each turn’s choices and the values for those choices.
  2. An interface to allow the players to make/update their next set of choices, which is related to:
  3. An interface explaining the current status of their personal resources.
  4. A process to register the choices en masse after a cutoff time, at which the turn is calculated and then
  5. Issue a report to the GM, so the GM can use it to write the synopsis of that last turn and introduce the next turn
  6. The GM can control the timing of the update to all players’ statuses (item 3) after the last two things.
  7. Might as well set up one more interface controlling how the turn is calculated, with each component, rather than making the GM do it all by hand elsewhere.

That would be a complete BSD gaming system.

Easier said than done. It has a LOT of moving parts. A sql database is trivial to set up - the hard part is writing all these interfaces and a process to make them all play together. not trivial

15

Sounds like we’d need two (or more) heads running this thing, as the fictional part of this endeavor will require as much skull-sweat as the nuts & bolts of the database management.

@daneel, @awjt, @penguinchris, @Mister44, @funruly, @patrace, @sam, @CaptainPedge, @bizmail_public, @JonasEggeater, (I’d also mention Slaal and cha0tic and danegeld, but I’m limited to ten mentions. Tsk tsk.)

I hereby toss my hat in the ring for the fictional side of this. Before the holidays, Daneel and PenguinChris and I were batting around some ideas, and I think I’ve got something based upon those conversations that would fit pretty neatly within the mechanical structure of the BSD framework, while being a somewhat different genre, and leaves room for the creative riffing that made BSD the awesomest thing to happen in my gaming life in memory.

I’m typing up a quick summary of the background and scenario. Later this evening I’ll PM you guys with what I’ve got, and if enough of you like it, we can prepare to play it.

In the meantime, those of you with skill at data-wrangling (which excludes me, since the best I could do would be to enter all the data by hand and calculate it with, like, an actual calculator, which would be time-prohibitive if we want to achieve something on the order of two or three rounds per week) can decide who wants to build the interface and the data-cruncher. Or whatever it is you’d call it.

At any rate, let me get to typing. I offer no guarantees you’ll like what I’ve got here (I hope you do), but gimme your honest opinion. if you like it and wanna use it, great. If you don’t like it and wanna use someone else’s fiction, great: that means I’ll get to play! Win/win.

3 Likes
16

Where you lead, I will follow.

1 Like
17

2 Likes
18

I volunteer - but my coding skills may be of the wrong type. I have no experience with web development beyond using python to create static html. I am fluent with C++, C, SQL, Fortran and like, but I don’t see much call for that kind of work on this project. The analysis side is small; this is mostly a web-app design issue, so I defer to the more knowledgeable.

But I do want to help move this along. I can certainly be beta tester.

I can volunteer one other possibility. Since this is supposed to be a BBS, I am happy to python-up a text-and-command line tool to support GM.

2 Likes
19

I don’t see a clear spec sheet, but I do want to make sure that whatever we end up with has some sort of support for “escrow.” I kind of made that up on the fly last game, but I felt it brought a richer set possibilities to the game.

2 Likes
20

yes, player-to-player trades, and/or bounties, was a great development.

I was too shy and didn’t play, but as a lurker, that was a great turn.