Include suggestion

[stuh505]

I would like to see a way to include .cpp/.h files (that would accept C++ code), either through the use of a prepocoessor directive such as #include, or by setting them through some kind of visual editor.

A lot of code, such as the STL, has been written in C++ and shouldnt' have to be written over again for AGS use.

I don't know how the AGS Script technically works -- if it is really using a C++ compiler, then this should be pretty simple right?

If it really is using a new compiler...then you could just incorporate a c++ compiler to compile the included files into binary, and then use that.

[scotch]

The AGS scripting language was entirely developed by CJ, and is not related to C++, so unfortunately this would not be possible.

Actually no scripting language I know of uses a C++ compiler, but many do have libraries that provide some of the STL classes to the scripting language... I wonder how hard it'd be for CJ to open up a few of them to the script, now that AGS script is more object oriented... some kind of resizable array/vector would be quite handy, I think.

I haven't looked at the latest plugin API but it may well be possible to make a plugin that does this.

[stuh505]

What was the point of writing a new language for AGS?  It would have been much easier to simply use the existing C++ language.  Maybe he did it for fun.  Well, I move that the AGS language be replaced by C++...and just have some built in libraries for the AGS functions.

[x_traveler_x]

Just my 2 cents as a passive observer...

It's apparent that you know C++ pretty well, or one can only assume since you speak so highly of it.  So I can understand where you're coming from.

But, part of the whole spirit of the AGS engine (at least from what I've noticed so far) is that anyone with or without scripting experience can use it with ease.  C++, on the other hand, is not something that EVERYONE is knowledgeable about.  Therefore AGS would most likely become less popular if all the sudden everyone had to learn C++.

[scotch]

Game scripting languages are often designed to have limited features, to be easier, they are most often designed to be used by non programmers.  If you had to write your AGS scripts in C++ we'd get games creating memory leaks and buffer overflows and all the other problems you can get when using C++ without care.  In my engine I'm using something with similar features to AGS script, which IMO is about the right tradeoff between safety and features.  You can do almost anything in AGS script that you would need in a traditional point and click adventure, and that was what it was designed for.

Why do you think making the AGS language be C++ would be easier for CJ? C++ compilers are very complicated, and the language is just not designed to produce scripts to be embedded in a pre built engine, I guess you're asking for some headers and that give you more access to the AGS engine, and then you'll compile your game with a C++ compiler, into a dynamically linked library or something.  95% of people would not be capable of that, and I personally wouldn't bother because the scripting language is just more suited to scripting AGS games.

Another advantage of bytecode compiled scripting languages, they can be cross platform with no need to recompile.  You can run an AGS game in the linux or DOS engines as it is, with the game logic done in C++ you'd have to make three versions, and keep your code cross platform enough to allow you to do that.

I'd certainly prefer the current way over giving someone a set of C++ headers and libraries and a compiler and getting them to write the game that way.  If it's not too much trouble to CJ it wouldn't hurt to let people do this, but I think the current plugin system combined with the scripting language is more than adequate.

[Gilbert]

All I can say is that, AGS is currently a game engine which is quite self-contained on its own (apart from the usage of plug-ins which are for use in AGS), it's not a set of game libraries for use in some general compilers.
Not for now, at least.

[Kinoko]

Part of that is exactly the thing I love about AGS. I knew next to nothing about programming when I started here, and it's the reason I started using AGS. It was just so easy to get a grasp of, and I've learn -so- much since then. Occasionally, I find something inconvenient, but the trade off for pure ease of use and the ability to get started with it in the first place is something I wouldn't want to loose. I think AGS currently has a fantastic mix of being both user-friendly, and customisable.

If you can use C++ (and again, I don't know much about programming so I may be WAY off the mark here), can't you pretty much make your own game without an engine?

[stuh505]

I have 2 things to say.

1) I assume that AGS language is here to stay despite my preference.Ã,  But in that case, there still could be a way to include modules of AGS script, so that users on the forum could for example write out an AGS file that contained some new functions and variables etc and then share it with someone else and they could just include it without literally having to copy/paste.Ã,  The good thing about this besides shareability is that by breaking it up into modules the main AGS script can be less confusing and long.Ã,  Also, these could be loaded with their own separate namespace to avoid variable overlap problems.Ã,  And it would all compile into 1 exe unlike plugins.

2) Back to the debate at hand.Ã,  The C++ syntax could be used in AGS without really changing anything at all.Ã,  Just because C++ is used doesn't mean that you have to learn a more complicated and new language...its basically identical to the AGS language in terms of everything that AGS can do.Ã,  The only real difference is that with C++ there are MORE things built in...so if you're not a good programmer, you wouldn't have to worry about trying to do any of the other advanced features.

