Here you can find other information which doesn't fit in any categories, including a more explicit explanation of what aspects of the game are controlled by the developers, and other answers to infrequently asked questions.
We initially assumed that a list of aspects which are not controlled by players did not need to be clarified due to there being clear process around controlling the set of submitted cards via Subreddit posts, and no process around changing various other things about the game. However, we've been asked to be as clear as possible about this.
The players control the processes which we have defined in the other pages, including adding cards to the games, updating them, and everything in the section on Realms. The final say on other aspects of the game come down to the developers. This includes balancing Heroes, decisions about which features to develop next, what color the logo is, etc.
You shouldn't generally expect regular changes to aspects of the game which are not controlled by players, even after consistent feedback.
We (the developers) want to avoid "knee-jerk" balance changes based on early feedback on new content. Reactionary responses to meta changes are an inevitable part of all online multiplayer games, and when developers immediately implement balance changes based on early reactions to new content, it can create volatile metas in which the focus is not on gameplay and player-controllable changes, but the arbitrary and error-prone decisions of the developers.
Balancing Heroes is delicate, and heavily influenced by the available pool of cards in the game (which is controlled by the players). We would prefer to err on the side of a given hero being deemed "underpowered" for an extended period over excessive week-by-week changes to developer-controlled gameplay elements in an attempt to find perfect meta balance.
When you provide feedback on balance, we listen; but your main method of resolving meta balance should be through card creation and updates, not through communication with the developers.
Core Gameplay Changes
Collective is a young game, and we (the developers) are willing to make changes to the core rules of the game if we think they will promote better gameplay. A recent example of this was changing the maximum hand size from 13. The hard limit is still 13, but at the end of turn, players discard extra cards in hand until they have ten. Among the reasons we made this change:
- At times, the meta involved both players regularly having full hands of 13 cards. We generally found this to be an undesirable game state, as did most players and playtesters.
- We already had concerns about ease of use when we make a phone version of Collective, and players were already finding it difficult to simply click on their intended card in hand on desktop.
We want to avoid making too many additional changes to the core gameplay, but reserve the right to do so. The entire game is a bit of an experiment, and when early decisions (such as setting many numbers in the game to 13) seem like clear mistakes, we will change them.
Infrequently Asked Questions
The rest of this page is official answers to rare but persistent questions from the community. It is not recommended reading unless you want to go into deep detail on the corner cases of the democratic process in Collective. This is why text in this section is darker in color than others.
How Can I Start a Discussion in Collective?
Begin on Discord
Whether you want to discuss something that's directly within the players' control (like the effect of certain cards on the meta) or something that is not (like when a new feature is released), you can start on the Discord.
There are many players in the Discord who have been in the Collective community for longer than you. Any discussion you can think of, and many more, have almost certainly been brought up there at one point or another.
Nick and Alec read several channels closely, and others less closely.
- #install-issues is for posting when you have issues installing the game.
- #feature-requests-concise is for suggesting ideas for new features.
- #bug-reports-concise is for reporting bugs in the game (after you've an in-game bug report, ideally).
Both of the "-concise" channels have "slowmode" on, which means you can only post once every two minutes (although you can edit your posts to provide more detail). This is to make sure that Nick and Alec can catch up with every post. Their accompanying "-discuss" channels are for longer discussions and do not have slowmode on.
We've seen a trend of players creating small polls with Strawpoll to get support for their positions. Feel free to do this and even ping us if you'd like, but they will not necessarily do whatever gets the most votes.
Formalize it on Reddit
If you feel strongly about something, make a post about it on the Subreddit. Just like with strawpolls in Discord, we (the developers) will not necessarily do something just because it's popular. However, we pay attention, and even if we don't respond, we will hear you -- and the Subreddit is a place where your message will get more visibility. Alec, for example, reads the Subreddit much more than the Discord.
Have you considered using Ethereum or other Blockchain technologies?
We are of the opinion that blockchain and crypto are conceptually similar to the ideologies behind Collective but its success/failure is tied to crazy world events we can't predict, and it invites speculators.
Our message has always basically been that the game couldn't work without our community and they're really important. Speculative markets can end up like pyramid schemes and just the flavor of that has the potential to spoil the optimistic idea behind Collective.
In a less emotional world it could definitely be a good tool, but we really don't want to have our brand associated with alleged schemes like Bitconnect.
Strict vs. Loose Rules Adherence
Any set of rules has grey areas. There are a handful of these grey areas in which we (the developers) are either very strict, or very loose.
Deciding when to follow our own rules exactly and when to bend them ultimately comes down to weighing benefits and drawbacks.
Strict: Copyright infringement
When it comes to copyright infringement, we are as strict as we can be. Here are the copyright infringement rules from Rules for New Cards:
- No cards which mention someone else’s intellectual property, for example a "batman" card.
- No clever use of the art editor to visually represent someone else’s intellectual property.
- No cards which are too close to a card from another game, for example a card with the exact same name and effect (or suspiciously similar name + effect, or a "parody")
- We’re a very small team and not going to take any chances with this.
There is a reason that this is the first rule for submitting new cards. We are a small team for an indie game and an extremely small team for a free-to-play online TCG. We can't afford to take any chances with this, and if we get a whiff of something potentially violating copyright, we may reject it before it gets in, change it once it's gotten in, or even remove it from the game. We have not had to remove anything from the game yet, but we certainly will if we didn't realize it had the potential to violate copyright.
The players have been very understanding of this so far, and we are extremely appreciative of that fact. Players new and old ask us on Discord when designing cards whether art, name, or effect is too similar to other properties or cards in other card games. If you have any questions, please ask us and we'll be happy to tell you.
Upside of upholding this rule
If this rule is broken even once, we all risk losing everything. Litigation, especially in the United States, can be wildly unfair, and even in a situation in which we have done nothing wrong, continually battling frivolous litigation from a corporation with more resources than us (which is essentially any corporation you have ever heard of) could end the project and bankrupt the developers.
Downside of upholding this rule
The potential downside of upholding this rule is low. Making a card which references someone else's property is never as creative as coming up with something yourself. To be very generous, making a parody of someone else's property could be somewhat funny.
Strict and Loose: Removing cards and preventing 'ground up' redesigns
In the Rules for Updates, the first rule is that "ground up" redesigns are not allowed. The purpose of this rule is the same as the second rule, "You cannot remove a card". Redesigning a card entirely is effectively the same as removing the original card and adding a new one.
We have avoided explaining exactly where the line on this would be drawn.
Upside of upholding this rule
The purpose of this rule is to avoid a situation in which a player gets a card into the game, only to come back later and find that it was later removed.
Early on in the development of Collective, we (the developers) chose to heavily protect the feeling of getting a card into the game. We want getting a card into the game to be a permanent accomplishment that cannot ever be taken away from you. Allowing systems in which someone's card is removed, even if the community unilaterally agrees on it, breaks this promise.
Changes to your card, such as changing its effect to be more balanced or to have different art, may be perceived as infringing on this accomplishment by players; however, Collective was never going to be a good game without the ability to update cards, at the very least for reasons of meta balance. We extend this trust in the community to improve on designs to other aspects of a card, such as art.
It is undeniable that a single card, if left unchecked, could ruin the balance of the entire game. However, as we say in Rules for Updates, it is our (the developers) opinion that any card can be changed to be balanced by changing its casting cost or adding prerequisites for its effects to occur. We want to protect the accomplishment of getting a card into Collective, and we believe that there is no card which cannot be tweaked without
For the reasons stated above, there is a limit on the amount that someone can update a card. We have not defined exactly where the line can be drawn, and we probably never will. This is one of many grey areas in the democratic process of Collective, and for now, our attitude on what makes a redesign go "too far" is that we know it when we see it. Hopefully this explanation at least helps to clarify what we see as the upside of this rule. It should make logical sense that a mean-spirited update to a card, such as changing its name to "badly designed card" out of spite, would break this rule.
Downside of upholding this rule
The downside to upholding this rule is that people who update cards "creates an atmosphere of paranoia" (a quote from one of our players) in which it's unclear what will and what won't be let into the game. To those who have actually read this far, this may be disappointing, but we (the developers) actually see this as a positive.
From the beginning, we have seen updates to cards as a necessity, not a core, enjoyable feature of the game. As said earlier, Collective was never going to be a good game without the ability to update cards, at the very least for reasons of meta balance. However, we believe that there is not much downside to having some limitations on updates, which is why we still have a limit on the number of updates allowed per week. Collective is not Wikipedia, where minor updates can be made to massive numbers of cards without negatively affecting player experience. Cosmetic updates, on the other hand, are acceptable in any number because they, by design, don't have an impact on balance and gameplay that would be impossible for relatively casual players to keep track of. This is the most important reason for distinguishing the two types of updates and enforcing limits on one type while leaving others to be unrestricted.
"Creating an atmosphere of paranoia" around updates in which players are afraid that their update may not be allowed in is not optimal, but we think it is another "necessary evil." Our priority is in protecting the original design, or "spirit," of the card, instead of prioritizing the wishes of one person or a small handful of people who want to change tens or hundreds of cards to be mechanically symmetrical, similar to the linked article about a rigorous Wikipedia editor. You can read more about why mechanical symmetry of this kind can spiral into extreme, 81-page-long set of rules which can create impediments for new users creating new cards in this blog post.
Sometimes, players submit bugfixes to their cards after they've gotten a high amount of upvotes. We have recently adopted a new policy. If your card has a bug, not only will you receive less gold than normal, but also be put into Limbo until the submitter fixes the bugs.
Upside of upholding this rule
Now that Collective involves in-game voting, there is more need than ever to have bug-free cards submitted to the subreddit. And it is true that allowing last-minute bugfixes could encourage a culture of submitting poorly-tested cards to Collective. On the other hand, we have found that finding bugs on our Twitch stream has almost universally resulted in last-minute panic and embarrassment by the creator. This, along with the gold punishment, seemed to be a decent deterrent.
We have, as mentioned, found that over time the number of cards with bugs submitted per week has not been going down. One of the unfortunate side effects of players' greater expertise with the Card Creator is that they are more comfortable submitting cards without testing them – we have noticed that most bugs would be noticed immediately upon brief testing, and often are obviously typos or mistakes as opposed to problems caused by complicated effects or interactions.
Not enforcing stricter punishments follows the previous idea of "protecting the achievement of adding a card into the game." If someone adds a card into the game and it gets a high number of upvotes, it was almost certainly a well-designed and pleasant card which voters wanted to see in the game. If there was a bug in their card, there is already a punishment to their in-game gold; we believe that the act of realizing a mistake and telling us about a fix is a good faith gesture which should be rewarded.
Downside of upholding this rule
Downside 1: Potential malicious "bugfixes"
It is potentially possible for players to submit "bugfixes" to cards which are not bugfixes, but instead have actual gameplay significance. This has actually happened, although it seems pretty clear to us that it was an accident and not malicious.
For this reason, we plan to eventually move towards a system in which the differences between cards are more easily comparable. This would allow for a variety of effects, including:
- Automatically generated images which show the old and new version of a card side-by-side on the Subreddit, allowing for an easier comparison and insight for the voters into what exactly has changed (currently they would have to leave the page and find the current version of the card to see what has changed)
- A new feature for the in-game voting interface in which [Update] posts could also be displayed in game, and the differences would be highlighted in the new version
- The ability for us to check differences in updates on the fly and immediately notice any differences which we wouldn't otherwise
#1 actually been mocked out by our users with a script that generates an image similar to what we had in mind, and #2 is a feature we would like to work on at some point. We believe it's somewhat low priority, but only because the community has shown a remarkable sense of morality for an online community, nullifying the benefits of #3. We have yet to see a new card with a feature (such as a subversive emote insulting someone or something) upvoted and added to the game. However, we have no guarantee that this good faith behavior will continue, especially should Collective become more popular.
Downside 2: Insufficient punishment for bugs
The second angle on the downside of upholding this rule is that people who submit cards with bugs should be punished harder for their mistakes, even if innocent. Proponents of this have suggested that cards which are bugged should be outright rejected, regardless of whether a bugfix was submitted to the developers ahead of time.
We are trying a new system in which cards are sent to Limbo if they have bugs, and will stay there until the original submitter fixes them. We hope this will discourage future bugs in cards. If not, we may need to come up with some new ideas. We want to avoid a situation in which it looks as if your card will get in, only for a bug to be found (especially a minor one) and the accomplishment to be completely removed.
Loose: Eleven cards getting in due to a mistake
Mistakes are inevitable, and while collecting the top ten cards, Nick and Alec have in the past accidentally added eleven cards instead of ten. Sometimes this is because a card was skipped, and sometimes it is because we (the developers) simply picked eleven cards by accident.
Our current policy is to let all cards into the game which were announced as winners, as well as the cards which "should" have gotten in (after an investigation in which we verify this was the case).
Upside of upholding this rule
Once again, this comes back to respecting the achievement of having your card added to the game, or in this case, denying others the ability to take it away.
To some, getting a card in as the accidental eleventh card may feel like a hollow victory. To others, this could add to the novelty of the experience.
Removing a card from the game after publicly announcing that it was accepted is something we never want to do. If we did this, some people might find it to be acceptable, but others would be disappointed. The disappointment of having something, then having it taken away, is worse than never getting it in the first place.
Downside of upholding this rule
The only complaint we've seen about this is about "fairness," as in, "it's unfair that the eleventh card gets in for some, but not others."
This doesn't feel like it outweighs the benefits to us.
Other Developer Decisions
This is a section with more information on the background and justification for miscellaneous developer decisions which are not democratically controlled.
Design Competition Topics
Design Competitions are an event in which card creators are given a prompt, such as "Cards with Flying," and the highest rated cards which are submitted with the appropriate Design Competition tag are added to the game.
Design Competition topics were generally chosen by the developers. However, they have gone through several different iterations, including:
- Design Competitions with Five, Four, Three, and even One winner(s).
- Design Competitions with and without "guaranteed slots." A Design Competition with "guaranteed slots" means that the winners of the Competition will get in, even if their score is below the score for the tenth card that week. Design Competitions without guaranteed slots have to have a score higher than the tenth card that week to get in, meaning that aside from providing extra slots that week, Design Competition cards are effectively the same as [Card] submissions.
- Design Competitions which do and do not take up the top 10 slots. If a Design Competition takes up the top 10 slots and has "guaranteed slots," it lowers the number of [Card] submissions added that week by however many winners it has. If it takes up the top 10 slots and does not have "guaranteed slots," it would effectively function identically to a [Card] submission. (This has happened at one point or another, but sort of defeats the purpose of Design Competitions.)
- Design Competitions which are and are not counted as [Card] submissions. A Design Competition in which cards are not counted as [Card] submissions means that no more than the maximum number of winners can get in that week. A Design Competition in which cards are counted as [Card] submissions means that cards with enough upvotes to get into the top 10 [Card] posts that week can still be added to the game. In this case, if the Design Competition had three winners which don't take up top 10 slots, and thirteen entries which all had scores higher than the top [Card] post that week, all thirteen cards would get in, and no [Card] submissions would get in, because they all had lower scores than Design Competition entries. (This situation never happened, and a major reason was that Design Competition entries traditionally do worse than [Card] submissions.)
- "Team" Design Competitions, in which pairs of players create a new card together.
- Design Competitions which establish a new Tribal Type.
- Design Competitions which the community essentially rejected – you can read here for a detailed rundown of community reactions to this Design Competition. The ultimate winner of the Design Competition, Massive Boulder, was posted afterwards, and certainly deserved its title as winner.
- "Design Competition Design Competitions," in which the players submitted their own ideas for Design Competitions to the Subreddit with the [DCDC] tag, and voted on which one would be the Design Competition topic for the next week.
We have experimented a lot with Design Competitions, and we have had a ton of fun with them in their previous form. Currently we are rethinking how to use the system in the future, and whether changes should be made. At the time of writing, we have put a hold on new Design Competitions, and aside from the occasional DCDC, do not have plans to run more Design Competitions for now.
Updating the Core Set
Players cannot update the Core Set of cards.
This has been a common point of contention, but explaining in detail why this is the case seemed to help on Discord. Here are the reasons why the Core Set cards can't be updated:
1. Technically, it's surprisingly difficult
This is primarily because the Core Set of cards is hard-coded in the game (unlike other cards, which are saved and referred to by the URL of their image). We already have a lot of work to do, with only one person (Alec) doing programming near full time (and he still has to make game design, business, marketing decisions, etc.)
Making Core Set balance changes slows us down by more than just the time it takes to implement them. you can read lots of stuff about what interruptions do to programmers and product deployment flows online, but the short version is it's like if we have a car driving 60mph and then we have to come to a complete stop to exchange one wheel for another, then rev the engine up for a while to get back to 60mph. it's not just the time it takes to exchange the wheel, it's all the time it takes to slow down and then speed back up again.
2. They're useful for tutorials
If players can vote on the Core Set there is no way for us to quickly add something to the game to be used in something like tutorialization.
For example, Ashgerdy's starting deck has the new Surveyor Bot "Choose One" UI, which inevitably will come up in the tutorial. This allowed us to make the "Choose" UI for a single target one click instead of two (i.e. click a target then hit "done") because a single click UI could be unpleasant to a new user who first saw a "Choose Multiple" UI, where you select targets and then hit done, then later sees a "Choose One" UI, where by selecting it, you immediately make that action happen. We had the ability to do this, which we thought made for a better UI experience, because we can just change the Core Set without asking the players.
We've made very few changes to the Core Set so far, but in the future we may have more keywords (user generated) which we want to show earlier on, or other changes to fit tutorialization of new game modes, or cards which have special effects in extra game modes -- we don't know. the Core Set is a large enough chunk of cards which are generally irrelevant to the meta that we can continue to dip into it for years if need be.
3. They could affect the meta, and shouldn't
If players can update the Core Set it's very likely, players will buff Core Set cards until they're relevant, and if we have to change something there, then it can affect the meta unintentionally, which ruins the bigger thing we want out of the game: for the meta to be determined by the players.
We believe that, even if the current players agree to only change Core Set cards to fit in with something like Affinity Identities, it will be difficult to make this case all over again for future players. For several months, players wanted to buff the Core Set to make it of the power level of other cards. The natural inclination players have is for all cards to be relevant, and the existence of an intentionally held back set of cards is unpleasant for the natural human desire for symmetry and balance.
Believe it or not, we consider the inability to update the Core Set, as well as their relatively low power level, to be part of the lore of Collective.
We assumed that the community would not create cards which were all weaker than cards in the Core Set (a very safe assumption), and turned out to be right. A major aspect of the game's plot is that you – the players – are "The Collective." You decide what is added to Wanderstar by voting on the Subreddit, and your actions have consequences. The Core Set is a representation of the native population of Wanderstar, and in accordance with the story of the game, you do not have power over the native denizens; you do, however, hold its fate in your hands. Wanderstar is a potential utopia or dystopia, depending on what you decide to add to the game. The fact that the players have chosen to add things to Wanderstar which are of a higher mechanical power level is already a choice that has been made for the future of the planet.
For more on this, read the Lore section.