Oject arrays in other objects

[MystikShadows]

Please Move to Another thread if you see fit.

I'm not quite sure what i man. but here goes. I have a room object that I plan on using an array of object in the building class. lets say its a 20 story building with say, to make it easier, 25 1 room appartements.  so it needs to be a 25x14x5 layout can i represent that as a 20x14x5 array. or would you think i better crate 14 floors in which i set the room in? how you you all organize this mess?

Tank you for your time.

[MarkMLl]

I'm only sitting down for a moment, so aren't going to try to write even pseudocode... just try to assure you that it doesn't look like too much of a problem.

A room object (an instance of the TRoom class, let's say) has various properties: definitely what floor it's on, but possibly also its dimensions, its connectivity to other rooms, and whether it contains a grue or no.

A floor object (an instance of the TFloor class, let's say) has various properties: definitely what building it's in, but possibly also its number (basement, ground, first and so on using British terminology), its connectivity to other floors, and a dynamic array containing multiple TRoom objects.

A building object (an instance of the TBuilding class, let's say) has various properties: definitely some sort of location information, and a dynamic array containing multiple TFloor objects.

There's lots and lots and /lots/ of ways you could dress that up with indexed properties and so on. Or if you don't particularly want to go the OO route you could have a 3-dimensioned dynamic array. Or if you really do know how many rooms etc. there will be you could use static arrays with fixed sizes.

HTH.

MarkMLl

[MystikShadows]

Thank you, If I wanted to say simulate the: https://www.imdb.com/title/tt0123755/ i would need just 1 3dimintional array. the thing is well not a must but i know i could serialized this to save it. I can do it either way though.

[MarkMLl]

"You are in a maze of twisty little passages, all different..."

MarkMLl

[Eugene Loza]

how you you all organize this mess?

Usually the organization comes from "what should be done". I personally prefer to separate data and methods. This way (let's imagine we are making a game) it would be (almost pseudocode, not tested):

Code: Pascal  [Select][+][-]

1. type
2.   TMapArray = array of Byte;
3. type
4.   TMap = class(TObject)
5.   private const
6.     SizeX = 25;
7.     SizeY = 14;
8.     SizeZ = 5;
9.   strict private
10.     FMap: TMapArray;
11.   public
12.     function SaveToString: String;
13.     procedure LoadFromString(const S: String);
14.     function GetCell(const X, Y, Z: Integer): Byte; inline;
15.     procedure WriteCell(const X, Y, Z: Integer; const Value: Byte); inline;
16.     constructor Create;
17.   end;
18. var
19.   Map: TMap;
20.  
21. constructor TMap.Create;
22. var
23.   I: Integer;
24. begin
25.   SetLength(FMap, SizeX * SizeY * SizeZ);
26.   for I := 0 to Pred(Length(FMap)) do
27.     FMap[I] := Random(255);
28. end;
29.  
30. function TMap.GetCell(const X, Y, Z: Integer): Byte;
31. begin
32.   Exit(FMap[X + SizeX * Y + SizeX * SizeY * Z]);
33. end;
34.  
35. procedure TMap.WriteCell(const X, Y, Z: Integer; const Value: Byte);
36. begin
37.   FMap[X + SizeX * Y + SizeX * SizeY * Z] := Value;
38. end;
39.  
40. function TMap.SaveToString: String;
41. var
42.   S: String;
43.   I: Integer;
44. begin
45.   S := '';
46.   for I := 0 to Pred(Length(FMap)) do
47.     S += Char(FMap[I]);
48.   Exit(EncodeStringBase64(S));
49. end;
50. procedure TMap.LoadFromString(const S: String);
51. var
52.   DecodedString: String;
53. begin
54.   DecodedString := DecodeStringBase64(S);
55.   SetLength(FMap, Length(DecodedString);
56.   Assert(Length(FMap) = SizeX * SizeY * SizeZ);
57.   for I := 0 to Pred(Length(FMap)) do
58.     FMap[I] := Ord(DecodedString[I]);
59. end;
60.  

Note that I'm using a "linearized" array above. This might be confusing at first, but it pays back later, especially when your "cube" grows larger or you need to do complex operations on it, like pathfinding.

Also as you see, FMap contains only data. It's game logic that will decide what happens when the Player enters this specific cell. Ideally it should be a simple structure, to be de/serialized easily and reliably, like in SaveToString and LoadFromString above.

In some cases it might be reasonable to have more information in every cell. E.g. positions and states of all monsters and items inside. Then you won't be able to "cheat" and will have to write de/serealization of each cell separately. It all depends on your specific usecase. But the idea is to start as simple as possible, and go advanced only in case it is really needed.

[MystikShadows]

Thanks so much Eugene. I see what your saying yes. makes perfect sense yes.

[Zvoni]

How to organize such a "mess" (Your words, not mine ) would depend how i would approach the programming.

i usually come from a Database-Approach (as weird as it may sound) regarding Normalization.

If it's the full OOP-Approach (see Mark's Answer):
Using Mark's example, TBuilding would be a Master-Table to TFloor, with TFloor having a Foreign Key to TBuilding, and TFloor being a Master to TRoom, with TRoom having a Foreign Key to TFloor.
Then i would sort out, which Attributes belong to which "Table" and so on.
Then it's easy (at least for me) to "reverse engineer" those "tables" back to Classes/Objects, and how they connect to each other, and which Property and/or method goes where.

Going the "simple" way:
A simple "table" holding all the information. Think having JSON-Objects as "content" of fields.
e.g. you have such a simple table called "TBuilding", and each record in that table represents a Floor.
you would have a Field "FloorNumber" and so on.
and one Field would be a JSON-Object containing all the TRoom's, with all its attributes

Bottom line: I would first analyze how the data is laid out you want to process.
If you have that, and decided which approach, it becomes more or less self-explaining