Special volumetric areas
(Go back to the main GSoC 2015 page)
For this project C++ knowledge is needed with some knowledge of mysql. In addition some mathematical skills are needed to define movement vectors and bounding boxes.
The game engine today knows about moving entities in a 3d environment where the main interaction is through collision detection, which allows for example to players to walk firmly on the ground, or buildings to block the way. This project is about defining special volumetric areas, which are not occupied by any 3d object part of the main area geometry. For example we may decide a certain area is made of water, and specific rules apply while an entity is inside the bounding box of that area. The entity may lose his weight and float, a player may play the swim animation, certain animals may die, others live. Other types can be areas made of cold, lava, magic. The new system should allow to define those areas with associated animations and scripts.
The main area of research needed for this project is how to define areas and detect the player movement in those areas minimizing the calculations. We have a similar functionality in game which is using proxy lists, basically a way to determine if a player is in range of a spell, or a NPC. This functionality at the moment is limited to a bounding box check, but has proven to be pretty expensive. After determining the best algorithm, the next step will be to create a list of possible attributes for the areas, for example:
- Do we want to have those areas associated to an invisible modeled 3d object?
- Can we define it with a simple box or sphere?
- Should the area have one or more scripts associated?
- Can we have some predefined areas, like for example water, lava, fire, ice, ....?
- What kind of effects should the area have on physics, entity movements, or their stats?
- Are those areas permanent or can be associated to specific events/time of the day?
- Can a new area be created at runtime, or should it be predefined before the server starts?
The answer to the questions above will determine how the final solution will look like. We would like to have system which is as generic as possible, and it's computationally light, server side and client side, as we already have many other calculations running in parallel.