I’m really good with Excel. Like, really good. (I’m humble, too.) I wouldn’t mind taking the spreadsheet thing up, but I need a lot more about what kind of things it needs to cover.
EDIT: @penguinchris, since you’re interested in helping with the spreadsheets, and @patrace, since you had experience with that the last game, could we work together on this?
I didn’t reply to the PM thread because I didn’t want to bother the first person who complained nor the others who were silently feeling the same…but…
…but I’m totally proud of happy mutant gang for pushing the boundaries of Discourse.
I’m sure you saw it upthread, but in case you didn’t, check out the Google Docs spreadsheet patrace posted earlier: https://docs.google.com/spreadsheet/ccc?key=0Ash2BsWLZbvSdFJReHpCTzhuWThXb182WWtKRGFramc&usp=sharing
It’s almost (but not quite) Greek to me, but it looks like it should be pretty readily adaptable to getting a new game off the ground relatively quickly, rather than waiting for one of you clever coders to build an actual Discourse-specific engine that allows the players to directly input their stats and choices, which would be the eventual goal.
Keep in mind, @JonasEggeater and @penguinchris, running the spreadsheet will necessarily disqualify you from playing as a character, so if one or both of you commit to the gig, please do feel welcome in joining me on the Story side as well! If you guys are ready to start hammering on this, let’s start hitting it thru email or PM so as not to give anything away to the players.
As we finalize the list of Stats, we’ll have to determine how they mathematically affect battle outcomes and so on, how much weight to give each factor, etc. Pat’s spreadsheet will certainly give us a huge head start (if you guys can make sense of it, which I’m confident you can), and we’ll only need to add or alter a couple of Stats, I’d think. Heavy consultation with that post Daneel linked to earlier will also get us going.
As a rough beginning, how about these as Stats:
HP
FirePower
ARmor (works like SHields did last time)
SPeed (on gasoline - heavy AR should work against this at a predictable ratio)
TorQue (on SHITGO - unaffected by AR or SP, and used instead of gas on certain missions)
ManeuVerability (like AR and SP, heavily influenced by Vehicle Class at the beginning)
ENgineering (better build quality means better survival and fewer repairs required)
LucK
In discussion with @funruly, he mentioned it might be cool to have a fourth class in addition to the fast and lightly-armored Scouts, the slow and tank-like Mules, and the medium-armored and medium-speeded but heavily-armed Escorts. He suggested a “wizard” type class, which struck me as an excellent idea. So we’ll have the Mechanics. They are slow, weak, and lightly armed, and will often have to negotiate for protection with pals in other classes. But the Mechanics have two things going for them: they can repair themselves cheap (free labor, reduced-price parts) and also sell their repair services to other classes for whatever price the market will bear; and also the Mechanics are the only Drivers who can read. In-game, this means that certain pitfalls can only be avoided, and certain stashes of loot can only be found, by the literate Mechanics, while everyone else will blunder right into those pitfalls (or miss the stashes completely) due to not comprehending the signs.
There will be incentive to protect the Mechanics and help them stay alive, at least for cooperative Mechanics who don’t use their advantages to the detriment of others. But there will also be other motivations. Cooperation in pulling the Ark to the launch pad won’t be the only logical goal… only the first and most obvious one at the outset.
As defaults, Scouts are high in SP and MV, but low on FP and AR and TQ. Mules are very high in TQ, high in AR, medium in FP, low in SP and MV. Escorts are high in FP and MV, medium in SP and AR, low in TQ. And Mechanics should be… well, low in SP, medium in MV, medium in TQ, low in AR, low in FP, but possess the Repair and Literacy skills (which, for the sake of simplicity, should probably just be binary constants, an either/or on/off kinda thing you either have or you don’t, with Repairs occurring to a negotiated price per hit point restored).
Does that sound good? And if so, does it give us a starting point to build a spreadsheet?
I just want to say; don’t talk about the mechanics or ideas of the game too much in this forum - I want to be left in the dark! (plus I’m hoping that we don’t end up with too many of the most interesting players from last time ending up behind the scenes running spreadsheets!)
One thing I was thinking about - if the number crunching can’t be automated, perhaps the task could be farmed out, such everyone does their own rolls and posts results, or everyone has a partner (static through the game or randomly assigned per round) and each partner does the rolls and posts the results.
I know you won’t believe this, but man, I just got an incredible roll. Took the bad guy without a scratch, rescued the girl, escaped with the loot. 3 times in a row that’s happened!
This is actually a brilliant idea. Set up the spreadsheet so that it can be farmed out to the individuals. All they have to do is provide inputs at a certain spot, put in their values, “roll the dice” and send back the calculations. Honor system should prevail, in that if people don’t like their roll, the honor system is that they shouldn’t re-roll until a favorable result pops up… OR… build re-rolls into the game, and people can “buy” one for a price.
This means not just 1 big spreadsheet for the whole game like the last time. It means, probably, lots of smaller spreadsheets to keep them from getting too confusing. And it means the spreadsheet designers need to cast a keen eye towards making the inputs and outputs easy to understand.
Or your partner idea - nobody rolls for themselves… or with the partners, the partner can check in with the user, and the user can decide if they want to use their free roll or not…
See my post below… or above… I don’t know which way is up…, addressing this…
I thought the big time problem wasn’t the dice rolling, but wrangling all the written text in preparation for the dice rolling. [*]
Under that scenario, we want to “farm out” the data entry and regularization, not the actual game mechanics.
To my mind, if we’re going to be sharing spread sheets, a single “input” spread sheet in the cloud (eg a google doc) that is shared by all players and has a clear edit history (to help tack down errors and discourage hanky panky) would be both simpler and more beneficial to the GM.
[*] I got the sense that rolling the dice and watching the battles develop was part of the fun for the GM.
I think that @Donald_Petersen, @penguinchris, and I are taking care of the GMing for the most part. I’m working on the spreadsheet now.
@Mister44, I really like the idea, but I think that players being able to view the spreadsheet could ruin some of the fun for you guys. Also, a couple more things:
EDIT: Spelling error.
I think the eventual goal (long-term, not in time for this particular game) will be to have a Discourse plug-in type thing wherein a GM can select a certain number of attributes with stat ranges and combat multipliers and all those variables at the beginning of a game, and then when the game gets going, each round the players have an interface wherein they input their data (purchases, upgrade choices, mission numbers, etc), and at each round’s deadline the GM idiot-checks the entries for shenanigans or mistakes, then triggers the randomized rolls, interprets the results, then writes them up.
But until that point, I think we still need to keep the data processing centralized to maintain everyone’s confidence in the integrity of the game. As long as everyone’s entries include a standardized dataset in addition to their rhetorical flourishes for each round, the data entry should be manageable enough for @penguinchris and @JonasEggeater to stay on top of, assuming their spreadsheet is robust and well-thought-out (which I’ll take as a given) and as long as we maintain a reasonable number of players. I’m thinking of capping that number at 30, but if anyone thinks that number is too high (or low, for that matter, though that strikes me as unlikely, given the personalized writeups we’ll need to do every round), let me know.
It’s true that our goal is similar to BSD’s unspoken Mission Statement: a hell of a good time along the way is much more important than “winning” or “losing,” but the fun does still come in the structure of a game, so reliable refereeing (with a healthy helping of liberal interpretation to encourage creativity) should be in place.
Hello Everyone 
very long time no see.
I thought the big time problem wasn’t the dice rolling, but wrangling all the written text in preparation for the dice rolling. [*]
I was thinking that a very easy way to keep the data “platform agnostic” and “forum shareable”, would be an aplication that writes and parses PNG files, pretty much like QR codes (or just using straight QR codes):
http://www.squidi.net/three/entry.php?id=12
If we use png lossless compression, it would be very easy to move around, write and parse these files. (a single strip of 64 pixels of height and 128 pixels of width could store a metric shit ton of players).
I’m thinking about using rgb values, but that may be overkill, a very simple monocromatic QR code can easily store a 3000 character JSON, that contains all the data needed for each player http://qrcode.meetheed.com/question3.php
This idea was originally toyed with as an experimental way of minimizing js/css payloads. (Which is of course kind of neat, but in practice you should get better benefits from just minifying and gziping content.)
It does work as a way of storing arbitrary data on a forum, but would probably be too difficult for an average user to generate a reasonably compressed image. http://iamcal.github.io/PNGStore/
If someone provides the code to generate a standard json file structure for a game (probably hosted on a jsfiddle type of site for collaboration and ease of use to run), a completely client side solution wouldn’t be unreasonable. For example, just Base64 encoding the serialized json and then creating an image element with the data as the source. You could them prompt the user to drag and drop this file, or you’d have to bounce this off a server to get an automatic file download. Base64 encoding of course inflates the file size, but we’re not storing much data anyway so it doesn’t matter.
In any case, by the time you get to level of complexity, it may be worthwhile just setting up a proper web app which can track the characters, stats, purchases, missions, and trades etc.
True, but a web app would make the game feel like another play by browser game, with complete disregard of the pacing, roots, and feel of the game.
I agree that it would be very easy to just build a web app on top of Node.js (for example) to centralize all the game logic validation, but do we want that? (I feel it would change the feel of the game too much)
Tho, I must say that, yes, the very first step would need to be the creation of a spec for a JSON data structure for players.
I agree, it would pretty much ruin the excessively long forum thread fun.
The main problem I’m having is that I’m constantly squinting at a google doc spreadsheet. A read-only app would be kind of fun to make that presents the current rounds stats in a more human friendly view. Like radar charts for character stats, hp bars and the like. I might tinker around this weekend if I have time. Scraping the shared google docs page shouldn’t be hard.
@patrace count me in on that singalong summoning!
Hey if you disrupt the lengthy threads then my method of using the mouse wheel to growth-hack my fitbit score will be totes obsolete.
YES ^ THIS. Let’s just get a JSON spec together of the elements needed. Writing a parser for Google doc ↔ JSON is tedious but not too hard, and just abandon it later if we want to spend time writing a web page, or Disqus plugin.
Here’s my idea. A player has to have an account on the bbs, and enroll in the game. Those players who are enrolled in the game will see a fifth item next to the 4 choices in the upper right. Give it a small icon of the outline of a d20 or something.
And keep it simple. When you click that item, only 1 thing comes up. A form with a title of the game, a subtitle indicating which round, and the form elements the player has to fill in and click OK.
This form can use the JSON format we already created to either post to another webpage somewhere, or dump all of its shit into a google doc. Or whatever we want. But that’s an in-BBS UI in its simple simon simplest functional implementation.
Okay, after fiddling around a bit, I’ve created a script that parses the public google spreadsheet, and renders a character’s information like this.
It’s just a proof of concept at the moment and needs some css styling love, so feel free to fork and play with it.
http://jsfiddle.net/gwwar/9Ly8W/ or
http://jsfiddle.net/gwwar/9Ly8W/embedded/result/ (if you don’t want to play with the code)
Edit: Now updated to be a bit more user friendly and with a compare feature.