AGS is really bad at managing data structures for example.Ã,  But if we were using C++, we could just link in to the the Standard Template Library, and you'd automatically have access to hundreds of data structure classes that have been tried and proven to work without CJ having to re-make them all by hand.Ã,  C++ is pretty universal and basically it would just allow everyone to reuse a lot more code!

Basically as a final note...the language could be switched over to C++ without anyone having to learn actually learn the new benefits of C++ if they didn't want to...they could keep on using AGS just the way they have been, and probably not even realize what had changed...except for a few very minor syntactic differences.

[scotch]

2.7 has added support for script modules.

There are still some things in C++,  that'd be nice to add to the scripting language, but I think we have most of them... I've tried scripting a lot of unusual things in AGS, there's not much that you'd need C++ for.  And I don't expect that 2.7 has the last improvements to the scripting language we'll ever see.

[Pumaman]

I think scotch has neatly summed up what I would have said in reply to this thread, so I don't have much to add.

there still could be a way to include modules of AGS script, so that users on the forum could for example write out an AGS file that contained some new functions and variables etc and then share it with someone else and they could just include it without literally having to copy/paste.

As scotch says, support for this has been added to AGS 2.7.

2) Back to the debate at hand.  The C++ syntax could be used in AGS without really changing anything at all.  Just because C++ is used doesn't mean that you have to learn a more complicated and new language...its basically identical to the AGS language in terms of everything that AGS can do.  The only real difference is that with C++ there are MORE things built in...so if you're not a good programmer, you wouldn't have to worry about trying to do any of the other advanced features.

In effect, AGS is already a mini-C++ compiler, supporting a limited subset of the C++ syntax. However, the things that are different are designed to make things easier for people to use -- for example the way the pointers and memory management work has been designed to be automatic so that people scripting don't have to worry about things like memory leaks.

If there is any C++ language feature missing that you think would be really useful, then we can of course consider it for a future version of the scripting language.

AGS is really bad at managing data structures for example.  But if we were using C++, we could just link in to the the Standard Template Library, and you'd automatically have access to hundreds of data structure classes that have been tried and proven to work without CJ having to re-make them all by hand.

It's really not that simple. Consider for a moment why AGS doesn't have much support for data structures. It's not a decision to annoy you, it's because AGS has to automatically save and load the game when the player asks it to. On this front a lot of progress has been made in 2.7, but it's still by no means perfect.

With C++ you have memory addresses and pointers all over the place, and it's simply not possible to automatically save the state of the code. Therefore, people would then have to manually code save and restore routines for their games. There are several other things like this that you wouldn't necessarily think of at first, but actually in practice mean it's not practical to support a "real" programming language in an engine like AGS.

[stuh505]

Do the script modules in 2.7 have their own namespace?

With C++ you have memory addresses and pointers all over the place, and it's simply not possible to automatically save the state of the code. Therefore, people would then have to manually code save and restore routines for their games. There are several other things like this that you wouldn't necessarily think of at first, but actually in practice mean it's not practical to support a "real" programming language in an engine like AGS.

That is a good point which I didn't think of.

However, it does not sound so impossible to me as you make it out to be

For instance, all you really need to do is keep track of the states of all the variables...which means keeping pointer records for each variable.

You must have already had to do this in AGS script for things like ints and arrays.

