Picking up and dropping objects

Started by Cassiebsg, Sun 08/07/2018 19:38:43

Previous topic - Next topic

Cassiebsg

Quote from: fernewelten on Sun 08/07/2018 19:08:37
In a P&C adventure, OTOH, life isn't that easy. For once, if room X features the objects A, B, and C, then the objects will only be known in room X. Thus, when Ego walks to room Y, it's hard to show the object A lying on the floor. At the very least, the dropping functionality is a big hassle in P&C games.

@fernewelten ... well that can easily e solved! You just have to stop thinking of objects (in the literary sense that the player can pickup) and make them characters in code. For the player they'll still be "objects" but in code they are characters. there are no limits for characters, and you can drop them in any room, since they're not attached to a room. ;)
There are those who believe that life here began out there...

Crimson Wizard

#1
Quote from: fernewelten on Sun 08/07/2018 19:08:37
In a P&C adventure, OTOH, life isn't that easy. For once, if room X features the objects A, B, and C, then the objects will only be known in room X. Thus, when Ego walks to room Y, it's hard to show the object A lying on the floor. At the very least, the dropping functionality is a big hassle in P&C games.

Frankly I find this incorrect to assume that it's game being P&C that makes dropping items difficult to implement, or that objects are restricted to one room because it's P&C. Of course this is related to particular engine capabilities. If we take AGS, it simply was not prepared for this, but as Cassiebsg pointed, you may still use Characters as dropped items, since Characters are efficiently objects that can move between rooms.
There is a recent thread related to implementing "Legend of Kyrandia"-like item mechanics in AGS: http://www.adventuregamestudio.co.uk/forums/index.php?topic=55827.0

fernewelten

Quote from: Crimson Wizard on Sun 08/07/2018 19:55:34
since Characters are efficiently objects that can move between rooms.

This is slightly off-topic here, but I've always wondered: If objects essentially are dumbed-down characters that are inefficiently implemented, why does the AGS compiler use objects at all? Characters could be used throughout, and the language wouldn't need to be modified in any way for this: Whenever the programm would ask for an “object”, a malloc for a Character could be compiled behind-the-scenes instead: “So, here's a pointer to your ‘object', use that”. Whenever the program wants to move the “object”, generate a call to Character.Move instead of a call to Object.Move. All the inefficient Object methods thus would simply be ignored. Then the next step would be to drop all the Object methods from the libraries, retaining only the Character methods.


Crimson Wizard

#3
Quote from: fernewelten on Sun 08/07/2018 22:54:15
This is slightly off-topic here, but I've always wondered: If objects essentially are dumbed-down characters that are inefficiently implemented, why does the AGS compiler use objects at all?

I assume you are not asking why Chris Jones made Objects a thing in AGS, but rather should not we remove them? Because the answer on the first question is probably simply because he was emulating old Sierra games.

Personally I would not agree that removing Objects is a proper thing. Imho that's a good idea to have a basic "sprite" holder in your game that does not have any excessive behavior. Characters may have additional setup, such as talking, walking, automatic idling animations, inventories, and so forth, that would be a dead weight if they are used like objects. On the other hand, in the past we actually had a suggestion to make Object a base class for a Character.
If you'd check out new MonoAGS tzachs is currently working on, it also has a distinction between Objects and Characters.
The "inefficiency" with objects in AGS is that you cannot move them around the game or reference from another room, but that's implementation issue that could be resolved.

Radiant

Quote from: fernewelten on Sun 08/07/2018 22:54:15
This is slightly off-topic here, but I've always wondered: If objects essentially are dumbed-down characters that are inefficiently implemented,

They are efficiently implemented, in that they do not contain properties or actions that you generally don't need (for an object). LucasArts does the same thing (using the terms 'actor' and 'prop' for character and object, respectively).

tzachs

Quote from: Crimson Wizard on Sun 08/07/2018 23:24:07
If you'd check out new MonoAGS tzachs is currently working on, it also has a distinction between Objects and Characters.
The "inefficiency" with objects in AGS is that you cannot move them around the game or reference from another room, but that's implementation issue that could be resolved.
Right, just to be clear, in MonoAGS this is already "resolved", you can move objects between rooms and reference them globally just like characters.
Also, characters are just an extension of objects with more skills, so you won't see quirky syntax differences like in AGS (for example: Character.x vs Object.X) and you can pass in a character to any function that accepts an object (GUI controls are also just extension of objects btw, so same rules apply to them as well).

fernewelten

Quote from: Radiant on Mon 09/07/2018 09:06:53
They are efficiently implemented, in that they do not contain properties or actions that you generally don't need (for an object).

I'm probably wrong, but my understanding so far was that objects have a hard limit per room because they really slow down the engine; characters, OTOH, do not slow down the engine that much and are unlimited.

As I understood, the recommendation is: If you need lots of objects in one room, use characters instead.

So I assumed that there's something with objects that eats computing cycles, whereas characters doing the exact same thing in the exact same way in the exact same quantity do not eat the computing cycles.

This is why I called objects “inefficient, dumbed-down characters” and wondered why those objects then were in use at all: After all, if the game writer can replace objects by characters, then the AGS compiler might do the same thing behind-the-scenes for them. That is, whenever the AGS code asks for an ”object”, hand out a character instead, and whenever the the AGS code wants the ”object” to do something, use the corresponding function that works with characters instead. Then the code that eats the computing cycles, whatever it is, wherever it hides, simply wouldn't be called.

I agree that this would be a stupid, memory-wasting kludge to short-circuit the object handling code. But if the object handling code turns out to be that klunky and deadweight and that's how it is... (roll)


Crimson Wizard

#7
Quote from: fernewelten on Mon 09/07/2018 17:35:09
I'm probably wrong, but my understanding so far was that objects have a hard limit per room because they really slow down the engine; characters, OTOH, do not slow down the engine that much and are unlimited.

I am honestly confused by this, did you read about this somewhere on forums? :confused:
No, there is really no reason for why objects would be exceptionally slower than characters. Because they are drawn essentially in same way, and in terms of internal processing characters require more time, since there's more features to check (but even then this difference is generally negligible).

Of course very large number of objects on screen could slow the game down, but so do characters. I'd make a guess that characters were unlimited  because in adventure games they are often in different rooms, and rarely appear in large quantities at once (at least such argument seem reasonable).

The object limit per room today is simply a relic of the past, the only reason it was not removed is... Ok, I do not even remember what. I did that in one experimental version earlier, but later scratched that being not very happy about the code. Probably that was a wrong thing to do. It could be done again.
Another issue is that object selection in the editor is not very convenient, but new navigation bar in 3.4.2 wip version (by tzachs) should perhaps fix that.

SMF spam blocked by CleanTalk