Engine Wishlist/Coordination

[monkey0506]

Now that the engine has had its source opened up, it seems to me that it might be a good time to start getting an idea of what people most want to see updated in the engine. This means anything that has to do with the run-time component of your game. Design-time requests should go to the Editor Wishlist thread.

There's a few that I would really like to see, but I haven't yet had a chance to look at the engine source at all. That with the fact that we've already been told that there are underlying complications for the ones that I will be suggesting might mean they still will require some time before they can be implemented. In any case, I think it's good for people to have a common place for this that we can post to so we can get an idea of what the most people want.

So:

• Dynamic limits!!
  
  Specifically I'm thinking of things like inventory items and controls per GUI, and room objects. Room hotspots are based on a bitmap still, so that would require even more work, but these other items could presumably be looked at.
  
  Thoughts: For compatibility with existing scripts, we would still need some way for the user to easily get the "highest used amount of XXX". For example, many scripts that I'm aware of use the algorithm for mapping a GUI ID and GUIControl ID to a single array index. That algorithm is dependent on a static number of maximum GUIControls per GUI. If the user could still read the maximum number actually used by any GUI at run-time, then dynamic arrays would be sufficient. This is something that will have to be dealt with for compatibility, and simply for the usability of this algorithm in new scripts.
  
  
• Dynamic Arrays..improvements
  
  Dynamic arrays are great, but they're rather limiting as of right now. We can't read back their current size, there are no standard functions for working with them (of course that's somewhat related to no support for type-casting), and we can't have dynamic arrays within a struct. These are improvements that I'd like to see. Also, some sort of constant should probably be defined like AGS_MAX_DYNAMIC_ARRAY_SIZE (the current value is 1000000).
  
  
• Pointers to custom types
  
  It's already possible for the engine to create single, static pointers to custom types, as evidenced by member functions and extender methods (which use the 'this' pointer). Opening it up for users to create dynamically typed pointers and assign them values has been a concern for some time though, particularly in preserving the game state for save games. I'd like to propose that we take a look at the existing garbage collection (which works great) and see what can possibly be done to open up the possibility of pointers to user types.
  
  
• Object-orientation
  
  It's true that not everyone is a fan of the OO programming model, but the majority of the functions/properties in AGS are object-oriented. I'd like to see what we can do to clean up some of the older properties/functions to bring them into conformity with this OO model, for consistency sake.
  
  
• eEventEntersRoomAfterFadein and eEventQuitGame (or game_quit, game_end, etc.)
  
  These two event types have been proposed for inclusion in the EventType enum and to be fired off appropriately by on_event, but they haven't been implemented yet. They would certainly make things a bit simpler for us programmers!

I think that's about it for now. So if you have any ideas, feel free to submit them here, and show your support for the existing ones. Also, any C++ programmers with access to the source should chime in if they've managed to make some way in including any of the suggested items!


P.S. Don't forget to thank CJ for opening up AGS so we can all work together to make it even better!!

[GarageGothic]

Amen, thanks CJ for this awesome opportunity!

I was thinking, regarding the dynamic limits, I think we should really try avoid a solution where those limits are fixed upon compile. I agree that removing the editor limits would be first priority, but for a long-term solution I think it would be worth the effort to make the system stay dynamic at run-time. To be able to create say a character or GUI simply through script would be a godsend for module scripting.

Edit: I'll have to dust off my C++ skills this summer, but among the things I'm gonna try to implement on an experimental basis now that the source is released are two new classes: Scene (a "virtual room" class which allows stuff like split-screen, instant room transition, and allows you to manipulate scene properties without usin the other-room module), and Layer (which are dynamic objects similar to Overlay but can be displayed behind objects, characters and walkbehinds). If it seems viable to implement them in the engine I suppose Layer could serve the purpose that I imagined for dynamic characters/objects in the original post.

[Dualnames]

Amen, for the last one brother!! I'm not sure whether this whole opening source business is a good thing, but only time will tell, but the lift of dynamic limits sounds amazing.

[Calin Leafshade]

eEventEntersRoomAfterFadein and eEventQuitGame (or game_quit, game_end, etc.)

These two event types have been proposed for inclusion in the EventType enum and to be fired off appropriately by on_event, but they haven't been implemented yet. They would certainly make things a bit simpler for us programmers!

Those look pretty easy to implement.

looking at the source the AGS runtime runs run_on_event ([a #define for the event], [data to pass]);

So we just need to add the event number the enum in the source and run that method in the source at the correct times.

I'm not sure if the compiler would need to be open for that to work though.

Also I daren't actually change anything in case I mess something up so ya know

[Charity]

Dynamic Control of Areas
An idea that was tossed about a few times and that I have been of proponent of would be the ability to use drawing functions to manipulate WalkableAreas, Regions, etc. from within the script.  I think in some cases this could make changing regions in game easier and less jury-rigged than predefining every possible region in the room editor (though in other cases it would probably just make things more complicated, since scripting is a little like working in the dark).  It could also make it possible to regularize how you use walkable areas and such, so for instance if you wanted to use WalkableArea 2 for wood floors and WalkableArea 3 for shallow water, and then test for them in a global script and set walking sounds and animations accordingly, you could do this and still be able to change walkable areas at run time without messing up your system.  Granted, this could probably be approximated using properties, but it wouldn't be quite as efficient.  

The key use, though, would for things like procedurally generated content and times when you want the player to be able to affect the room environment in a dynamic way.

Drawing Functions
Some drawing functions that could be implemented using the script but would end up potentially causing massive slowdown if used frequently might be nice to implement in the engine as well.  The two that come to mind off the top of my head would be:

DrawingSurface.ColorFill(int x, int y)
which would work like the bucket tool in most paint programs, changing all adjacent pixels of the same color to DrawingColor.

and the probably more useful,

DrawingSurface.ReplaceColor(int color)
replaces all pixels of color with DrawingColor.  Could be useful for imitating some palette functions in 16 bit and 32 bit color games.

Properties
Also editing object/region/character properties in the script, seems to get brought up a lot. I know there are good workarounds and I think Chris said that changing this would actually be non-trivial, but if we have more people working on it.

Pathfinding
And I think it would be good to have access to pathfinding in the script.  Things like:

Paths.IsPathViable(int from_x, int from_y, int to_x, int to_y)
returns true if character will be able to reach the desination point, given the walkableAreas and other obstacles recognized by the pathfinder.  Otherwise returns false.

Paths.NumberOfWapoints(int from_x, int from_y, int to_x, int to_y)
returns the number of waypoints (places the character will change direction or stop) between the starting position and ending position of the path, including the stopping point in a path that will not reach its destination.

Paths.GetWaypointX(int from_x, int from_y, int to_x, int to_y, int waypoint)
Paths.GetWaypointY(int from_x, int from_y, int to_x, int to_y, int waypoint)
return the x and y coordinates of a given waypoint

There are instances when I would like to know exactly where a character is going to walk beforehand.

Views
A way of getting the number of loops in a view and the number frames in a loop would make VewFrame functions and properties a lot easier to play with without crashing the game.
How did I miss that?  Thanks, Monkey.

[perludus]

A) A Macintosh version that's up to date.  It would make a huge difference in my engine decisions if I knew I could use AGS and make a game for both PC and Mac.

B) A version that allowed games to play embedded in a web browser. 

[Knox]

I thought of a few suggestions, what do you think about these?

1) Merging Calin's alpha plugin into AGS so you no longer need the plugin would be cool!

