Custom Query (296 matches)

World-class: the main loop of each level needs some caring to:

1. Modularity:
   • The world exists of many different things: environment effects lights enemies the player and so on.
   • the idea is that the world loads, and updates them, but it should not paint them itself
   • Meaning: everything that is not a loop goes out of world and into a own class (like the light)

2. Design:
   • initialisations
     • file loading
     • class loading
   • loop
     • class updating
     • class drawing

3. Restucture:
   • Only functions that are really necessary are located here.
     • Load
     • init
     • loop
   • everything else goes out into other classes

I hope, that with such a modularity we can bring more insight, clearity and simplicity into the very important world-class.

The goal is to reimplement the ground terrain in the existing debug levels (currently some nice sinusoidal hills with snow on their top).

Reasons/Requirements:

• The ground must be modular (=exchangeable), so there has to be a possibility to change the ground form without changing mathematical functions (sin/cos)
• There has to be a simple way to add terrains coming from diffrent types of files (having different date sources):
  • Height Map
  • Obj Files
  • self generated terrain matrices (as it is currenty the case)
• Working without errors on ALL platforms

Implementation:

• The problem is a typical class/object-problem, closed in itself so shall it be implemented
• There shall be different ground-data-types for each ground-type (height-map (existing) and obj-loader (existing))
• Class of type WorldEntity
• The ground-types must be separatable into different parts for the application of octtrees and such techniques.

Implement a debug level, that shows all posibilities, that the pnode system of orxonox can offer… its realy open this one…