Soft Skills

[Jayrodd]

Soft skills are character traits and interpersonal skills that characterize a person's relationships with other people and work ethic.

It might be a given to communicate when you're working with a team, and that being organized can make everyone's life a lot easier. How often do you talk about it though? It's always good to take a step back and look at your process and see how you handle things on a macro and micro level with your team, and everyone functions a little differently so maybe what someone else does can work well for you!

• Discuss tricks teams can use to make jobs easier on everyone
• Share useful tools for keep track of progress or communicating with your team and audience
• Brianstorm ways you or your team can tackle your goal in an efficient manner

 

[Shgeldz]

To the surprise of no one who knows me, going to put in a plugin for Slack here.
Slack is basically an IRC/Discord, but designed for teams working on projects. I've used it at two separate jobs, in a newsroom, as the main form of communication for the PEG team, and for a beta testing program. Here's a super sneak peak into what our Slack looks like (keeping some stuff/names censored)

Spoiler: shhh

We've got channels laid out for the different aspects of game design, and it helps to segment them accordingly, keeping us on track. One of the best side effects of slack though are the non-game related channels, which allow for teams to really hang out and become close. I know I had no idea who anyone on PEG was besides Evan when I joined and I know know everyone super well, and have even been to some people's houses!

 

[Deo]

Seconding the plug for Slack, it's wonderful. Discord is okay for this sort of thing, but Slack is far superior.

I'm in a bit of a weird position when it comes to project management since typically I only work with my friends, so we all know each other usually. Slack is ideal for keeping the project organized if you can get everyone on your team to have it on in the background or have push notifications enabled for it. Google docs are also very handy with details and brainstorming for a project.

One of my favorite things with Slack/Discord/whatever has support for channels is having a channel for ideas that pop into people's heads, aptly named #random-ideas. It's such a simple thing to add, but some really awesome ideas have been posted in there from my team. I love it. I'd highly suggest adding something like this if you haven't already.

If I had to end off with something that I think is really important for being a team member: be open to feedback, and be flexible. I've worked with people in the past that aren't very open to critique and aren't receptive to feedback. That's being a bad team member. That feels like such an obvious thing to say, yet you'd be surprised at how many people make pretty poor team members.

 

[Tomix9tomix]

I think that a lot of being able to make a successful team comes from the leader or if the team mates are able to be somewhat independent. It is pretty obvious that you need a leader who is able to organise, oversee and assign jobs, otherwise things would probably not get done because the team mates might not have any direction.

However, you don't need a great leader who makes sure everyone has jobs and are doing them, having a few people who know what is going on and know the end goal would work. They would know what direction to work in and as long as they communicate enough to understand how the project is coming.

But you can't put all the blame on the leader if the plan fails, I find that is it a lot easier to lose motivation if you are part of a team because while you may be able finally be a part of something that has a chance of reaching its end goal, it may not be what you had envisioned because it is not just your project. Aspects of it that you don't like will stay as a constant reminder that this thing your working on is not what you have been dreaming of. Motivation is a hard enough problem when creating a project by yourself, but it can become even worse in a team. But the team aspect can help keep up motivation. If you are part of a team you need to do more than just discuss work, make sure to talk to them properly and learn about them. All of a sudden you will feel a lot more motivated because you will enjoy it more as you like these people more.

This thing that I just wrote may not have that many good thoughts in it, Its hard for me to talk on the subject as I'm someone who doesn't enjoy those school projects where you work in groups.
But to sum it up I guess...
-The leader plays a big part, being able to manage and organise is key.
-Team mates are also to blame, it is hard to find people who will work hard for free on another person's project. Motivation is important
-Make sure to communicate, not only so the team is in sync with development, but also because you should get to know who you are working with, it helps massively.

 

[Aki]

you can't put all the blame on the leader if the plan fails

I actually think the opposite. If a leader (any kind, not just a dev team) is going to get credit for a thing succeeding, they also get the blame when it fails.

If the team is setup in a way that there is a clear team leader making the overarching decisions and seeing the most of the big picture, it's on them to keep everything organized. It's not really any individual team members' fault if their leader has left them hanging on quality control or what to do next for the project, because acting alone and making assumptions on those things can be a waste of time at best when you don't have 100% of the information.



As for team structures...For maximum efficiency, the best team structure might be a team leader who confers with specialist members individually, but I think an isolated approach like that needs specific personality types in order to work. A team that interacts more as a group, and has opportunities to combine ideas from different perspectives is naturally going to have more morale and be more self motivating (assuming everyone gets along decently of course) .

 

