¡Nuevo! En español. (Spanish translation by Andrés de Pedro)
GameDevLessons.com has migrated to HobbyGameDev.com - please update links!
Chris DeLeon's GameDevLessons.com Free Lessons
Vol 7 - October 10, 2009
Hello!
I'm Chris DeLeon (about me), and thank you for joining me for my monthly videogame development Free Lessons, Vol. 7. This series is one of the ways that I aim to help new game developers get started, while helping current game developers take their work in new directions.
II.) Beginner - First Time Working Together
Breadth of Skills is Useful...
...But No Substitute for Teamwork
Apply for Match-Making and Experienced Support
III.) Intermediate - Establishing a Videogame Development Club
Carnegie Mellon's Game Creation Society
If you build it, they will come (and if you don't, they won't)
Keeping project scope within one semester
Emphasize completing all games
It's ok to lose people that don't want to work
Leaders pitch projects, let members assign themselves
School credit threatens agility
Provide optional team organization resources
Give content creators creative latitude
Allow proven members to juggle roles on multiple projects
Share progress weekly, in playable videogame form
Actively recruit a variety of people
Be technology and tool agnostic
A project leader should be able to finish alone
Focus on videogames, not games
IV.) Advanced - Discussion: Is a Videogame Its Source Code?
A Brief Discussion with Jesper Juul
V.) Warren Robinett - Atari Adventure - Interview
VI.) Mentorship Now Free
VII.) Donations
To read previous editions, or subscribe: http://gamedevlessons.com/?page=free
If you would like to be notified when the next edition is available, you can join the mailing list. It only takes a minute, I will never send out more than one e-mail each month (only to announce these free lessons), and it's easy to unsubscribe at any time.
Though these lessons are not intended to be cumulative, the various topics in each may prove helpful. If you're new to these lessons, I recommend Newsletter Vol. 1 for its non-technical conceptual introduction to programming, and the links it contains to free resources for image editing, audio work, 3D modeling, and other asset creation.
II.) Beginner - First Time Working Together
Breadth of Skills is Useful...
I'm an advocate for solo game development. I encourage developing a breadth of skills. I think it's helpful for every game developer to have at least a little comfort and fluency in the tools needed for art, sound, and programming. This improves communication. This creates respect between people with different strengths. This increases freedom to develop your own ideas. This accelerates team projects by removing bottlenecks.
...But No Substitute for Teamwork
That said, strengths vary.
Knowing how to use Photoshop or 3D Studio doesn't mean someone is a good artist. Knowing a programming language doesn't mean someone is a capable programmer. Knowing how to use Fruity Loops doesn't make someone a talented musician.
Even if you can do all of those things very well, there are still advantages to working with others. Different artists do different types of art well, and learning to work with an artist other than yourself makes it possible to develop games with any type of art, depending upon which artist you work with. Different programmers enjoy different types of problem spaces, whether artificial intelligence or online multiplayer or distinctive graphics tricks. Learning to work with someone else means who you work with next can greatly vary the types of videogames you make, avoiding a creative rut.
Team members can help to keep one another on track. Much like having a partner for workouts, studying, or joining a club.
Teamwork also builds your future network. Networking with beginners may not sound like a strategy for future success, but they'll be tomorrow's experienced developers.
Connections can make a big difference.
Finding a team can be hard. When your passion exceeds your experience, it's hard to get the attention of an established team.
Making the problem even more challenging is that, without prior experience, it can be tricky to tell passion on track for success from passion on track for disaster. Everyone has ideas, and everyone has good intentions.
Just a few minutes of feedback from an experienced friend might be able to save months of trouble, or steer a team clear of a known causes of project dissolution.
|
Altogether: 2-3 people. Having that third to provide audio support, additional art, or additional puzzles and levels can be helpful. If you can find an experienced advisor to touch base with a few times over the life of the project, that's also smart thing to do.
If there's already a club of interested videogame developers in your area that you have access to, I'd suggest joining in with them. If you're in a situation to found a new organization of that sort, check out the next section in this month's Free Lessons for some tips and tricks to help increase the chances of success. If you're like most people, and you have neither easy access to a videogame development club nor a situation in which it could make sense for you to found such an organization, I'd like to help.
You're reading this section, probably, because you have some experience in at least one of the areas needed for game making (programming, art, audio), and you're ready to translate those skills into videogame making without starting from scratch in the other skills. I recently put out a call to some of the project leaders that had successfully completed projects with the Game Creation Society, to see who would volunteer to fill that experienced advisor position. I have five people willing, supporting up to six teams, since I'll be volunteering for this effort, too.
Apply for Match-Making and Experienced Support
Please e-mail please e-mail cdgdl.free@gmail.com (this is a different e-mail address than used elsewhere on my sites!) providing the following information. Maximum 2 sentences each.
|
These questions are not to judge you. These questions are not because I'm asking you to prove yourself (although practice doing that is a good life skill). These questions are strictly because the short answers to them will help me pair you effectively with team mates that have similar interest, similar experience, and, only if you're interested, with an advisor that has relevant experience.
To be clear, the volunteering advisor would not serve any sort of management, directing, or authoritative role. They would be there strictly to offer advice from experience on a few limited occasions, which you could then ignore or interpret as you see fit.
I am offering this completely for free. No strings attached, no selling of your information to anyone else, and no promotions or spam. I like helping people - a clear extension of what GameDevLessons.com and these Free Lessons files are all about. If you have friends that would find this sort of assistance useful, please let them know about it!
It may take awhile for responses to be collected, matched, and selected by the volunteer advisors. I'll do my best to reply to every inquiry. If I can't match you with an advisor, I'll at least try to match you up with others with common interests around your skill level as soon as suitable matches become available.
It can only help. E-mail cdgdl.free@gmail.com.
III.) Intermediate - Establishing a Videogame Development Club
Carnegie Mellon's Game Creation Society
While in school, I helped get a game development club off the ground, structuring its processes, setting the standards, and ensuring projects began in a way suitable for their teams to finish. That club is the Game Creation Society at Carnegie Mellon, and you can find the videogames from it at GameCreation.org.
Although that game development club was started at a university setting, many lessons learned from it are equally applicable to kicking off and growing a community of game developers, whether locally or online, whether as a high school club or among people long finished with school.
Every year, many videogame development clubs start. Many of them initiate a handful of large projects, struggle with teams falling apart as member retention suffers, and after a couple years of sliding schedules, either close down or transform into a game playing/culture club instead of game development club.
Of course, what worked for us certainly isn't the only way to do things. There are surely other organizations out there that have succeeded, doing things very differently and following very different rules of thumb. All I can say for sure is that these rules of thumb worked well for us during the first few years. I'm hopeful that others with drastically different experiences will help share learnings from their organizations, as well.
If you build it, they will come (and if you don't, they won't)
Although I developed the process for the group, and led the club for two years, I did not start it. Curt Bererton, then a Robotics PhD student and now the founder/CEO behind PlayCrafter and Cat's Cove, Curt founded the organization, writing its charter, posting flyers, building members, and running weekly meetings before he found any of us on campus that helped the group take off. He didn't kick off the organization with all of the people and resources that he needed - he kicked it off partly as a way to find them. (And what I did wouldn't have gone anywhere, if members like John Nesky and Greg Peng hadn't shown up - but we couldn't have found them without the club first existing.)
Keeping project scope within one semester
Each semester, everyone's time commitments changed. The longer a project took, the greater amount of uncertainty was involved between starting and finishing. For these reasons, we attempted to schedule every project to fit within the project it was started in. Doing a more complicated project was only possible by working faster, devoting more hours to the project, and being clever about avoiding unneccesary or wasted effort. For the especially ambituous projects, we occasionally would let experienced developers plan for a full release at the end of one semester, then a second release with additional features/content the next semester.
Emphasize completing all games
Finishing virtually every project started is terribly important. This is true even if it means encouraging less ambitious project scope, shorter timelines for greater predictability, and turning down some enthusiastic "I want to make the next big MMO" types. Nothing is worse for new member recruitment than having a spotty track record of incomplete projects, and nothing is worse for member retention than having art, audio, and levels made but thrown away. New members are attracted by the prospect of working with a reliable team, using a known process, in high confidence that their work will result in a finished game.
Vet project leaders
Each project leader had to fill out a simple one-sheet proposal, outlining what the name of the game was, how long it was anticipated to take (again: maximum one semester), what it was about (in a nutshell), and how many people of each position the project would be expected to need. We then met one-on-one for an hour or so, chatting about the project's goals and schedule. This wasn't a very strict or demanding filter, but it was an added layer of protection to help minimize the chances of otherwise motivated members from being brought onto dead-end projects started by well-intentioned but unprepared project leaders.
It's ok to lose people that don't want to work
Making videogames involves a lot of time, energy, work, and additional learning. Each year, we brought in as many members as we possibly could during the Spring Activities Fair - with as many as 100-150 people showing up at our following meeting - by focusing on the importance of having all kinds of people (artists, writers, programmers, modellers, musicians, testers...) involved in making videogames. In the first meeting or two, we explained the process, and some people would leave when they understood that this would involve more time each week than just attending the 1-2 hour meetings, and wasn't the same as simply playing videogames. This was a good thing, not a problem.
Leaders pitch projects, let members assign themselves
The project pitch was just a 15 minute powerpoint (showing concept art, spelling out project leader contact information) and speech about the project leader's initial vision for the project. The last part of the project's pitch as the leader's name, e-mail address, and a list of the minimal roles they need for the project to be made: two 2D artists, one sound person, etc. Anyone interested in those roles would then talk to the project lead after the meeting, or contact them by e-mail. If the project leader didn't collect enough members within 2 weeks of being pitched, or didn't adjust its plans to reflect the members that did join, then it wouldn't become and active project. When people aren't being paid, and aren't receiving credit, its important that they're able to work on something that appeals to them.
School credit threatens agility
One of the advantages of being a non-class/non-workplace organization is that people who are disinterested can just leave, instead of being locked in by their need for the salary, school credit, etc. At first we began to investigate the opportunity for active students to get course credit or some other type of academic recognition for their work in the organization, but after a few semesters we were thankful for the agility that came with members self-selecting based purely on their interest in making videogames.
Reach out to guest speakers
There are a collection of people in the organization that are eager to hear about videogame industry topics, ranging from recruitment talks to more experienced developers sharing their insights. Meanwhile, companies have people who devote their full attention to finding an audience to recruit from, and experienced developers are often happy to have a chance to share their stories. Establish e-mail contact with anyone and everyone that you think might make the trip - more people will say no than yes, but even one yes a year can translate to happier members, new members (guest speakers are prime events to invite non-members to drop in on), and improved networking opportunities for all. It can even lead to internships and jobs for organization members, which translates into lasting alumni industry connections.
Provide optional team organization resources
We gave every active project team a folder on an FTP server with a custom login/password, for members on the team to share files, as well as a section on a message board to keep a history of each project's discussion. These were provided as free secondary user accounts on a low-cost StartLogic.com account, using ezBoard then phpBB for the bboard system. These minimal resources helped facilitate working around asynchronous schedules for student teams.
Give content creators creative latitude
People want to show off, and get practice in, whatever style or subject they know how to do best. Projects that can accommodate this will come out better, yielding not just better games but happier members.
Weekly goals for everyone
Busy work isn't a good thing, but people get involved in hobby projects out of an interest to contribute, gain experience, and have something to show off proudly when it's done. If someone on the project team has a three week period with nothing to do, they may fade away from feeling like there's no use for them on the team.
Allow proven members to juggle roles on multiple projects
This partly addresses the above problem - while one project's need for an artist or audio contributor slows down, another project's needs may swell. This also creates a greater variety of experience in the same amount of time, and helps project completion.
Share progress weekly, in playable videogame form
Giving each project lead a chance to present the group's progress gives everyone something to push for weekly. It decreases the odds of going a full week at a time without any progress, or going more than one week with a team member lacking clarity on their next task. This also encourages focusing on visible changes, an important focus no matter whether you're trying to impress players, recruiters, or producers.
Actively recruit a variety of people
A room full of people that are experts in _____ is a room where everyone is going to incorrectly assume _____, or focus too much on _____ and completely overlook the importance of _____. Every type of expert has different words in those blanks.
Even if it's a room full of computer science people that know how to program (this was our core group with the Game Creation Society), it helps to find programmers with a variety of side interests in music composition, sprite animation, interface design, etc.
Active recruitment is also an important aspect of this. Flyers are important, but evangelizing for the cause goes a long way, as does being outspoken at fairs and other recruitment opportunities.
Be technology and tool agnostic
Some 3D artists prefer Maya to 3D Studio, or vice versa, while some others are most productive in Blender (or they may not have $3,500 laying around to spend on their hobby). Some programmers swear by C#, some prefer ActionScript 3, while others are content to script in Unity or Game Maker.
Whatever tools and technology platforms that people know best, welcome them to use those platforms to their fullest extent. At the end of the day happy members and well-developed content will go further. Giving people freedom to teach themselves new things is awesome - but forcing them to teach themselves new things is what their classtime is for (!).
Minimize Content Bottlenecks
Role-playing games and adventure games are scary. No matter how simple they look, they require (at a minimum) dozens of pieces of enemy art, level layouts for dozens of cities, outdoor areas, and dungeons, balanced stats/prices/art for a wide variety of items, several emotionally intense songs, and countless pages of strangely paginated written dialog for dozens of characters. It probably needs at least a minimal in-game scripting engine, too. After I had been making videogames for seven years, I was able to lead a small team to make this really weak, limited RPG. That isn't offered as encouragement, but as a warning.
Side-scrolling beat-em up games and platforming games also involve a huge amount of animated art. Variety in badguys, bosses, and backgrounds are what compel people to keep playing them.
Some types of videogames scale much better, and don't require mountains of different art - especially puzzle or action games that take place in non-scrolling/one-screen levels. When beginning teams present their first projects, it's best to favor games that will be able to efficienty reuse content in different combinations, and get away with minimal content. Not only does it improve the chances of that particular project succeeding, but it prevents any one overly ambituous, epic project from gobbling up all of the club's content creators into a black hole that (likely) won't turn into a finished game.
A project leader should be able to finish alone
People will leave the organization. People will leave teams. No matter what people intend, and no matter how nicely everyone is treated, things will change, and priorities will shift. To the outside world, it's very important that the club maintains a reputation for finishing its games. Internally, this means it's very important to the club that project leaders ensure that the game they start gets finished. This requires that project leaders have at least minimal fluency in digital art, programming, and finding/editing/making audio for use in the game, such that if everyone else left the team, it could be finished, even though it may not look or sound as good as was intended. This accountability further motivates project leaders to keep their project members content, and to seek replacements any time project members leave the team, since work they can't get someone else to do is work that becomes theirs.
The demo is the game
As a scheme for scope reduction, one thing we did to help reel in project scope during pre-pitch meetings was to ask the project leader what is the minimal amount of functionality and content they would need to create a demo for the game.
Since it's a portfolio and experience piece for the team's project members, this demo size is about as much content as most outsiders will digest. Making a larger version of the game would have diminishing returns on learning, in addition to increasing the odds of the game never being completed. And a videogame that isn't completed isn't a videogame to the outside world.
In consideration of this, we adjusted plans, content, team size, and story for the "demo" sized version to be the finished game. Before the project was ever pitched or started.
(This has the unintended side effect of increasing believability and buy-in from members to the project pitch. When someone tries to entice members to join their project that is planned to have 20 worlds, 30 weapons, and 16 main characters, no one takes a pitch like that seriously.)
Focus on videogames, not games
A club that tries to be for everybody is a club that works for no one. A board game, dice game, tabletop/D&D game, casino game, sports game, game show, game theory, or Conway's game of life club is not a videogame development club. Even if those are things that may appeal to some categories of videogame designer, they're less likely to appeal to 3D artists, software engineers, dialog writers, playtesters, animators, music composers, sound effects specialists, and the whole host of other skills that go into hobby and professional team videogame development.
Welcome members that have an interest in those things, just as much as members are welcome that have interests in programming operating systems, animating feature-length films, and writing novels. But keeping it clear that the organization is not there for pitching, producing, and networking games other than videogames, just as much as it isn't for film making or novel writing, helps keep the core strong.
Be ready to adapt
Depending on who the organization's leaders are, what the project leaders want to make, the rules of thumb will need to be different. How established the club is will also lead to huge changes in organizational needs - a young club is battling aggressively for growth, credibility, and clarity, whereas a more established club does well to focus on retention, visibility, and stability. I'm good at the first 3 of those 6 ideals, and I struggle with the latter 3 - which is how I knew when it was time to establish officerships and transition to new leadership.
IV.) Advanced - Discussion: Is a Videogame Its Source Code?
A Brief Discussion with Jesper Juul
Games are made of rules. Videogames are not.
That is at the center of the discussion I had with well-known videogame professor Jesper Juul, based on his old blog post that I ran into through Ian Bogost's DiGRA 2009 keynote.
It began on his blog: My initial discussion of the question.
The bulk of my argument is presented here: My prepared arguments on the subject.
V.) Warren Robinett - Atari Adventure - Interview
In the foreward to The Video Game Theory Reader, Warren Robinett, the man who invented the action-adventure genre of videogames in his mid-20's, mentioned that the people who built the conceptual foundations of our industry - our medium's versions of Bach, Plato, Shakespeare - are still very much alive today. Insofar as we're full of questions that we would love to ask the innovators of other fields, we shouldn't take this fact for granted; we owe it to the future generations to interview these people. So I did!
Check out the interview with Warren Robinett, creator of Adventure (first action-adventure game) and Rocky's Boots (one of the first megahit educational games).
At this time, I am no longer charging for teaching and feedback. I just want to help people as much as my time allows, and realize that need has no correlation (or possibly a negative correlation) to money. There are six questions on the application page, each requiring no more than a two sentence response, to apply.
If no one applies, no one gets free guidance outside of these newsletters. If you're the only person that applies, you'll definitely get free guidance. If you're one of many that applies, I'll either provide as much help as I can, or at least see if I can help you network with others around your skill level. Surely the chance that this could make a big difference is worth writing 10-12 sentences!
These Free Lessons are developed to help the community, and I like writing them, although they are very time consuming. If you find these lessons valuable, and can afford to make a small donation of $10, $30, or more to show your support, it would be greatly appreciated and help me continue setting aside the time needed to keep quality a priority in the free lessons. PayPal makes the transaction safe and simple - you don't even need to have a PayPal account if you have access to a credit card!
Chris DeLeon
PS I am writing this newsletter series to help people, and I want the contents to reach as many people as possible. Please pass along this link if you know someone that might find this useful: http://gamedevlessons.com/lessons/letter7.html Sending the link works better than copy/paste, since that way they'll see the latest updated version with Q&A or corrections.
PPS If you'd like to be kept up-to-date with these monthly mailings, simply subscribe to the GameDevLesson.com Free Lessons: http://gamedevlessons.com/?page=free