Meetings and Scheduling

Once you have assembled a capable team and completed all of your project planning, it should be time for your first meeting. The first meeting is the toughest; it’s all about explaining the specifics of the project and what exactly they’ll be doing, without scaring them off. For my first meeting for Delirium, we held it in one of the classrooms at the school, so I could use the projector. I put together a slideshow that had a lot of specific information, and I elaborated on things throughout. To be honest, though, I don’t think the meeting went as well as it could have. If I had the chance to redo that first meeting, I would have ditched the slideshow, gathered all the new recruits around a large table, and simply talked to them about the project. I think that this would have been much more effective, since, well, let’s face it, slideshows are usually pretty boring. Plus, anything you can do to break the ice between everyone is great; after all, these people are supposed to be working together, so let them get to know you and the rest of the team. Team dynamic is very important, so try to bring it out during that first meeting. Of course, you still need to talk about the specifics of the project, but this way, everyone should feel more comfortable, especially if they have any questions. It’s also important to get contact information from everyone during this first meeting. I actually relied too heavily on those online applications I did, and not everyone filled out all the contact information properly. Be sure to get phone numbers, emails (we each have a school email and a gmail), Skype accounts, and anything else you might be using. If people have multiple emails, ask which one they want everything sent to. Once you have all of their contact information, you can start adding them onto email lists and your project management tools.

While the first meeting might be the most difficult, it’s certainly no small task to schedule additional meetings. I asked all of my team to send me a copy of their school and/or work schedules, which I then used to determine what days and times were available to the most members. Finding meeting times that work for everyone is a challenge, but you should be able to find at least one or two days that work with everyone. For Delirium, the biggest problem we had with scheduling had to do with the fact that we had distance students on the team, and they happened to be in a different time zone than the rest of us. If some members aren’t able to make it to your meetings, then take some one-on-one time with them to make sure they stay in the loop. We also published notes from each of our meetings on Assembla, which is the project management tool we use. The key is to make sure that as many members as possible can make it to your meetings, and in case anyone can’t make it, be sure to keep them up to date on what’s going on.

Speaking of meetings, it’s definitely not okay to just have one meeting a week. Originally, we started off with having two meetings a week: one for updates on the project and to check up on our progress, and another to do planning and actual work. As it turned out, this wasn’t enough, so we decided to set up another meeting specifically to work on the game, along with a separate lead meeting to make sure it didn’t interfere with any other meetings. This change was reflected in the actual game, and by setting aside a specific time to do nothing but work, we were able to produce better quality assets in a reduced time frame. Furthermore, it also helped improve the team dynamic, motivation, and communication, as it is easier to talk to your leads in person than it is through email. The number of meetings you have for your team is totally up to you, but I recommend having at least two to three, with one being a work session and another for a lead meeting. Also, it is important that everyone on your team knows what days, what times, and where you meet. We have all of this information on Assembla, so all team members can easily access it, and I usually send out reminders through a group email. If a meeting gets cancelled, be sure to let everyone know at least two hours before the meeting, if not sooner.

Communication

Communication is, by far, the biggest challenge you will face as a project manager, producer, or lead. This is why it is so important to get your team’s contact information early on, and make sure that you have the most up to date information. We keep a list of everyone’s contact information on Assembla, which allows each team member to update their own information if it has changed. As for communication methods, we utilize email (mostly gmail) and Skype for anything that isn’t in a meeting. I send out weekly updates on the progress of the current build, and I usually send an email for things like reminders, sprint retrospective surveys, questions/answers, and anything else that the team as a whole needs to hear about. I don’t recommend sending out too many group emails, as your team might get tired of them and not even read them. For group emails, try to keep things short, simple, and, if you can, exciting. It’s also important to always remind your team of how great they’re doing, and you never want to come across as rude or demanding. If you have to tell someone something important, try to do it in person if you can, since emails, no matter how nicely written, are never a substitute for hearing it with your own ears.

Despite how well you may be communicating with your team, they might not always respond to you. Not everyone has great communication skills, but let them know when they join your project that you are treating this as professional environment, and that communication is critical to the game’s success. If you need to get an answer out of someone, try talking to them in person instead of through an email. This way, you can get the answer you need in a timely manner, and either of you can ask additional questions if there are any. If you do have to send an email, though, be sure to ask for exactly what you need to know (don’t be skimpy on details!), and specifically tell them that you need a response from them. On occasion, I’ve found that some members don’t respond back if they don’t think they have to, so if you want a response, just let them know. Furthermore, if there’s time sensitive information, put something like “important” in the subject line, and tell them when you need a response by.

