Project 3: Rules

These rules are meant to be common sense – not tricks to limit you. They are the same as the rules as in previous years.

Note: some of these requirements make more sense when you understand how the project will be evaluated when the project is done.

On one hand, trying to do a game design that fits into this funny class project setting is kindof silly – since the constraints are pretty artificial. However, any real design project is about meeting a set of constraints – and the ones imposed by a class could be the ones imposed by the reality of a company’s situation, …

I could have made up a hokey story about how these constraints aren’t because this is a class project, but rather, because you are working for a real game studio and a big publisher is considering buying you, therefore you need to demonstrate to them how good you are in a very short amount of time.

OK, the rules:

1. It must be a game (e.g. fun)

You should think about how you will use game design principles to make it fun.

2. It must be buildable by a team of 4 students in the time period provided.

This is a big constraint. There isn’t much time. You’ll basically have 3 weeks of real implementation.

So, I recommend in your design you consider 3 things:

What the game would be like in the ideal, if you had tons of time
What the game could be like if 4 people worked for 3 weeks and everything went well
What the game could be like if things went badly in those 3 weeks

A different way to put it: your design should have a simple version that can easily be pulled off in 3 weeks (or faster, if things go well), but can be extended into something bigger and cooler (if you have time).

2.1 It must not require code or ideas you’ve written previously

Many students in class have their hobby projects or code they’ve written previously. You can’t use this.

For one: you might not even be part of the team building your game. And while you might be willing to give another group your code, you’ll be too busy making your own game to give them much support.

While games must be designed so they are practical to build without using previously written code, teams can make use of "old" code from their members providing that the entire team agrees, the person providing the code agrees to make it publicly available, the code is not overly "game specific", and the students get permission (by email) from the instructor.

2.2 You must be willing to “give up” the idea

Once you pitch the idea, other students may like it and go off an build it. Anything you pitch is explicitly in the public domain.

3. It must have a low-startup overhead

Your playtesters (and target audience) will not have a lot of time. In 15 minutes, they need to figure out your game, and play it enough to appreciate it. (although, it should leave them wanting to play more)

This puts a little bit of pressure on you to make your game "demo well." A design that is hard to learn, requires you to get to level 17 before its interesting, or offers no sense of "progress" until you’ve played for hours might be less attractive. (note: the game should offer the depth for long term play – it just needs to get the player hooked quickly).

3.1 It should not require the player to already know something obscure.

The target audience for your game includes the TA and professor, and other members of the class.

If your game requires the player to be familiar with (for example) the scenario from some book, the characters from some movie, or the rules of some existing game, you might be in trouble if the player hasn’t read the book, seen the movie, or played the game.

4. It must be self-contained

A new player needs to be able to sit down at the game and start playing. This means that any instructions / explanations need to be part of the game itself (or documentation).

5. It must provide for a short experience, but have replay value (or extended play)

6. It must not require any intellectual property that isn’t either yours or freely available.

If you want to use a story, a character, music, … from a copyrighted source, you can’t (since you won’t have a license to do so).

If you need a technology to implement the game, it must be freely available. So (for example) its not OK to design an add-on to a commercial game (and couldn’t be feasibily built from scratch in 3 weeks).

Note: for the project, teams may use available engine platforms, providing they are either freely available or are flash (because we have flash licenses). (actually, we might not have flash licenses – I’ll have to check)

For your actual implementation, you may only use tools for which we have license to use for class projects. This basically means Open Source only. (note: while you can use Unity for your personal projects, using it for class projects or on University owned computers is against their license).

7. It must run on the computers in 1358 and 1366 CS.

An exception can be made if you choose to make things work on a mobile platform (like an iPad or phone). However: it will be up to you to arrange for devices for the playtest. Please discuss with the Professor.

8. It must be single player

This restriction is to make play testing easier. Its a great bonus if there is a multi-player mode, but there should be a single player experience.

9. It must be in good taste

Avoid gratuitous violence, references that may be offensive to some, …

Your game must get an "E" (everyone – all audiences) rating.

10. It must require non-trivial programming and design

This is a hard one to describe.

Basically, the work of building the game must be primarily computer science. It can’t just be making artwork and showing a slideshow. It has to be "hard enough" to build, but there’s a tradeoff: you don’t want to pick something that’s too hard (and risk not finishing by the deadline).

This is why we suggested a "Scalable" design above – pick something where you know you’ll have something at the end, and hopefully you’ll do better than the minimum.

Previous Ideas

Here are the past proposals: