The Asynchronous Collaboration Game Challenge, Part I (Rules)

LibrarianBot
Feb 6, 2010
11:04pm
2D and 3D elephants making music

This post is way too long! Just read the bullet points at the end.

Our next challenge is a two-parter! In Part I, you are tasked with designing your game's gameplay and assets.

In Part II, you are tasked with coding together someone else's game, but we'll worry about that in a few weeks.

Does the prospect of making a game without learning to code appeal to you? Well get your head out of the cloud, buster, it's not as easy as your daydreams make it out to be. There are some barriers, technical and human, which you need to deal with.

The Technical (or: The Rules)

To be eligible to compete, and to be awesome, your game must incorporate at least two of the following keywords: animalsfood, future, and snow. How you incorporate them is up to you!

Here's the tricky part. If you want something in the game, you have to make it yourself. Do you want your guy to be able to run and jump to the left and the right? If you don't want your game looking like Karoshi, where the main guy is facing forward the whole time, you have to draw all of those pictures! Don't worry, it doesn't take as long as you fear. I drew this guy in a minute: low-quality walking animation Imagine what you can do with ten minutes.

If you have a grander vision, however, you are welcome to team up with people. Teams can be up to three people in size. Have one person draw the backgrounds and one person draw the sprites and one person compose the music, I dunno! (You can also make THREE DEE MODELS, if that's your thing.)

That's one reason you should bring stuff you've made to the next meeting: you can see who's interested in what and team up with people who complement you. Don't worry if you suck at everything; all of us suck at everything! That's why we're in college.

The deadline for this thing is March 2nd. Establish your vision by then.

The Human (or: Protips)

You'll want to make your game design as detailed as possible. Otherwise the programmer could misunderstand your vision! Make sure you write down exactly what you have in mind. Draw levels on graph paper, specify speeds of things in pixels per second, write down text exactly how you want it to be worded. Coding a game is hard work; the programmer has enough on his plate without having to make arbitrary decisions all the time.

Remember, though, coding is hard. Keep your game simple. If you make your game design too complicated, the programmer won't have time to finish it all—he might just pick the funnest subset of your game to make, or worse, skip it entirely! Take a look at some existing games we've made to get an idea of what a reasonable scope is.

tl;dr:

  • Form teams of 1 - 3 people to design a game. People cannot be on multiple teams.
  • Design the game, but don't create the game: describe the game in words, and provide assets (art and sound) for it.
  • Game designs must match at least two of these keywords: food, future, snow, animals
  • Game design descriptions should be as detailed as possible so that the game design is not misunderstood
  • Game designs should be easy to implement, because some of them will be implemented in the next challenge
  • There will be prizes
  • The design is due in four weeks, at the meeting on March 2nd
Challenges