I have read numerous articles on how to ask for, receive and action good feedback, but I have never actually seen anyone comment on how to give feedback; and in a typical designer playtest where there are four committed individuals sitting at the table, three of them are in a better position to influence the local feedback meta, and create a culture which helps all of us raise our game(s).

More as a reminder to myself, I thought it might be helpful to write a few notes of how to approach the feedback process, and how I might endeavour to give good feedback in future. Ultimately, we are all likely involved in playtesting in order to improve our own games, so creating a certain order in the process and a culture of constructive and useful feedback within the playtesters’ community of which we are a part, benefits all of us.

Feedback is not (Re)Design

We’ve all done it! We’ve playtested a game and been inspired!
Inspired by the potential we see in paper chits and card sleeves, by a cool new mechanic or just a theme. We do what we always do with a new game, we start thinking about what we would have done with it.
And we are sitting here with the designer – and they want us to tell them. How can we not…?

Even when we know what playtesting etiquette demands its hard (really hard!) not to get caught up in the moment and start the redesign process. Especially while sitting at a table with other designers who are all joining in.  If I am going to show off my design chops, I need to offer the best ideas, after all.

There is a place for all types of feedback. And it might be the case that your great ideas are just what the designer needs to help them lift their game from great to awesome, but I have often seen the post-game discussion stall around a debate on something that isn’t actually being playtested, and in fact isn’t even in the game.

Before the Game

Before playing I think it is probably helpful to ask the designer if there is anything particular that they are looking for feedback about. If they answer in the affirmative, then you can ask if they would like to share that, or do they want to keep what they are exploring a secret. Either approach could be valid. Sometimes the designer just wants to chalk up another play, but whether they have something specific in mind I think the prompt can be useful, in encouraging the designer to think about what they are looking for and whether they should have a particular goal for this playthrough.

During the Game

While playing the game, take notes. Nothing quashes the impulse to redesign on the fly, better, than writing down every thought, idea or mechanic as it comes to me. I know then, that if I decide my idea is worth it, at the end of the game, I won’t forget to mention it, but I don’t feel the need to interrupt game play with a cool idea for turbo boosts.

The most easily actioned feedback of any demo, playtest or teach is information on how well the rules of the game came across. It’s never nice to have to admit that you didn’t understand something, especially if other players seem to be getting it. If you aren’t afraid of looking stupid then commenting out loud when the light comes on, or when something that you missed in the rules’ explanation can be helpful. Whether it was stated and missed, or not well explained at all, the designer can easily make a note to make it clearer in future.
(One playtesting trick, if you don’t think you understand how everything works, is to just focus on one thing and do it to death. After the fact you can explain that you were exploring how that one aspect of the game functioned in isolation. It is actually really useful to have playtests which do this, and has the added bonus of you not having to admit that there was something that you hadn’t understood!)

Additional feedback during the game can be appropriate. I tend to comment on things I really like.
“I like the way combat works out”.
Or about the way the game is making me feel.
“I am feeling frustrated because I want to do….   …but I can’t, because…”
Or when I discover a new consequence of the design that the designer likely knows is there, but I have only just discovered.
“I’m finding it hard to choose which action I should take first because…”

In some instances I might simply make a statement, which points towards the way I might be feeling. “So, I now need to take action A, then B, then C and that’s going to take me three more turns.” I will also be making a note of this, but the intention is that I have primed the designer with the fact that I might have found gameplay too prescriptive or too slow so that when we discuss it later there will be a point of reference.   

Outside References

The third type of feedback I may introduce in this higher- level overview is to mention games that may be similar in some way.
“Have you played…. because it has a similar auction mechanic…?”
“This feels quite like…. because of the limited choice of actions”.

All these sorts of comments reflect my overall feel for the game, and avoid analysis of why the game mechanics create those feelings; I especially try and avoid, at this point, what could be done to fix them.

Post-match analysis

In the immediate aftermath I’ll tend to wait for the designer to initiate the discussion, giving them the opportunity to guide the discussion towards the feedback they are looking for (see this article by Chris Backe for ideas on how to do this). It also helps if the designer recognises that something needs work, if other playtesters haven’t already piled in with their critique.

I try not to take cheap shots at obvious weaknesses. 