On every project, though, there are always “problem children.” I’ve found that, on Delirium, these people were the ones who never, or rarely, communicated. I’ve had a few members simply disappear off the grid; we weren’t sure what they were doing, or if they were even on the project anymore. Of course, people get busy, so try your best to get in touch with them and find out what’s going on. If their schedule is a bit too crowded, try minimizing their workload and making sure that they check in at least once a week with their lead. Do your best to work with them to resolve the issue; you might even find that they simply didn’t know that they weren’t communicating properly. Sometimes, lack of communication can be resolved fairly easily, but other times, it gets to be a serious problem. If you’ve tried working with someone, but they still aren’t communicating, it’s probably best to set up a meeting with them, in person if possible, and explain why their lack of communication is hurting the team. If you have a producer on the team, I’d recommend having them attend the meeting, as well as that member’s lead. Clearly explaining why they need to communicate with everyone will usually resolve the issue, but not always. If they still aren’t communicating or doing their share of work, you might have to let them go (depending on other circumstances, too, of course). It’s an unfortunate thing to do, but if they aren’t contributing and keeping involved, they are only going to bring the team down with them.

Team Feedback

In order to properly maintain your project, you need to know what is working and what isn’t. It sounds simple enough, but most of your team isn’t going to just tell you outright. On Delirium, I set up sprint retrospective surveys, which I would send out to the team at the end of a sprint or milestone. Each survey had the following information, which was used to help me figure out what could be improved upon:

• Name: If a member is having a problem that is specific to them, you need to know who it is in order to remedy it.
• How well do you feel this sprint went overall?: They simply had to pick the answer that they agreed with most; answers were poor, adequate, good, and excellent. This gives you a good overview on their opinion.
• How did you feel about the amount of work assigned to you?: This question is similar to the last, with the answer options being not enough work, just the right amount, and too much work. This lets you know how they felt about their workload, and can help you to adjust everyone’s workload for the next sprint.
• Rate yourself on how well you did on the following: Each member is able to rate themselves on their communication skills, logged hours, and completed work. This gives you an idea of how well they personally think they are doing. It can also tell you who isn’t doing work, as they will either say it or try to lie (you can check this against your own records and project management tool).
• Rate your lead on how well they did on the following (Leads, rate your team): This question is the same as above, but instead of rating themselves, they are now rating their lead (or team if they are a lead). This can give you good information on if your leads are doing their jobs correctly, and can also sometimes reveal if a member does not like their lead (as they will rate them poorly, despite the lead’s best efforts). If the lead fills it out, you can get an idea of problems and/or successes they might be having when dealing with their team.
• Rate the entire team on how well they did on the following: Again, this question is the same as the above two, but gives insight on the individual’s views of the rest of the team. It can tell you if they want to see more or less communication, and how they feel about the overall work that the team is completing.
• What went well during the last sprint?: Unlike the other questions, this and the following ones require the member to write something. This question is important to understand what they think is going well, which you can bring up at your next meeting and praise the team for their efforts. It’s imperative to highlight the positive aspects of the project, and not just the negative ones.
• What could be improved upon from the last sprint?: This question is basically the opposite of the previous, and lets you know what you and the team as a whole can work on for next time. Plus, you might find some good suggestions for improvement here! I’ve also found that if a team member is having a specific problem, this is usually the spot they put it, and it tends to have the longest answer.
• Problems/Issues? Additional comments, questions, or suggestions?: This last question is usually left blank, but I have seen a few answers here, such as suggestions for improvement, comments about problem members/leads, and even problems the person had with the actual game. If it is filled out, be sure to carefully read it and follow up with the member to learn more, and, if there’s a problem, work on solving it.

Team feedback is extremely important, and I’ve found that having these relatively short surveys at the end of each sprint helps to find and eliminate problems. More importantly, if you find any problems or suggestions, you need to take the initiative towards resolving them. If your team takes the time to fill out a survey that doesn’t change anything, they aren’t going to waste their time doing them anymore. The purpose of the survey is to get information that your team might not otherwise state, and use that information to better both the team and the project.

Maintaining Motivation

