WARNING: Wall of text approaching!
From my experience as an IT consultant, I would break down the skills into 3 categories:
- Design skills
- Project Management skills
- Technical skills
Technical skills are the most clear-cut. They are your programming and art skills and experience. Can you create, rig and animate a model? Do you know how to use the level editor? Are you familiar with the intricacies of C++ and the UE4 code-base?
The importance of technical skills I would argue are inversely proportional to the size of the team, being critical if you’re in a small team or one-man-band and inconsequential in a large team. The main reason being that in a large team you won’t have time to actually do any development as you’ll be engaged in organisation and making sure the team is on track, and you’ll have people to do those tasks already. In a small team however, people will expect the project manager to lead from the front and make a material contribution, especially in an amateur setting.
Project management skills are the ability to manage the project lifecycle and ensure that everyone on the team has what they need to do their job. This is the hardest skill to “learn” as much of your ability is defined by experience. As the team size grows this becomes a very demanding role, which is why technical skills start to take a backseat. Ultimately your job is the following:
- What do each of my team members need to do their jobs?
- How do I ensure they have it?
Things your team need are of course direction. What do they need to work on next? This is important as you don’t want your artists duplicating effort by accidentally working on the same thing, or focusing too much on one area and neglecting other important ones. Then they need an organised process. What change management tools are you using, do they know how to use it? The last thing you want is your team treading on each others toes, overwriting each others work, pushing commits to the wrong branch and so on. You also need a fast turn around, a disorganised project can easily discourage people as they get fed up of weeks passing before they see their contribution in action, or not having a proper road-map so they can see how far they’ve come and how much further they have to go. Finally they need support, if someone is struggling with something then why are they struggling? What do they need you to do to resolve their issue? If you can’t resolve the issue, what work-around can you come up with to help?
I would argue that you want to be familiar with tool-sets like Github and SVN, and the UE4 engine workflow. Note that you don’t need to be an expert in programming or art, as that’s what your team is for (unless it’s a small team as mentioned earlier). But the team will expect you to worry about setting up the necessary working environment and it definitely helps if you know the workflow from getting a rigged model into the engine for example, even if you don’t know the actual technical aspects of rigging and animating.
Finally we have design skills. By these I mean the core game mechanics, rather than the art style which is a separate matter. Design is all about the numbers. How many times do your players die on average at a particular point in the game? What is your difficulty curve like? For this it helps if you’re a bit of a stats nerd and have an analytic mind. Essentially you need to understand what data you need to collect, how to collect it and how to interpret it. If you’re designing a UT level, you might want to capture stats on where your players spend the most time in your map. If the players are spread evenly out across the map, that might be an indication that the map is a little dull with too much downtime as players try to find each other. If they tend to congregate too much in one or two points and ignore the rest of the map, that might indicate you have too many choke points and players tend to camp and hog the resources. The secret is to set up play test sessions with a very clear goal in mind for what you want to learn, whether its map flow, difficulty curve etc. and ensure you have the means to capture the right information for later analysis.
Sorry, I know you said “in a few words”, but making games isn’t quite so simple, there’s a lot to it. That’s why so many projects fail!