I also tend to listen to other playtesters first. If I think my list of input might be longer than others (and it often is!), I prefer to keep my powder dry, rather than come across as someone who has just unleashed a torrent of critique like a scatter-gun at each and every target. It will help me pick and choose which of my thoughts are the most relevant.

Starting with how the rules were explained, gives the designer something they can use no matter how complete they feel their game is. My preferred learning style for any game (and pretty much anything else) is ‘show don’t tell’. I want a demoer rather than a personification of the rule book. Even if the game is reset after the first turn, I find the person teaching can run through the rules more quickly by playing a round or two, as opposed to pointing at different card, chits, tracks and tokens and telling me what they all do.
After the game, if there was anything I missed during their explanation (and there is often a lot!) I will point it out. If none of my other feedback proves useful, I think this at least can be immediately actioned – especially if playtesting at an event where the designer may be playtesting with multiple groups of people.

Refer to Notes

If I can relate the critiques of others to notes I have written down then I will do that. I might have specific examples, or be able to point to specific moments in the game when something came up.
If they are not brought up by other players then at some point, I will work through the rest of the notes that I still consider relevant. Once it has been written down, it is surprising how often I decide my great idea should probably be kept to myself.  

If I do decide to raise something, I will try and phrase my thoughts as either questions or points that might bear further exploration, and I try not to offer immediate solutions. Questions respect the designer, by assuming that the balance of the game is something they may have already considered.

“Have you tried the game with less restrictive movement?”
“Is there a reason why you limit the action points to 3?”
“How often do the cards come out in this particular way?”
“What happens if players have more money at the start of the game?”

If something is conspicuous by its absence then I will assume that there is likely a good reason why it was taken out. I have lost count of the number of suggestions I have heard from playtesters of something to add, where the designer responds with the fact that they tried it and there was a reason why it didn’t work.

Avoiding a Defence

I will also comment about points that might be worth further testing, without expectation of a response from the designer. It is too easy to create a situation where the designer feels they need to defend their game – it might even be worth reminding a designer that they should not feel the need to respond straight away and that they may prefer to wait until everyone has given feedback. If the same issue is raised by multiple playtesters then it might be worth addressing. If it was only an issue for one player then it might just be a case of “different strokes…”

This might be another opportunity to point out other games I have played, with similar mechanics or which have solved problems that have been identified during the playtest. Suggesting the designer play a particular game or at least find an online playthrough is an efficient way of describing an entire mechanic, and has the advantage of enabling the designer to go away and find their own solution rather than telling them exactly what to do and trying to fix the game at the table there and then.  

Making the object of the discussion another published game can also make it a little easier for feedback to both be given and received. If the designer hasn’t looked at enough other games then it is clearly useful research, but it can also give some authority or credibility to an idea – especially if the game mentioned is a classic. No-one (not even me!) wants to be ‘that guy’ and when the object of comparison is another published game it can be easier for a designer to take something on board rather than feel the need to defend their creation.

The Calm before the Brainstorm

At some point in this process it is almost inevitable that the discussion will move on to solutions for problems that have been identified or the more esoteric, “Have you thought of adding…?”

This might depend on how the feedback has been taken thus far. If I am hitting a brick wall then there really is no need to waste either my or the designers time; or more importantly perhaps, the time of the other playtesters.

It is quite hard not to end up here sooner rather than later – especially with multiple playtesters, as we spar for the opportunity to show how helpful (and clever) we are. It might be beneficial to ask the designer if they are open to hearing a few more ideas, but it also depends on where they are in the design process. If the game is a raw prototype then reworking the action point mechanism might be an option, but if they are hitting Kickstarter next week then the most useful feedback might be how they can communicate the rules better.

Questions can really help as a lead in here.
First giving the designer a prompt to ask their own questions “Do you have anything else you’d like to ask about?” and then asking my own. 

Rather than; “You need to allow 2 workers on every space”, I might ask, “Is there any way that you can make the worker placement less restrictive?” And if drawing a blank “Maybe you could try…”
In fact, it is rarely the case that other playtesters do not offer suggestions at this point.
In this way I would hope to maybe guide the designer towards a possible solution – not necessarily my solution – but one that they feel is appropriate for the game they are trying to create.

 Accountability

Even harder than the self-discipline required to keep my own impulses in control, is together creating a culture where all designer/playtesters do so. And this will likely require occasionally calling each other out. This can be a gentle prompt such as “Shall we save the ideas til the end?” or simply reminding others that you have an idea but will share it later.
In any playtesting group, a regular routine or checklist might be helpful in keeping feedback on track.

