TEAMWORK AND YOU PT. 3: RMN

This is less a part 3 of Teamwork and You and more of an addendum of part 2, which you can read HERE. This article is less about teamwork in general and more about using some RMN features that some may not be aware of. Yes, there are plenty of alternative methods of communication with varying levels of effectiveness. However, RMN does have a surprising amount of features that enable effective communication between team members.

One thing to keep in mind is that RMN is not the ultimate solution. Something could happen that would temporarily shut down the site. As such, RMN is probably best if you're working on smaller projects. If you're going to work on something huge (like Final Fantasy Discovery huge) you're probably better off moving off site to arrange your documentation.

____________________________________________________________________________________

1: The importance of documentation

When you're working alone on a game, documentation is important. When you're working with a team, documentation is vital. Keeping your documentation as precise and accurate as possible is important to make sure that you are all on the same page. In fact, I made a conscious effort to go through each and every segment daily to make sure that I didn't deviate from the design of the game.

If there is any confusion, you can go to the section and pull quotes to remind others why you made certain choices.



2: Why I prefer it over Skype or Google Docs:

RMN is awesome, but you may be wondering why we chose this method instead of, say, Google Docs or Skype for ease of communication. After all, aren't they more specialized in the field of sharing design documents? At least Google Docs is. Well, you are correct. It's especially convenient that you can make the edits to a document yourself as well as add annotations in the appropriate places on each document. However, if everyone can edit and annotate as they please, it would be pretty easy for information to get confused or distorted, especially if there is some sort of miscommunication between your team that could cause any incorrect edits to be made. Plus, as far as I could tell, it would be difficult to revert back to a previous version of the document.

In order to prevent information from getting jumbled up, it's best to gave one person alone be in charge of making edits to the documentation. This will keep everything organized and the team doesn't have to worry about random changes after certain parts have been implemented.

The second major reason I prefer RMN is comments. If information needs to be referenced at a later date, it's best if you can just scroll through the comments and mentally retrace your conversation. Google Docs has a drop down menu where you can read all the annotations in order of posting, but I found that it isn't as helpful as reading through an entire conversation near the bottom of the page. Perhaps it's just the layout of RMN that I like, but it helps keep all the information organized. Forum posts are the same thing as annotations, but they are all collected into one area that you can easily reference.


The final reason why I like RMN is you can set up different tabs for each category of your game. With tabs, it's easy to keep all the information organized within each category, so there's no hunting down a long string of messages just to find one directive or instruction you had forgotten about.

Here, take a look at the Remnants of Isolation page list:



You can see here that we have a different page set up for each category of the game. This is important because there are a lot of aspects that go into a game's development as I'm sure you're already aware. Keeping all that information straight in your head isn't hard, it's impossible. Therefore, organize your thoughts and plans into each category and make a tab covering each one.

Arguably the most important page of this entire list would be the Deadline page. Here, the different dates where certain parts of the game are expected to be finished are listed. Use this tab to set both short term and long term milestones to give the team constant goals to look forward to. When should the first level be completed? The second? Third? When should the character art be finalized? When should the enemies in the first/second/third levels be done? And of course, when should the actual game be completed.

Pro tip: Plan to have the beta build finished AT LEAST four days before the deadline. That way, you can go back and fix up issues and pretty it up later. Better to have a mediocre playable product than an unfinished one with a pretty ribbon.


3: That beautiful little checkbox, "Dev's Only"



If you make a new page with this box checked, only people listed as devs and testers can see this. This makes communicating with the team that much easier.

Guess what? Testers are part of your team as well, so you should make sure to set up your game page so you can talk with them just as you would a team member. Plus, naming people as testers gives them a nice boost in Makerscore, and as we all know, Makerscore is life!

However, if you choose to go this route, understand that testers will now receive notifications of every post you make in non testing pages. They aren't devs, so they won't be able to sift through all the pages you've set up, just the ones they receive notifications for. You could use this as an opportunity to have an in-depth discussion with testers about their reports

If you're okay with this, then great. Just be aware that this will happen.

Going back to the management page section, if you scroll upward, you'll notice another checkbox:



Leave this unchecked. Checking this box will make the page available on the primary navigation bar on the public profile. Of course, nobody that you haven't named as devs or testers will be able to actually follow the link, but having a public link that players can't follow is just unprofessional.



4: Hot potato the build:

This section alone could go in a different article about development styles so I won't go into too much detail here. I'll just say this: You have the ability to mark downloads as testers's copies. Use it. This allows you to put up PLAYABLE content for your team to actually PLAY and look over. Because until you have something PLAYABLE, your perfect design plan is about as meaningful as a fart in the wind.




It's important that you do this constantly, because a) you get a constant feel of how the project is turning out (which is almost never like how you planned it in your head) and b) it contributes to a checks and balances system. If you're playing new content that your teammate just uploaded, it's possible that you could catch something that they did not, and can address it before it becomes a problem later down development time.


____________________________________________________________________________________

Hopefully, after all this, you have a better understanding of how you can use RMN's features to make communicating with your teammates easier. If you have any questions, let me know and I'll do my best to answer them.

Thanks for reading!