Recent

Author Topic: Oject arrays in other objects  (Read 1066 times)

MystikShadows

  • Newbie
  • Posts: 3
Oject arrays in other objects
« on: July 14, 2024, 04:21:27 pm »
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

  • Hero Member
  • *****
  • Posts: 8035
Re: Oject arrays in other objects
« Reply #1 on: July 14, 2024, 05:19:24 pm »
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MystikShadows

  • Newbie
  • Posts: 3
Re: Oject arrays in other objects
« Reply #2 on: July 14, 2024, 05:37:21 pm »
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

  • Hero Member
  • *****
  • Posts: 8035
Re: Oject arrays in other objects
« Reply #3 on: July 14, 2024, 07:35:24 pm »
"You are in a maze of twisty little passages, all different..."

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Eugene Loza

  • Hero Member
  • *****
  • Posts: 729
    • My games in Pascal
Re: Oject arrays in other objects
« Reply #4 on: July 14, 2024, 08:48:17 pm »
Quote
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.
My FOSS games in FreePascal&CastleGameEngine: https://decoherence.itch.io/ (Sources: https://gitlab.com/EugeneLoza)

MystikShadows

  • Newbie
  • Posts: 3
Re: Oject arrays in other objects
« Reply #5 on: July 16, 2024, 08:48:12 pm »
Thanks so much Eugene. I see what your saying yes. makes perfect sense yes.

Zvoni

  • Hero Member
  • *****
  • Posts: 2747
Re: Oject arrays in other objects
« Reply #6 on: July 17, 2024, 08:32:55 am »
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
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

 

TinyPortal © 2005-2018