Future AGS development

[Dualnames]

If you can make a list of commands and ways a visual novel coding works, I can make the equivalents in AGS. Trust me it can do anything. It now is programmed to wake me up and dress me.

I'm serious on the first part.

[GarageGothic]

The associations you're talking about actually are already kept in XML in the Game.agf file. IIRC even the relative paths from the import are stored in place of what CJ described as a future "update sprite from source" option (I believe).

Oh, I didn't realize this. I thought view, loop, frame assignations were part of the sprite .dat file for some reason. Then a custom resource file plugin along with an editor plugin to circumvent the sprite importer (and decode unsupported file formats to thumbnails) should do the job. Thanks for clarifying.

[monkey0506]

It would ultimately have to end up in the same place anyway, in the same format, for the compiler to be able to make use of it. However, if the editor source were opened up then it would presumably be possible to write functions to handle that.

[GarageGothic]

It would ultimately have to end up in the same place anyway, in the same format, for the compiler to be able to make use of it. However, if the editor source were opened up then it would presumably be possible to write functions to handle that.

Not necessarily the same format (and certainly not the same place if you by that mean the default sprite .dat file). A plugin can easily draw images in different formats to the viewport from a virtual folder structure in a resource file. Possibly it would be necessary to use custom animation functions, though - I haven't looked that far into the plugin API.

The huge benefit that comes from accessing images from individual files stems not just for the ability to use different formats (e.g. photographic backgrounds in PGF and cartoon characters in PNG or even vector formats like SVG) to limit file size, or make editing of imported files easier, but also can help portability to other platforms. E.g. store your art in a very high resolution and zero compression and have it resized and compressed upon compile - a lower res version for iPhone and Flash, a medium resolution/quality for free download, and a printed DVD collector's edition with super-high resolution for fans with the hardware to run it. Or if you prefer having full control of scaling filters and touch-ups, store alternate versions in subfolders or using an amended file name which will then be prioritized upon compile for that resolution.

I should explain that what I wanted to do with my plugin was to make AGS totally resolution independent by replacing AGS' screen rendering and use a virtual resolution property instead of fixed pixel width/heights. So in the above examples, whatever the image size they would all stretch to the allocated screen space and placed on screen coordinates scaled accordingly. At the moment there's no way to intercept viewport initialization from a plugin, so we're stuck with the limited resolutions AGS currently offers, but as soon as that's possible it will all make sense - at least for the non-pixel-artists  .

[monkey0506]

The reason I said that it would have to end up in the same place is because I'm assuming that the editor doesn't read back raw byte streams for the images at compile-time but that the compile step actually directly makes use of the built-in sprite storage, which is encoded differently than the regular image formats.

The editor can do whatever it wants, but at compile time if the resources aren't where the compiler expects them to be, in the format in which it expects it to be in..then it can't very well make use of the resources.

I'm not sure what methods might be exposed that might be able to avert this situation altogether, but short of the compiler feeding decoded image streams into the native C++ code I don't see how it's going to work.

[GarageGothic]

True, the compiler would fail if I messed with the game.agf - so the editor would have to write image location and properties to a custom file instead. There'd still be an empty sprite file in the distribution folder, but that's pretty much it as far as compiler compatibility. Personally I don't really care about supporting the view editor if I have to write custom animation routines anyway (which would be for the better to avoid double caching), but of course some kind of integration with existing editor features would be necessary for a publicly released plugin.

[Babar]

I wish that the scripting for AGS would become less programming-like too.

Maybe something a bit more English (newbie) friendly,

INTERACTION EDITOR!

There was someone creating a plug-in, and then they basically just....left it. Who knows if it will be fixed up again now that the editor may possibly be opened up. Shouldn't the current OOPness make it EASIER? Like someone would select from CHARACTERS, OBJECTS, ROOMS, HOTSPOTS, etc. and then further select which instance of that thing they want, then they'd select a function (walk, changeroom, addinventory, etc, depending on what functionality is available for what they chose)... it could possibly even be completely automated!

People underestimate the greatness of the Interaction Editor...it REALLY made everything very simple for average AGS users (perhaps not the code-gods in here). BRING IT BACK!

[Wonkyth]

I confess, I cant stand non-code programming, like that in Game Maker, it always seems so limiting and irritating at the same time. 

[monkey0506]

Part of the reason that plugin was abandoned is due to limitations in the editor plugin API which made things difficult at best to really get working properly. If the editor were opened up, that's one of the many things that could be added in more fully.

[Scavenger]

