[feature suggestion] Views as enums

[ericoporto]

Today AGS creates a define macro for each view according to it's name (NAME_OF_VIEW).

I was thinking about having it be a eVIEW_NAME_OF_VIEW or eView_name_of_view or similar - maybe even just NAME_OF_VIEW for maximum compatibility. It would be prettier with eViewNameOfView though.

This way parts of the AGS Script API that accepts Views could use the enum type in it's parameters, instead of the current int view a VIEW view or what will be the type name used for all views. This way the views will appear as suggestions in the autocomplete on the editor when writing that parameter.

Since enums are just int I don't think this will break anything.

It's a new feature so I think it would be for AGS4.

[ivan-mogilko]

Unless I miss anything, this might be very easy to do, just replace whatever is generated (#defines probably) with enum. (and adjust function prototypes)

[ivan-mogilko]

I recall @fernewelten was suggesting to do similar thing for room numbers https://github.com/adventuregamestudio/ags/issues/1135#issuecomment-733844485 But that would require adding room's "script name", so probably should be seen as a separate slightly bigger task.

[morganwillcock]

Is it enforced that View names are unique?

[ericoporto]

Unless I miss anything, this might be very easy to do, just replace whatever is generated (#defines probably) with enum. (and adjust function prototypes)

Yeahp, exactly that :)

[ivan-mogilko]

Is it enforced that View names are unique?

I don't remember if it's checked at creation (probably yes), but every object name in AGS is forced to be unique simply because it is used to generate variables and macros for script.

There's a different issue: some things are not required to have script name even having a field for one, which I think may need to be fixed (by generating some dummy name at least). But that's completely different story...

[fernewelten]

Is it enforced that View names are unique?

enum values don't need to be unique, either, so this wouldn't alter anything from that viewpoint.

But seemingly it does: I've just tried to assign an identical name to two views in 3.5, and the Editor complains, “This script name is already used by another item.“

[ericoporto]

Apparently the method is IsScriptNameAlreadyUsed in the Editor/AGS.Types/Game.cs.

[rofl0r]

is this the same thing happening here ?

https://github.com/rofl0r/ascc/commit/948d5642f52ff6671b2a4c582f1bd0d2e1e095af

#define ICONBAR FindGUIID("ICONBAR")

[morganwillcock]

This seems like something that is very useful for how everything works right now, but if this is implemented as a #define doesn't that preclude any dynamic creation of resources?

I guess I am mainly talking about the longer term approach (and maybe experimenting along the way is worthwhile, especially when the changes are easy), but it would seem more flexible to dynamically select objects based on hierachy+selector rather than statically define everything up-front. Potentially this would also be how you would dynamically load and select any game object, regardless of when/how it appeared.

[ericoporto]

it would seem more flexible to dynamically select objects based on hierachy+selector rather than statically define everything up-front. Potentially this would also be how you would dynamically load and select any game object, regardless of when/how it appeared.

@morganwillcock you mean a view object?

Example:

struct my_view_1 extends view //alternative a class with overrides?
{
   // I don't know how loops work here
  Loop[] = {{1,2,3},{4,5,6}};
}

struct my_view_2 extends view
{ }

...

or maybe

View* my_view_1;
View* my_view_2;
... 
// And some method initialize all of these before game_start

[morganwillcock]

I think I mean a conscious split between actions the 'engine' takes when it starts and what the 'game' does when it is running. I think a lot of problems (RunAGSGame, multi-game distributions, save game patches, dynamic object creation, etc) might be solved by allowing for some interaction or providing hooks for actions the engine itself takes, and then the game script runs by getting references to any data that it needs. Obviously that isn't trivial to do, and it should definitely be optional (having everything static is probably making the learning process fairly easy and operation predicatable), but it would be good to move away from the "let's create lots of empty objects in-case we need them after the game is released" approach.

[ericoporto]

I think this discussion could use it's own issue (moving to dynamic characters, objects, views and items) because while I vaguely understand what you mean, there are many different ways to implement what you are saying.

For the particular case of views, being static (I know they currently really aren't because they can be edited), they could be prepared in a texture map that gets loaded in the GPU. Not sure if this is a good way since I know a lot of developers use a single view per character with a huge amount of loops - see Dave's devstreams, there's even a request he made for named loops because he currently needs to track each loop in handmade enums.

Alternatively, Box2D uses some plain structs (no methods/functions, only properties), that you fill the value of each and then you pass these plain structs to the functions that can create objects (Vulkan API has a vaguely similar approach too, but more C-ish). In this approach what the Editor defines are these initializers and then some factory method or the object constructors take these as their input parameters.

Anyway, to do this in a way that the Editor writes AGS Script directly, we would need function pointers to pass functions for the interactions callbacks.

---

All that said when I mentioned I was really thinking in the simplest solution possible mentioned because when I started using AGS I understood I should preceed characters with c, objects with o and other things to be easier to identify them in script but I didn't do the same with views (like preceding with v or something) and since they build for all caps defines, it took me a long time to figure out I didn't need to use numbers to refer to them, because the script API uses pure int, and since the defines are already generated, it felt like a easy fix.

[morganwillcock]

I don't mean to say don't do it, if it makes views work the same way as other types of object then it is probably good in the short term, but I don't think the long term goal should be to mandate that everything should be statically mapped out before the program starts. In this particular case it is probably an easy win but I don't think the same approach could be followed across the whoie system as it stands.

612

its not "names" that we need, but different timers design

[ivan-mogilko]

I actually agree that dynamic creation of objects, all objects, including those assigned at design time, is the way to go in the long term. I.e. in my belief it all should go through same process in the engine, and even when engine loads game data it should create all objects using dynamic creation methods. I gave it a quick thought in the past, and the first problem that came to mind is exactly how to handle / transition existing predeclared variables. BTW, I quickly mentioned this on Discord once, I wrote this dirty draft with my thoughts a while ago: https://github.com/adventuregamestudio/ags/wiki/AGS-4-Draft:-Game-Data-and-Entities

Anyway, I also think this is something that has to be discussed as a general concept first, separately from anything else. This particular ticket (and similar suggestions) do not aim to change anything conceptually but simply enhance existing situation.

[ivan-mogilko]

@morganwillcock

I don't mean to say don't do it, if it makes views work the same way as other types of object then it is probably good in the short term

Please note that the above proposal does not change anything about how views work at all, it will simply convert view IDs made with #define into enum. They will still be integer constants after that.

but if this is implemented as a #define doesn't that preclude any dynamic creation of resources?

[DELETED a lot of text] because I realized there's much more problems to address, and I dont want to derail the thread...

In short, IMO it won't preclude dynamic creation of objects per se, what it will preclude is deletion and replacement of pregenerated objects. In other words, important problem to resolve is, whether we would like to keep objects defined at design time static (permanent) or not.