Following my experience developing an editor plugin, I would like to ask the following features:
* If a game uses a component (plugin) that is not currently installed, keep the previous component xml as-is when saving the .agf file. Currently it deletes this xml node completely
* Interface to get the current game player id (IGame doesn't provide this information)
* It's only possible to load one room at a time and it affects the GUI if there is an existing room edit in progress. There should be a way to load a room in-memory without affecting the GUI
* If a script or room was changed, but not saved, there should be a way to detect that there are pending changes.
* When a plugin component FromXml method is called, the CurrentGame DirectoryPath is null, it should have the right value when this method is called.
* Ability to register plugin's own unhandled exception handler, maybe by giving an option to load a plugin to its own AppDomain or an internal mechanism
* Provide plugin access to the properties window
* Provide plugin access to the error pane
* Allow a plugin to add an additional window in the right pane (next to the tree and properties window)
Additionally, I believe the following editor feature should be useful to the user:
Add back and forwards buttons to go through the different open documents. An enhancement could be to give a component an ability to add its internal locations to these events, but it's a nice-to-have addition.
Quick question, now that the forum has been upgraded, should this (and similar requests) go to the Editor Development subforum in order to be considered or is this the right place?
They should probably go to Editor Development, but that's not a condition for (or guarantee of) being considered.
It would help to be able to test a room without having
to go through every room to test room 40 and beyond.
dbuske, you can. Just set the room the player starts in.
Or with debug mode on Press Ctrl+X to change rooms. Unless you've removed the on key press call, which is basically this:
if (keycode == eKeyCtrlX) Debug(3,0); // Ctrl-X, teleport to room
Thank you Guys. This will help me test the games faster.
Not sure if this has been asked before or even possible:
1) The ability to lock an object in the room editor
2) The ability to change an object's Z depth (like buttons).
3) "Zoom To" object/character if the room is really large and you dont want to scroll around manually triyng to find it
4) Have the option to specify in "Preferences" the maximum number of objects per room (so people can plug in their own values)
"The ability to change an object's Z depth (like buttons)."
Are you speaking of the baseline? It's already possible in the room editor. Just change BaselineOverridden to true and set the baseline yourself.
Z-depth is background to foreground, the implied third dimension.
Which is exactly what the baseline controls.
...Well, now that you mention it, so it is. But it's established on the vertical dimension, which makes it non-intuitive for sleepyheads like me. :-[
With the background itself being 2-dimensional, how else should the z-order/baseline be represented? Although it would be fair to note that characters have both a baseline which controls what is drawn in front of what, and a z-order, which basically just offset's the y position the character is drawn at while still triggering events as if the y is unchanged.
Z-index in CSS, for instance, simply uses a stacking order number. I'm guessing it probably works much like I anticipate BaselineOverridden would. An object with a z-index of 1 is behind one with a z-order of 2, etc. An object with a z-index of 10000 is on top of everything.
Actually having z-order for objects instead of baselines could be cool...or atleast offered along with baselines.
The problem with a fixed z-order is that the case where it is tied to the on-screen position (i.e. something that is lower on screen is closer) is so common that it ought to be really easy to enable. Basically any time you have characters, objects and walkbehinds arranged on a plane seen from above (which is most of the time), this is the case you want. Using the baselines (i.e. bottom pixel y-coordinate) for z-order is a very straightforward and pretty intuitive way to make it work.
You don't want to have to manually shuffle the z-order every time a character walks in front of or behind a tree, for example. It's much easier if the tree's z-order is set to its baseline and the character's z-order is set to its baseline and it just works.
What is a bit confusing is the Character.z is not the z-order, but a way to adjust the y-position without affecting the z-order. (Intuitively, it lifts the character up off the ground.)
The problem is that AGS has two meanings for Z.
One is the GUI sort order, which shouldn't be called Z-order at all. The end-user may not know about projection matrices, and the Z here is pretty arbitrary.
The second is the third spatial coordinate, up/down relative to the ground. This makes a little more sense except that x and y don't exactly define a ground plane in a lot of cases.
This could all be cleared up by renaming the GUI variable.
[EDIT] Cool! I got a little light bulb icon!
Quote from: Snarky on Fri 25/05/2012 20:37:11Basically any time you have characters, objects and walkbehinds arranged on a plane seen from above (which is most of the time), this is the case you want.
I admit up front that I might be talking out of my ass here, but I can see some instances where that might not be the case. Say you have a shelf that a character can tip over, and things that are on the shelf. The things on the shelf would need to have a lower baseline than the shelf, though that's not physically the case. Right?
Now say you have a two-by-four that overhangs a stack of boxes on which it sits on top. Would it be tricky to set the baseline so that the board appeared on top of the boxes, and yet the character would walk behind it in the proper manner at the places where it overhangs? Like I said, I'm perfectly willing to accept "You are talking out of your ass" as a response. I haven't gotten far enough into game making myself to have encountered a situation like this.
Regarding the 2x4 overhanging the boxes scenario, it wouldn't actually be that difficult, assuming that if the character is behind the board then they're also behind the boxes as well.
As long as the box baseline is greater than the board baseline, you can let the player's baseline be determined automatically based on their y. So say the box baseline is at 200, the board baseline can be at 199. If the player's y is 200+ they'll be drawn in front of both, 198- they'll be drawn behind both.
I'm going to go upstairs and mess around with AGS a bit to see if this is the case, but for other beginners who might be wondering: would that not draw the board behind the boxes?
I may have been a bit confused by your wording, but if the board should be drawn in front of the boxes then just swap the box and board baselines.
Yeah, sorry. That was not the best way to describe the scenario. But as you said, it works much better than I would have imagined. I guess I hereby withdraw my support for a z-order function.
(http://www.ericnewsom.com/ags/boxboard.png)
Quote from: Eric on Sat 26/05/2012 01:33:15
Quote from: Snarky on Fri 25/05/2012 20:37:11Basically any time you have characters, objects and walkbehinds arranged on a plane seen from above (which is most of the time), this is the case you want.
I admit up front that I might be talking out of my ass here, but I can see some instances where that might not be the case. Say you have a shelf that a character can tip over, and things that are on the shelf. The things on the shelf would need to have a lower baseline than the shelf, though that's not physically the case. Right?
I'm not sure I follow exactly what it is you're imagining here, but if you're talking about something like a cabinet with objects sitting on a shelf, the issue is that the cabinet is sitting on the floor while the objects are sitting on the shelf
off the floor. So it's not an example of the common case I was talking about, since they're not on the same plane. To make it work correctly, you should set the baselines of the objects to be lower down (higher y-value) than the baseline of the cabinet.
So yes, there are definitely cases where the simplest "just set the baseline to the y-coordinate of the lowest pixel" method doesn't give the right results, but it's still pretty easy to make it work correctly. For objects of varying depth it can be a bit tricky, and you might have to write special code or break up the object into separate pieces; this is a fundamental problem of trying to do distance sort with only one distance value for each object.
Quote from: Kweepa on Fri 25/05/2012 23:26:35
The problem is that AGS has two meanings for Z.
One is the GUI sort order, which shouldn't be called Z-order at all. The end-user may not know about projection matrices, and the Z here is pretty arbitrary.
The second is the third spatial coordinate, up/down relative to the ground. This makes a little more sense except that x and y don't exactly define a ground plane in a lot of cases.
This could all be cleared up by renaming the GUI variable.
[EDIT] Cool! I got a little light bulb icon!
Actually, z-order is the standard term (http://en.wikipedia.org/wiki/Z-order) for sorting objects by "distance," and is commonly used in graphical user interfaces to describe how windows are stacked on top of each other.
If anything should change, I think it ought to be the character property, which might be renamed Y_prime or something like that.
If I were a programmer, I'd be upgrading the image-based pathfinder for a polygonal one instead. While the image-based approach is novel in terms of an easy setup,
it very quickly becomes clumsy and brittle in comparison to its polygonal sibbling.
There's a range of benefits inherent with a polygonal pathfinder that would be impractical or impossible with the existing tools. Complexity, accuracy and speed are its three signature strengths.
To name a few things that a polygonal system will bring to AGS:
- Arbitrary direction-independent navigation interactions Eg. Scaling - walking downwards into the distance
- Spiraling multi-tier structures that can overlap.
- Solves navigation through complex maze structures accurately and on the fly.
- Accurate character maneuverability Eg. Diagonal Loops - character's sense of direction now feels accurate and less clumsy when maneuvered.
If anyone is interested or has already considered upgrading the AGS pathfinder, I believe these links would be very useful.
http://www.david-gouveia.com/pathfinding-on-a-2d-polygonal-map/ (http://www.david-gouveia.com/pathfinding-on-a-2d-polygonal-map/)
http://blog.sokay.net/2008/07/23/northstar-intro-to-pathfinding-around-irregular-polygons/ (http://blog.sokay.net/2008/07/23/northstar-intro-to-pathfinding-around-irregular-polygons/)
Yes, though modifications to the pathfinder logic would be an engine-editor issue, as you can 'define' walkable areas and whatever in the editor, but it's actually the engine that makes sense out of it. Certain elements in the editor would have to be modified, mainly how walkable areas are constructed (the user would instead place points to define a polygon or choose from a selection of preset shapes that can be resized) and saved. From there the engine would have to interpret the new data, so there's a bit more work involved than just drawing some shapes in the editor.
While I have not tried using polygons in such a way I did use them for a tile-based engine I made once (defining tile and sprite shapes for collisions) and yes, there are considerable speed benefits to referencing a series of points rather than calling up a bitmap and looking for non-transparent or specific color pixels (which is how I believe ags currently handles walkable areas).
Quotemodifications to the pathfinder logic would be an engine-editor issue, as you can 'define' walkable areas and whatever in the editor, but it's actually the engine that makes sense out of it
Yes, correct. But I wasn't going to double post between two threads so I picked the editor one I was on at the time.
QuoteI did use them for a tile-based engine I made once (defining tile and sprite shapes for collisions
Fascinating, Progz! I'm intrigued.
Do you think it would be possible over time to extend the functionality of your tile-engine to meet the functionality of a full-blown polygonal pathfinding solution?
Is there any place where we can see all the features requests and their status?
I'm very interested to know this, and may implement some. This question also applies to the engine, I'm actually a C++ programmer, .net is just extra :)
This may sound a bit off key here but I'd like to see the main menu icons in AGS further apart. I have bad arthritis and it's difficult to always be precise. A couple more mm apart would be perfect for people like me.
(nod)
A few things I could sure make use of would be:
* Importing animations straight from .ASE format (aseprite) or even .MNG
* A way to overwrite more sprites at once, perhaps with a checkbox saying "Overwrite existing sprites" * done
I will look into those, because I need them since I foresee many tweaks as my game strides forward. If someone wants to help I'll be glad, but that's probably not gonna happen, is it ?
- Alan
Quote from: Alan v.Drake on Mon 02/07/2012 07:18:25If someone wants to help I'll be glad, but that's probably not gonna happen, is it ?
Not with that attitude. :P
What exactly do you want/need help
with? I know nothing about ASE. I know MNG is one of the animated PNG formats (personally I think that APNG would be better simply because it, unlike MNG, is backwards compatible, meaning it will still display the first frame in any PNG-compatible software).
The now official tracker for Editor bugs and requests:
http://www.adventuregamestudio.co.uk/yabb/index.php?project=5
(I hope that works, and you won't need admin rights to use that ;))
Quote from: monkey_05_06 on Tue 03/07/2012 22:35:42
Quote from: Alan v.Drake on Mon 02/07/2012 07:18:25If someone wants to help I'll be glad, but that's probably not gonna happen, is it ?
Not with that attitude. :P
What exactly do you want/need help with? I know nothing about ASE. I know MNG is one of the animated PNG formats (personally I think that APNG would be better simply because it, unlike MNG, is backwards compatible, meaning it will still display the first frame in any PNG-compatible software).
Don't worry, that's a low priority. With the change I made one can already import over a range of selected sprite via the "tiled import" option.
It would be certainly of use to have the possibility of importing directly animations with alpha channels (apng, mng, ase) if we can find libraries to handle them and it doesn't take too much work.
Also, multiple selected sprites could be merged into one of those formats (gif if withouth alpha) and opened in the associated editor. But maybe i'm going too far.
- Alan
Examining the Grim's Cat Lady production screenshots suddenly brought me few ideas:
http://i.imgur.com/2NOz9.jpg
As you see, his project tree is quite a big one. Now, imagine you have opened lots of folders there and now want to close them, or maybe open different type of items. You will need to scroll up until you find the root.
My suggestions:
1. Make "Collapse current tree"/"Collapse all" options in context menu for the project tree.
2. Make "Go to:"->Item category option in context menu.
3. Actually also: "Find item" option which will open a "search for project item" dialog.
4. Add combo-box and filter-box at the top for Project Explorer. Combo-box allows to choose item category which to display, or "All project items". Filter box allows to type a string with wild-card characters and thus filter the displayed contents.
EDIT: A much better alternate for item-type combobox are bitmap buttons that may be toggle on/off, with two extra "check all" and "uncheck all".
EDIT2: Also struck out 2 and 3 since their functionality is covered by suggestion No 4.