The inventory in video games, when grabbing objects

Started by Santiago, March 04, 2023, 13:32:14

Previous topic - Next topic

Santiago

hello, many times I have the unresolved dilemma of what is the best way to have an inventory of objects in units.

I wonder if I should use a FIELD inside the TYPE UNIT


type unit
    field pivot
     field entity
     field vel#
     field fuel#
      field inventory$[64]
end type



sometimes you have units that can have a lot more items inside than others. and sometimes it seems unoptimized to have 64 [64] empty spaces, when you have a unit that can only grab one object.

and then you have a vehicle that can carry much more.

and all this, it should be easy to save and load every time I use the game

What do you usually use?

Derron

Can't you have a custom type "inventory" ? so there might be "Null" if it has no inventory at all, or "TEndlessBag extends TBag" with unlimited inventory slots etc.


bye
Ron

RemiD

@Santiago>>
you should really not overthink such things, nowadays widespread computers have a lot of system ram.

consider this :
a byte variable uses 1byte
a short variable uses 2bytes
an integer variable uses 4bytes
a float variable uses 4bytes
a string variable use 1byte + number of chars (if i remember correctly)

most computers have at least 1-2gb of sram, and 1gb is 1,000,000,000 bytes.

what else to say ?

Santiago


Derron

Not otherthinking will sooner or later lead to stuttering  - if they decide to have particles based on units and then spawning thousands of them in a GarbageCollector-managed environment (or similar things).

Avoid mistakes right from begin - but do not overcomplicate things if not _needed_. If most units do NOT have an inventory, do not reserve so many slots. Think of what could be the "biggest" use case and how likely these things are. If they are unlikely then it is not good to reserve memory. Offload into extra objects ("inventory:TInventory"). This also helps to encapsulate things (take / give / limit...).

bye
Ron

RemiD

@Derron>> sure, it is better to do a quick calculation of the most ram the app may use.

in this case :
(considering blitz3d has no byte variable and no short variable (storable in a custom type or in a dim array), so these will be declared as integers)

for 1000 entries of the custom type 'unit'
(4+4+4+4+64*4) * 1000 = 272,000bytes... ;)