If the editor code is opened up, does this mean that 256 colour mode could be made a little easier to work with (More remapping options, like when importing GIF animations [they can't be imported exact palette, if I recall], viewing the room palette rather than having only one pane for a global palette, exporting backgrounds as indexed etc)? I know I'm probably the only person left on the planet who uses 256 colour mode, but still, it would be nice to have the workflow a little easier. I don't like having to wrestle with AGS for 8bit mode.

[subspark]

If the editor were opened up, that's one of the many things that could be added in more fully.

Monkey's right. A refresh on the interaction editor could be assembled so that most of the current scripting language could have a click and drag front-end.

For example you might have a scene where you need your character to play an animation while he is speaking as the room scrolls to the left. This is relatively basic to set up in the script already, but I imagine this sort of thing (and more) would become quite trivial to the most basic user.  8)

Sparky.

[Pumaman]

What use is the editor code if the compiler code is still closed?

because surely we cant actually change anything since the compiler still needs to understand what the editor does.

What use would the compiler code be if the engine code is still closed? There's no point being able to change the compiler if you don't have the engine source code, since it wouldn't understand what your new compiler had produced.

As monkey_05_06 says, having the editor source code effectively extends the editor plugin API to allow you to do whatever you want within the editor.

If you close source the native DLL wouldn't this be detrimental to using the editor on any other platform?

Personally I have no interest in seeing the editor on other platforms. The Mac/Linux voice always shouts very loud, but it is such a tiny proportion of real world users that in terms of the editor it's not something I think it's worth spending time on.

The engine is a different matter, and having Mac/Linux ports of the engine is a good thing so that the maximum number of people possible can play games that are created with AGS.

But all in all realistically for the engine to improve you have to either open source it.  Or give the code to a highly capable and motivated team of people.

As I have said, opening this editor code is a first step. It's an experiment to see if opening up AGS will lead to productive results, or just stagnate or make a mess.

If things go well, then I'll consider opening up the rest of the code too.

[Calin Leafshade]

What use is the editor code if the compiler code is still closed?

because surely we cant actually change anything since the compiler still needs to understand what the editor does.

What use would the compiler code be if the engine code is still closed? There's no point being able to change the compiler if you don't have the engine source code, since it wouldn't understand what your new compiler had produced.

Fair point,

I actually look forward to sprucing up the gui editor! ^_^

[Dux]

Woohoo!

Exciting times ahead for sure=) Coders start up your engines and show Chris what a dedicated community can do!

[xenogia]

Personally I have no interest in seeing the editor on other platforms. The Mac/Linux voice always shouts very loud, but it is such a tiny proportion of real world users that in terms of the editor it's not something I think it's worth spending time on.

The engine is a different matter, and having Mac/Linux ports of the engine is a good thing so that the maximum number of people possible can play games that are created with AGS.

I disagree.  Do you think that Mac/Linux users only want to play AGS games and not create them themselves?

[Gilbert]

There're still methods to run the Windows Editor, like Wine and Parallels (or whatever solutions that I don't dare learn about), though whether the Editor could be run without any problems is another matter. Given the amount of work that may be involved in making native versions of the Editor to these platforms it's arguable on whether this is needed considering the user base of such platforms.

Also, as this is only the first step in open sourcing the AGS stuff it may still be possible to do such porting later, just not at the moment.

[subspark]

Personally I have no interest in seeing the editor on other platforms. The Mac/Linux voice always shouts very loud, but it is such a tiny proportion of real world users that in terms of the editor it's not something I think it's worth spending time on.

I think your underestimating the adoption value of would-be handheld developers. It's the chicken or the egg. If there's no chicken, there's no egg. CJ, sorry buddy, but your the chicken.
Sparky.

[BatWitch]

If you can make a list of commands and ways a visual novel coding works, I can make the equivalents in AGS. Trust me it can do anything. It now is programmed to wake me up and dress me.

I'm serious on the first part.

I'll definitely hold you for that statement in the future when I am a bit more clear on what I need to get the job done. Right now I'm at a stage where I'm a little disorganized/tough to collaborate with.

[xenogia]

If you can make a list of commands and ways a visual novel coding works, I can make the equivalents in AGS. Trust me it can do anything. It now is programmed to wake me up and dress me.

I'm serious on the first part.

I'll definitely hold you for that statement in the future when I am a bit more clear on what I need to get the job done. Right now I'm at a stage where I'm a little disorganized/tough to collaborate with.

Why not just use Ren'py to create a visual novel??

[BatWitch]

Creating a imagemap (or any kind of interactive visual element) in renpy is quite dreadful.
I think that the way adventure games have things you can point and click is the way to go, rather than having everything as a menu choice. Having a main character who can walk around on a map (even if it's low resolution) is also a huge plus.