Projects

During the later half of the course, you should make a small project in groups of 1-4 students.

2 persons are highly recommended. At 1 person, you are on your own so you need more discipline, but it is often a good choice for the more experienced students. On 3 or 4, you must show me how you can split the work on so many people so nobody is left behind, and also that the project won’t get caught in project management issues.

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.

Timeline

Before the end of the lecture series: Write specification and get it approved. I want a suggestion by the time of the second to last lecture and a specification the day of the last lecture. (As of 2024, that means friday the 1st of march.)

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 as the source code.

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.

Project specifications

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/scenes (array in 2 or 3 dimensions, polygons...), level design and generation (text file, graphical editor, randomly generated...), player controls, simple collision detection and handling.

List of "might do" features. This could be sound, networking, advanced possibilities for the above, 3D model input, advanced collision 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.


Example:

3D Maze Game

Participants:

Nils Nilsson, ninil000@student.liu.se

Arne Anka, arnan313@student.liu.se

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.

Will do:

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

First-person view

Light sources

Might do:

Random generation of mazes.

Skydome.

Special graphics for the goal

Enemies, hunting the player. You lose if they touch the player.

Score objects

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

Sound effects

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.

Presentations

The project must be presented in a short seminar, demonstrated, and described in a report. More info here.

Scheduled project labs

There are scheduled project labs in the schedule. These are generally not supervised all the time, but I will often pop by and discuss your progress. Also, I occasionally handle late lab examinations there.

This page is maintained by Ingemar Ragnemalm