Ganttbearer

Or maybe just call it Burndown.

I was joking around with a friend after playing Torchbearer about reskinning it to be a game where you play a software team trying to finish an awful software project.

I think the trick is making it playable and fun, and not just a mechanical grind. (The new game, I mean. Haha.)

"You've been working all night and this last task is due tomorrow, except there are no written requirements for it."
"Can I guess what the business wants?"
"Sure. Make a Userlore check. Ob 3."
"Gah. 2 successes."
"All right. You're now Hungry and Thirsty, but you have some kind of guess about the functionality you're supposed to deliver."
"Even if they'd documented it, they'd still change their mind when they saw it."
"Right."
"I'll hit the fridge for a Jolt and eat someone else's leftovers to clear the condition."

Comments

  • I like it!

    I've designed a couple of satirical office work games in the past, but I've never had an opportunity to play one of them.

    One had a fun feature I stole from someone else's draft online:

    The office workers socialize by playing a fantasy dungeon crawl game, which you actually play out, using satirical and simplified D&Disms. The fun comes from remembering that you're playing Thundorr the Barbarian AS Bob from Accounting, and getting that across to the other players.
  • edited August 2018
    The fun and interesting sides of software development are mostly the mind-boggling and unbelievable details (e.g. "I'd like to tell you the story of why the four functions must be executed in alphabetical order, but unfortunately the story ends with lawyers and a NDA" or "the demo failed because [ten layers of cascading failures] because the new SSD unit on the laptop you used is too fast") and the human relationships (e.g. reeducating a nice and helpful but dangerously incompetent colleague, day by day, or managing managers to get a raise). More professional aspects, like the sense of accomplishment for solving puzzles or building something great and useful, are hard to simulate in a game and better left for real software development.

    Therefore, the typical Ganttbearer story should be a fugue of complications within complications crashing against deadlines and showdowns.
    The project (campaign) should start from an easily understood general domain (e.g. banking, self-driving cars, videogames...) or, even better, something all players are experts of.
    Invent a customer, with the internal organization and NPCs the players will deal with, invent a general starting description and delivery timeline for the project, and unleash the player characters.

    The main subject matter should consist of clearly defined problems: their creation, their evolution into different problems (as they are understood better), their proliferation (https://en.wiktionary.org/wiki/yak_shaving), their occasional solution, mitigation, disappearance or acceptance.
    The general pattern of the rules should be randomly generating abstract problem types and randomly determining abstract action outcome types and mandatorily requiring the players to turn them into a specific description. This has many benefits over the OP example: creativity (and meaningful fiction) instead of arid "roll playing", being able to leverage player knowledge and common sense (for example, about what is more urgent), being able to introduce and sustain specific themes and plot lines (for example, revealing a NPC's personality through their work).

    Different problem types can be approached with different actions: phone calls, conference calls, meetings in person, emails, chat, thinking very hard about technical puzzles, writing various types of document, studying about a new technology, making an experiment, actually implementing and testing the product, and so on. Each action can have its modifiers and outcome tables, all tuned to almost ensure disaster.

    I think most randomness should be framed as rolling on complex random tables, reducing skill checks and conflict resolution to a niche role, because most random results are the revelation of unknown information or an unexpected event.

    For example, suppose the project is an action-adventure videogame featuring a modern day vampire hunter and the "customer" consists of a hierarchy of bosses from the same studio as the PCs and representatives of the publisher.
    The PCs receive the initial brief of a level design task: they'll make a medieval abbey with bad stuff in the crypt.

    Taking into account the stats of the NPC head designer you roll dice getting a terrible design document:

    2 "neglected special case, minor" (one "easy to guess" and one "uncertain")

    "what if the monster's corpse obstructs the stairs?" (easy to guess because, traditionally in this game, corpses disappear as soon as the player stops looking at them)
    "what if the player runs out of wooden stakes?" (there can be automatically generated caches of wooden stakes as usual, but their placement needs careful consideration)

    1 "impossible requirement, major" (tagged "objective incompetence" and "easy to correct")

    "the specified room sizes and positions imply a complete overlap between the kitchen and the former stables" (the head designer didn't bother to draw a floorplan, but the former stables can be easily moved to the other side of the corridor)

    1 "unclear requirement, major"

    "the church is supposed to be dark, but it's daytime and there are large windows"

    2 "missing specifications" (both "hard to guess").

    "the abbey has been maintained and restored through the centuries: how modern does it look?"
    "room content is listed for all the abbey except the west wing, but it can't be empty because monks live there"

    At this point the players could try to interact with some big shot to get the head designer fired (probably by using this disastrous design document as evidence), start working, ask for clarifications, and so on.
    Of course, attempting to contact the head designer should have random outcomes like "not in the office for a known reason, but expected in 2d4 hours" or "missing, everyone is worried" or "under the influence of psychoactive substances, roll twice on the Major Misunderstandings table".

    Regarding deadlines, the players can make up their own estimates and plans, then revise and refine them desperately as the dice fall.
    There should be a defined time scale for programming tasks, consisting of a time unit and a typical task size in time units, determining pacing (monthly reports vs daily stand-up meetings vs "are we there yet?") and detail level (e.g. cycles of frantic little experiments vs cycles of testing and bugfixing). Task decomposition can and should be hierarchical.

    For example, for the abbey level the time unit could be, by agreement, half an hour with tasks up to 5 hours.
    The players could decide that a randomly determined total of 124 hours of work consist of 68h of making 3D assets, 10h of assembling the level, 4h of important technicalities, 42h of tweaking and playtesting. Would it be a correct estimate for a real game? It doesn't matter: it's what players decided, it makes sense for them and their fiction, and it can go as wrong as any other estimate.

    There should be random tables for task complications, with results such as "decompose it into subtasks" (if longer than the elementary task scale; for example 68h of making 3D assets could be 4h a special vampire, 8h statues, 40h various furniture, 6h candelabra, 4h plants, 6h tools and objects), "you need another task worth 8d20% of the original as a prerequisite" (e.g. renewing the monthly subscription for your 3D software before 3D modelling, which at 6 hours can be a sequence of phone support calls, and at 50 hours can involve uncovering a management plot of bribery and embezzlement), "waste 1d4 time units to develop a doubt: roll on the Requirements Issues table" (for example, collecting plant references, the 3D artists finds out that there are many types of pine, not only the compact ones they initially assumed, and both very tall trunks and crawling shrubs would look good and make sense), "you make it" (not too often).

    Lastly, some rules should offer incentives not to work too hard, maybe tracking stats like Love, Fun, Health and the like, and to maintain a good relationship with NPCs.
  • Are you familiar with No Boundaries? You might consider to use it's 'fluff' for your hack.
  • This would actually be a useful module or supplement for Murders and Acquisitions, which is like a stabby Office Space. But it needs better adventure design "technology."
Sign In or Register to comment.