Support Room points

[ericoporto]

Describe the problem Adjusting NPC characters path and destinations is a bit hard once you change art, since all points are hardcoded when scripting mostly.

Suggested change Support a new room element, points, and have some way to give a script name to these points. And in Script, add Character.WalkToPoint(Point* p).

They could perhaps not even be part of room.crm but perhaps just manifest somewhere in the room script when compiling.

Alternatively, they could generate macros so it that points could be used in x, y type of function parameters: #define POINT_A 32,64

[ivan-mogilko]

They could perhaps not even be part of room.crm but perhaps just manifest somewhere in the room script when compiling.

Alternatively, they could generate macros so it that points could be used in x, y type of function parameters: #define POINT_A 32,64

Would not this end up as a potential cause of conflicts, if it's located in the script which user may freely edit? If done through script, this would likely require a separate autogenerated script, which is merged or linked with the room script somehow.

[fernewelten]

I've been doing a poor man's version of that idea in all my recent games:

• At the start of the room file, define some Points as global variables with descriptive names.
• At room_Load, initialize these.
• Within the rest of the room coding, make characters systematically walk to DescriptivePointName.x, DescriptivePointName.y instead of to explicit numeric values.

This works, kind of, but it's very labour-consuming, and I'm unhappy that I can't see nor move the point co-ordinates within the room editor, similarly as the WalkToX, WalkToY coordinates of Hotspots.

[ericoporto]

Sorry, I should have been more clear, I meant since ags4 offers a different storage for the room information in the xml file, it could be in autogenerated script that would merge with rooms script, and then there's no need for modifying the .crm room format. About the macro mention, that is only a suggestion in case adding a point variant to the relevant parts of the script API is not feasible - for whatever reason.

I imagine in the room Editor the point could have the it's name visible and a clear mark of where it is.

I'm unhappy that I can't see nor move the point co-ordinates within the room editor

Yeahp, that is exactly why I thought of this. Maybe the points could even be grouped in the Editor so you could select a bunch to move around together.

[messengerbag]

Yeah, (some version of) this would be a great QOL improvement for game makers.

Would it also be possible to make these Room variables accessible from other scripts somehow? That way you could do things like changing rooms with a certain point as the destination, without having to hard-code the coordinates. (Cf. forum thread.)

[fernewelten]

If we do this idea, then room points would be similar to room objects. So shouldn't they be implemented similarly to objects, too?

• Create a point[] array similarly to the object[] array and initialize the entries, per room, at game creation time.
• Declare individual points in an autogenerated script and include this script automatically at room compilation time.

[messengerbag]

Maybe I shouldn't have brought it up here. I don't want to derail the proposal, but I thought it might be relevant to consider future extensions in deciding on the API and implementation.

Your proposal, @fernewelten, is the solution closest to legacy features (though in any case it requires a fundamental change since we need to be able to access the points in the target room, not the current room), but I don't think it's the best API from a user POV. It certainly doesn't make for particularly self-documenting code. In general I think it would be better to move away from relying on indexed arrays and towards using named variables by preference. So I suggested an API that could be used something like:

player.ChangeRoom(rmStudy, rmStudy.xyDoor, eDirectionDown);

Admittedly it's a little tricky to make something like this within the AGS model. You'd probably want rooms to be instances of a common struct with common methods and properties (a lot of what is currently in the static Room struct; and yes, a room[] array to iterate through them), but you'd also want to access their individual properties (objects, hotspots, points, …) directly by name, as in this example, and these would of course be individual to each room. Perhaps you could make each room its own "sub-struct" that extends a common Room struct.

[AlanDrake]

This could also be done as a module that provides some ingame debugging tools to create/remove points, saving them on a Dictionary. What's missing, in that case, would be the ability to persist this data inside the project, rather than volatile user folders.

I don't agree with letting devs access variables or objects from other rooms. The correct way is using proxy variables/functions to deal with these things. Rooms are Scenes, and I have never seen any engine allowing users to freely meddle with other unloaded Scenes directly.

I'm suggesting this because modifying points visually from the editor, is only marginally better compared to the immediacy of being able to alter values directly ingame.

What's really needed is exactly that, a flexible mechanism to adjust arbitrary values, not just points, directly ingame, and persist them in the project. Currently we lack this capability, which could be made to work only in debug mode, as the only access to project data is $DATA$, which is readonly.

