review [Ventures]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== The Design of Ventures: A Review From the CAMPO ======
=====The Reason for This Page=====
I often find when I am looking through old Society Game wikis that they seem very much "locked in time", to the point before the game started. There are a lot of interesting ideas and design decisions shown that were, presumably, either successful or unsuccessful, but there is no external verification of whether or not they worked. As someone who strongly encourages building off the lessons learned by others (something which was also thematically relevant in the context of //Ventures//), I have elected to write this up on the wiki as a reflection and consideration of the decisions that we made in //Ventures// -- what worked, and what didn't. We made a lot of new mechanics/systems that haven't been seen before in society games ([[game:downtime#goal_actions|Goal Actions]], [[system:influence|Influence]], [[system:items|Equipment]], distinctions between [[game:crewing|narrative/personal crew]]), as well as iterations on some prior concepts ([[game:crewing|remote crew]], [[system:quirks|Quirks]]), and this record here is to ensure that the information we learned is not lost. My advice to future game-runners and their projects. 
=====The Idea Behind the Game=====
//Ventures// was always a game about starting apocalypses. From before I had another GM on the team, it was always the goal to put the galaxy through the wringer.  

Over time (i.e. the first few meetings), this congealed into a philosophy and metaphysics I'm really happy with. Every sci-fi property that deals with aliens inevitably has to grapple with the concept of the Fermi Paradox, and //Ventures// had a //weirdly// high number of aliens in a very small volume of space. One potential resolution to the Fermi Paradox is the concept of a Great Filter, that acts as a barrier to the development of life. In the //Ventures// setting, there is a filter, but it comes in a post-civilisation world. Civilisations bring about their own destruction, internal or external, venturing too far, stagnating, or other form of collapse. In this context, //Ventures// is a story about the end of all things.  

But it is also about fighting. Pushing back, standing stalwart in the face of unstoppable odds. Looking at the inevitable collapse of everything and saying "no". It is a story about persistence. There will be an end, but it will not be today.  

It is also a story about what comes after the end -- the legacy left behind. There are those who have been and gone in this galaxy before who have already left their mark, and it is a mark that persists beyond them. 

A strong, thematic core will help in any game, but it was particularly helpful for many of the other game-running decisions.
=====9 GMs?=====
//Ventures// had an unusually large GM team for a Society Game, something which had not been attempted in recent Society history (either due to difficulty recruiting GMs, or from a belief that a large team wasn't necessary). All in all, I think this was a place where we showed that conventional wisdom is not always accurate. Perhaps it is just a testament to the GMs themselves, but I felt as if having this number of people greatly enhanced the game, as opposed to hindering it.

Scheduling was never a problem: the meeting was set at a fixed time every week, and usually got full turnout (especially on on-week meetings). Making sure that we had enough seats at the table was a bigger problem, but this just meant we needed to be selective about meeting location.

And having 2 players per GM really meant we could go all-in on our writeups. There were many weeks where I was only responsible for one turnsheet (although often with multiple people in it), and I could dedicate my full attention to making it the best piece of writing I could.

The only somewhat major issue I felt on my part was that there was //a lot// of explaining to do to members of the team regarding how things worked (wiki, emails), especially at the start. This in my opinion is more indicative of having a high number of first-time GMs than having a lot generally, although the number did arguably compound the issue. 

If you are planning on implementing a large team, there are some pieces of advice I'll give:
  * Make sure that the game philosophy and metaphysics are clear to everyone. In matters of dispute, there should always be a central theme/message to come back to that everyone agrees on, that can take priority over any in-character logistical issues. Making the story thematically consistent is, I would argue, one of your top priorities (alongside making the game fun for everyone).
  * Make sure that everyone on the team vibes with everyone else. The //Ventures// GM team felt particularly cohesive, to the point that we were scheduling extra things during the week to meet up and write turnsheets together. I do not think it would've worked if we disliked each other.
  * Set a meeting time, and stick with it. Consistency is key here to making sure everyone can show up and getting schedules to align.
=====What about Crewing?=====
Overview
There were a few reasons this was such a big part of the game. Firstly, it was done with the knowledge that this was being run as a paired game: //Threshold// players were given an opportunity to get to know //Ventures// players in a low commitment, low requirement role. They could come to uptime with a few instructions, not need to worry much about emails if they didn't want, and then not need to stress over turnsheet stuff. To this extent, I believe we very much succeeded for the few people able to benefit from this. Secondly, it was a way for graduates and people moved on from Oxford to stay involved with Society activities, still getting email opportunities from afar. I think success here was a lot more mixed, working well for some, but not as well for others. There are definitely some lessons to take away from this.

You need to be //very// clear with the responsibilities here with your GM team: perhaps even treating preparing the crew briefings like a turnsheet allocation. As the CAMPO you should also be checking up to make sure these are being given in appropriate time, but it's helpful as a GM to ease this burden. It is really important to look after crew! Especially for aspects of the game that you control directly as a GM, you should be proactively guiding your crew through this. They are there to help enrich your world.

More specific advice, but creating crew NPCs that target specific players with things they want to bite can be //very// hit or miss: it seemed like most of the players we were targeting were ones who didn't engage in emails at all.
====Remote Crew====
The best Remote Crew NPCs (in terms of engagement) were people who had hidden knowledge/information that the players knew about and wanted to get, or had a strange origin that, if questioned, might reveal more information about hidden aspects of the setting, or had access to something that would greatly help the PCs in their goals if they also had access to it. This knowledge also had to be something that was widely desired, as opposed to something only a small subset of PCs would want.

Players sometimes also seemed averse to talking to remote NPCs: I don't fully understand the effects at play here, but the end result was that PCs were turnsheeting a lot to have conversations with crew NPCs that would've been easier to have in emails. This may have been a failure on our part to communicate that this was a possibility, but it may also have been players not having desire or time to reach out. I don't know if this is a universally applicable issue, or just a result of people not sending as many emails in //Ventures// as they have in other Society Games.
====Narrative/Personal====
This one may be more conflicting in terms of opinions. It's a lot easier for us to design a narrative NPC that we know will fit nicely within established ideas, plots, and lore, but at the same time, it can be a lot more interesting for a crew member to design the NPC that they want to play as a PC-lite, especially if they intend to engage with the game as "I want to roleplay but don't want to give a lot of commitment".

However, this does mean that narrative NPCs might end up feeling more stagnant, especially if PCs aren't getting involved in their plot. This might be fine: either you're very active in getting PCs involved, or you're happy taking a less-involved role in the game. My advice though is for Remote Crew to take on narrative roles over personal ones, as you can be guided more actively to engage with things that people will email you about.
=====Goal Actions=====
There's a lot of stuff I liked here. I liked having the freedom to pick between 1 and 2 big writeups when assigning writeups to GMs, but still have the second be meaningful even if it was short. This is also an area where having a large GM team was very helpful, because it gave us the freedom to write two actions for some people, if we wanted.

The biggest issue was with the goals themselves. Specifically Culture. It was too ill-defined, and too hard to make a consistent "yeah that happened" writeup for. Technology was also a bit finnicky. Although I stayed on top of the trackers the whole game, it somewhat suffered from player expectations. Players can often find it difficult to judge just how much they are going to be able to succeed with an action, and then at setting expectations. This isn't a problem when they overestimate their capacities so much, because it's possible to scale them back, or make that a higher summit to reach with milestones along the way. The problem occurs when they underestimate their ability, and spend time on something that would be trivial for the character. I don't know if there is an elegant solution to deal with this. Surveys, Equipment, and Presence Goal Actions were all fairly simple to handle, though, and worked rather well. 

I would encourage people to pick this concept up in future and build on the idea: as a Player in games before, I have found a single action to be limiting, and I think this is a promising balance between manageable GM writeup workload and enabling PCs to do more things.
=====Equipment=====
I have mixed feelings about gear and item systems in RPGs. It's very easy to make them into "busywork" for the Player or GM, or for them to just be annoying lock-outs of content (i.e. "If you don't have this specific item, you can't do this thing"). It's hard to make something that balances the feeling of progression with avoiding the above issues.

In general, I would say that the best bits of our system were the extras: Augmentations, AI companions, Vehicles; stuff that wasn't necessary most of the time, but still could have a notable positive impact. Some players delved deep into this aspect of the game, but for many it was just a case of "get the Equipment probably needed for this system survey". Because the content of system surveys was also largely unknown (the first time, at least), this also meant that there was some degree of luck in determining whether or not you had helpful Equipment already. This potentially compounded issues, since it shifted the decision when acquiring Equipment from "I want to get this piece of equipment because it will enable something I want to do" into "I want to get this piece of equipment because there's a chance that I might need it", turning something that enables player plans into a mandatory task to avoid GM consequences. 

Modifiers also presented somewhat of a problem: partially with balancing costs, but partially with making sure that they were considered. In general we were pretty good at remembering they existed (helped by the fact that the Equipment section of private bios was very neatly formatted, I think), but decisions were often too clear-cut for it to be clear that //A Cut Above// or //Shoddy// had had an impact. We were able to communicate this sometimes, though.

If I were going to redesign this, I would definitely abstract away a lot of the work. I would probably remove Modifiers entirely, in favour of using Quirks to represent your aptitude and skill with Equipment generally. I still think it makes sense to keep Equipment as a system, representing a form of continual customisation and progression, as well as your improved capacity to overcome obstacles that you face, but I might remove specifics. Perhaps instead of tracking each item you own, we simply track a pool of "equipment points", which depletes as you go into and get out of difficult situations, or you actively spend to boost your success. Or, if that is too difficult to quantify (which it potentially is), then we simply assume permanent access to generic equipment, and only track the things that actually allow for more expression, letting other systems pick up the progression angle.
=====Influence=====
This is definitely an aspect of the game that I would have liked more iteration time on, with a very limited internal iteration time, as well as a very short period between playtest and final publishing. [[https://en.wikipedia.org/wiki/Iterative_design|Iterative design]] is very important to ensuring that systems you make are the best they can be, and I would recommend giving yourself as many cycles as you can manage.

In my opinion, with any system you design, you have to consider first and foremost the themes and gameplay you want that system to encourage. Influence was intended to be something that any player could easily dip into to get a small benefit, but that rewarded you with compounding power the more you invested and put into it. In that sense, I think the system fulfilled its intended purpose: many players used it to purchase a Squadron or an Agent to help them out with their endeavours, and only two went more deeper into setting up Extractors and using them to gain bonus EP. I don't quite think we got the numbers balance right here with how long it took to build things up, but this isn't that hard to rectify, it just stands as testimony that iteration time is very important.

Overall, I think there two main issues/changes that would've been beneficial to consider earlier in the development:
  * Firstly, there was a matter that the system required //a lot// of information, and presenting and editing it neatly on the relevant pages were not trivial tasks. This may have benefitted from using pictures instead of words to show things on Faction pages, but also was a consequence of there being so many different terms within the system (Base Traits, Labour Standard, Agent Fields, Squadron Traits, Squadron Modules, to name a few). 
  * Secondly, there was an issue with trying to give people a fair number of EP for NPC assistance. Quite early on, we were effectively handing people bonus EP from NPCs that were assisting them, exceeding the default 2 EP from a Goal Action, although usually with more strings attached the more EP was being given. This, in my opinion, partially undermined the point of giving things costs in the first place and the sense of personal accomplishment, since PCs could just ask for help to get what they wanted without needing to spend the turns building up to get it. A solution to this would either to be abstracting away costs entirely, or ascribing more numerical values to various sources of bonus EP (e.g. the //Business Partner (+)// Quirk might give a flat 2 EP per turn, certain government NPCs have a set budget of EP they can allocate to PCs in need, etc.). My preference would be to make it more abstract though: turnsheets are inevitably resolved in a fairly abstract manner, so ascribing numerical costs to things used for that implies more certainty than can actually be given.

Perhaps if I were tasked to redesign this system, I would think of a "slot" style approach rather than a "point-buy" one. Here, individual assets don't have costs associated with them, but take up one of your "slots" (representing abstractly your capacity to administrate, repair, or pay rent on the Asset in question). When you fill up all your slots, you need to recruit more people with free slots to help you manage things, or invest to get more. In this design, it is still fairly easy for PCs to dip into the system (since everyone would start out with a base number of slots, and the actual Assets themselves would be fairly easy to acquire), but acquiring large collections of Assets requires heavy investment. Like Equipment, I think removing modifiers on things would be a wise decision because of the extra overhead work that it introduces, but I may also create more Assets to compensate (e.g. splitting a Squadron up into the carrier and sub-light ships).

=====Playable Species=====
I am of the opinion that sci-fi is best when everyone plays a human, or no one plays a human. If you enable humans as an option among others, it inevitably gets seen as the "default" option. I think we made the correct decision with the selection of species we gave in //Ventures//: each one a unique, custom-built society with differing politics, cultures, and ideals, but still enough internal variation in each that it did not feel too Planet of the Hats. 

It did take a lot of time to develop these cultures and systems, but if you have that time and are willing to spend it, the outcome is well worth the time invested. I think adding the myths greatly helped with these cultural identities, especially the in-character metatextual elements, addressing how the understanding of those stories had changed over time. 
=====The Quirks=====
Something I have said when it comes to the other mechanics, but is especially relevant for Quirks: think about what the themes are, and make mechanics that reinforce those. Clumsy/Careful were, in my opinion, two of the most important thematically relevant Quirks, because they fed directly into Things Going Wrong. They are not something seen in many other Society Games, but were used in //Ventures// because they reinforced the themes. If you're ever copying Quirks from old wikis, make sure you fully consider what style of play that Quirk is encouraging, and whether or not it works for your game.

We tried to design Quirks such that they reinforced other systems, allowing players to pick and choose which parts of the game they wanted to interact with. I would say that this was broadly successful: in most cases, all of a PC's Quirks were considered in the outcome of turnsheet actions, and got used to help them out with the relevant systems. Quirks are a well-established Society Game mechanic though, and not something we made significant changes to.

A final word of advice though, one that any prior GM team will give you. Don't make a Quirk that gives some people extra snippets of information. We only had two players take it (one of whom dropped out partway through), and it was still painful to manage. Don't do it. 

=====The End=====
If you've read this far, then thank you. I am glad to have had the opportunity to run this game, and appreciate greatly everyone who participated in it. I wish you luck in your future works, and in running your own game. I'm sure you'll do an incredible job.

--Harry W.