History

For nearly five years, the Metanet Community has been growing and progressing to the point it's at today. Drawn together by a fun little, independent game for the PC, our group has representative members from all walks of life. Gamers, artists, musicians, coders, web designers, kids who just want to pitch in; we have class clowns and intellectuals, chronic underachievers and Ivy League scholars; we have people from Asia and America, Australia and Europe, all parts of each country and all over the world. (Except South America for some reason... but Kablizzy has always had a thing against Brazil.)

But if there's one thing we all have in common (and there may be only one thing), its our love for free games. Simple games, indie games, games that the players can give back to. N became famous for its community features. The highscore board, the level editor, the exchangable map and demo formats, and the user map archive. Every level is taken to the limit by highscorers. The map archive is literally brought to the breaking point every month by the traffic it garners. As diverse as we are as people, we're still rabidly brought back to the game so we can give back to it.

The Proposal

The logical next step to this fauning over N is to try to recreate its magic in our own game.

We have serious talent in this community. We have enough experts and hobbyists to pull off a project like this. Don't start thinking that you can't help out just because you're not a master of your craft. Raigan Burns, co-creator of N, once said about game programming, "You can play guitar to be a really good guitar player or you can play guitar 'cause you wanna write songs." You don't have to learn everything there is to know before you can work on a game. If your song only uses five chords but sounds really, really good, who's to say you're not a musician?

This project is open source. That includes code, images, music, anything that goes into the game. The final product will likely be offered up for free, with or without copyright. As an open source project, we're asking you to join up and contribute. Everyone is welcome, as long as you're not damaging to the project. You'll be working on a team, so you'll be expected to compromise. And of course, you'll be expected to do some work. I've seen too many game projects crash into the ground because half the team disappears at the mention of work.

If you're wondering why we're using Assembla.com rather than just a collective public upload, it's because Assembla runs a service called revision control (specifically SVN, if you're in the know). With revision control, file histories are saved, and two users can work on the same file without overwriting each other's changes. There are SVN client programs for all operating systems that let you download all the files in the project, and update them to the latest revisions with a click.

What Will Be Expected Of Me?

First and foremost, find the team that fits your talents. You're allowed to join more than one, but don't stretch yourself thin. The mass of data for this project will eventually be pretty big, and keeping track of just one section will be challenging enough. Try to fill gaps in the team where possible. If you're both a coder and an artist, join the team of 2 artists instead of the team of 15 coders. Above all, do something you'll enjoy. Yes, there will be some grinding and some hard work, but don't burn yourself out on something just for the sake of the project.

Coders

    You may be asked to: 

• assess and outline new modules. The other team leaders will tell you what they need, and you'll break it down into functions and processes to be coded by your own team.
• learn a new language. The language will likely be chosen based on the needs of the game. Flash won't be used for a sprite game, and C won't be used for a Breakout clone.
• debug incessantly. Less bugs now means less bugs later.
• comment your code. Comment as you write. Other people have to know what's going on. If you don't have time to comment, you don't have time to code.
• work outside your comfort zone. "Teamwork" in programming means consistent code. You might have to write code in a strange way to keep in line with the team.
• help others learn what they don't know. You're here because you're a specialist in some regard. You know more than others, and hopefully they can learn from you.

Artists

    You may be asked to: 

• set the bar for style. A game's atmosphere is often defined primarily by its graphics. You will be leading the way.
• replicate your work from scratch. A game's graphics need to be consistent, and you aren't the only artist on the team. Lay out your style objectively so others can effectively copy it.
• copy the methods of others. The team leader will usually have first and final say about how the graphics look. Once a style is decided, your own work will have to mesh with it.
• be creative under constraints. Just because you're drawing to a set style doesn't mean your work has to be boring. Try to stand out while still fitting with the other artists.

Level Designers

    You may be asked to: 

