Conclusion chapter - Game Programming Lab '11

Group members: Daniel Bucher, Etan Kissling, Jan Rüegg, Francois

Summary of final results / Significant changes since Alpha Release

Controls

Controls were redone and simplified again.


 

Y-Axis can now be individually inverted by players depending on their preference.


 

Gameplay

Switches have been added. When a player touches a switch, his color will fade to the color of the switch and all collectible lights will also adapt to the new color, allowing the player to hide better.


 

Graphics

Animated 3D textures are now used on walls for a nicer look.

Player lights now cast shadows on walls without a major performance loss.

Particle effects have been added for the player lights for each light the player has collected. Particle effects run on the CPU since the GPU is already pretty busy rendering all the shadow and light stuff.



 

Missiles are now rendered differently to avoid confusion when they are too fast.


 

Added a presentation mode to counter the crappy beamer in the presentation room.


 

Split-screen was improved to adapt to different player counts and making it less disturbing when the game switches from three players to two players.



 

Sound

Added new sounds for various events in the game.

Content

New levels have been added, with the addition that the position of the collectible lights can now be specified explicitly so that they do not spawn in walls anymore. Also, initial player position and viewing angle is also read from the level files now.

Version Control

Fixed many merge conflicts.

Commentary about our experience during the class

How well did your initial design ideas materialize into the final game?

We made it into the proposed high target with the decision to swap the originally idea of environmental lights with switches. Extras where not implemented.

Were you able to follow your development schedule, or did you deviate significantly from it?

We did not follow the original development schedule, since we have already experienced early that we have to redo multiple game elements again and again. This includes the shadow rendering, the player light rendering and the controls as well as code refactoring and switching between version control systems. Therefore, we met every week and assigned tasks depending on the corresponding state of the game.

How did the different elements of the project structure (development schedule, prototype, playtesting, etc.) contribute to or hinder your progress?

Beginning was very slow. Development schedule was useless, prototype falls also in the category of a simple time waste. However, the different releases and the feedback from Blackrock studios as well as the assistants and the playtesters were very useful and motivated us on working on the game. The layered project structure with the different targets was also useful to plan which game element to improve next.

Personal impression of the course

Did it meet your expectations?

There were a lot of lectures which were presented way too late in the development process (like the balancing lecture etc). In addition, some presentations were not really helpful (for example the playtesting results presentation or the interim report presentation two weeks in advance of the alpha release presentation). They just used time to be prepared and were not really interesting to watch (proved by the lack of questions and constructive feedback by other course attendants).

Are you happy and proud of your game?

We are proud of the graphical aspects of the game since it was a part which directly rewarded the development time and the process of redoing it multiple time visually. For the gameplay mechanics, we think that it could be improved way more. Currently, the game feels more like a simple FPS game where you are confused about all the light spheres and get stuck in a wall every now and then if you are not used to the control scheme.

Do you feel there wasn't enough time or that the schedule was too compressed?

We lost much time to version control issues (like 1-2 weeks). Otherwise, the schedule was pretty perfect to create a game which meets the goal of the course. We learned the game development process and could achieve a playable result.

Additional questions

  1. What was the biggest technical difficulty during the project?
    Light and shadow.
     
  2. What was your impression of working with the theme?
    We somehow squeezed the theme into our game idea after it was already somehow fixed.
     
  3. Do you think the theme enhanced your game, or would you have been happier with total freedom?
    Total freedom would have been nicer since we had other game ideas that didn't fit within the theme at all and may have made up better games.
     
  4. What would you do differently in your next game project?
    Don't use Git. And create some sort of code structure before starting to work. Beginning with a xna test project in a single file and then adding some documentation afterwards is not very efficient.
     
  5. What was your greatest success during the project?
    Volumetric shadow maps. And the "Maze" class.
     
  6. Are you happy with the final result of your project?
    See above.
     
  7. Do you consider the project a success?
    See above.
     
  8. To what extend did you meet your project plan and milestones (not at all, partly, mostly, always)?
    Functional minimum - completed
    Low target - completed
    Desired target - completed
    High target - partly completed
    Extras - untouched
     
  9. What improvements would you suggest for the course organization? (perhaps in D1 evaluation)?
    The field trip was a nice surprise. Keep it in the course :-)
     
  10. Did you like the XNA framework?
    The XNA framework allowed us to do a fast game development. However, sometimes problems arised since the version 4 we had to use did not include all features of version 3 which were mentioned in tutorials.

Page URL: https://twiki.graphics.ethz.ch/bin/view/GameClass/RodFinal
2024-03-28
© 2024 Eidgenössische Technische Hochschule Zürich