I’ve worked on many games in the past in my own time, however I have finished very few. I am now working on a quite large project with a few teammates, and I’m wondering if ya’ll have any helpful tips with leading a team.
I’m the only programmer, there are two artists, and someone else who is willing to learn animation. We all will be working on the world building, and while I’m leading game design we all have a say of how the game will work.
We have the basic design document completed, the groundwork of the game. I have started working on tools and the foundation systems of the game in Unity, and my artists are doing concept art. I am also working on the design document as I go. (On things that are important, but not the foundation. For example, the design philosophy of dungeons).
However, I am not sure what order things should happen. Is concept art truly that important in the beginning, or should we completely focus on getting the design document somewhat completed? When should animated characters be implemented, after most concept art is complete or before? The reason for this question is combat goes hand-in-hand with animation, since it’s all timed due to animated elements. However, technically it is not required.
I guess I’m just asking for tips to lead a game, those are just some examples. Any tips would be great! I’m very new to leading.
I don’t think that I can help you much, but a good practice when you are taking on any new endeavor is to keep a journal/logbook. Just jot down important decisions you made and when you made them, and then perhaps once a year review it. You can do that as a team to help figure out what works well/not well. Also, taking a few moments at the end of the day to review it can help keep up your focus and motivation.
You need to figure out all of the uncomfortable questions no one wants to deal with: contracts, who owns and owes what exactly in which case, who makes decisions on kicking people out of the team if necessary, who has the last word in each area if no consensus can be reached, how are disagreements going to be resolved etc. etc… If you don’t talk about that stuff now, I predict 99+% chance of project failure in one way or another. If you manage to figure these things out I’m optimistic you can get that number down to like 95% or so. So it’s probably a good idea to think about how you can structure your process, so that the project still has value to everyone involved, even it you don’t reach your ultimate goal of a finished game. Not trying to be a downer but you probably all know that’s how those projects usually end.
When you’re fairly certain you’ll need them and won’t make any more changes to the design that would impact animations. Also have all the technical requirements figured out beforehand. And concept art should come first of course, otherwise what’s the point?
Placeholder animations can be made to only blend between the most important key-frames.
In the past I have tried to ask for rough versions of the assets so that I can get some programming done. But since I’ve been doing that in unpaid groups, nothing ever got done and I abandoned the projects.
I’m still convinced that’s the right approach, though. Give me really rough animations and a blocky character. I can work with that and replace them with better stuff later. In fact, for non-animated things, I can just use actual blocks, or mock something up in Blender real quick. Animation really only matters when it affects gameplay.
I suggest that if your design document is more than 10 pages you may be heading down a difficult path. It’s tempting to try to capture everything before you start development, but this has flaws: No one reads long documents, and game development is an uncertain process. At best, long documents are a waste of time; at worst, they cause miscommunication when they fall out of sync with design changes.
Concept art, on the other hand, can convey in a single picture what might take several pages of text.
The previously-mentioned tips are great: keeping a logbook, settling business agreements upfront, and working with blocks (e.g., graybox levels and units) at first. Graphics too early will mask the core game design.
About leading the team, it’s a job itself. Don’t expect to be programming 100% of the time. Account for this in your business agreements. Similarly, the artists may spend long stretches waiting for you to fix a bug or implement a gameplay system. You’ll also have to be sensitive to how your teammates are doing. If someone’s not working out, you may need to be prepared to gently and fairly cut them. Communication is key. If you’re all remote, set up Slack or Discord. (And of course set up a version control system.) If you’re closer together, get together to playtest often, and to also play other games or just go out and kick back to blow off steam together. Working in a team is in some way more work, but it’s also really rewarding and a lot of fun.
Edit: Speaking of version control, always keep your main branch a playable, even if it’s significantly behind your development branch’s features. This really helps motivation. This way you and your teammates can show off the game any time, such as if friends or family drop in, or if you go to a meetup or expo/conference. Few things are as motivating as showing your game to new people.
Definitely this. I’ve run into an issue with a project (not a game) that I’m trying to update, for which I did not keep a “working” version before going in and breaking everything to build it better, where I want to use the program for stuff it was already capable of before the in-progress update, but can’t because everything isn’t fixed yet. It’s kind of demotivating and creates an unnecessary bottleneck.
Thank you all. These were extremely helpful tips!
It’s true that my teammates usually don’t read the document, honestly it’s mostly for myself, but yeah I now realize it’s mostly a waste of time. And wow, that playable branch is GENIUS! I love it!