2) No more problems with alpha channels with the GUI's + buttons  (yay!)

3) Have alpha-blending/semi-transparent/translucent sprites working for our text windows

4) Merging Helios' customProperties Helper into AGS so we dont need the plugin

5) Making AGS games work on the IPhone/IPad (quadruple yay!) *dont even know if this is possible

6) Making ViewFrame.Speed not read-only

7) Dynamically drawing over Gui's/Overlays that draw over gui's (?)

[monkey0506]

Views
A way of getting the number of loops in a view and the number frames in a loop would make VewFrame functions and properties a lot easier to play with without crashing the game.

You mean like:

Code: ags

int viewCount = Game.ViewCount;
int loopCount = Game.GetLoopCountForView(VWALKING);
int frameCount = Game.GetFrameCountForLoop(VWALKING, 0);

Granted, none of those are referenced in the ViewFrame Functions and Properties page in the manual, but the latter two functions are both referenced in the entry for Game.GetViewFrame.

Dynamically drawing over Gui's/Overlays that draw over gui's (?)

I'm not entirely sure that I'm understanding you correctly, but it's possible to create dynamic overlays/GUI background graphics using the DynamicSprite and DrawingSurface functions. What more than that are you looking for with this exactly?

[Sephiroth]

Thanks a million for this great opportunity CJ!

