game code architecure

[Yogibear]

In order to realize the idea of a more comfortable replay i spent the last days digging into the code and trying to understand it.

I noticed, that most of it is organized according to a functional approach. That is, the architecture of the code focuses on functions more than on variables. It's a little bit hard to explain, in Germany we call that "structured programming" in contrast to object oriented programming, which is more focused on the data.

Did you ever think about turning to a more object oriented structure? Although i favor this approach very much, i am well aware of the drawbacks. Even though it structures the code better and makes it easier to understand it introduces a new level of complexity: Dealing with polymorphic methods, abstract classes and interfaces is anything but easy. So to really benefit from such an approach, you need a lot of know-how and experience. And of course it might not fit into the KISS philosophy.

On the other hand if i watch myself digging into the code, i have a lot of trouble to locate certain functionalities. Take the config-object as an example. It gets passed as a parameter all over the application and you really have a hard time figuring out the relevant code. At least if you look at this for the first time.

So, what do you think about that? I remember Dave saying, that he plans to isolate certain modules with clear interfaces. That sounds to me like a step to a more object oriented approach.

PS:
Please don't make this a flame war!

[Yogibear]

Ok, it looks like either no one understands what i am saying or i have not been specific enough (or no one cares ).

So i would like to come up with something more specific, that is easier to discuss about. Let me cite the Wiki first:

- Modular

As said before, we wish to make wesnoth totaly modulairized. The 'glue code' needs to be removed and put into its own module. Doing this will result in clearer code which will make the development of Wesnoth easier.

The modules that are already in place should be moved to their own subdirectories, so that it is clear which files belong to what module. Each module should be defined in its own namespace and the API should be documented.

Perhaps as a next goal, we can give people responsablitiy of a module. This'll take some load of the head developer (Sirp) and divide it among the module maintainers.


- Design

The design of the new modules isn't yet available but is in the making. The following list gives an idea of the modules which can be created:

* Wesnoth Core - The game core with mostly the game logics, almost all modules depend on this module.
* Editor - The Wesnoth editor
* Server - The Wesnoth server
* Networking - The Wesnoth networking code
* Data - Units / Terrains / Game data
* GUI Manager - Dialogs, menu system, input devices

Here is a suggestion, how to do that, based on a standard MVC-approach (Model, View, Controller). A picture says more than 1000 words (see below).

Additionally, i would like to suggest some rules:
- the gui does know about the model, but not the controller
- the model does only know itself
- the controller knows about everything
- the data-layer knows about the model, but not the controller

"Knowing" another module means having access to its definitions. Think about it as having an "#include" of that module.

These rules originate from the goal of reusing code. The module/layer with by far the highest chance to be reusable is the "Model". Therefore, it should not have relations to other modules. The rest is pretty much straightforward.

I also tried to assign some of the current classes to the modules, to give you a rough imagination of their functionality and role within the application.

Now how do "Model" and "GUI" notify the "Controller" of certain events, if they don't have knowledge of it? That is achieved by self-defined events. Basically they are nothing else than callback-functions. One could think about having some sort of typechecking to assure the event-handlers match the corresponding event. Just like .Net does it with delegates, maybe.

So, how's about that?

[Tomsik]

I think just noone wants to change it, it would need much work.
(at leasti think so, if im wrong correct me)

[Yogibear]

No, you are absolutely right. It probably requires refactoring the whole application. But it becomes sort of unavoidable, if the code grows beyond a certain limit. The more code there is, the more organisation it needs.

And i agree with the wiki, that the code is about to reach such a limit. So it's rather the question, when not if you are doing the work.