Since most items, rooms, etc., in the game resolve to a unique ID, creating a class to encapsulate a room might be a little overkill in the object oriented department.
I'm not even sure that a room is complex enough to even warrant creating a class for it. A struct would probably do just fine since a room is essentially a data block.
A room in the map reduces to this:
- A description
- Items in the room
- Doors in the room
- Anything else relative to your game
Doors can be done with this:
Code:
struct Door
{
int iRoomID; //Room ID the door is in
int iRoomToID; //Room ID the door leads to
bool bLocked; //Is the door locked?
}
struct DoorKey
{
int iDoorID; //Door this key unlocks
int iRoomID; //Room the key is found in
int iDoorTypeID; //Alternate unlock ID that allows one key to unlock a set 'type' of doors
};
When the player goes through the door you check the door structure. If the player room ID is Door::RoomID then you set it to Door::RoomToID. If the room ID is Door::RoomToID then you set it to Door::RoomID.
Making everything in the game an object is not going to help you in the long run. Use very simple basic data structures for doors, rooms, etc. Classes should be reserved for complex items such as an inventory system, parser system, map system, etc, etc.
I also recommend you keep the map system simple. If you are going to create a room object then I recommend keeping them in a vector. The map can be a simple class that wraps a 2D array that contains integers representing room IDs. So if map[10,10] has the number 52 then you would request room 52 from the room manager or container and then display the returned data to the user.
Once you create a default standard way of displaying each room to the user you can simply call that function and pass in the room ID to display.
Code:
void RoomMgr::ShowRoom(int iRoomID)
{
....
}
I made this part of a RoomMgr class but you can do what you want. But as long as you have a function for this then you can simply change the ID of the room to display and everything works as it should.
Just my two cents. Just trying to caution you away from over object orienting your design. Objects are great but you don't want to create an overly complex system that is cumbersome to use and hard to maintain or extend.
The usual approach I see to managing objects here by many is to make an object and stick it into an array to create your map. The problem with this is that the objects are known only to the map and yet the map really doesn't care about the objects. A road map is a map that leads you to somewhere or shows you where to go. Your map should be much the same. If you reduce everything to integers as unique IDs then you can store all your objects in nice, neat container classes. Anyone who needs access to these objects just asks the container for it and you have a nice centralized way of creating, managing, and destroying your objects.
I would create lists or vectors of objects, items, descriptions, vocab, etc, etc that are populated at load-time. You can create a master manager class and derive from it for your various object managers or you can use one huge list (not necessarily an STL list). This also makes the data separate from the core engine code to run the game and will make your life easier. Figure out how you want the game to look and feel and how objects are going to interact with each other. Write it all down and then get to coding your newly developed system. The 'big picture' you have on paper will help a lot when you get to coding the other classes. If you don't have the 'big picture' you are going to code yourself into a corner pretty quick.
This might sound complex but it is a very good lesson in object oriented programming and will greatly improve your C++ and object oriented design skills. Knowing C++ is just half the battle. The other half is actually designing a class architecture that works.
