2013/2014, 2nd quarter, time slot D
INFOB1PGT: Gametechnologie introductieproject
Coordination: Frank van der Stappen (www, email)

news | schedule | resources | teams | description | opdracht | vereisten | beoordeling | symposium | contact

OPDRACHT

The ultimate goal of your project is to create a playable game. As a rule of thumb, your game should provide at least about 5-10 minutes of fun gameplay in the end. Of course, the time to achieve this goal is very limited and too short to create a complex game. Also, you are at the beginning of your education, so we can't expect everyone to do a complex implementation yet. Hence, your concrete task is to
  1. implement a retro game,
  2. extend parts of it with current state-of-the-art technology.
Based on your experience from the course Gameprogrammeren in the first quarter, your team should be able to easily achieve the first subgoal. The second part is where you have to "get out of your comfort zone", i.e. where we expect you to do something new that you have to research and learn for yourself. You are encouraged to be creative and aim high.

Notice that the separation in first and second subgoal is not strict. You don't necessarily have to do a full implementation of the original retro game. For example, if you want to do a 3D version of a traditional 2D arcade game, there is obviously no point in implementing a 2D version first. In addition to the actual game, you will also create related promotion material such as website, flyer, and video trailer.

DETAILED PROCEDURE AND TODOs

The basic idea of this project is to adapt and extend (parts of) an existing retro game with state-of-the-art technology. This involves the following steps:
  1. Found your team and present it to the world.
    Since you will be developing a "real" game (including promotion material, etc.), you should also act like a real game development group. Hence, you have to pick a (cool) name for your team, and promote it by setting up a blog with a page for all the small bios of each team member. For details on the delivery of this, please refer to vereisten: initial blogpost.

  2. Select the retro game that your own game will be based on.
    Have a look at various retro games (gameplay and technology) and decide which one to use. Don't just pick a random one that you happen to like, but make sure to do an educated choice ...
    • considering the limited amount of time that you have for this project. Also make sure that you can cut down the project in case you are running into unforseeable problems. Aim high and be ambitious, but make sure that you can cut back and still have a playable game in the end if you can't reach your hight goals.
    • considering the possibilities for its extension with new technology. Keep in mind that not all extensions might work with a game. Also, be careful that some extensions might have results on other issues (e.g. if you move from a 2D to a 3D visualization, this could not only effect your graphics, but also significantly complicate things such as collision detection).
    • considering the "5-10 minutes of fun gameplay" rule mentioned above. This goal excludes for example adventure games or anything that needs a long tutorial to explain the gameplay and goal of the game. Obviously, this also makes sense given the limited time issue already mentioned above.
    Notice that "retro" is not that strict, i.e. your game doesn't necessarily have to be based on a game from the 80s or 90s. There are two reasons why we dediced to use retro games. First, it makes it more likely that you are focusing on the technology related aspects and not the game design. Second, implementing a 2D retro game is something that we can expect you to achive easily based on your experience from the first quarter of your studies. If you want to use a newer game that fulfills these criteria as well, you are welcome to do so. In case of doubt, you should discuss it with your tutor.

  3. Analyze and describe the game and/or used technology.
    If you want to re-implement and extend an existing game, you need to have a good understanding of it first. Depending on the concrete game and plans that you have, you might need to look for example at the following aspects:
    • What is the idea of the game, how is it played, and how was it implemented?
    • What kind of technology was used in the original implementation (graphics, AI, networks, physics, ...)?
    • Why was this game or the used technology so popular (or not popular)? What makes the game fun and interesting? You might also want to look at some old reviews to get further insight (cf. for example Video Game Reviews by the Video Game Critic).
    You have to summarize your observations in an analysis document. For examples and details about delivery, please refer to vereisten: analysis document.

  4. Write a design document for the new or adapted game.
    Keep in mind that the focus should be on the usage of new technology, and how it is going to be used to adapt the game and/or to create new gaming or interaction concepts, etc. It is not about game design. Of course, using new technology to adapt an existing game can significantly change it or might even result in a totally different game. Hence, you will most likely need to do some sort of game design. Just keep in mind that design is not the major focus of this project. You are however encouraged to create something unique and exciting. But be aware of the limited amount of time to develop your game, especially when you go for a rather risky modification. You have to specify your decisions in a design document. For examples and details about delivery, please refer to vereisten: design document.

  5. Implement your game.
    Keep in mind that the implementation phase also includes a detailed testing of both the correctness of your code as well as the actual gameplay. You should use C# and XNA to implement your game. Exceptions might be possible but need prior approval from the tutor. You have to use the faculty's SVN server for version control of your code. There will be certain deadlines when you have to upload your code to the server. For details about this, please refer to vereisten: svn server.

  6. Create the promotion material for your game.
    To promote your game, you have to create a website, a flyer, and a video trailer. In addition, you have to burn a DVD and make a nice cover for the related box. For examples and details about delivery, please refer to vereisten: promotion material.

  7. Prepare your game for the grading and public introduction.
    For the grading, you have to prepare a presentation and a playable demo of your game. This will be the basis for the rating of a jury on Wednesday, January 30th. The jury will also nominate five candidates for a best game award. For the symposium on Friday, February 1st - where your game will be presented to the public - you have to prepare a playable demo of your game. If you are nominated for the best game award, you also need to prepare a short presentation for the symposium. If you are not nominated, you can still win an audience award. For details about grading and the symposium, please refer to beoordeling and symposium, respectively.

  8. Go to the symposium and have fun :)