• work in different magnitudes. An RPG will have essentially one very large level, whereas a platformer might have 20 or 30 smaller levels. Flexibility will help you here.
• define "fun". This is fun, but how can I recreate it elsewhere? This isn't fun; what can I do to make it so?
• finetune gameplay mechanics. What running speed is the best? Will I get better puzzles out of double-jumping or single-jumping? Why do the freaking coders keep turning down my flamethrower?
• revisit your work again and again. A game's levels are its face to the world. Whether there are five large levels or 100 small ones, they should be as enjoyable as possible.

Musicians

    You may be asked to: 

• compose to fit a scene. You might be composing based on a piece of concept art, based on a story arc, based on a general mood in the plot, or any number of other sources.
• research musical styles. If Level 2 has an Egyptian theme, you'd do well to listen to some Egyptian music before you compose. Find out what instruments dominate the style.
• offer specific criticism to others. Because everyone else can see that A-B-A-B-G-D-F is crap compared to A-B-A-C-G-F-B.
• collaborate on songs. No man is an island, especially in this project. You might benefit in surprising ways if you leave the percussion and rhythm to other teammates.

Foley (That's sound effects.)

    You may be asked to: 

• imagine what things sound like. Well, it's an alien with five spikes on its head and a pronounced underbite. I bet it grunts like a caveman.
• record your own sounds. If you can't find that sound you're looking for on the web, go pull out a barstool, a pair of shoes, a fork and knife, and your trusty microphone. 
• process and edit effects. Whether you're changing the pitch, adding reverb, or just trimming down time, sound editing experience is a must.
• live outside the spotlight. The one recurring theme with sound effects is that people only notice when you do them wrong. (At least you'll be listed in the credits.)

Team Leaders

    You may be asked to: 

• handle a sizeable fraction of the project. Each team will have a leader responsible for guiding the team. The leader should be an expert in the field, but also be good with helping people and inspiring the team to work.
• break tasks into parts. Set small, specific goals for your team. Here's a list of 18 images I need. Here are eight functions we need for calculating collision deflection.
• meet with other leaders. The artists aren't going to be skimming the coder discussion to see what image formats are acceptable. The artists won't be checking level design to see what map layouts need images. Leaders will interact with other teams so members can focus on their work.
  

Joining the Team

Anyone can view the files in progress, but editing and contributing requires registration.

There are two main ways to register. The first is to give your e-mail address to a project Owner (LittleViking for example), and you'll be invited to the team by e-mail. The other is to register an account and watch this space. That will put you on the Team page as a watcher, and the next available Owner will promote you to Member.

Once you're a member, go to the chat page and write down what role you'd like to have (Coder, Artist, Musician). Or if you send your e-mail address to an admin, you can include this info there.

Using SVN

SVN, or Subversion, is a software system used in development teams to hold a central database of the most up-to-date files. When you upload a change to any file, only the changes you made will be applied to the old file, so devlopers don't have to worry about overwriting each other's work.

TortoiseSVN (Windows)

1. Download and install TortoiseSVN.
2. Create a folder on your computer to contain the project files.
3. Right-click inside the folder and select 'SVN Checkout...'
4. URL of repository: http://svn.assembla.com/svn/metanet
5. To get the latest files, right-click in this folder and select 'SVN Update'
6. To upload changes you've made, right-click and select 'SVN Commit...'

Note: Any time you're asked for a username and password, use your Assembla account info. 

Mac OS X

Assembla recommends: SC Plugin, svnX

Repository: http://svn.assembla.com/svn/metanet 

Linux / Unix

Assembla recommends: RapidSVN, sSvn, QSvn

Repository: http://svn.assembla.com/svn/metanet

Command Line (All Operating Systems with SVN installed)

The general syntax is:

• To "check out" (download) all the files to a new directory called "metanet" (you only need to do this once):

  svn checkout http://svn.assembla.com/svn/metanet metanet

• To update to the latest revision (while in the working directory):
  

  svn update

• To add a file:
  

  svn add file.name

• To commit your changes to the repository:
  

  svn commit -m "Description of changes" 

 More information is available by typing "svn help" or at http://svnbook.red-bean.com/.