I understand that things are not black and white.  I still struggle with how much feedback to give to someone who has done no research, has no real clue of the board game industry, and shows no desire to learn. It’s not my job to burst their bubble even if I think it might be the humane thing to do.

But, having put this out there, I am now committed to trying to get better at the process of giving feedback. And if you ever find me sat across the table (virtual or otherwise) from you playing one of your games, just mention that you read this article and I will likely shut up!

TL;DR

Remember;
Playtesters are there to test the designer’s game, not redesign the game that they would like to make.

Different feedback at different points in the game – 3 levels.

• During the game;
  • When rules become clear
  • High level overview
  • When strategy is revealed
  • Feelings, Fun, Frustration
  • Compare with other games which feel the same After the Game

• After the Game
  • How could rules be explained better
  • Other games that have solved similar problems
  • Questions not solutions
  • Avoid a defence (don’t attack!)

• Brainstorming
  • More questions
  • It’s not about you… (or your game)

Accountability

• Better playtesting feedback benefits us all
• Create a culture
• Call each other on it

This is the first in a series of blog posts about virtual playtesting. Here;
Playtesting in Pyjamas
Giving Playtest Feedback
Getting the Most from Virtual Playtesting

If you’d like to put yourself through the ordeal of playtesting and receiving feedback and are struggling to do so during lockdown, come and join us on the Virtual Playtesting Discord server. We aim to be playtesting every Thursday night, from 6pm current UK time (5pm GMT / 6pm BST) using Tabletop Simulator (or other means).

You’ll hear the advice everywhere, “playtest your game as much as possible” but what does that actually involve? There’s pretty standard advice out there, “don’t just play with your friends”, “get as many people to test your game as possible”, “playtest with the sort of people who’ll play the game”, “ask the right questions”. All of this advice focuses around playtesting with other people. In my work as a designer, playtester, and developer I spend a lot of time playing games I’m working on, on my own. Yes some of that is solo, but only so much, the rest I’m playing the game as multiple players. I’m lucky to have some close friends who live nearby who are happy to playtest games, but I can’t take over every game night with prototypes and I have no regular access to playtesting specific groups. One friend in particular, David Ellis, is incredibly good for testing games with, and we have a great working relationship, which is pretty much co-design on some projects, but a lot of the testing falls on just me. So how do I do that? How do I make the most of that time? What about that method has helped me develop my own skills? You’re about to find out!

This is not the perfect solution

The methods I will go on to detail will not work with every game. Some games lend themselves to this method of testing better than others. Some mechanisms are impossible to replicate on your own, some require a lot of roleplaying (which I will go on to explain). If you’re reading this you can probably think of what games won’t work, social deduction, hidden roles, real time etc. However it does work for a lot of games you might not think it does. My personal tastes are for medium to heavy euro style games, that’s not all encompassing but it’ll do. These are also the games I’m often asked to work on. That’s about me knowing where my strengths are and getting to know the right people. Anyways, if you think your game design might benefit from this style of testing let’s get on with the how.

Examples

It’s not appropriate for me to quote from projects I’ve been involved in but at times I feel the need to provide examples. I’m going to use one of my own games; The Seven Dwarves, in these examples. It was my first design, and for a number of reasons I don’t think it’ll ever be published. It therefore will serve us well for an example piece of work. It’s a dice placement euro game for 1-7 players, core is Kingsburg like, for those of you familiar with that.

Initial stages – Just play it

Play the game. I’ll often start at 2 players and just play the game a few times to learn it, see what it’s about and get a feel for it. There’s no right number here, sometimes 1 play will be enough sometimes it’ll take a few and at different player counts. The aim to get a good overall understanding of what the game is about, how it plays, and more importantly how to win. If you have the option to play with other folks at this stage do so, but only if the game is playable. If it’s an early prototype don’t inflict it on others yet, but sometimes other people may spot things you didn’t notice. Across these plays just jot down some ‘big picture’ notes, if you think anything like me you’ll need to actively ignore going into too much detail.

So in The Seven Dwarves, I would have notes like this:

7 different player powers, 7 different powers ups, so 49 combinations

1 way to score points but in 3 different types, some in-game, some end-game