I think a good start would be to 'update' the code, forgive me this word but as Pumaman mentioned himself, some of the code may be old and not compatible with the future changes we're planning to implement.

If we could give the code a refresh, including the suggestions about OO complete rework, without breaking the engine, then we would have a solid basis to work on for any new features.

I'm still trying to compile the source properly, when I do, I'll be glad to share my opinions and ideas.

[Wyz]

I thought of a few suggestions, what do you think about these?

1) Merging Calin's alpha plugin into AGS so you no longer need the plugin would be cool!

That, or we could go for pixel shaders! I've seen the engine itself already uses them put it would be cool to expand them or even allow users to implement their own shaders.

5) Making AGS games work on the IPhone/IPad (quadruple yay!) *dont even know if this is possible

If we switch to Allegro 5 that might actually be possible! However there is still a long way to go I figure.
For now linux and mac are already really feasible. (with still some stuff that is obvious to break, but in many cases not vital like the game explorer and avi support). The games built with AGS can be stored as .ags files and these should potentially be platform independent.

[Calin Leafshade]

Mac support should be a priority since it wouldnt require that much effort (relatively speaking) and the mac platform is much more relevant now than 12 years ago.

[subspark]

I've mentioned a slew of serviceable features before (Hotspot.SetDescription(); writable property, etc) but I think adding anything on top of the engine's accumulated disorder isn't particularly forward thinking or wise.

I propose two very important steps that I think need to be considered.

These obviously precede other development tasks.
The status quo:
a) CJ warns that AGS is a mess. There is one trunk currently (as I am aware) and it's simply not in a state where it would be practical to write new features into the code mix.
b) Backwards compatibility is to be preserved. This also correlates to the above.

The logical steps:
a) Clone the engine into a second branch. Branch 1 = AGS 3.2.1 / Branch 2 = AGS 4.0
b) Tidy the engine from the inside out. Lay foundations for additional branches for other platforms.

The aftermath:
a) Clean code, new AGS (no immediate backwards compatibility support necessary)
b) Gather feature requests from forums and add them to an official developer wiki with a voting/like button beside each feature listing for anyone involved with AGS.
c) Developers with commit rights to SVN were awarded those rights because they were trusted to expand on AGS for the general community. These individuals can of effortlessly refer to the neat dev-wiki to draw a clear priority list for feature implementation.
d) Investigation begins for exploring backwards compatibility possibilities for AGS 4.0.

These are just a few suggestions, but it is abundantly clear to me that we really need to introduce a reasonable level of coordination for I've mentioned a slew serviceable features (Hotspot.SetDescription(); writable property, etc) but I think adding anything on top of the engine's accumulated disorder isn't particularly forward thinking or wise.

I propose two very important steps that I think need to be considered.

These obviously precede other development tasks.
The status quo:
a) CJ warns that AGS is a mess. There is one trunk currently (as I am aware) and it's simply not in a state where it would be practical to write new features into the code mix.
b) Backwards compatibility is to be preserved. This also correlates to the above.

The logical steps:
a) Clone the engine into a second branch. Branch 1 = AGS 3.2.1 / Branch 2 = AGS 4.0
b) Tidy the engine from the inside out. Lay foundations for additional branches for other platforms.

