In this topic i like to share some of my concerns about the current state of communication between the devs and the community.
I’ve structured this topic into
- Financing games
- Learning from the leaders and losers
- Project management techniques
- New communication Strategies
- Incorrect assessments and answers
to explain why regular communication should be the normal case in every software development company and especially in a game company.
Antecedents of my present topic
In the run-up of the C++ update we had a lot of discussions about the communication style between the devs and the community in the “I need an update about the update” post. Even before that there where frequent discussions about the amount of information shared by the devs about core gameplay mechanics and feature sets of B< which had as a consequence the question appeal. Unfortunately, the amount of shared information did not changed despite the previous efforts and i’ve observed that the community increasingly polarized about this topic. Now i like to sum up some of my core concerns and eliminate some of the incorrect assessments which I have observed in the community on the prior discussions.
Goal of my topic
First of all i like the make clear that i have the utmost respect for the devs and their performance with the creation of this game (As someone working in the software industry i know the problems and the struggle you need to deal with). With my topic i don’t like to push the development or attack someone (sometimes I’ll considered impolite - sorry in advance). But what i like, is to clear up some of the statements i heard a lot in the last discussions which show either missing knowledge in project management or incredible credulity. Furthermore i like to show solutions for the devs and the community (example oriented) how early-access (further referred to as EA) is handled in other EA projects i follow and how the current system could be changed to satisfy the requirements of EA and to involve the community into the development process.
Financing games in today’s games industry
In the past the game industry was led by “big-companies” like Activision, Ubisoft, Electronic-Arts and many more. All of them have in common that they have enough money to pay the development of a game by their own (either as publisher [invest in other developers] or as producer [develop the game with their own staff]). If a small development studio like wonderstruck liked to develop a game they were reliant on the money of the big-companies because every developer needs a wage (otherwise it would be unpaid - only few take this way).
In modern days - and after the success of crowdfunding and EA - developers are less reliant on the money of big-companies to finance the development time. Both methods (crowdfunding and I) go slightly different ways to finance a game as explained below.
Crowdfunding
Usual crowdfundings for games go something like:
- You have a running prototype of your game (sometimes only a really good idea) and you need money for further development.
- You start your campaign on a crowdfunding platform (eg. Kickstarter).
2. Campaigns have a defined end-date and either you aquire the money and start your devolopment or you need to rethink your concept becaus it was not accapted by the community. In contrast to B< where there is no defined end-date (See FAQ “Why aren’t you funding on Kickstarter?”)
2. You set different tiers of reward for a funding pledge (eg. 32€ → “Get Access Today” [also called EA or Alpha-Access or Beta-Access])
2. You wait till the end of the campaign. - You start/continue development
2. You give your “backers” (the persons who fund your idea) regular updates about what you do and how you progress over all (are there problems ? are we in time ?)
2. Backers can give you information what they like or don’t like and help you define your requirements for the final product (you learn from them what you need to produce that others would buy it). - You end your development and deliver the final product.
Early-Access
Early-Access is in many points (#3, #4) like crowdfunding but you need a running prototype and you like to give your players access to your prototype. There are many reasons (i like to name usal reasons) why you might want to open your game for EA:
- Testing (you can’t affort a huge testing set-up or paid testers)
- Information mining (you need informations what your customers [player] want to play)
- Money (you spent all your savings into the development and now you need fresh money)
In contrast to crowdfunding (where you don’t get “early-access” to the product always) you always get access to your EA game. furthermore i like to quote how Steam describes what one of they key-argument for “early-access” is.
Learning from the leaders
You can easily see that both (crowdfunding and EA) have in common that the devs share information with their players and involve them into development. As you can read in the Steam quote there have been number of prominent titles that have embraced this model. Some of them (i’ve fundet or played in EA) are Banished (finished), Kerbal Space Program (finished), The Universim (devolopment - alpha access) and Besige (development - EA).
All of them have a very active and big player-base. All of them share informations about core-concepts, art ideas or development plans on a frequent basis and have an extremely good rating on steam and other sites.
Learning from the losers
On the other hand i’ve also followed a few other games (EA) that made extremly poor in EA and therefore been abandoned by the players. To name one of the most awkward examples in my collection Godus which is nearly dead after 2 years and a promising kickstarter campaign (530k+ funds raised [yes, this is more than Oort-Online made before Sony]) in the beginning. 22cans made the big mistake to IGNORE the players opinion. Although a lot of informations was shared in the beginning the direction changed over time like now with Boundless (not saying it’s going the same way - but there are parallels)
Project management techniques
Over time the project management techniques used in the software industry changed a lot. In the beginning there were:
Over time the Spiral-Model advanced to “Agile Development” which finally resulted in “Scrum”. Most of the software companies out there work with either the “Spiral model” or with “Scrum” (i assume that wonderstruck also uses one of them).
Without wanting be too “technical” (added links for further study) i can summaries that one of the key aspects of the evolution of project management techniques is that the communication with your customer (in the case the players or the community) is a key part of the success of a software (or game).
Interim conclusion #1
In the past sections i showed (or summarized) that frequent communication (and learning from the said) is a key aspect for successful software-development and especially for game-development. Communication is desired, both by crowdfunding and by EA games (steam declares communication and inclusion as part of the EA definition). It’s also a key aspect of todays project management methods which leads me to a simple question:
Why don’t you (or stoped) communicate your concepts with the community ?
I saw a lot of opinions why devs should not spend their time on communication with the comunity in the prior mentioned topics and i like to give you an answer (in the following section) why this statements are invalid.
Incorrect assessments and answers
I don’t want to name or quote the authors of the following statements (i tried to sum them up and obtain the context) because of courtesy and i don’t want to expose anyone but if you insist i can quote directly.
Statement 1: The devs don’t want to reveal gameplay concepts yet
This is the most valid of all statements i’ve seen but it’s also only partially valid. There are two reasons why they might not want to reveal the concepts yet. While one is valid the other one is not.
- There is no concept yet that would fit into the B< game universe.
- They think it’s particularly significant.
The first argument (#1) is valid. If there is nothing to tell yet, they don’t need to tell it. This becomes awkward if there is a “direct request” from the players (like the bunch of unanswered questions in the “Question Appeal” Topic) because they like to know how you (devs) handle this problem. The result is that you should come up with a concept ASAP to show it your players and to get feedback if it’s a good idea or not. If it’s low on your priority list you can tell this your community. Most likely they will start a discussion if the idea has a consensus and you get your “community-approved-concepts” for free.
The second (#2) argument is nearly completely invalid IMO because there are no “particularly significant” informations in game-development (even in most software projects over all) that could not be presented in a way (abstraction, small world examples) that no other company could use it. If your idea is “special” it’s a key aspect of your game that’s for sure, but if your idea is stupid your game will flop because of it (eg. GW2 combat system). Therefore it would be better to “tease” your community with this idea and let them discuss it if they like it or not. You can still keep something secret and you don’t need to reveal everything but the “core idea” should be revealed to the community.
Statement 2: The devs stoped communication because we insist on what was said
In the prior sections i showed why communication should be the highest bid in a user-centered development process so there are no excuses for not talking to the community. If the community does not like your concepts or insist on something you mentioned before you should think about it! Either your idea was bad or you should not change it (or at least explain why you need to change it before you change/drop it [eg. the tier system in B<]).
You can also re-schedule any time frame that was planned early without any problems (but you need to tell it your community). Most of the players will prefer a “finished” game over a “delivered on time” game. No One want to witness BF2 again!
Statement 3: The devs don’t want to show unfinished work
While this may sound valid it’s a source of a lot of problems. Everybody only want to show the very best work he can do (that’s natural and understandable). But not everything that is in progress should be finished. I can name you an example from my own experiences in the software-industry. After a long briefing with a customer we (the developer - 5 people) sat together and discussed how we can fulfill the requirements of the customer (very open definitions and they wanted concepts for new workflows and user-interfaces) so that we can show some cool prototypes after the first iteration. We sat together and had really cool ideas but as we showed this “cool ideas”, on which we spend some time, to our customer he hated it. Even after we tried to convince him that this is a “cool feature” he did not budge. Long story short some features should never see the light of the day because they will never be accepted from your customer (let’s hope you find the rotten fruits before you ship the final product).
Statement 3: It’s a small dev team and they don’t have the man power
As a part of the project management nearly every software-team defines rock-solid project definitions for themselves (which result from the project definition in cooperation with the customer). This definitions will be split up into smaller chunks of work (backlog-items) and added to your “todo-list”. Within this backlog-items most of the information about a feature should be written out in text or diagrams. It’s not a big deal to take this backlog-items and write them down into one or two sites and show them to your customers (players). They can see your thoughts and what you are working on. You can get your customer’s approval for the idea and / or good input or new ideas for other features you can sell him.
Statement 4: Do you want to play the game or read about what you can play in a week ?
That’s an obvious but also lazy approach. If the team spends time on writing things down they can’t do what they are writing down in the same time (only only have your time once). But there is a pit fall in this approach. The time you need to write down your idea is also a time you have to think about the idea and clarify it (have i thought about everything ?). Who of you ever tried to learn a complicated subject knows that it’s a fundamental part of learning to explain something to someone else. Only when you are able to clearly tell what your idea/the subject “is” and if you are able to explain it to a person and the other understands you, your idea/the knowledge is fully “discovered”.
Statement 5: There is nothing interesting to tell
Let me tell you something, there is always something interesting to tell. Even in the times of the C++ rebuild it would be possible to tell something about “That’s the combat system”, “How the player driven economy works” or “Let’s talk about the cool ‘central guild’”. It’s not really that interesting for most of the audience to hear highly “technical stuff” about “Why C++ is so fucked up” but it’s extremely interesting for nearly everyone to hear about gameplay concepts. Concept-Art is nice but the information in Concept-Art is limited and it’s a source for speculations, assumptions and false informations.
Statement 6: laissez-faire - the devs know what they do
Even if i had never a doubt that the devs know exactly what they do when they develop the game i’m not sure if they know what exactly their players like to see (see Statement #1, #3). EA is not game development in big companies and you need to evaluate your players-needs by your own (or you need to hire a pollster). Big companies give a ■■■■ about their players wishes and just do how they like (as seen in nearly every game with a number greater than 2 in the titel). That’s why gaming is more and more boring and repetitive. If you like fresh ideas you need to talk to more than old game-designer.
Interim conclusion #2
Let’s conclude the above statements. There is not one 100% valid argument not to talk with your community about gameplay concepts. If you find one feel free to ask me for a solution (there is always one).
##New communication Strategies
I really like to encourage you (devs) to talk more and on more prominent locations (new topics) with your community. At the moment, a lot of informations is spread over several topics and only mentioned in sub-clauses. Eg. as you dropped the tier system it would have been really nice if you had started a new topic (maybe with a poll) and explained to us why you think the tier system is bad. It was a core part of the originally planned game (Oort Online) and if something needs to be changed it would be cool if we get an reason why (as you see the community accept it without outrage anyway).
A regular update about your current progress would be nice too. It’s not that much work to summarize some of your ideas and present it to us (1/3 a man day on a bi-weekly basis should be sufficient). It also “feeds the mob” (we have something to discuss) and it keeps the audience in this forum up. TBH the audience is really really low (only 10% of the players are registered and only 1% was online in the last month. Worst is that only ~0.2% are active forum users).
A lot of my friends think this game is dead (even if i try to convince them it’s not) because they see only few information about the development and gameplay-concepts and mostly only Concept-Art. A running prototype (even if it’s only a screen-cast) is better than pictures that are born in photoshop.
It’s really pity too, that after more than 3 month only a few of the questions in the “question appeal” topic are answered. This does not give (me) the feeling you really care about your community.
Final conclusion
As you saw in the interim conclusions #1 it’s common approach to talk with your customers about theirs needs. It’s also common to talk with your backer about the status of the development and about their opinions. In interim conclusion #2 you can see that there no (or only few) reasons not to talk to your costomers. Nearly every incorrect assessments is based on missing knowledge or credulity (no offense).
In the long run every software can only benefit from an open and constructive discussions with your customers. I really hope you devs (@james) rethink your current communication strategy with the community and i hope i’ve cleared some things up for all.
Again i like to say that i don’t want to offend anyone. If you feel offended please tell me and i’ll try my best to alter my topic according to avoid this.
If you have any suggestions about my thoughts feel free to discuss them but please refrain to come up with the already answered above statements (unless i’ve forgotten an extremely important point).
Thanks for your time to read this 