Track mechanism that provides upgrades, player order, and end game trigger

Some variable set-up

Dice placement, but there is some mitigation, no dice are ever wasted

7 resource types of varying values

Build the players

The next stage is outlining the strategies you want to test and how you are going to assign them to your dummy players. There are many different ways of doing this and it depends much on the design itself. 

In The Seven Dwarves there are player powers, and upgrades so all 49 combinations of those needed testing. Each player has a colour and each upgrade gets a number. From these we get RED 1-7 etc. This list produces 49 players we need to test, the number of tests you need depends on player count in each game.

There are also 3 different types of cards we will be building to score points, so there is another 7 players.

7?! Yes seven. Here is a key part of the process. In our example there are 3 types of cards we will score points from, so that gives us 3 strategies, I call these the “extremes”. The players will do all they possibly can to solely focus on one of those card types. Then there are 3 “50/50” strategies where the player now has 2 things to choose from. Finally an “all balanced” strategy where all the card types are considered equal.

So we now have our players, all 343 of them! Your game may be a lot simpler, it might not have player powers, or ways to upgrade or engine build, there may only be 1 way to score points. Or it may be more complex and less easy to work out. If it’s simpler, great! If it’s more complex we may need to figure out another way to outline our players and that’s why you need to play the game enough first. Write a list of strategies, it doesn’t have to be all-encompassing, but write a decent list of what players might have as a strategy in your game. Think outside the box too. We all have that one gaming friend who manages to come up with something really whacky, emulate or talk to them. One of my known traits when learning games is to ignore something, I’m going to digress briefly on that.

Ignore one thing 

Here’s how I’ll often play games for the first time, outside of design work. I’ll listen to the teach, or read the rulebook, or watch a playthrough and pick out one element of the game to ignore. Because of my personal preference this will often be combat, or bidding, but could be a certain worker spot or action, or a mini-game, or a phase. I will then play the game ignoring that thing as much as possible. Sometimes it quickly becomes apparent that I picked the wrong thing and I have to buckle and do it. This is not failure, I have identified that that thing is essential to gameplay, this discovery is really important. A lot of the time it will provide a huge insight into how that thing and all other things play out within a game. Sometimes it will make no difference whatsoever, that is a huge red flag for me. If it made no difference at all to the game experience why on earth is it there at all?!

The Seven Dwarves features a track that represents each Dwarf jostling to try and be Snow White’s favourite. It’s a great example of ignoring something. If ignored it, I’d never get the upgraded player powers, or get an extra dice, or score bonus points at the end of the game. On the flip side I would always be first player and would have 1 less resource to worry about so can focus more of my attention elsewhere. By playing the game ignoring this track I can clearly see how important it is from almost every angle. I find this a lot of fun and very insightful.

WARNING: If you are going to do this in a playtest someone else is running tell them first! It will often look like you are trying to break their game intentionally and that is not well received. Until people understand what you are doing, be polite so they don’t go onto the back foot.

Play the “extremes”

We should now have a list of strategies we categorise as the “extremes”. Ideally these would be within your player count. So if you have a 4 player game with 3 extreme strategies, we are good to go. As soon as the number of “extremes” exceeds your player count you are in for a much longer process. I’ll leave you to work that out, but it should be easy enough.

Play a game in which all the “extremes” play against one another. Here’s a top tip for doing this. Post-it notes. Write the strategy on a post-it note and put that in that player’s area. It may be that players have boards, or hands, or resources, or whatever, put the note with them. It will remind you how that player wants to play the game.

We identified our extremes as the 3 card types which are; armour, weapons, and jewellery. So we need a 3 player game where each player follows one of those extreme strategies, simple.

Record the results and look at the trends. Don’t forget to write about player experience as well as the scores. It is as important to find out if a player is having more fun than the others as well as if they are winning. Even more important, look at how the two relate to one another. What you do with this information, how you look at it, and what you go on to change or work on depends on your design brief.

What do I want my game to be?

I always write myself a design brief for my designs. When working for someone else I get them to tell me what they want. Does the game need to be perfectly balanced? Should player powers be exciting and varied? Should an all balanced strategy be better, worse, or equal to an extreme one? How much strategy do you want players to have? How adaptable can strategies be? How much tactics is there as well as or instead of strategy? Do I want the best player to win? How much scoring is open? How much scoring happens during the game and how much after? What should a winning score be? How much of a final score should each thing be? I could go on and on about this but you need this information in advance to know what you are testing for and why.