The aftermath:
a) Clean code, new AGS (no immediate backwards compatibility support necessary)
b) Gather feature requests from forums and add them to an official developer wiki with a voting/like button beside each feature listing for anyone involved with AGS.
c) Developers with commit rights to SVN were awarded those rights because they were trusted to expand on AGS for the general community. These individuals can of effortlessly refer to the neat dev-wiki to draw a clear priority list for feature implementation.
d) Investigation begins for exploring backwards compatibility possibilities for AGS 4.0.

These are just a few suggestions, but it is absolutely abundantly clear to me that we need to introduce a reasonable level of coordination to open source movements that concern us . The same checks and balances apply across the world of open-source developments and should largely apply to AGS as well.

I love all the enthusiasm, I'm beside myself with excitement right now, but I force myself for good reason to sit back for a brief moment and ground the impulses of unstructured desire to add more stuff. There are things to do before this becomes a practical reality.

[Wyz]

Yes I pretty much agree with that, I had exactly the same thoughts. After I compiled it and I knew that part would be no problem it is time for me to study the code, and only after I understand how it all fits would I start actually coding stuff.
I think we should first ready the code for multiple developers working on it. I also think breaking backward compatibility for a while with a new branch and adding things in gradually is the logical thing to do. I'm in for doing code refactoring and working on a future branch. We should however get organized. How do we do that?

[Joseph DiPerla]

I think since the engine and editor are now open source, the best thing to do is to also open up a new development forum to discuss further implementation options and code structure.

I agree, there are a few things that need to be done before porting or adding features to AGS. For instance:

1) Code needs to be cleaned up more so for better understanding and better porting/implementation.
2) Code needs to be documented and commented better.
3) A plan needs to be discussed as to how to maximize portability of the Engine source.
4) Another plan needs to be in place to discuss what kind of ports will be created and how the engine should function to obtain that portability.
5) A user group of CJ, Steve Mcrea, Elektroshocker and others should be established as to lead and maintain the project.
6) A standard should be set as to how new features will be implemented so that they achieve maximum portability and stability.

Personally, I feel that the main focus for AGS before implementing new features is to clean it up, optimize it and be sure it can run on other operating systems. New gaming features can be added after. After all, the engine can already do anything we need it to. We just now need it to be playable on other systems.

[Ryan Timothy B]

Free access to all room elements from within any room. Objects, Hotspots, Walkable areas, Regions, etc.

Eg:  room[2].object[4].Visible = false;

That would definitely be very nice. That way you wouldn't require the needless global variables and such just to turn off an object for another room, or whatever element you're doing.

Of course though, you'd run into problems with room numbers not being in numerical order.

[monkey0506]

I'm not sure how well it works with the most recent versions, but Steve's OtherRoom module of course provides functions for working with the "room elements" from other rooms.

In any case, it would be nice to implement this at some point I suppose. So, that being said, as far as rooms not being in numerical order, you could have something like this:

readonly static int Game.RoomCount

Returns the actual number of rooms this game uses (regardless of actual room number).

readonly static int Game.RoomID[int index]

For index 0 to (Game.RoomCount - 1) returns the actual room number of the specified room.

Then you could do:

Code: ags

room[Game.RoomID[2]].Objects[4].Visible = false;

[Ryan Timothy B]

Wouldn't it be possible to have two pointers, where:

Code: ags

roomID[301].Object[4].Visible = false;

and

Code: ags

room[1].Object[4].Visible = false;

Could actually point to the same thing?

[monkey0506]

Well I think you've reversed the meaning from my post (where the RoomID would return the actual room number of the Nth room), but something along the lines of what you've described would be possible if the rooms were actually opened up this way.

[Ryan Timothy B]

Yes, I understood your idea of having roomID[] being the numerical order. I just think roomID[] would make more sense to have it access the rooms in the non numerical order while room[] would act in numerical order just as object[], hotspot[], etc, currently work. It only made sense to me.

Edit: Actually I think I'm the one who's confused. Your method seems to be the better method. I guess I didn't see the Game.roomID

My bad.

[Calin Leafshade]

I think we should move away from global arrays towards an OO pointer system

i.e

Code: ags

Room r = Room.GetRoom(roomID);
Object o = Object.GetObject(roomID, objectID);