[Tomix9tomix]

I actually think the opposite. If a leader (any kind, not just a dev team) is going to get credit for a thing succeeding, they also get the blame when it fails.

If the team is setup in a way that there is a clear team leader making the overarching decisions and seeing the most of the big picture, it's on them to keep everything organized. It's not really any individual team members' fault if their leader has left them hanging on quality control or what to do next for the project, because acting alone and making assumptions on those things can be a waste of time at best when you don't have 100% of the information. .

I see where you are coming from, but if a team member disappears one day because they don't want to work on the project anymore, and if that team had assigned roles, the project would be likely to fail. I feel the team leader shouldn't take the blame for that. Yes it is their job to oversea everything but I do feel like the team members deserves some of the blame too. Like I said "you can't put all the blame on the leader if the plan fails". I didn't mean that the leader should take no blame, the leader and their responsibilities is what my first bit was about. But I do feel like it is unrealistic to expect the leader to be able to predict whether the members will be able to hold their jobs or not.


I however, completely agree if your point on team structure.

 

[Aki]

I see where you are coming from, but if a team member disappears one day because they don't want to work on the project anymore, and if that team had assigned roles, the project would be likely to fail.

That's a good point; in fan game teams where there's no money keeping/attracting team members on the project, it would be pretty hard to replace an important contributor mid-development.

That reminds me of something actually, does anyone have strong opinions or even plans of what to do when a project falls through? Personally I'd like to see more devs releasing their resources for public use but it seems more often people hold onto them.

 

[Shgeldz]

The best leaders and managers will always take the blame to outside parties whenever there's a failure on the team. If you have people working under you, and a mistake happens, it's ultimately your mistake.

 

[Rhyden]

I agree with Aki on the whole leader's fault thing. Before I started working with @Sparta on anything I thought I was in a good position with a group of people who had a fair amount of concepts for a new fan game already done. The artist did a phenomenal job at designing new Fakemon and I was hard at work making some great tunes, but our leader was a definite slacker and because of that alone that whole project just died. For the (checks old music folder) 11 songs I had started with most of them completed and the starters fully designed by our artist, the leader had made one tiny, crude map in Essentials. Over three months that's all they had for show and couldn't convince anyone to stay after they had neglected their own project. Meanwhile, with just Sparta, we managed to make Steve: HoD in a month and an April Fool's game in a month simply because he reinforced the importance of deadlines (as stressful as they were) and was dedicated. Leaders don't only coordinate projects, they have to be a figure that's respected and looked up to. They're vital to group efforts in numerous ways and while they deserve so much more praise than they get, they also do deserve the blame a fair amount of time.

 

[Evan]

I do think "Soft Skills" is a bit of a misnomer--considering that half of the effort to get out a fangame is just having the perseverance to keep working to get the game playable/out, I would say these "soft skills" are actually quite important. Especially as someone who's been 'team lead' for a group of people from 2008 until today (a group of people who have had people come in and leave a ton, as fangames do), it's incredibly important to make sure that if/when you're leading a team in fangame development, facilitating enjoyment is necessary. People are only on the project because they're having fun doing this hobby, and when they're not enjoying it, or when arguments get to be too much, or when their voices aren't heard, they may leave. This is not good when they're doing an important task on the project.

The best tip I can give for people working in a team (and specifically for leaders) is to keep track of progress in things like Google Docs and make sure to celebrate progress with the team and make sure everyone feels as though their contributions are helping create your product.

I personally think I have a TON more "soft skills" than "hard skills," but I also think those soft skills have kept me happy to work on projects and develop my 'hard skills' for years and years.

 

[doof]

Soft skills? I do have some skill in being soft. But uh, yeah. I digress.

Being a team leader isn't as fun as you'd think. You see a lot of first time fan-game developers out there thinking "Oh I'm going to get a team and I'll be the leader calling all the shots and they'll love me and doing everything I say and I'll make the best game ever." If that's your line of thought, then one of two things will likely happen: You'll either never get a team and be a lonely developer, or you will get a team, but reality will bitch-slap you in the face with Thor's hammer.

When you become a team leader, you take up a lot of responsibility. You have to make sure that everyone is up-to-date on all the latest information and developments, you have to make sure that everyone is happy with what they're working on - I wouldn't want to have someone putting a lot of work into something they didn't like. You've got to be open and understanding and honest, not afraid to speak your mind when you need to. And sometimes you have to deal with situations that you might not want to.