COMMENTS ON POTENTIAL GAMES AND EXTENSIONS

If you are too young to know any retro games, a simple web search for "retro games" or "arcade games" should help in providing examples such as this one or this one. But you probably know some of them already, such as King Kong, Super Mario, Pacman, Bubble Bobble, or Tetris. In order to improve one of these games by newer, state-of-the-art technology, you could first have a look at what platform it was written for (including the resulting limitations) and what consequences this had for the structure of the game. Then you could think about why this game was so popular (or not popular at all). Based on this, you can think about a modern variation of this game using newer technology and opportunities. For example, today we have better graphics (both hardware as well as related algorithms), network connection (which, for example, offers options for multi-player modes or online highscores), various interaction devices (e.g. Wii remotes and cameras for vision-based interaction), etc. You can restrict yourself to one of these, or improve the game by various aspects. You are only limited by your creativity and imagination - well, and the time schedule and deadlines, of course.

Possible examples include:
  • Interaction:
    • New interaction via Wiimote(s)
    • Using a web cam for motion tracking (a-la Microsoft Kinect)
    • Fullbody fighting by using lamps and a camera to control games such as Streetfighter (*)
  • Sound
    • Adding 3D sound effects
    • Control sound via the Wiimote
    • Completely audio-based version of the original game (*)
  • AI
    • "Smarter" ghosts in Pacman
    • Realtime analysis of the game and automatic adaptation of the level of difficulty (*)
  • Graphics
    • Particles systems
    • Shaders
    • Ambilight-like additions for a better atmospherical impression
  • Networks
    • Multiplayer modes via network
    • Highscore lists on a website
Notice that examples marked with (*) are considered to be rather difficult and challenging. To get some inspriation, you can also look at the games produced by teams in previous years. Notice however that some of the promotion material produced then does not highlight the actual contributions and extensions very well - something we expect you to do a little bit better this year ;)

Further comments related to topic selection: Keep in mind that time is limited and deadlines are fix. You should be prepared for unforseen problems. Have a backup plan if things go wrong or don't work out as expected. Also consider that some students of your group might drop out of the course. It is not a big problem for your grading if you have to cut down your original plans because some of your team members left. It could be a problem however, if you are not able to deliver something playable at the end, because, as said, you should be prepared for such a case and have an appropriate backup plan.

As a rule of thumb, you should aim high, but be prepared for the worst. The most important thing for passing this course is to have something playable at the end. You will have a hard time convincing the jury to give you a passing grade if your game is not playable. The most important thing for getting a good grade is to have an ambitious project.

FREQUENTLY ASKED QUESTIONS RELATED TO TOPIC SELECTION

  • Q: Can we use open source code? How about graphics, songs, sounds (both open source as well as commercial)?

    Hardly any software project nowadays is done from scratch, but generally relies on existing code or data. Hence, in general, the answer is yes. However, you need to specify concretely what you've been using, so the jury can consider this in your grading. For example, if a team puts lots of effort into creating nice graphics or composing their own sounds instead of just copying them, they should get credit for that. If another team re-uses lots of code that they did for another course in the first quarter and only makes minor changes, they shouldn't get much credit for it.

    You should also consider legal issues when using other people's software or data. More infos about copyright etc. will be discussed in the 3rd lecture.

  • Q: I recently bought a Wii controller, Kinect, 3D laser gun, robot, etc. Can we use such additional hardware in our project?

    For practical reasons, it would be best if your game can run on a regular Windows PC with standard hardware plus webcam. But of course, if you have a cool idea, you are allowed to use alternative hardware. But you should keep the following things in mind:
    • Most likely, the department can not provide any related resources and support, so it is at your own risk (e.g. if the one person in your team who owns the hardware decides to quit, it's your problem)
    • You will be graded for what you actually do and not for how much cool hardware you use. Hence, you need to clearly specify what you used - not only the hardware but also related tools and software. For example, if you use the programming tools of Microsoft's Kinect, you can probably create a very fancy demo quite easily, whereas a team that implements complex computer vision algorithms to do body tracking with a webcam might not have such a cool demo as you, but they could have actually done better work. The jury needs to be able to judge that.
    If you are in any doubt about this, make sure to discuss it with your tutor. Also, there are some resources available at the department (e.g. there's a Kinect in the Gamehall, and we also have a Motion Capture Lab that was used by one of the groups last year). If feasible, you are welcome to use those. Please contact your tutor about this. He will help you to get in touch with the right people to see if it works out.


(c) Frank van der Stappen