Messages

Thats fucking cool guys.

I will be releasing some modules for this!

I think a constructor would be great and a destructor might be cool (?)

static methods should already work right?
Do properties work? I forget what AGS calls them.. attributes i think.

This is a known issue in WINE's clipboard handling. It's a wine bug i'm afraid.

I think gc is likely null because you get the GUI using the mouse coordinates after registering a click.

This sometimes means that the mouse can be over the control when the click occurs but may have moved before you actually get the control using the mouse coords and so you can register a gui click but have a null control.

To know for sure we'd need to see what calls your function

The only downside is that the games will only run on Windows if they rely on a plugin.

This is not true. Plugins can be compiled for any environment you like and AGS can load them providing then are native to that environment.

When will this be merged with master so the ports can take advantage of it?

If you can make that work then you'll have gone a long way towards "fixing" AGS Script.

Has anyone done any kind of analysis on this yet? I'm working on stripping out scintilla which is a native library and so far, so good. What else is there?

I think I remember there being named pipes for the debugger which is a windows-only solution so I suggest we replace that with a tcp socket solution which is pretty standard cross-platform.
I believe the debugger communicates in plain text so it should be a very easy swap with only the comm method being changed.

Is there anything else?

Tzachs? CW?

Those particular items dont highlight because the Lua plugin is disabled for that project

It would be highlighted just fine if the plugin were enabled and the script header were injected.  :>

So I rolled up my sleeves, made a new branch and started:



At this point the dependency on scintilla is completely gone and AGS works minus some features like autocomplete.

I agree with CW. This is, at best, a hacky stopgap.

The pointer syntax in AGS is a weird anachronism as it is and shouldn't be expanded.

I think it would be better to move towards true object references.

AGS does have a way to add arbitrary structs to the object pool via the plugin interface. Is it a huge deal to simply expose this to the script env?

Your post illustrates why people think you're a really cool guy.

on_mouse_click should be called when, i dunno, maybe, possibly, when the mouse is clicked.

Just an idea.

I still think this distinction is utterly stupid.

Some more promotional art:

Ah yes, i see that now.

That's fair enough. There's nothing stopping someone else from hosting nightly builds. That's usually what happens when OSS devs charge for builds.

Not open source anymore?

That is some bullshit.

Mmmyes, but what if you have background characters that are always doing something (birds fluttering about, or e.g. a librarian who's stacking books on different shelves)?

I think this is likely to be the exception in 99% of cases and so you could make some kind of exceptional logic to deal with them. But I also think that this kind of example highlights exactly *why* my system is a good idea. I shouldnt have to save the location of the birds in the sky. From a semantic, gameplay perspective it's enough to know that there are birds in the sky. More than that is not fully related to the players progress and their experience.

It's certainly not for every type of game. Heroines Quest is a good counter example for the reasons you mentioned.

Also, I do save some state information because I consider it to be semantic and very easy to store. For instance I save whether or not dialog options have been chosen but I *dont't* save whether or not they are active.
I'm using the custom dialog system demoed in my Lua thread and each dialog option has essentially a function that returns whether or not the option should be visible. Like this:



This is all saved in a lua file and then the condition is compiled dynamically and tested every time I want to process any particular node of the dialog tree. It seems to work very nicely and it's very convenient.

With regards to saving tweens and animations and stuff, I get around this mostly by limiting when the player can save the game. I don't think the player should be able to save the game "mid-event" and so only allow them to save in open play, basically when the game isn't blocked. This eliminates most of the very immediate stuff.

It doesn't seem to be more complex but I havent made a big game this way yet so I guess we'll see. I think, with good plannig, it should be *less* complicated.

I've been experimenting with something a little different for my new project Latency

In AGS we usually model our game progress by simply saving the whole state of the game. We save what music is playing, where the characters are, all the internal variables, which objects are visible. It's a snapshot in time that we resume later.

In Latency I'm attempting what I call a "Limited State". Essentially we only save the progress the player has made and we rebuild the game state from that information. This has a couple of advantages as far as I can tell.

1 - Complete decoupling from AGS's save state information. This means that, as long as you have logic to handle changes, save states can persist across versions of your game because you're saving *semantic* information about the game state rather than raw data.

2 - It's easy to recreate a game state from scratch for testing purposes. Most adventure games really have very few important events. It's not usually necessary to store everything the player has done, only what advances the game state in some way which often only amounts to a few actions. The terseness of some walkthroughs is a testament to this.

3 - Data in your game can persist across saves. Ever wanted to do some kind of transitions when loading an AGS game? This is possible but its a bit unwieldy since you can't persist timers and stuff between the old state and the new state. With this method you can.

4 - I'm not sure about this one but I *think* this method should be far less buggy because the game state is very explicit to you as a designer. You are forced to distil your design down to atomic events. You have a 100% clear idea on the game state because you set down those rules yourself.

What do you guys think? Food for thought at least, right?

EDIT: maybe Semantic State is a better name...