Developers Diary – Developing Methodology


In the beginning of our project our goal was to create the game in a pipeline wich remove some of the problems that we face in previous projects.

  • Breaking the development;
The development of the game cannot stop because the designer didn´t  finished his job or because the programmer didn´t finish his job.
The develepment must be easy enough so anybody could modify some part of the code.
  • Allow the designer to modify the rules of the game;
Create a visual system to modify some characteristics of the game
  • Create something like a balancing system.
Create a system to balance the game where everyone could modify the game balance with no code.
We realized that maybe oriented object could not be the best paradigm to use because the development always begins in a good way but in few inheritances or in few iterations of the game, you generally see yourself having to change so many stuffs that you got discourage.
Take a look at this
“Even fairly simple objects such as rocks or grenades can end up with a large amount of additional functionality (and associated member variables, and possibly unnecessary execution of member functions). Often, the traditional game object hierarchy ends up creating the type of object known as “the blob”. The blob is a classic “anti-pattern” which manifests as a huge single class (or a specific branch of a class hierarchy) with a large amount of complex interwoven functionality.”(Cowboy Programming)

Creating behaviors that could be reused by several kinds of objects would probably create a big and unmannaged dependency tree, and i cannot see a way to dinamicaly reuse behaviors, attaching new ones in my entity without creating a complex structure and without compromising performance.

Thinking in this problems we searched a new way to treat the etities and the behaviors.

Then we were introduced to Artemis an entity system that really works.

 

, ,

  1. Nenhum comentário ainda.
1 200 201 202
(não será publicado)