I don't think I make a good leader, so I don't know what good traits one would have. And contrary to what @Raiden said, I absolutely hate deadlines. The only reason we had those for those two projects were because we needed to have them out on a certain day. I don't want to have to use deadlines in a project, unless we've already set a release date, but I might have do that - for me, mostly. I'm really good at slacking off and not doing anything.

But there are somethings that I do think are important traits of a leader:

-Know what you're doing. Don't be that guy (and let's face it, all of us were once that guy) who wants to put a team together right out of the gate. That's never a good idea, even if you get a team together. The leader is the one that brings it all together and makes it into one single game. They need to know what they're doing. They can't be just writing the fan-fiction and having someone else make it a game. That never works. I always cringe when I see people say "Oh, I need technical people to put it together because I'm the creative one." Don't get me wrong, I was the "creative one" too many a year ago, but I was the "creative one" who actually sat down and did the hard stuff.

-Communication. Always be able to communicate with the team as often as possible. If you know you're going to be away for a little while, let them know that. Don't just up and disappear without telling them. If a huge life emergency happens out of the blue, well, nothing can prevent that. Just get back to the team once things are back to normal and let the know what happened. Disappearing without any explanation is typically a bad thing.

-Organization. my team knows I suck at this. And up until I met Raiden I didn't really write that much down. Having a new team member meant I had to get them up to speed. And it didn't dawn on me until I started writing out the story that it was completely wacko and made sense pretty much only to me. 90% of it was changed as I went, and it's likely that, years from now when it's done, it's going to be 90% different than what we had on paper. But it's important that all team members know what they're working on, what the story is, what goes down, etc.

-Understanding that they should take the blame. This is something that I usually end up doing in real life, too. Sometimes, there are situations that the leader can't avoid, no matter how much they try. They need to be able to say "hey, that was my fault. I could've done better. I am sorry." and learn from that mistake. When you see what you did wrong, you know how to change it in the future. A good leader never says "Hey, that wasn't my fault! That was Steve's fault! We were doing fine until Steve screwed it all up!" A good leader will never point the finger at someone else.

-Kill your babies. Yup. I said that. "Killing your babies" is a term used in the TV/Movie industry that simply means "letting go of concepts and ideas that you think are prefect." When you're working with a team, you'll have a lot more opinions floating around on what is good and what isn't. And sometimes, you'll have to let go of something you really liked simply because it doesn't fit/it isn't good enough in the long run. I usually try to give each team member the chance to give some ideas on what they want to do. It's lead to some... sticky situations at times, but right now I think we're all content and willing to work on the project at hand. I've had to cut some stuff in favor of stuff that Raiden and Llama have wanted to do, but in the end, that'll probably make it better.

Well, I've typed long enough and I need to go brush my teeth now.

That reminds me of something actually, does anyone have strong opinions or even plans of what to do when a project falls through? Personally I'd like to see more devs releasing their resources for public use but it seems more often people hold onto them.

That's exactly what I'm planning to do. My original long-term project just recently, well, it didn't fall through, but there are massive changes planned for the somewhat distant future, and I do plan on just releasing everything made so far. Project files, tiles, sprites, etc, for anyone and everyone to use.

 

[Deukhoofd]

Okay so tools for communication and development in the Epsilon team is something I've spend a fair amount of time on, and I've been using several tools to make our life a bit easier.

First of all you need my three main motivations on why I do things: I want our team to communicate without issues, I like shiny new tools and I am lazy enough to not want to wait until things are done processing.

The first two motivations have lead to our current used communication tools:

• Mattermost: I've seen people in this thread mention Slack before. Slack is a nice tool and all, but having some features hidden behind paywalls was just not acceptable to us, and we did not want to spend the 5$ per user to keep more than 10k messages archived and have search. This lead us to Mattermost. Mattermost is an Open Source clone of Slack, and has almost all features of Slack. Of course this needs to be hosted yourself, but as I already had a small personal server I used for testing stuff, it was no issue to host it there. Of course, one feature was still missing: namely voice calls, this gave us our second communication tool:
• Jitsi Meet: Jitsi Meet is a really nice tool that allows for full video conferencing. It comes with several cool features, such as voice calling, video calling, screen sharing and collaborative document editing. You can use this for free here, but for privacy reasons we chose to self host it on my server, and made it require authentication with Mattermost.

To make our development process a lot faster we use two other tools:

• Git, with Gitlab: This is probably one of the most useful tools to have for collaborative development. Using Git we can easily track changes, and work on the game without accidentally breaking each others code. If we accidentally touch each others code, Git allows us to properly merge the two changes until everything works again.
• Teamcity: Okay so this reason mostly has to do with me being lazy, and specifically to do with me being too lazy to actually wait until the game is built. We have a Teamcity server set up to track any changes on Gitlab, and when a change happens it will rebuild the game. This allows us to track issues real fast (if an error exists it will not be able to build and will throw an error), and makes it so that our entire team is able to constantly download the most up to date development build of our game. This allows our testers to keep testing without having to wait on a new build being uploaded. Furthermore we have set up several Unit Tests that will run before the game is being built. These Unit Tests will run several functions in our game and will verify that the outcome of these functions is the same as what we would expect it to be. This allows us to find bugs in our code almost as soon as we've written it, which makes development a lot faster

I hope this will help some people, if you have any questions regarding any of these tools, please ask!

 

[manta]

I don't do much working in a team, but I will say that the team leader should always be the main one pulling the project along. Too many people try to form a big and elaborate team with many roles because they want others to make the game for them.

 

[Evan]

I don't do much working in a team, but I will say that the team leader should always be the main one pulling the project along. Too many people try to form a big and elaborate team with many roles because they want others to make the game for them.

Yeah, my main advice for those seeking to build a team with the intention of doing none of the work themselves (or just being a "creative manager") is this--know HOW to do all the different parts of making a game. You don't need to do it well, but KNOW the basics of understanding code, KNOW how to use MS Paint, KNOW how mapping and eventing work, KNOW all the stuff so that you can 1) be a better manager and help guide people toward a better product and 2) be able to pick up where team members left off if they leave.

 

[doof]

Yeah, my main advice for those seeking to build a team with the intention of doing none of the work themselves (or just being a "creative manager") is this--know HOW to do all the different parts of making a game. You don't need to do it well, but KNOW the basics of understanding code, KNOW how to use MS Paint, KNOW how mapping and eventing work, KNOW all the stuff so that you can 1) be a better manager and help guide people toward a better product and 2) be able to pick up where team members left off if they leave.

(I realized after writing all this out I might've take the quoted post slightly out of context, but I still just want to throw my thoughts out there, even if they're slightly irrelevant.)

My main advice for those seeking to build a team with the intention of doing none of the work themselves would be to just don't. Why should they expect other people to do work on their game when they're not doing any work on their own? After all, it is their game. It just really irritates me to see people like that - wanting to write the fan-fiction and then looking for others to carry the entire burden of development themselves. Even in my early days, I knew it was going to be really difficult, and I would've liked someone else to do all the work, but then I decided to just stop dreaming and actually make the damn game. And that's gotten me farther than trying to find a team to do it for me.

To be fair, in the right circumstances, I would say that, yeah, it could happen and work well, but more often than not - it won't. Most people won't just join a project blindly, for that matter. They look for people who are capable of actually getting the work done. Someone looking to not work would probably have a hard time getting a team together in the first place.

But I would agree with what you said. Should the situation arise, I would feel more comfortable having someone who understands the process kinda managing from the side rather than someone who doesn't know what they're doing. Someone who knows would know what is possible to do would be able to aim for goals that are achievable and realistic, whereas someone who was just taking charge on their first rodeo would probably want to do so much stuff that's just not easy or even doable (like 151+ Fakemon and multiple regions respectively).

 

[Evan]

(I realized after writing all this out I might've take the quoted post slightly out of context, but I still just want to throw my thoughts out there, even if they're slightly irrelevant.)

My main advice for those seeking to build a team with the intention of doing none of the work themselves would be to just don't. Why should they expect other people to do work on their game when they're not doing any work on their own? After all, it is their game. It just really irritates me to see people like that - wanting to write the fan-fiction and then looking for others to carry the entire burden of development themselves. Even in my early days, I knew it was going to be really difficult, and I would've liked someone else to do all the work, but then I decided to just stop dreaming and actually make the damn game. And that's gotten me farther than trying to find a team to do it for me.

To be fair, in the right circumstances, I would say that, yeah, it could happen and work well, but more often than not - it won't. Most people won't just join a project blindly, for that matter. They look for people who are capable of actually getting the work done. Someone looking to not work would probably have a hard time getting a team together in the first place.

But I would agree with what you said. Should the situation arise, I would feel more comfortable having someone who understands the process kinda managing from the side rather than someone who doesn't know what they're doing. Someone who knows would know what is possible to do would be able to aim for goals that are achievable and realistic, whereas someone who was just taking charge on their first rodeo would probably want to do so much stuff that's just not easy or even doable (like 151+ Fakemon and multiple regions respectively).

Oh gosh yeah definitely taken out of context, but that was my fault more than yours--I forgot to say in my post that once you know all the parts of making a fangame, you're not going to want to sit on the side and watch other people do it for you. That would be SO boring. You'd want to hop in and take a commanding lead, which is what you should do when youre on a project.

I guess more concise advice was: Instead of learning nothing and having others build the game for you, try instead being a leader that knows a bit of everything and has your hands inside all aspects of the fangame creation.

Definitely rule of thumb is don't just be a person who doesn't touch the game. Then you're not a leader. You're a figurehead.

 

[Djaco75]

Personally, I'm not a big fan of teamwork. I'm someone who likes to work individually. dont hate me guys.

I don't mind a little bit of help to get a small thing done, but when making a large project, I prefer to work by myself. With that being said, the Australian Education System now forces people to work in groups, so I'm kind of experienced in this area:

Discuss tricks teams can use to make jobs easier on everyone
I think that tricks people can use to make jobs easier on everyone is allocating a plan of work and then stick to it. For example, someone could be in charge of sprites. That person can't just go over to the music guy and say that he's just going to take his job. With a strong plan comes a stronger team.

Share useful tools for keep track of progress or communicating with your team and audience
I'm going to be pretty general with this one, because the possibilities are endless. Instant Messaging tools allowing the group chat function are great for communicating with teams, as well as emails, though somewhat outdated. When communicating with the audience, I would try to stick with a content release a month to let people know what's going on.

Brainstorm ways you or your team can tackle your goal in an efficient manner
I feel like the best way to do this would just be to get right down and do it ASAP. I love working quickly, and I find that the best way for me to work. For procrastinators, I think they need to allocate a work schedule in ratio to their game making schedule so they are organised and prepared to do their various tasks.

 

[SirAquakip]

Just as a preface: I'm not joking. So don't laugh.

But the most useful piece of advice I have is this: have fun. There have been many times where @Evan and myself have slaved away and away and lost track of why we were doing this in the first place. Because it's fun and we love it. At the end of the day this is a hobby and there is no money to be made (important!!), so don't stress over the small stuff and just have fun creating a homage to a video game you love. It shouldn't be a crazy ordeal, and if it's turned into one, then take a step back and reevaluate what you're doing and why you're doing it.

 

[Deukhoofd]

Just as a preface: I'm not joking. So don't laugh.

But the most useful piece of advice I have is this: have fun. There have been many times where @Evan and myself have slaved away and away and lost track of why we were doing this in the first place. Because it's fun and we love it. At the end of the day this is a hobby and there is no money to be made (important!!), so don't stress over the small stuff and just have fun creating a homage to a video game you love. It shouldn't be a crazy ordeal, and if it's turned into one, then take a step back and reevaluate what you're doing and why you're doing it.

Agreed, having fun is one of the most important things. If you don't enjoy what you are doing, and still continue you're just burning yourself out. If you ever notice you are not enjoying your work, take a step back, and just go do something else. This can still be something related to your game if you want, as long as it is something you enjoy doing. Design a website or set up a nice community for your game or something.

 

[Dragonite]

i don't actually know how to work on teams but Jayr00d made me write this anyway

I like the way Slack looks but I've never actually used it. Discord's all right if everyone takes it seriously but also makes it really easy to get sidetracked thanks to all the bells and whistles attached. Theoretically you could make a private Forumotion or some other free forum and use that to organize everything; I've never actually done that but it sort of sounds like a good idea.

Also I'd just like to take a(nother) moment to point out how wonderful Trello is for both singleplayer and multiplayer projects.

Also also it's my life ambition to make a game with a team using nothing but IRC. That sounds awful. Don't actually do that.

edit: oh by the way the far most important tool for working on a team is the person who manages to keep seven or eight people on task instead of sharing memes and rule34. i speak from experience and have no interest in trying to do that, ever again.

I actually think the opposite. If a leader (any kind, not just a dev team) is going to get credit for a thing succeeding, they also get the blame when it fails.

Blame is kind of fluid. Sure, it's the leader's job to keep everyone in line but at the end of the day the other people on the team are still real people and if everybody decides to mutiny one day there's not much the leader can do about it.