Implementation Discussion

May 4, 2010 at 3:29 AM

This thread is for discussion implementation by the Coders. This includes the design and architecture of the game's code.

May 4, 2010 at 4:19 AM
Edited May 4, 2010 at 4:22 AM

OK, I think we should use the MVC architecture or similar. Such that, the game model, terrain, entities, actions, etc, are seperate from the views and controllers, either human or AI. The tank knows it has a gun, it can carry people, it can move so fast, it has structural health, it's facing north and moving, etc, it does not know what image is used to draw it, where it's drawn, of the the W key moves it forward and that its turret tracks the mouse cursor. As such, the game model can run completely seperate from any view or control. Nobody would do anything, but the game world could still be processing on.

The views and controllers, however, are a bit more dependant on the model, or at least the model's data and interface.

We shall enforce this by working with multiple projects, with the model in one, and the views and controllers in another or more than one, as appropriate.

Jun 28, 2010 at 3:21 AM

The Process of moving from region to world to screen coordinates

Since our game world is going to be fairly large, we should take into account how to handle that since float types only have so much precision that at farther distances they're no longer suitable for recording positions of objects  And then they have to be translated into screen coordinate, though for rendering purposes, if the object is very far away from the camera, it doesn't matter so much if the precision is lower, the player won't really see it at that distance.

So to solve that, I think we shall implement discrete cubic regions. Each region will have its own origin to which the objects within are measured against. And when a measurement against an object in another region is needed we can use the bigger double type for that and it'll be a simple calculation.

When it is time to render the objects, the origin of the region the camera is currently in will be considered the world origin, all regions that the camera can potentially see (in this case, very simple since it's a 2D isometric camera) will update their sprites to use the correct world coordinates. These are then converted into screen position by the camera and finally rendered.