Play the “50/50s”

We have looked at the “extremes”, analysed the relationship between them, and probably made some changes to the game. Now we move onto the “50/50s”. This could not be any easier. Remember those post-it notes you put in a player area? Move them half a place around the table so each one sits between 2 players, simple. Now play some games where each player balances 2 extreme strategies, perhaps here you’ll need to add some other type of note to help make decisions, maybe one player wants in-game points and another end game points, for example. This will start to expand your testing into more varied strategies. This phase will take longer as there is more variance. Study these results (don’t forget player experience is of equal if not higher value than the raw data) both against themselves and the extreme tests. Go back to your brief and work out what you want to do with these results. Don’t forget that small changes can have huge knock-ons. “The player with the most cows always wins so lets just make cows worth less VP”. “Oh crap, now no-one wants to buy cows and the supply chain has broken down completely”. If in doubt go back to your brief and your theme. These will inform your decision making.

Play the “all balanced”

If possible add this player into your “extremes” playtest as an additional player, once you feel you’ve ironed out a lot of the wrinkles. This is the best test for this. Now more than ever you need to have a clear idea in mind of what you are trying to achieve in terms of balance. I repeat; player experience is as important, if not more so, than the numbers. 

I wanted balance in The Seven Dwarves. You can imagine the time I spent trying all 49 player setups and that’s something specific to this game as it had the 7 player powers and 7 player upgrades. The strategy testing was as important. Specialising in only 1 card type is suboptimal as you end up with too much waste, perfectly balanced is also suboptimal as you’ll be chasing too much. So here’s the key point for me in this design, not everything is balanced but there is no right or wrong answer. Tactics (the decisions you make during the game) outway any strategy, the player who plays the best will win most of the time. However a real strength is that players have a lot of fun having done one thing better than the other, “you may have won but I got way more jewellery than you and that’s cool!”. In this way the game filled the brief perfectly.

The hard work

Be prepared to play the game a lot!

Remember we identified 343 players that needed testing, and yes I tested them all!

Record every playtest and always apply your brief to the results. Make changes when you need to and want to and keep testing. Sometimes you’ll need to go back and test using a player group again, sometimes you can move on and not worry about it. 

When you are ready or able to playtest with other people let them play however they want to. You’ve tried every option you can think of already, so give them freedom to do what they want. This testing method should get your game into a really polished state, playing with other real people will get you all sorts of other information.

Yes I spend a lot of time playing games like this but it appears to be working and unsurprisingly has led into designing and developing solo modes for games, which I will cover in the next blog.

Thanks for taking the time to read this and I hope it’s helped in some way. Check out all I’m doing board game wise at www.facebook.com/DavidDigbyBoardGames

It is hardly surprising that the current circumstances, which have reduced the opportunities for folk to meet up and play games face to face, has resulted in a huge increase in traffic to the virtual board game world. Tabletopia has reported at least a 10-fold increase in traffic with similar increases also reported by Board Game Arena.
Neither is it entirely unexpected then, that virtual playtest groups have also sprung up and more designers are getting involved in playtesting online through interfaces such As Tabletop Simulator or Tabletopia.

The biggest surprise is, why have we all waited so long?

Over the past week or so I have playtested 5 or 6 games belonging to other designers and uploaded one of my own into Tabletop Simulator for my first virtual playtest.
It works! Really well!
I’m sure there is plenty of space for discussion on any and all aspects of virtual playtesting, but for now I thought I’d start with a list of the obvious Pros and Cons to a relative noobie.

Pros

• Prototyping is actually pretty easy. Uploading 2D digital assets is straightforward, and many regular components (dice, counters tokens etc) are already available.  Even a little bit of effort allows prototypes to look half decent.
• Novel Components. You can create novel 3D assets far more readily without having to resort to a 3D printer. And virtually cost free.
• Flexibility. In the virtual world you can create your game the way you would like it to be – without the constraints of cost.
  Do you want custom dice? Just add your images to the template.
  Do you want 1000 more mauve cubes? Just Ctrl C, Ctrl V !
  Is there a particular type of piece that you’ve seen in other games that would really suit your own? Then ‘steal’ a piece from another mod.