[ivan-mogilko]

I'd like to add, that perspectives of accessing any Room contents at this point in AGS are unclear, because: 1) AGS is designed so that the rooms are optional. They are not required to be present for the game to compile, and they theoretically may be added to existing game, or replaced freely. This makes declaring anything about rooms in the global scope complicated (if not impossible). 2) As @AlanDrake mentioned, the room contents are not accessible when the room is not loaded. From the implementation pov, this might be technically possible, as "room states" have to be stored in memory for all the visited rooms (this is where the distinction between state-saving and non-state-saving rooms come from) in order to restore them when player comes back. But this is done only for certain parts of rooms, not all of them (probably in sake of saving on memory); and is not logically purposed for the script access at the moment.

Overall, accessing anything in other rooms would require a serious redesign of how AGS handles rooms.

[morganwillcock]

It would be interesting to hear arguments against using an invisible room object, because I can't think of what a dedicated Point object is adding in terms of behaviour, only that it is a simpler variant of an existing object.

i.e. If deciding to use an invisible object and positioning or moving it is inconvenient why not just fix that and change the default sprite to a corner pointing arrow instead of a cup?

(I would guess that the core problem is more when the user decides to use an object as a point marker and how that relates to how objects are pre-instantiated and already referenced in scripts).

[messengerbag]

I don't agree with letting devs access variables or objects from other rooms. The correct way is using proxy variables/functions to deal with these things. Rooms are Scenes, and I have never seen any engine allowing users to freely meddle with other unloaded Scenes directly.

I don't know about "meddle" (I don't think these values need to be editable in any way), but I think there are some parts of the room info that ought to be available from outside the room—especially given the way AGS handles ChangeRoom(), with the API encouraging users to define the entry location when calling the function, outside of the room. That info includes room dimensions (Height/Width), probably room edges, and—if added—defined room points. Proxy variables and functions can only offer clumsy and tedious workarounds.

AGS is designed so that the rooms are optional. They are not required to be present for the game to compile, and they theoretically may be added to existing game, or replaced freely. This makes declaring anything about rooms in the global scope complicated (if not impossible).

