- Title: How to program a game in GameMaker in a team... for free!
- Description: A guide on how to have multiple people work on the same file efficiently while staying organized.
- GM Version: All
- Registered: No
- File Type: None
- File Size: 0
- File Link: None
- Required Extensions: None
- Required DLLs: None
If you have ever started programming in a group, you quickly ran across the problem of working on the same file from different places. How do you synchronize? Well, using dropbox and piratepad, you can do it... for free! It doesn't even require you to export resources!
This will only become a GREAT tutorial if people reply with comments! I don't know if I'm destroying your experience or creating it! Please reply! (Don't mean to sound needy)
So... you've got a concept worked out for your game, you've got the pseudocode, and you've got the people to program it. But wait... how do you do it? The GameMaker file is only one file... so how can you program with a team?
Well, I was recently faced with the same problem. I was working with another programmer on the same game, and when I changed something and he changed something, we didn't know how to merge our files. After looking around, I found a solution (importing/exporting resources). But there was another problem... we were both using GameMaker Lite, and importing/exporting resources required a Pro version. So I set off on my quest to find out how to solve this problem completely for free.
So what's the solution?
The first step is to find out how to synchronize your files. For this I recommend dropbox (or another similar cloud service). Every time you make a significant change to the GameMaker file, save it as "gamename_vXX" where "XX" is the version number (e.g. version 0.5 = gamename_v05.gmk). I would suggest not overwriting previous versions, since you never know when the code you just added might have completely messed up your game. If you have the version before you made the change, it is very simple to go back and find out what went wrong. Dropbox is a great alternative to email, since you don't have to constantly send the emails. Its 2GB free usage limit is also sufficient (even for 3D games).
But wait... how do I make sure we're not working on the same file at the same time?
An obvious problem comes up... what if you and your team simultaneously change the .gmk file? Then, when you go to upload, you'll have two different files of the same version! Well, Piratepad is a great solution (or any of the etherpad-type services). Piratepad is an online word document that is updated in real time. What does this mean? It means that if you and another person are working on the same document, and you write something, it is instantly visible on the other person's (or people's) screens. Because of this, it can also be used as an IM service. But we're interested in the real-time update part. Why? Because every time you go to work on the file, just go to piratepad and type in the following template (or improvise your own):
______________________________________________________
Name
Date
Version started
Version ended
Time started
Changes made
Changes made
Changes made
Time ended
______________________________________________________
If you want to work on the file, go to piratepad, access your document, and check if anyone else is working on it. If the "Time started" is filled in but the "Time ended" isn't, go do something else while that person works on the document. On the other hand, if nothing new is there, go ahead and fill in your message that you're working (just don't fill in "Time ended"). When you're done, put time ended. This is also a great way to keep track of all the changes you've made, and when you've made them.
How about the "Team" aspect?
So this is great and all... but how are you actually going to coordinate and do everything with a team? What if you're on a deadline (which you almost always are)? Well, here are some general tips on working with a team:
1) Team job assignments
So think about this situation: You have four members, and you want to program a game. You each follow the steps above, and get the basic setting worked out. But then, one of you makes the player sprite, and the rest of the team thinks it's terrible. But you just spent a lot of time on the sprite, since you're not very good at it. What do you do? As you can see, if every member of the team doesn't have a specific role, things can get chaotic. In order for everyone to be happy, organized, and doing the job they do best, you will probably want to work out team roles. The following roles are some that I have found helpful:
Team Leader: This is not a role in and of itself. This is an additional role for somebody on your team (generally a programmer). Most likely, this will be the person that came up with a basic idea for the game. This person should be motivated, social, and able to inspire team members. This member should also not be afraid of doing a little work and crunching down on some members that may not be living up to their full potential. The team leader's duties should include:
- Supervising work
- Figuring out a timeline (explained later)
- Motivating team members
- Deciding aspects of gameplay
- Making most final decisions about the game
- The team leader should probably work (or at least appear to) the hardest
- Visualizing the game and thus
- Being able to tell each member of the team what their final work should look like and do
- Handle the planning for the game (not completely alone, but it is up to the team leader to actually handle the planning)
(Lead) Programmer: This is the job that requires more people... the programmer(s). One of the programmers should be designated the "lead" programmer, so that if there is a question about integrating the different parts of the program or about the program itself, it can be directed to the lead programmer. The lead programmer is generally the most experienced programmer. All of the programmer(s) should know GML and... be able to program. This is a relatively self-explanatory job, but some of the duties of the programmer are:
- Note: Things marked with an "L" are for the lead programmer to pay special attention to (though for everyone to do)
- Writing all of the code for the game
- Integrating the sound and graphics into the game
- Figuring out if the game is possible, and how long it should take (L)
- Putting all of the pieces together (code, graphics, sound, etc.) (L)
- BEING PATIENT! Nothing in code EVER works on the first try!
- Debugging the game
- Uploading the newest version of the game to the cloud
- Not being embarrassed about asking for help
- Reading through the code in order to check whether it is understandable (L)
Graphics Artist: This is fairly self-explanatory, as well. The graphics artist should be very good with graphics (obviously) and have an idea of what the game will actually look like. Some duties include:
- Visualizing the game
- Managing most (if not all) of the visual aspects of the game
- Making all sprites
- Creating the color scheme
- Constantly uploading new sprites and other graphics to the cloud
- BEING ON TIME. If the programmers don't have a sprite to move, they can't do anything!
- Being creative
- Being artistic
- Making the game... look good!
NOTE: I was never a graphics artist, so if anyone has any other tips, please post them below. This will be taken down either after a month or after enough views/posts when I know that no other ideas will be put forth
Audio Artist: Again, a fairly self-explanatory job. This person should handle EVERY single sound in the game. Including sound effects. This person needs the least amount of experience with GM, so commonly audio artists will be used that actually make music as a hobby, not program. The duties are very simple, yet take quite a bit of creativity:
- Creating all of the music for the game (in the right format)
- Creating all of the sound effects for the game (also in the right format)
- Being aware of general game music aspects, and where to apply what type of music
- Making music that fits in with the style of gameplay (no classical-type music when it's a first person shooter, etc.)
- Conferring with the graphics artist about color scheme vs. audio (if color scheme is ambient, music scheme is ambient)
2) Timeline
Deadlines, deadlines, deadlines. How are you ever going to meet them? When you start a game, it seems like a LOT of work... music to be composed, sprites to be made, and gameplay to be programmed. And so little time! So how are you ever going to make sure that you meet the deadline? Well... you make a timeline. Here are some tips:
- Team Leader: You should actually write the timeline, but it should be written with the help of every member of your team. The graphics artist knows better than the programmer how long it will take them to create a certain sprite. DO NOT say that something is given too much time... if you have a faster way of doing it, suggest it. Otherwise, keep quiet. You don't know as well as the specialist how long a certain task will take. The timeline should be submitted to each member of the team for proofreading. Of course, if you actually have the problem where someone is incompetent, and can't stick to the timeline, you may need to replace them (which should be done by consent of every other member of the team).
- The timeline should be at least week-by-week, with monthly deadlines that HAVE to be completed. If your deadline is a very small time away, you will want it to be day-by-day. There should be an official check once every designated time (say... every month) where everyone checks everyone else's work and makes sure it is finished and completed well.
- At the very end, leave some buffer zones. If the deadline is a year away, leave 2-4 weeks as buffer zones/debugging zones/game testing zones/overload zones. This stops you from having all-nighters the days before the deadline in order to get everything finished. This DOESN'T mean you are less stressed about doing things on time... it's there for anything that comes up and can't be handled quickly.
NOTE: If anyone has any other tips, please comment!
Well, I hope you liked this tutorial on how to program games with a team completely for free. This is all available without spending any money at all! Programming with a team is a very enriching experience that everyone should try. The most common problem with programmers (and game artists) is that they don't know how to work with a team, and working with a team is a VERY beneficial experience. All great games were programmed by a team, simply because one person alone isn't original enough and/or skilled enough to program and design a fully functional, fun game that can be completed in a reasonable amount of time. And programming with a team doesn't have to be stressful! Just remember...
ALWAYS THINK ABOUT OTHER PEOPLE! Empathy is the greatest tool in the toolbox of an efficient team.
Things Changed:
2/12/12 Added "How about the 'Team' aspect?" section. Also added notes on where I need more comments directed.
Edited by ddan49, 15 February 2012 - 01:21 AM.