After the first few weeks or maybe months, your team is probably going to start losing motivation. It happens to the best of us, but it certainly doesn’t mean it’s the end for your project. There are a lot of little things that you can do to keep members motivated, including workshops, overall and individual praise for team members, bringing in snacks to a meeting every once in a while, letting them actually play the game, having small parties/celebrations when a milestone is completed, and just letting them know how great they are. Both the art lead and tech lead on Delirium have hosted workshops to teach their team some cool new skills, and afterwards, those members were ready to put those new skills to work. I’ve made cupcakes and cookies for the team several times, and after big milestones, I usually cancel a meeting and let them take the day to relax. Praise, too, is always important, and everyone likes to hear that they’re doing good work. Even if they aren’t doing the best, let them know that they’re still doing well and that you appreciate their hard work. Sometimes, constructive criticism can also be a good motivator, especially for artists and designers, since they are usually looking for ways to improve their work. Just be careful not to be too critical, and always point out the things they did well first. Another thing you can do to both improve team dynamic and boost motivation is to get the team together in a non-work environment. Try to just hang out with your team and keep from talking about work; get to know your team, and ask them how things are going. Remember: making games might be a lot of hard work, but that doesn’t mean it isn’t fun, too.

As a final note, I think it’s important to bring up how to maintain both communication and motivation over breaks. I only started up the Delirium project in September, 2011, so this winter break was the first real time apart the team has had from each other. If you’re working on a student project, there is no way of getting around winter break (or summer, if your school doesn’t go year round). What we did was have a meeting before the break started, and I let everyone know that all of the leads will be open for communication if anyone wants to do any work, and that there would be work in the backlog that a member could work on if they wanted to. We made it clear that we weren’t going to interfere with anyone’s break home, but for those who wanted to continue working, they still could. When we returned for the spring semester, not much work had been done, but some is always better than none. If you want your team to keep working over the holiday break, you need be very clear that you do, give them specific assignments (nothing too big), and check in with them via email or Skype every week or two. Either way, when your team returns from break, make sure they are still able to stay with the team, and get them back in the swing of things as soon as possible. If you let them sit around for too long, they probably aren’t going to want to do much work, so set your first sprint up and let everyone know that it’s time to get back to work.

Thanks for reading, and I hope that this has been informative! If you have any questions about this or the first part, feel free to ask me!

• 5 Quick and Easy Photoshop Textures You Can Make From Scratch
• 30+ Best Texture Tutorials for Photoshop
• 77 Essential Photoshop Techniques for Photo-Realistic Textures
• 5 Ways to Create Textures Completely in Photoshop
• Texture Tutorials from CG Textures (open the Tutorials link at the top)
• This one isn’t from scratch, but is definitely helpful when working with pre-made textures or images: How To: Creating Seamless Textures with Photoshop

Bonus! If you’re interested in creating textures for 3D models/static meshes, check out this tutorial by lead texture artist Daniel Vijoi: Creating Next-Gen Textures

Thanks for reading, and keep a look out for my Textures and Materials in UDK video coming soon!

Project Planning

Lots of people have game ideas, but the majority of them never take the next step towards executing them. If you’re serious about making your game, then the first thing you need to do is figure out how you’re going to make it. Planning is an important part of any project, and it’s no different for video games. Long before you can even begin development, or pre-production for that matter, you need to set specific goals for your project, come up with an estimated time frame, determine a target audience, do risk and cost analysis, and recruit a team. Creating goals for your project should be one of the easier tasks, as you should already have a good idea of what you want the game to be. If you set up clear goals early on, it will make it much easier to get across to your team, once you’ve recruited them. I’d recommend creating a one-pager, which is literally a one page document that lists out what you want in the game in bullet points. When doing this, don’t just list a bunch of cool design aspects you want in your game; list out what the whole game should look and feel like when it’s completed. You should also define your target audience here, as it will help to shape what your game will be. If you do make a one-pager, you can even send this out to your team members to help them understand what needs to be done.

Next, you need to establish a time frame for the game’s development. I started by listing out the phases of development for my project: pre-production, prototyping, development with alpha and beta builds, polishing, playtesting, marketing, and release. Then, I estimated how much time it would take to complete each of those phases and created a Gantt chart. While you don’t have to create a Gantt chart, I did find that it was helpful to see an actual schedule and how things like holidays might affect the time frame. A time frame is a helpful tool for scheduling milestones, sprints, builds, etc., as well as for the recruiting process. If your time frame is looking pretty lengthy, then it may be a good indicator that you need to cut down your scope. For my project, my initial time frame was one to two semesters, about eight or nine months, granted that my project’s scope isn’t very expansive. Many of you are probably looking at close to a year for your time frame, and that’s typical of most game projects. 

