Simple isometric engine

rogerdv 101 Aug 22, 2003 at 20:30

Im creating a simple isometric engine, oriented to RPG and RTS games. So, although it is for my personal projects, I would like to make it as generic as possible, so I can reuse it for different projects and maybe extend it to use both opengl and d3d .
Currently i have a working 3ds file loader and a nice isometric view. I plan to add some basic 2d managements and widgets and maybe filesystem abstraction
I would like to hear some suggestions about how to organize this in a coherent, yet simple structure.

5 Replies

Please log in or register to post a reply.

baldurk 101 Aug 23, 2003 at 09:09

I think it all depends on how your mind works. Different organisations and coding styles work for different people. You need to first decide what kind of structure do you want. Do you want a heirarchy? no heirarchy? will it be strict, or loose? etc. Then you’ll probably find that you’ve thought of how you want to do it.

rogerdv 101 Aug 23, 2003 at 12:58

Well, Ill try to explain what I want. First of all, it is oriented to iso view, so some work with fake 2d is required (textured polygons to represent the ground). I wnat to make it independent of map structure, but at the same time I want to spare memory and avoid, if possible, having two data (user map, and engine representation of the map). I see a contradiction here, so I guess I ll have to provide some flexible enough map structure.
For example, you load map and feed it to the scene manager or something, if you add a tile then you specify texture, if it is passable and maybe later the height. If you add a geometry you specify the mesh to render…
Any suggestions about this?

baldurk 101 Aug 24, 2003 at 08:20

well, if you’re loading different maps, why not do it this way:

Generic Class to Load map: named “A”

Class to load map type 1 inherits “A”
…more classes to load map types…

then simply have them load the map type and convert it to an internal format. You just need to load user map, convert to an internal map, then remove the user map. You can also take a pointer to A, and point it at whatever map type, then just use virtual functions in A, derived in the other classes.

Of course, this way might not suit you, but it shows what you could do :).

anubis 101 Aug 24, 2003 at 12:34

think of this as writing different importers for different image/model formats…

baldurk 101 Aug 24, 2003 at 17:16

you could think of each class as a kind of translator, that translates your other map into your internal format.

Basically, any external map is converted into your version. You don’t have to keep the external map in memory, because you’re not using it. I guess it would even be possible to convert on-the-fly as you read the file, but depending on how close to your format the external is, that might be difficult.