Yeah, but this is a silly design decision that hardly any games actually make use of—if any at all. (Again, the limitations on accessing data from outside the room makes it almost useless: you can only test whether the room exists—no room name, no coordinate to e.g. place on a map; you can't even get a list of available rooms without actively checking every number from 1 to [some defined maximum]—so there is no way to offer elegant navigation to added rooms. And that check for room existence is only introduced in 3.6, so there has never been an official AGS release that offers any safe way to offer navigation to non-pre-defined rooms.*) It shouldn't restrict improvements.

Overall, accessing anything in other rooms would require a serious redesign of how AGS handles rooms.

Yes, I realize that. I guess that's what I'm proposing. Though I'm not arguing that it is a requirement for this issue. Just something to keep in mind in choosing how to solve it.

(*I guess pre-3.6 you can use File.Exists(), and you could bundle a separate "room manifest" data file with external room info, but it gets very hacky.)

[ericoporto]

I really thought of something with a much smaller scope that could make use of the flexibility of xml room files, but I disagree it's only marginally better, being able to visually set something in the Editor is really useful. It's #1175 again.

[AlanDrake]

It's marginally better because switching from game to editor to adjust values is the bigger overhead. Just imagine how it'd be implemented... another room mode layer with property grid and dropdown. It may be better than merely copying mouse coordinates into a #define but on practical terms, you're still going to switch back and forth from the Editor to Game for fine-tuning. But now, you are forced to go back into the room editor, and fiddle with the visual interface or property panel to update the coordinates in the property panel.

It's not simple finding better workflows... I too have been cutting my hands while trying to find the best solution to handle door-room handling/management, global room states, and simple coordinates.

We lack facilities to enable management of custom data, conveniently and effortlessly. Though it's possible to use custom data files, I feel we need some kind of solution that could allow both editor and engine to manipulate this custom data, or even room design props.

Maybe we should shift this discussion toward designing a module that does this, and see what we lack from the engine/editor side to make it work. It's a different scope, but if we had that, we could solve this and other weaknesses.

[ericoporto]

Maybe we should shift this discussion toward designing a module that does this

The only one I remember is God Mode

https://user-images.githubusercontent.com/2244442/206012647-cd95e7de-b27f-42ff-af70-045074a27b13.mp4

But if we had points in the room editor, it wouldn't be hard to also have polygons, and with these we are not far from Tiled, and with polygons I can have physics.

[ivan-mogilko]

Again, in addition, now in regards to the API:

@fernewelten

Create a point[] array similarly to the object[] array and initialize the entries, per room, at game creation time.

@messengerbag

In general I think it would be better to move away from relying on indexed arrays and towards using named variables by preference.

I propose to develop certain principles for any future API. A while ago I wrote this fantasy draft, where the suggested principles (relevant to the above problem) are:

• Any kind of object can be created at both design and runtime;
• The scene or any part of it may be saved and loaded at both design and runtime.

This makes raw arrays undesirable in the long run. Also, I opened a proposal to deprecate object[] and similar arrays for another reason too (see #1729). If iterating over all the objects of certain type (or accessing using a numeric index) is still wanted, this may be achieved using a function or an indexed attribute (e.g. see Game.AudioClips[]), which hides the internal storage implementation.

[messengerbag]

It would be interesting to hear arguments against using an invisible room object, because I can't think of what a dedicated Point object is adding in terms of behaviour, only that it is a simpler variant of an existing object.

I guess the argument against it is that it's rather non-obvious. As in, will users think to actually employ invisible objects in this way, as mere storage for coordinates? I certainly never have, in all my decades of using AGS. But yeah, it is a good solution.

[fernewelten]

I certainly never have, in all my decades of using AGS. But yeah, it is a good solution.

No wonder, objects were a scarce and limited resource. And the current 3.5 in-game manual claims (under the title “Animating background scenes” in “Advanced room features”) that “Objects slow down the game - the more objects on the screen, the slower the game runs”.

[ivan-mogilko]

@ericoporto, since you are proposing something that exists only in the project data format and script (will not be part of the engine's room, will not be an engine's object), have you considered a Editor plugin?

I don't remember if this is supported right now, but if Editor plugins could add room layers for display and interaction, what remains is generating scripts, which they also can do.

I have a thought that if Editor API would be enough, then plugins may be used to test and flesh out ideas more easily than trying to integrate things right into the Editor itself from the start.

But if we had points in the room editor, it wouldn't be hard to also have polygons, and with these we are not far from Tiled, and with polygons I can have physics.

Not sure how much of a priority this is overall, but it would definitely make sense to write some kind of a draft, outlining the proposed future goals, because if we start adding these piece by piece without seeing a bigger picture, the things will quickly turn into the mess. First we'll add Points without knowing about polygons, then start adding polygons, and find out that we should have done things differently with points, and so on. You seem to have certain idea, but we do not know it, and the above sentence raises questions. What is "Tiled"? What about physics, are you speaking of writing physics in script, or having integrated physics support in the engine? How having points and polygons specifically in the room editor will help with physics? (Why not write a custom level editor? several people did that in a form of AGS games.)

[ericoporto]

Sorry, the subject evolved, plugins and other stuff it's all a possibility, Tiled is the name of the external editor I currently use.

But going back to points it's something I always thought about, but I really only realized it's not only my problem when I watched the most recent dev stream from Dave here: https://youtu.be/r1hfcSkoHgg

You can see the workflow of copy and pasting points between the room editor and the script editor A LOT.

[ivan-mogilko]

EDIT: sorry, I decided to remove my previous answer, after realizing it does not add anything of essence to what has been said above by others.

Overall, I think, one important thing to decide here is whether were are talking about: 1) a design-time tool, which automates writing a script (and maybe generates some custom game data). In which case this may be achieved as a combo of editor plugin and a script module, for example. 2) a new full game entity. In which case both editor and engine should be aware of this, and engine should also provide some API for working with it.

[ericoporto]

