During the later half of the course, you should make a small project in groups of 2-4 students. You may choose the task yourselves. You should define the problem you wish to solve and hand in the description to the examiner for approval.
Feel free to make your own suggestion, but here are some to start from:
• 3D labyrinth
• Interactive solar system
• Robot with moveable limbs
• Driving simulator
• Flight simulator
• Terrain rendering (beyond lab 4)
• Ray tracer
You will have to decide on features yourself, depending on experience, group size, and interest. Among interesting features you may wish to consider are:
• Use of shaders
• Large world considerations
• Collision detection
• User interface
• Game rules/application-specific details
It is important to note that you are expected to make small projects. Do not aim too high. The separation of your specification in "will do" and "might do" parts (see below) is an important tool in avoiding to aim too high.
Before the end of the lecture series: Write specification and get it approved.
Once the specification is decided: Design and implement.
Late in the course: Presentation and demonstration, report. When you get close to finished, drop me a note and I will book as many presentation sessions as needed. You may have the presentation at the end of this period, before the written exams. The report should be handed in at the same time.
You should get started early in VT2, and we will have the demonstrations in may, before the may-june exam period. BUT please note that when the written exam takes place, that is when the course ends and there will be no more demonstration sessions. So there is a strict deadline.
You should hand in a project specification at a specified deadline. (The last lecture.) You should at the very least have discussed it with me before that.
A project specification should not be more than a page (remember, this is a small project). Here is an outline:
Name of project
List of participants
Brief description of the project
List of "will do" features. This should be basic features that helps me to understand how you plan the design, and sets a minimum technical level.
Typical "will do" features: texturing (how is the mapping done?), light (how?), limitation and storage of levels (array in 2 or 3 dimensions, polygons...), level design and generation (text file, graphical editor, randomly generated...), player controls, simple collission detection and handling.
List of "might do" features. This could be sound, networking, advanced possibilities for the above, 3D model input, advanced collission detection, effects by particle systems. Don't list impossible dreams, but the more advanced features that you hope to do some of but probably not all, features that you don't have quite the total control over.
The specification may be written in english or swedish.
3D Maze Game
Nils Nilsson, email@example.com
Arne Anka, firstname.lastname@example.org
We will write a maze game, where you see a maze in first-person perspective. The maze is a 2D maze, based on a grid.
Maze descibed by a text file, stored as a 2D array.
Textured walls and floor.
Collission detection camera-walls.
Simple geometry for objects, like boxes and spheres
Random generation of mazes.
Special graphics for the goal
Enemies, hunting the player. You lose if they touch the player.
Selection of different camera placements, like third-person view, top view or zoom feature.
Drawing optimized to the frustum.
Spotlight light source following the player
Import OBJ objects.
What would I say about a project like this? I would say it is OK, for a 2-person project, but suggest that the first two or three "might do" at least are promoted to "will do" or at least "will most likely do", since the basic project is simple and those demands are, too. I would also ask what you mean by the goal graphics. A simple object marking the goal should be a "will do", but a nice firework congratulating you is more like a "might" feature.
I may also ask for more detail on some points. Is the maze walls axis aligned? How many light sources do you plan to manage? Have you considered any optimizations for that, like limiting the number of light sources that can be active in any specific place?
Keep it simple, but note that the project should be bigger than just one lab! Rather like three labs with some preparations and planning on top. All in all you are supposed to spend about one and a half week, full time.
Language and tools
I recommend that you make the project on the lab computers, so the step from Lab 1 and 2 is small, but feel free to use what you like the best. Other platforms and other programming languages, it is up to you, as long as you can demonstrate the results at a seminar.
If you work in the lab, using CentOS, you can use command-line compiling or Kdevelop. I am afraid I can't help you get started with Kdevelop, though. In Southfork, you can also boot from MS Windows, but there are no development tools installed. I don't recommend that.
Need a compiler? If you use Linux, you certainly have one (or more) installed already. If you use OSX, you will find tools on the Developer's CD that comes with OSX, or you download from AppStore (for 10.7) or Apple's developer pages (10.6 and lower). (And you can ask me about more.) If you use MS Windows, you can find a free compiler here.
For OSX you can use Xcode, which comes with the developer tools (you can't install developer tools without getting Xcode). An alternative is Lightweight IDE, an IDE in development by myself, which is intended explicitly for laborationsand small projects, a kind of study in simplifying the user interface. If you don't like makefiles and project files, this is for you. (And I need testing and lots of feedback to make it better!)
The project must be presented in a short seminar, demonstrated, and described in a report. More info here.
Scheduled project labs
On wednesday evenings, there are scheduled project labs. These are generally not supervised, but merely time where a lab is reserved for you. Use this resource as you please.