Now that you’ve got a little bit more of your project planned, it’s probably a good time to try and find a producer. I originally took this role, which stacked on top of my project manager and lead designer duties, so I found that I didn’t do a very good job of this. Once I did bring a producer onto the team, it was extremely helpful, and I’d recommend finding a good one and having them help you out early on. A good producer will help you with all of your project planning needs, including risk analysis and cost analysis if you’re going to sell the game. If you can’t find or decide you don’t need a producer, you can certainly do this yourself, but if you’re a designer like me, you’ll find yourself more inclined to do design work and might neglect some important project planning. Either way, you should be using this time to prepare for development and set up goals for your project. Before you begin recruiting your team, you want to be sure you have everything set up and ready to go. If you plan on using any project management tools, such as Assembla, or a Wiki, take the time to get them working. If you can, go ahead and start writing on a design document, as it can help both during and after recruitment. If you have any ideas about art or sound direction, write up your ideas into a document so you can show prospective artists and/or audio designers what you’re looking for. If there’s anything you can do that will help your team be better prepared when it’s time for development, you should do it before recruitment. Prospective team members are going to have lots of questions about your game and what you want to do with it, and if you did your planning properly, you should be able to answer all of their questions with ease. 

Finding Team Members

Let’s face the facts: you probably can’t make this game all on your own. You’re going to need a team, and you can’t expect them to all just magically appear and start working on your game. Instead, you need to recruit a team of able-bodied, talented, and hard working individuals. To start with, think of team size. For my project, I wanted a team of roughly ten people, but you may need more than that depending on your game’s scope. When estimating team size, consider the scope, the project length, and the general amount of work that will need to be done to reach your goals. Don’t forget to include yourself in that number, since you are part of the team. Once you have a good idea of how many people overall you want on the team, break it down into a hierarchical structure to help you better assess how many of each discipline you need. Below is an image of what my initial structure looked like:

Using this hierarchy, I was able to divide up my team size among each discipline. I was taking the role of lead designer and producer, but I determined that I would need one to two other game designers, one art lead, one tech lead, one audio designer, two artists, and two programmers. At the time, this sounded completely feasible, but these numbers did shift. My current team size is roughly fifteen, with a producer, two designers, an art lead, a tech lead, an audio designer, five artists, three programmers, and myself as the lead designer and project manager. Remember that the team size you come up with is just an estimate, and if you fall short during development, you can always recruit more people where and when you need them.

Now that you have a pretty good estimate of how many team members you need for your team, it’s time to start recruiting. There are a number of ways you can go about this, so it’s really up to you. For my project, I created a recruitment blog, which contained information about the game, what the team would be like, a time span, and more. I posted the link to the blog on various social media sites and on my school’s forums to help spread the word. Having a web site to direct people to made it much easier in the recruiting process, and it  answered many of the questions they might have had otherwise. The other thing I did with this web site was job postings and the ability to apply directly from the site. I looked at a bunch of actual job postings from various studios, and based my own off of those. It made the overall project look more professional, and helped to weed out the slackers. I had job postings for game designers, an art lead, a tech lead, artists, programmers, and an audio designer. I got a lot of positive feedback from those who looked at the job postings, and many told me that it helped them to understand exactly what would be expected of them if they joined the team. I also included a form on the site that allowed those who were interested to apply for the desired position, which meant that the main questions I had for them were answered when they applied. After I received their application, I sent out a follow-up email, and if I thought they would be a good fit for the team, I set up an interview with them. The interviews were rather casual, but it helped me to get to know everyone and gave them the opportunity to ask additional questions and show off their work. Overall, this process seemed to be well received, and I’d definitely recommend doing something similar for your own project if you can.

As I mentioned before, there are a lot of different ways you can go about recruiting a team for your project. No matter what methods you use, there are a few things to keep in mind:

1. Never lie or offer incentives you can’t deliver on.
2. If you do have incentives you can offer, be sure to mention them (portfolio piece, internship, etc.).
3. Be sure to state exactly what you expect of prospective team members.
4. Don’t expect everyone to come to you; it’s your job to find people.
5. Look for people who are willing to stick with the project, and won’t just drop it if times get tough.
6. For leads, look for someone who has good leadership and communication skills.
7. Don’t recruit friends unless they are serious about working.
8. Look for people who are passionate and driven, even if they are lacking some of the skills.
9. Don’t just look in one place for team members. Use a variety of methods to spread the word about your project.
10. Don’t be discouraged if you don’t get any applicants at first; keep working at it!

