Sign in to follow this  
Mybowlcut

Design question

Recommended Posts

Hey! I have a level editor that I'm refactoring. I've chosen to re-factor it instead of re-write it, because even though it has a lot of issues, it refreshes my memory on what I was doing back then. So, I have a situation where I need to make a design choice. I have a class called XGeneric_Tile_Map (X means the refactored version of the class - I keep the old classes for reference). This class stores a vector of XTiles. Since this is a level editor and I need to edit stuff, I have derived a class from XGeneric_Tile_Map called XEditable_Level. XEditable_Level has functions that allow me to edit the level like Apply_Tile_Pen, etc. The problem is, I'm considering whether to derive a new class XEditable_Tile as well, and giving it a function like Editable_Update so tiles can handle being changed, or just checking for changes to XTiles inside XEditable_Level. So, what do you think I should do? Should the tiles check for themselves to see if someone painted over them or is that more appropriate for the level (XEditable_Level) to handle? Hopefully I haven't just dumped a whole mess here... I've tried to explain it clearly haha. Cheers.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mybowlcut
I have a level editor that I'm refactoring. I've chosen to re-factor it instead of re-write it, because even though it has a lot of issues, it refreshes my memory on what I was doing back then.

That's good. :)

Quote:
I have a class called XGeneric_Tile_Map (X means the refactored version of the class - I keep the old classes for reference). This class stores a vector of XTiles. Since this is a level editor and I need to edit stuff, I have derived a class from XGeneric_Tile_Map called XEditable_Level. XEditable_Level has functions that allow me to edit the level like Apply_Tile_Pen, etc. The problem is, I'm considering whether to derive a new class XEditable_Tile as well, and giving it a function like Editable_Update so tiles can handle being changed, or just checking for changes to XTiles inside XEditable_Level.

The X prefix approach is unnecessary. Consider using a source control system, or at least backup the old version. Keeping both versions around in the same project will likely lead to confusion at one point or another.

Anyway, rather than immediatly jumping into the technical details, it might be a good idea to first look at the big picture. What sort of tiles are we talking about? Do levels consist of tilemaps only? Do you have multiple, layered tilemaps? What is so 'generic' about that tilemap, anyway, that it needs to be named generic?

Personally, I would probably not even use a tile class at all, since a tilemap consists of a list of textures and a grid of tiledata, that simply stores indices into the texture list. Then again, if you're storing more data per tile, such as walkability, cover value or whatever else is specific to your game, a tile class might make sense. Either way, I don't see the need for an editable derived class - what exactly would that distinction gain you?

As for the paint logic, I'd put it in the level class. Having every tile check for input sounds a bit... inefficient, don't you think? :) Of course, if you're going with a tile class, you could

Share this post


Link to post
Share on other sites
Quote:
Original post by Captain P
Quote:
Original post by Mybowlcut
I have a level editor that I'm refactoring. I've chosen to re-factor it instead of re-write it, because even though it has a lot of issues, it refreshes my memory on what I was doing back then.

That's good. :)

Quote:
I have a class called XGeneric_Tile_Map (X means the refactored version of the class - I keep the old classes for reference). This class stores a vector of XTiles. Since this is a level editor and I need to edit stuff, I have derived a class from XGeneric_Tile_Map called XEditable_Level. XEditable_Level has functions that allow me to edit the level like Apply_Tile_Pen, etc. The problem is, I'm considering whether to derive a new class XEditable_Tile as well, and giving it a function like Editable_Update so tiles can handle being changed, or just checking for changes to XTiles inside XEditable_Level.

The X prefix approach is unnecessary. Consider using a source control system, or at least backup the old version. Keeping both versions around in the same project will likely lead to confusion at one point or another.

Anyway, rather than immediatly jumping into the technical details, it might be a good idea to first look at the big picture. What sort of tiles are we talking about? Do levels consist of tilemaps only? Do you have multiple, layered tilemaps? What is so 'generic' about that tilemap, anyway, that it needs to be named generic?

Personally, I would probably not even use a tile class at all, since a tilemap consists of a list of textures and a grid of tiledata, that simply stores indices into the texture list. Then again, if you're storing more data per tile, such as walkability, cover value or whatever else is specific to your game, a tile class might make sense. Either way, I don't see the need for an editable derived class - what exactly would that distinction gain you?

As for the paint logic, I'd put it in the level class. Having every tile check for input sounds a bit... inefficient, don't you think? :) Of course, if you're going with a tile class, you could


What does a source control system do? For now, it's easier for me to just keep them together as I can easily distinguish between the two and right now I don't have time off from uni to mess around... but I am interested to know what a source control system is anyway.

XGeneric_Tile_Map is just a way of saying a collection of tiles, with a camera that can move over them. The idea is that in the editor, there is a panel of all the tiles I can use... which can be represented by a class derived from XGeneric_Tile_Map. The actual level that you edit is represent by a class derived from XGeneric_Tile_Map (XEditable_Level). Tiles will eventually store passability information and other stuff so I really do need a tile class in this case.

The painting thing.. either way every tile that is in view of the camera (I keep a vector of XTile pointers called camera_tiles - which point to the tiles from the main vector of XTiles - that are in view of the camera for efficiency) is going to be checked... but I guess that if I did it the other way and made tiles editable... then it would be inefficient for each tile to check.. haha.

Share this post


Link to post
Share on other sites
A version control system allows to restore the state of your project given a date/time, a version number, or a tag. It furthur allows to branch the project, so you can start to implement a big change into a branch without disturbing the already running source (the so-called "trunk") or any other branches, and join the branch first when the feature is implemented and all of its hickups are corrected. So you can have various versions of the project in parallel, and you can go back in the history of the project. It is senseful especially if several people work together, but it is also senseful for one-person projects due to its versioning. Look e.g. at SVN.

However, coming to the original question, IMHO editing should not be part of the model classes itself. Instead, Editor classes assigned to the model classes should do the job, so that presentation and modification are distinct. Running the game with the model will not be bloated by editing stuff, editors can be loaded lazily, developing other/additional editors will be more comfortable, and the class hierarchy will be much more simple.

Share this post


Link to post
Share on other sites
A source control system records every change you make. If you made a mistake and saved the file all you have to do is revert. If you wanted to look at your code base at a certain date you can do that too. I wouldn't develop without one, although it only becomes very useful once a system is up and running, but since you are refactoring that's perfect. I recommend subversion with tortoisesvn if you are using Windows.

Consider delegation over inheritance. Also look into these links, when I embark on coding my engine these will be my first ports of call.

http://www.gamedev.net/community/forums/topic.asp?topic_id=468549
http://www.gamearchitect.net/Articles/GameObjects1.html
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
http://www.gamedev.net/community/forums/topic.asp?topic_id=463508
http://www.gamedev.net/community/forums/topic.asp?topic_id=473840
http://www.gamedev.net/community/forums/topic.asp?topic_id=489703

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this