It seems like the only modification you would have to do to regular C++ code in order to make it truly-saveable is to record pointers to the memory locations whenever a variable is defined(or declared, I'm not sure when C++ actually allocates space) or when the new operator is used.

This could be accomplished by just doing a pre-processing pass to modify all the C++ code before it was compiled.  This would be limiting in that one could not use C++ binaries compiled outside of AGS.  You could even release a separate AGS C++ compiler that simply did this preprocessing step before compiling, allowing binaries to be compiled and linked in seamlessly.

[Snarky]

If there is any C++ language feature missing that you think would be really useful, then we can of course consider it for a future version of the scripting language.

The for loop!

(Hoping that CJ didn't add it without me noticing so I'll look all silly... No, actually it'd be worth looking silly if it meant having the for loop.)

[strazer]

Hoping that CJ didn't add it without me noticing

You can check the status of a particular feature on the bug tracker: "For" loops

[Traveler]

I don't think using C++ would be a good idea at for writing games. Unless you want to implement the basic engine to run the game, having a separate scripting language is much better in terms of simplicity, efficiency and maintainability.

I use C++ for a long time now (~8 years) but I still like the AGS scripting language better - although I don't have much experience with it. It's actually good for a change to not to have to deal with pointers, memory management, etc. I started liking even C# for the same reason (in spite of its stuuupid name.    ) It would be nice to have strings similar to C#/VB6 instead of using StrCpy(), etc.

If you really want to add some code in C++, you can still write plugins in C++ and import your functions into AGS. If you want to use C++ containers, just whip up an interface for the STL class and you can start using it. I was thinking about implementing dynamic collections this way so that any number of items could be stored in it with a key for fast lookup. I need more time to get it done, though.

[strazer]

It would be nice to have strings similar to C#/VB6 instead of using StrCpy(), etc.

http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=258

[stuh505]

If you really want to add some code in C++, you can still write plugins in C++ and import your functions into AGS

Can you?  I didn't think that the plugin code could call AGS functions.

It's actually good for a change to not to have to deal with pointers, memory management, etc. I started liking even C# for the same reason (in spite of its stuuupid name.    ) It would be nice to have strings similar to C#/VB6 instead of using StrCpy(), etc.

I also learned C# last summer and found it to be an extremely efficient language to program in...after about 2 weeks I was doing some pretty crazy stuff like writing dynamic code and having it compiled and loaded into the current environment...doing a lot of stuff I could never do in C++ with ease.  The only reason I was pushing C++ is because it's more universal, even if it is a bitch.

[Pumaman]

Do the script modules in 2.7 have their own namespace?

No, but because member functions and static member functions are now supported, the only thing that pollutes the global namespace is the struct name itself. As long as the structs are named in a verbose manner this is not a problem.

However, it does not sound so impossible to me as you make it out to be

I'm not saying it would be impossible - rather that I don't think it's worth the time and energy to make it work. C++ compilers generate native code, so if the scripts were compiled that way they would no longer be cross-platform; and also, I just don't feel that the few extra features that the C++ language would provide would be worth it for the significant amount of time it would take to implement.

It would be nice to have strings similar to C#/VB6 instead of using StrCpy(), etc.

Yeah, I agree. The reason I haven't been too enthusiastic to do that so far is mainly performance. Strings in VB6 and to a lesser extent .net are very slow since memory is always being allocated and deallocated and so forth -- in some large VB6 projects, up to 10% of the CPU time is taken up with allocating strings.
In a game environemnt such as AGS, I would need to give careful consideration to string implementation to ensure it was not a problem.

Can you?  I didn't think that the plugin code could call AGS functions.

Yes, the plugin API provides the GetScriptFunctionAddress function to allow the plugin to call any AGS script functions.

[Traveler]

It would be nice to have strings similar to C#/VB6 instead of using StrCpy(), etc.

Yeah, I agree. The reason I haven't been too enthusiastic to do that so far is mainly performance. Strings in VB6 and to a lesser extent .net are very slow since memory is always being allocated and deallocated and so forth -- in some large VB6 projects, up to 10% of the CPU time is taken up with allocating strings.
In a game environemnt such as AGS, I would need to give careful consideration to string implementation to ensure it was not a problem.

That's true, I didn't think of it. Anyway, I wasn't asking for the actual behavior of C#/VB strings, just the ease-of-use... which is the actual behavor, if one thinks about it. 

Edit: I knew I shouldn't have messed with quoting tags... now it looks fine.

[stuh505]

Yeah, it would be nice if you could program from a dynamic higher level perspective and then have it be implemented more efficiently.  Wouldn't that be nice?  Sort of like how some languages will code up a non-recursive version of your recursive functions automatically.  But I think that's just a wee bit too much to ask from our friend CJ