Remove object cap.

Started by Pax Animo, Mon 24/01/2022 22:28:54

Previous topic - Next topic

Pax Animo

Hello,

So I'm currently working on a project that involves one long room, "very long room"

My problem is i'm to trying to avoid the caps on objects in rooms and instead I'm using characters, though this method currently works, it's tedious and drains me of effort.

The reason I'd like the object cap to be removed is it's much quicker to place an object rather than a character, (creating a new char, setting a new view, placing character in room,)

I understand that using a character rather than a object is better overall due to character script can be used outside of room script.

Note: objects can be used in global but with certain restraints, *unless I'm misunderstood* (the ID of the object has to be called)

The reason i ask is i just don't think i can handle the management of creating new characters every time i want to place a new object.

Another reason of why I'd like no object cap is: it's a quicker way to work with objects rather than creating multiple characters.

Edit: I forgot to ask, why is there a limit on objects in place?
Misunderstood

Crimson Wizard

#1
[REDACTED]

I'm sorry, I deleted my previous replies, because realized that did not give full picture of a problem (and potential solution), and what I wrote first may be interpreted incorrectly.

I will think about how to explain this better and post a new one.

I apologize for the possible confusion.

Pax Animo

The game is a side scrolling adventure.

The plan was to have one long room with lots of small areas,  the reason i wanted to use this approach was to give a more open world feel.

After taking in everything that you've replied with and having a now better understanding of why there is a cap, i shall take a different approach.

The game is pretty much a porotype at the moment so plenty of time to rethink the structure.



Misunderstood

Crimson Wizard

#3
So, trying to clarify the situation.

Technically, the limit of room objects may be removed. This would require rewriting some parts of the engine, where program is relying on object list having a fixed size. Also changing something in the script API, where the global array of room objects (declared as "Object object[];") may be replaced either with a dynamic array (like "readonly Object *object[]") or a property in Room class (like "readonly attribute Object *Room.Objects[];"). Either way has its pros and cons, but either this is doable.

The problem, however, is bigger than simply the number cap.
The room objects in AGS are "static", in the sense that they are only created in the editor. They cannot be created or deleted in script, during game run. All of them also stay in memory all the time, and part of their state is also kept in memory even after player leaves (unless that's a non-state-saving room, one with number above 301).

In this situation, if we remove the object cap completely, I'm afraid that will encourage misuse of AGS. People who would want to create non-adventure games, such as arcades, strategy games, or other kinds of gameplay involving very large amount of objects, would simply set up hungreds of these or more in the editor, not realizing that they are using an inefficient method, resulting in suboptimally made games.
You may of course say that's it's better than not being able to create a game at all, but I beg to differ. It's been said that AGS is a hobbyist tool, many AGS users sadly do not have a full understanding of program work. In the past I witnessed on many occasions how people create games in a way that seem most straightforward for them, but is often inefficient, leading to bad habits and badly optimized games. This may not be always noticeable on PC, especially with small games, but becomes pretty clear when the game becomes bigger, or is ported, for example, to mobile or console device with lower capabilities.

What I believe is that the true solution lies in featuring dynamically created objects: when you may create these objects as these come into play and delete them as they are no longer necessary. This is of course going to be a significant change in paradigm for AGS, but would allow to make non-point&click games easier and more efficient.




Before that is done, there are still methods to achieve "open world" games in AGS. They are not as straightforward, but feasible.

One method that I may mention is called "object pool". I personally used it myself when making couple of arcade games in AGS, and maybe other people did in the past.
The idea of this method is to reuse same list of objects, moving them into player's view and away from the visible room bounds, assigning them different look and roles.

This method is not a "dirty hack", and not specific for AGS, other engines use it too sometimes. Even creating and deleting objects dynamically sort of work as an object pool internally (or maybe, "logically").

I was planning to publish my arcade script at some point, demonstrating this, but did not manage yet. The games I worked on belonged to other people, and i'd have to detach my scripts from these games and set up some dummy art, etc, so that would require time. But I have posted a simple module that helps to keep the track of "object pool": https://www.adventuregamestudio.co.uk/forums/index.php?topic=58853.0

The biggest issue with this, and similar approaches is that you cannot configure starting object positions in the editor. Instead you'd have to setup these as either a script data, or in custom files. For these kinds of games it also may be better to create your own level editing, either make an in-game level editor, or a separate tool if you know how to.

Pax Animo

#4
Quote from: Crimson Wizard on Tue 25/01/2022 19:02:49

if we remove the object cap completely, I'm afraid that will encourage misuse of AGS. People who would want to create non-adventure games, such as arcades, strategy games, or other kinds of gameplay involving very large amount of objects, would simply set up hundreds of these or more in the editor, not realizing that they are using an inefficient method, resulting in suboptimally made games.
You may of course say that's it's better than not being able to create a game at all, but I beg to differ. It's been said that AGS is a hobbyist tool, many AGS users sadly do not have a full understanding of program work. In the past I witnessed on many occasions how people create games in a way that seem most straightforward for them, but is often inefficient, leading to bad habits and badly optimized games. This may not be always noticeable on PC, especially with small games, but becomes pretty clear when the game becomes bigger, or is ported, for example, to mobile or console device with lower capabilities.

This is most likely where I'm going wrong, i was thinking that using objects as just a one time place object and then forget about it, but i could later on move objects around if needed and also it's easier to work with objects and characters when it comes to interactions and walk behinds. An example been having say a large room with many interactions but the room is just one background sprite, i guess here i have to start using hotspots which also have a cap of 50 i think it is, on top of that I'd need to start using walk behinds which is horribly tedious when it comes to the paint walk behinds tool, baselines of objects and characters are easier to work with.

As you say regarding AGS been a hobbyist tool, i'm always keeping that in mind as there is no need to go out of the way for the engine to change it's behaviour for a small percentage of users.

Edit: Also i'm guessing it's most likely bad practice to use multiple characters instead of objects is not the way to go.
Misunderstood

Crimson Wizard

Another interesting option that may complement objects is room overlays. We may say that AGS has two "layers" or "spaces": GUI space and room space. These have their own coordinates and their own object sorting.
Overlays are dynamic objects that may be created and deleted at will. They are currently existing in the "gui space", always above the room. Since 3.6.0 Overlays may also sort among GUI, so their use is improved.

It should be possible to support creating overlays in the room space, where they will be positioned in room coordinates, and sorted among the room objects and characters.

As overlay is nothing but a sprite, with no built-in interaction or advanced behavior, these are ideal for temporary visual effects.

SMF spam blocked by CleanTalk