For my project, I initially only got about three applicants, all of whom were artists. It did feel a little discouraging, but I continued to spread the word, and I did receive more applications in the following week or two. Once more people started hearing about the game and became interested, more and more applications came in, which eventually forced me to reject some people, simply because we didn’t need any more artists or designers. There were two areas we had difficulty in recruiting, which were for programmers and an audio designer. Luckily, we were only starting with pre-production, so we didn’t absolutely need them. I did manage to find a programmer who was interested fairly early into the project, and he actually took the role of tech lead. With his help, we were able to find the other programmers we needed, so don’t forget that your team members know people who might be interested, as well.

That’s it for part one, but keep an eye out for part two, coming soon! Feel free to ask me any questions, as I’m always glad to help out! I hope that this post was helpful and thanks for reading.

While you’re waiting for my videos, why not check out some from Unreal University? The Unreal University sessions from this year’s Montreal International Games Summit are now available on the UDK youtube channel. There are nine videos up currently, and I definitely recommend checking them out (plus, they’re free!).

Check out the videos here: Unreal University Sessions

Since we’re on the subject of UDK, the October 2011 build is available for download! You can download it straight from the official UDK site, and since it’s what I’ll be using for my videos, I highly recommend getting it soon.

No matter who you are, there will always be at least one point in your life when you have to do something you don’t want to. When trying to get into the game industry, you’ll likely find yourself with an entry level position working on a game you would probably never play. But just because you wouldn’t play it, doesn’t mean no one would play it. Every game has its own audience, and it’s that audience that you’re making the game for – not yourself. So how exactly does one make someone else’s game? At the beginning of her presentation, Laralyn presents that same question, only to pose a second, better question right after. Instead of asking yourself how to make a game you wouldn’t play, ask, “how do you motivate yourself to make this game?” Even though you may not want to make this game, it is still going to get made, so you might as well motivate yourself enough to make it a good game. She then provides six steps towards motivating yourself and making the game the best that it can be:

1. Do your research.
2. Meet the competition.
3. Meet the players.
4. Put something personal in it.
5. Involve the team.
6. Get a hobby.

Don’t dismiss a game just because you don’t like or understand it.

- Laralyn McWilliams

You are a game developer, regardless of what you’re working on…

It’s not about what I want; it’s about what the audience wants.

- Laralyn McWilliams

Don’t change your games, change yourself.

- Laralyn McWilliams

For those of you who might be interested, I’ve assembled a team of about ten to fifteen people to work on a 2D horror game called “Delirium.” We’ve been working on the game for a little over a month now, and will have the first two levels working by the end of this month! We’ve started a development blog for the game, which you can check out here: www.deliriumgame.wordpress.com . The rest of the team and myself will be posting about our progress on the game there, so be sure to check it out from time to time! Thanks for your support!

In the mean time, I thought I’d talk a little bit about prototyping tools for game designers. As designers, it is our job to clearly describe the game’s vision, but sometimes, it’s just too difficult to do with words alone. Sure, you could use mock-ups or graphs to help get your point across, but every once in a while, it helps to just show everyone on the team exactly what you’re looking for. This is where prototyping comes in, and if you don’t happen to be very good at coding, digital prototyping can often be a difficult task. Fortunately for us, there are tools we have at our disposal! Many of you have heard of, if not used, Game Maker, which is a great tool that makes prototyping a breeze with its drag-and-drop coding. As much as I love using Game Maker, there is, however, a newer tool that takes what Game Maker does and builds on it. I’m talking about Stencyl, and while I haven’t used it much, it seems to be a fantastic prototyping tool. It retains the simplicity of usability that Game Maker has, while also allowing you to easily collaborate with a team. And don’t worry: you still don’t really have to code! Stencyl features an interesting little snapping code system, where you can snap blocks of code together to form strings… think Kismet meets Game Maker. There are a lot of cool features, so check out their web site for more information and to download the free tool!

http://www.stencyl.com/

This is the tool my team and I will be using for our prototyping needs, and I highly recommend it to any other game designers. You can even use it to create iOS and flash games, if you want it for more than just prototyping. That’s all I’ve got for today, but I’ll be posting more soon. Also, if you have any suggestions for my next UDK workshop video, let me know. Thanks for reading!

Visual Scripting in Kismet Video

I’m starting to get the hang of making these videos, and I managed to get my hands on a better mic, so hopefully the quality is much better this time. I think next time I’ll be adding in some extras to go along with points where I’m just talking and not actually showing anything. Also, I’ve been receiving some comments that the July beta has some changes that make the first video confusing, so I’ll be working on some notes after I get back from PAX Dev to go along with the video for those using newer versions. Remember that UDK is updated every month, so little things may change from time to time.

Enjoy the video, and let me know if you have any suggestions for improving them or for the next one I make!