• Changing a prototype is even easier. You don’t have to print anything out again – you can just add one more card or change the art file for your board. If you decide a card is too small, or your resource cubes are too big then you change them right on the spot, between turns.
• Additional Expense. Pre-lockdown, I used to attend monthly playtest events in my city and another city an hour away. Both of these were in commercial establishments where I would buy some food or drinks. So with travel and expenses each playtest of my game could cost me £20-30. At conventions I could maybe expect to play my game 3 or 4 times over a weekend, but at a likely cost of at least £100-200.
• Convenience. I can playtest in my pyjamas. (Not that I would ever do that!) Compared to monthly face to face meet ups or infrequent conventions this is a breeze.
• Playtesters. You now have access to designers and playtesters from across the world at almost any time of the day or night. And adding new contacts to your network may prove beneficial in the longer term.
• Pitching to Publishers. For all the reasons above, virtual playtesting can be a great format to reach publishers. Especially publishers who have a bit more time on their hands and won’t be attending many conventions this year (where the majority of designer publisher events take place).
• Recording. Although designers do occasionally record playtests, setting up a full audio video setup while out and about is more than most of us will bother with. Recording a session on a PC can be as easy as a touch of a button; and with a relatively small outlay could be setup to record the faces of each player at the same time. This is the sort of ‘blind-playtest’ setup that all but the largest publishing houses could only dream of.
  
  

Cons

• Cost. Whether you are buying Tabletop Simulator through Steam, or loading your game into Tabletopia there is a cost involved. It’s not much but it exists. And while Tabletopia is free to players, every player must purchase Tabletop Simulator. I actually bought 4 copies of TTS for about £20 through one of the frequent Steam sales, just so I could fire up TTS on multiple local computers and could also give copies away to would be playtesters.
• Some work is required to get your game into the virtual environment. You can’t just scribble on index cards and begin.
• “Playing a board game in tabletop simulator is like playing a regular game one handed, while wearing oven gloves.” The interface can take some getting used to. And require some patience of playtesters who are unfamiliar with how it works.
• Time. Games do take longer – maybe twice as long. It can be hard to tell how quickly a game will play in the physical world by extrapolating experience in the virtual world.
• Pace. This is linked to time, but if your game relies on an element of pace for particular mechanics (i.e. players have to be the first to grab something when a particular card is drawn) or to maintain interest, then playing in the virtual world may be difficult.
• Complicated stuff. Some things which come naturally to players holding on to physical components are quite difficult in the virtual environment. One of the prototypes I tested last week had a rotating rondel, and we lost count of the number of times spinning the rondel threw all the components across the table. There is however a growing community of folk coding scripts to control specific components, and they are more than willing to share experience.
• Overproduction. Its hard to really describe this as a con, but I can already see how easy it will be to overproduce my prototypes. When it is easy to make things look good then the production values could easily get ahead of the readiness of the game itself, and might create expectations of playtesters that the game is further along in the design process than might otherwise be the case.

So clearly, I am sold on the idea. I don’t think I will ever go back to purely physical playtesting after the world situation returns to normal. As long as I can find other designers or playtesters (and with the whole online world I can’t see how that will ever not be the case) I expect to make much more use of virtual environments in future. I even have a blatant board game rip-off of an old arcade game that I think might be better released into the virtual world than trying to publish it.  

Designer Playtesting. A new video series of Playtests on Tabletop Simulator

If you would like to see what a virtual playtest might look like then I have been involved in a new project to record a series of online playtests with games from different designers.
The first edition has just gone live here.

http://www.thegamespeople.co.uk/designer-playtesting-video-series/

https://www.facebook.com/groups/2555070314529353/permalink/2908259269210454/

https://www.youtube.com/watch?v=vYsmEZAeU08&t=

This is the first in a series of blog posts about virtual playtesting. Others here;
Playtesting in Pyjamas
Giving Playtest Feedback
Getting the Most from Virtual Playtesting

Since writing this I have been involved in establishing the Virtual Playtesting Group. We meet on Discord on Thursday evenings (6pm UK time) until late, and playtest in Tabletop Simulator or Tabletopia.
With moderators in time zones from Eastern Europe to the Pacific, we welcome you to bring your online prototypes to playtest with other designers.

Here is an invite to the Discord Server.
https://discord.gg/Ze9mBWc