I have written a game library using Component-based architecture, including Ogre 2.1 and Bullet.

In the last few month, I created some tiny game as a prototype, and the library looks good so far.

Now, I started to create a more complex game.

Many features of my game start to work good within my game engine environment - but is a crap elsewhere.

Example

I have a custom data-structure - 3D grid manager, named Grid.

class Grid{
    GridMember* gridMembers;
    int numX,numY,numZ;
    void add (GridMember* gridMember, int x,int y,int z){
          gridMembers[ ((z*numY)+y)*numX] = gridMember ;
    } 
    //other functions
};

-

In the game logic, I used inheritance:-

Game entity that stores  : derived from Grid
Game entity to be stored : derived from GridMember

-

I found that this Grid class doesn't go well with the component-based architecture :-

The game entity should not have any function!!

So I changed it to match the component-based architecture.

class Grid_System : Game_Engine_System{
    void add (ID grid, ID gridMember, int x,int y,int z){.....}
    //.............. other functions ............
};

Notice that Grid will now really depend on the game-engine.

----------------------------------------------------------------------------------------------------------------------------

The fear about losing modularity in code start to overcome me.

It accompanies by fear that Component-based architecture will become an obsolete technology soon.

I have not slept well.

I start to have nightmare in some nights.

Am I worry too much?

Am I worry too much?

Short answer: Yes you do.
Long answer: The example you showed could probably written more elegantly, but that's not the problem here. The software you develop will depend on the base you build it on. You can devise clever wrappers, build in extra levels of abstraction, but some level of dependency will be there. Even if you abstract away your engine perfectly, you will still depend on (either knowingly, or unknowingly) the actual implementations inner quirks, and if you swap the implementation behind the abstraction, that will have different quirks. This haunts every branch of software development, and this is one of the reason why we become extra careful, even when it comes to simply just update an external package we depend on to a newer version. (With a big enough codebase on your hand, a simple minor version upgrade in one of the dependencies can turn a peaceful workday into hell, and it's especially not fun when you have a deadline on the horizon.) Of course you want, and you should build your codebase using sound engineering principles as much as you can, but what really matters, is the end result, and the endusers opinion/feeling about it, not the cleverness of your engineering solutions.

Another thing to think about is the case of UE4 vs Unity, if you create a game with one, you cannot easily port it to the other, the two have fundamental differences in their design. And the question is: why would you even want to change the engine mid development?

Thank a lot, LandonJerre.

Now tonight, I can start to sleep well. :D

In my opinion, yes and no. It's just one of those things that is answered with "it depends".

Typically the game the goal is to hide direct interfacing with your lower level systems. This little layer of complexity is to allow you to modify things without severely screwing up a whole lot of other crap. The programmer who's doing all the game logic really shouldn't be too concerned with how the lower level systems works to do his job.

But in order for code to work properly, there is BOUND to be some sort of dependency or ties in other locations. It's completely unavoidable.

Now... let me give you some tips for the code that you just mentioned :P. Because you are using Ogre3D 2.1 and Bullet, I am going to assume that you made a 3D engine.

The Grid class that you made is actually completely redundant and inefficient. For 2D games, it's perfectly ok to use grids for placing tiles down. But generally you'll find that there are better ways to solve this issue. For 3D games however... you have an extra dimension adding onto space requirements. Which normally means that a large percentage of it will not actually be used. 40^3 = 64000

Imagine trying to fill that up :<

Instead. You can just store data in a dynamically growing 1D array. If each object holds information about it's transforms, and it locks it's self to the grid, then you will have a dirt cheap gridding schema that will only use a very small fraction of a fixed grid's cost.

Also, you're putting too much faith into the component system. The component should be reserved completely for logic only. Objects aligning to a grid are not logic based. They are more akin to a scene manager. If the programmer wants to jump an object from grid square to grid square, then he should manually write the logic to do so.

The example you showed could probably written more elegantly ...

May you provide the more elegant signature of the function, as an example, please?

I am curious. :D

Thank, Tangletail too!

Objects aligning to a grid are not logic based. They are more akin to a scene manager. If the programmer wants to jump an object from grid square to grid square, then he should manually write the logic to do so.

Yes, grid square <--> object .

In real usage, the array is usually quite tight. (I think I know what you mean. :D)

The object inside a grid is "game object".

The game object should be stored as ID (entity) to make it still transparent to other systems.

Therefore, grid should has ID as type of parameter.

I think this kind of binding is quite unavoidable.

Please fix me if I am wrong. :D

I can't help you there without more information.