Hey, it took me a bit to get it working again, below is an example I made for my own AgsBox2D plugin, here you can load your room background (for dimensions purposes) and add rectangles (it could have other polygons, but I haven't added them yet), and then it will generate the necessary code to create those in AGS Script

https://ericoporto.github.io/agsbox2d/

(This is why I mentioned physics in the previous answer)

---

About option 2, what do you mean with new full game entity? Like, if it could be created with the current script functionalities, is it the same case?

I also may have started this with a wrong assumption. We don't have an already pre-generated script that gets merged with the room script? For some reason I thought the script instances that appears extra in the autocomplete when editing a room script were part of a generated script that was merged somewhere behind the scenes when compiling - like import Object* oBlueCup and stuff like that. But maybe it is, but since we can't use new in script scope (only function scope), we can't initialize a point in pure script in this case.

[ivan-mogilko]

About option 2, what do you mean with new full game entity? Like, if it could be created with the current script functionalities, is it the same case?

Like something that engine is aware of, and provides means to create it, and so on. But I guess that hardly makes sense in case of a Point, which is just a struct with 2 ints, fully declared in the script header, and does not require any behavior (like drawing). Maybe it would make more sense if this was a part of a Room struct, provided by the engine, but it's hard to tell.

We don't have an already pre-generated script that gets merged with the room script? For some reason I thought the script instances that appears extra in the autocomplete when editing a room script were part of a generated script that was merged somewhere behind the scenes when compiling - like import Object* oBlueCup and stuff like that.

There's a pregenerated room header, which contains these declarations. (Tool crm2ash generates this, for instance, from crm, but in ags4 we need a newer tool that would generate same from the xml.) But it does not have a script body, and does not need one, as all of these objects are created by the engine itself.

But maybe it is, but since we can't use new in script scope (only function scope), we can't initialize a point in pure script in this case.

For that purpose you may generate a script that contains init function, for example game_start. "Global Variables" pane does this in order to initialize Strings. (This is also what agf2glvar tool does.)

For rooms - this is under question. If this is generated as a global module, then you could use on_event with eEventEnterRoomBeforeFadein event. If you'd like this to be a part of the room script... firstly, AGS does not support having multiple scripts per room at the moment, secondly functions like room_Load must be linked to room events in crm. So in such case a number of things ought to be redesigned.

[ivan-mogilko]

Back when this discussion was going on, I was probably way too occupied by finishing 3.6.0, so did not have much time to think all this through. So only gave formal comments about existing options.

Re-reading this conversation and trying to look at this from a larger perspective, I think that there were 2 problems mixed in here:

1. Have a new type of object, with a purpose of marking a location in the room. It's definite that this will be useful on its own regardless of other use cases, as it's much more convenient to have a visible object, optionally with extra hints, that you may align in the editor, and optionally even display in the engine too in a "debug" mode.
2. Have an ability to generate custom script with object declarations and initializations. This refers not only to generating these "points", but, in a perspective, anything else, such as, for example, geometry and physical objects generated by plugins.

My proposal would be to separate these two tasks, as one is the intent, and another is specific method which may have both uses and restrictions depending on a case. There's also a consideration about having short-term and long-term goals and benefits. That is - having these "location markers" would be instantly quite beneficial for users, regardless of how they are implemented, even if in a temporary way (keep in mind that we have an import/upgrade process mostly fleshed out for both project and compiled data). Even if we have this object added to a compiled room data, imho that's not a big problem, as the crm is initially an extendable format: it's already based on "components" which may or may not be present in a file.

@AlanDrake 's argument regarding the workflow, where you have to test in the engine but switch to editor for adjusting things, is a valid one of course, but this is a general problem with literally anything really; it's not related strictly to "room locations". Having these "locations" implemented will not change anything, won't make things better or worse in this regard. I think this workflow should be a topic of a separate big discussion, as it likely involves ability to edit game data from within the engine (or similar tasks).

---

Let's assume that we want to follow task 1, with intent of having a type of object marking a room location. My question is: is Point struct really enough? It seems so at the first glance that we need only coordinates at runtime. But let's assume that we want also to have a list of these to be able to iterate through them. This may be useful for various reasons: debugging, displaying or editing at runtime, and so forth. So, besides individual named Point* variables (e.g. Point* walkToPos;) we need to have either array of Point* roompoints[] or an indexed attribute like Point* Room.Points[]. If you imagine how do you iterate these, you may find out that we will also need to identify the elements of this array. Which means that we need these elements to store their IDs in them.

This brings me to a though that Point is not enough, and instead we'd need another type of struct which has at minimum:

• Coordinates, X,Y
• String ScriptName

As well as optionally:

• A layer index (room / GUI), which could be hidden, similar to Overlays.
• String Description/Name for a human-readable hint. (maybe design-time only?)
• Graphic, in case user wants to distinguish these visually using different icons. (maybe design-time only?)

Potential names for this struct:

• Location; may conflict with term "Location" from functions such as "GetLocationType/Name", also we might later use "Location" for something defining an area (?).
• Marker; as something that "marks the spot".

Although it seems to have a downside of introducing a new type of object, OTOH one benefit of such struct is that it may be later integrated into the proposed object hierarchy (#1228), as a simple descendant of a "Thing2D", or even a parent for other objects, since it shares few most common properties.

What is the easiest way to implement these "Markers" at this time? It's to actually implement a new type of object in both Editor and Engine, therefore also save it into compiled room. As I mentioned above, compiled rooms are extensible formats. The rest is to add a small API.

Alternatively, we might experiment with adding a more generic parent class already, similar to Thing2D, and make it a parent for most of the existing game objects, then add this Marker somewhere in this hierarchy, either in the "middle" or "branching out". This will also allow to share most of the common properties and avoid duplicating them for this particular new object type.

[ivan-mogilko]

Hmm, maybe i should add small clarification, why do I think about having an "integrated" object type, as opposed to the "raw" Point struct. The reason is that this allows for easier extension, and integrating with the rest of object hierarchy in AGS API. With generated Points you are going to be stuck with its current form; unless you want to make an overhaul again in the future, replacing parts of Room API that let access or use these points. And if you're going to generate script with fully custom types, we won't be able to use these types in the engine's API, obviously.

You may accuse me in far-fetching here, but when I think about idea of "room location" (as opposed to a simple geometric Point), I start thinking about which features users may expect from it. Like, I've been writing the above comment, thinking that this "Marker" type needs only X,Y and a ScriptName, but then thought that users may want to display a "description", then they may want to display an "icon" for easier visual cues, hence it needs a Graphic.

Then, after finishing editing this comment above, I suddenly thought, what if users would like to attach Custom Properties to this "Marker"? Seriously, suppose someone wants to write a module, where character's behavior would differ depending on which room location it is ordered to travel to? AGS does not feature ECS, but Custom Properties are closest to that in terms of extending a built-in object.

But if this "marker" is a part of the major type hierarchy in AGS API, we may have parent class(es) having a number of common properties, such as X, Y, ScriptName, Description, CustomProperties (and functions to work with these). Hence, when you add a new object type, deriving from these, you automatically receive all the common functionality.

---

EDIT:

Hypothetically, how may we expand these Markers into other geometry? For example, if we want to have a line or a polygon? Having a marker with a script name etc for each point in a polygon would be overkill, imo. So, instead, we could derive a new type from Marker, called e.g. ShapeMarker (or MarkerShape), and have it have a list of points, for instance:

struct Marker {
     int X, Y;
     readonly String ScriptName;
     ...
};

struct MarkerShape extends Marker {
     Point* Points[];
};

In this case the Marker's XY will serve as a polygon's "origin", and polygon's point list will be relative to this origin.

[ivan-mogilko]

Now then, let's look at the method number 2, that is - generating new types of objects in script, instead of having them in the game data. There have been a consideration to try to not add engine API for things that do not require extra mechanics, in other words something that may be (relatively) easily implemented in script. This may be a way to work around that, albeit an unexpected one.

First comes again the question of what kind of behavior do we expect from this generated "room location".

1. If this is simply to have constant coordinates, and literally nothing else, then the solution is mentioned by eri0o: generate macro like #define POINTNAME_X 10 #define POINTNAME_Y 20, or perhaps rather constants, as these are supported by the new compiler now: const int PointNameX = 10 and so forth.

These may be easily added to the generated room header.

In fact, one may add them into the global generated header too, grouped into structs, thus giving an opportunity to sort of "reference" location in another room. E.g.

struct RoomAAA
{
    const int PointNameX = 10;
    const int PointNameY = 10;
};

struct RoomBBB
{
    const int PointNameX = 10;
    const int PointNameY = 10;
};

2. Suppose that's not enough, and we want to have an object, as the object may be extended, and it's easier to work with in script. And this is an object of type that may be created in user script (not builtin). (We are not limiting ourselves to just Point, it may as well be a different type, like the aforementioned Marker.) Then the requirements are:

• We need to have these objects' declaration in a generated header (global or room's).
• We need to have these objects' initialization somewhere in a generated script body, in a function that will be run either at the start of the game, if that's an object of a global scope, or at the start of the room, if it's an object of a room scope.
• We need to decide how these objects are stored and accessed. Separate pointer variables, pointer variables in a struct, pointer attributes in a struct, and so on.
• We need to decide if we want to have an array of these objects for easier iteration, or a indexed attribute in a struct for similar purpose.

Right, in theory we could have a generated / template module that implements attributes with getters and setters, too.

Are there any obvious limitations to this? Like I mentioned previously, if we want objects to be declared and initialized in a room scope, currently engine:

• does not allow any additional script to be associated with a room;
• does not provide a script callback for a "room load" case that may be plugged in from a autogenerated script without conflicting with user scripts.

The first problem may actually be worked around, using the fact that the generated room header will only be included into the single room script. This allows us to add any actual variable declarations and functions there (not just imports). The downside to such approach are: potential naming conflicts and incapsulation issues, as anything we write there will be "seen" and accessible from the user's room script (unless we invent a way to protect this generated code).

If that does not sound like a good solution, then the task is to implement some kind of "secondary" or "service" room script support that is run besides the user script; preferably prior to it.

The second problem might require implementing a new script callback that is run at the room load. The bigger change would be to reimplement existing room events to run functions of predefined names instead of linking to the room event table. But this won't work for our purposes if we have the generated function in the generated header, only if there's a separate "service" room script.

---

Besides all the above there's also one important consideration: the separation of compilation tools. Since it was decided that eventually the output game data should be generated by stand-alone tools rather than the Editor, it may be important to make generation as simple as possible, or as generic as possible, to ease the generation/compilation logic. What I mean is:

• make simple rules that tell how xml data is converted into script declarations;
• whenever possible use precreated script modules (templates) with types and functions, rather than generating that all in code.

[AlanDrake]

Consider also the alternative approach I'm using in my half-baked module:

• all properties end up together into a single database
• room exclusive stuff follows a naming convention like "room1.object2.propname"
• everything is a simple key-value pair

Not entirely sure how script declaration would be handled this way, though.

I wanted to explore viable ways for run-time design-time changes, and despite the module limitations, like lack of direct script declarations. The experiment was a success: (Screenshot of a debug overlay to draw vector paths and assigning footstep sounds)

Having to wait for room_Load before assigning values to script variables adds some boilerplate, but not excessively so. The main strength is flexibility and not being bound to predetermined structures. It would be awesome if it were possible to edit Objects and other editor props directly, but overriding values at room_Load is also an option.

As for having Marker and MarkerShape natively as multi-purpose tools, there could certainly be uses. Duke3d's map editor used specific sprites that were linked to special engine behaviors, and in a similar way an AGS gamedev could code something similar, or just use the script instances directly. Only thing the editor would be missing for ease of use, would be the ability to add such markers in different "layers". It could be potentially confusing if one had everything jumbled together.

Another additional marker type that might be useful could be a MarkerRange, a point with extra RangeX RangeY from the center point. I use a similar construct for advanced interaction coordinates, and light sources.

Though, my experience is that trying to make customizable things from editors, usually leads to overcomplication and annoying constraints. Which is why I'm more inclined to keep the editor as simple as possible while exposing APIs to let us do things via script.

[ivan-mogilko]

Consider also the alternative approach I'm using in my half-baked module:

• all properties end up together into a single database
• room exclusive stuff follows a naming convention like "room1.object2.propname"
• everything is a simple key-value pair

Can you elaborate, what properties are these, and what is the "database"? How do you set up or declare individual objects? Or is it the names of engine builtin objects properties, which you store in a dictionary and then assign on room load? How precisely this approach is letting to implement the room locations which are in question here?

Only thing the editor would be missing for ease of use, would be the ability to add such markers in different "layers".

Which layers? may these layers be supported in the editor?

Though, my experience is that trying to make customizable things from editors, usually leads to overcomplication and annoying constraints. Which is why I'm more inclined to keep the editor as simple as possible while exposing APIs to let us do things via script.

How much should be done in script, supposing a person would like to have "room location" to walk character to? Would we need to distribute ready modules for that, or each game developer will have to script their own?

[AlanDrake]

Can you elaborate, what properties are these, and what is the "database"? How do you set up or declare individual objects? Or is it the names of engine builtin objects properties, which you store in a dictionary and then assign on room load?

Any arbitrary property, the "database" in my implementation is a Dictionary that reads/write to a tsv file, and is wrapped in several functions for convenience. But it could be anything, in theory. Room Objects and properties could be declared by simply existing as a key, like "room1.object2.x/y/name/graphic/etc". I'm not doing anything with objects yet, but I can use that naming convention to add custom handled overrides or additional properties.

Which layers? may these layers be supported in the editor?

Custom layers, or groups, for the room viewport in the editor. I'm only suggesting it for the Marker idea, because if abused for different purposes it may end up becoming hard to read, if there's no way to filter markers by context. Hiding each marker could become annoying if you start having a dozen or more. We also once discussed a potential extra folder view on the side, maybe this could be an addition to that, because I don't know how you'd handle custom layers with the current Room UI.

How much should be done in script, supposing a person would like to have "room location" to walk character to? Would we need to distribute ready modules for that, or each game developer will have to script their own?

That's the hard question. With a builtin database API, one could query the key directly, be it created by Editor or script. With a module, we may provide a starting point for a customizable editing interface and custom types.

Where to draw the line on what to implement directly in the Editor and what via script, would be how common is the use case. Maybe we should start with a module, and see what users need, what could be integrated, etc.

[ivan-mogilko]

Alright, maybe I don't fully understand, are you speaking of replacing the game data completely with a database of properties? Because in the past we discussed a generic text format for the game data (like JSON, for example) which both editor and engine could read.

[ivan-mogilko]

Sorry for a little bump; somebody reminded me about this again. And also see #2202, as that may be related in terms of editing.

Strictly theoretically for now, what does everyone thinks on my proposal on a new "Marker" type? I wrote large comments above, and not all of this text is regarding them, sorry for this, but it starts with comment https://github.com/adventuregamestudio/ags/issues/1846#issuecomment-1567721540

The gist of my arguments is this: For a new type of object which defines a position, being just a Point may not be enough. It may be better to have a distinct new type, even if it had only x,y properties at start. The reasoning is:

• we may want to extend this with additional data;
• we may want to derive other, more complex types from this type eventually; mentioned in several comments: Shape (polygon), Range, but I guess there could be also things like Line or Path, where individual points inside these shapes are unnamed, and just part of the collection in a parent object.
• we may want to even integrate this type in a global type hierarchy later when this is worked on.

The proposed type name is Marker (may be argued about), and the proposed starting properties are:

• X,Y: origin coordinates
• ScriptName: for addressing it
• Graphic, an optional and possibly design-time only property.

Maybe it would be better to open a new ticket for this proposal? EDIT: I might also post this proposal on forums, to get more opinions, although my main concern at this point is engine design (majority of users will likely be glad to receive anything that would let them mark the locations).

I also feel like this may not be exactly what @ericoporto had in mind originally, from his use examples (physics etc) it looks like he may be needed something with less complexity that may be created in large numbers. And maybe he wanted to have means for generating custom data purely in script. But I may be mistaken.

[ericoporto]

My idea of using points is so you can WalkToPoint(point) and then you can move the point around if the art changes. But also because we added point and didn't use in the script API at all.

I really recommend trying Tiled Editor. Here is a description of polygon editing.

At the time I wrote this I had just made a game using tiled in löve and using gedit to code and was surprised by how well things went, so I wanted the same point and polygon features from tiled.

[ivan-mogilko]

So, is there a difference of whether it's a Point or a different, extensible type?

Will it be more convenient to have this generated purely in script?

EDIT: I guess there's also a question: what is more convenient when making polygons: to have separate Point objects, or have 1 engine's "polygon" type that has a series of points in it as its own property.

I really recommend trying Tiled Editor. Here is a description of polygon editing.

Unfortunately I never used it. How is this Tiled will be translated into AGS, does it mean reading a custom file and creating something based on it?

In other words, what would be the requirements for this feature?

[ivan-mogilko]

Perhaps I see a benefit in both approaches:

• having a builtin extensible object to work using script API, and
• a mechanism that would generate custom structs in script, either global or per room, from the design-time only data, created by either an Editor itself, or a Editor plugin.

Both seem to have their uses, both may expand in various ways; but would require different paths in the editor (and editing tools).

EDIT: hmm, I might try writing a ticket for a general case situation of generating such scripts (without exact type or struct). This may be advantageous to have for other purposes, or may become a first step for this Points feature too.