Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SomeGuy]

I'm not sure if this is exactly the right place for this, but I would be highly curious to hear the replies.. Why is it that Every Adventure Engine, be it AGAST, AGS, Wintermute, SCI, Glumol, Sludge, or what have you, all integrate a scripting language within the game?

It seems that you could do nearly as much by using clever API definations, and then wouldn't run into as many problems.. People complain about AGAST not having decent arrays, or it's class system failing, but it seems that all of these problems would "magically" go away, if it were used as a set of libraries intended for the use in, and creation of, Adventure games.
Then, whatever language WM was programmed in (C/C++?), could simply be used to program the game, rather than relying on a scripting language that may or may not be suitable to the task.

I'm not attacking the creator, I'm sure she had great reasons for doing it that way.. I just am REALLY curious to hear what they are.

Now, I know you are going to be temped to say that the scripting language makes it easier, but I'm not sure that that is so. If you could define each object on the screen seperately, and define macros, then you could have all of the functionality of C, with the Ease of a scripting language, such as Lua.

There is no reason you couldn't have a C++ (or Java, or what have you) Object called Ego. Then, you could trigger that object, and have a function (Method) called LookAt.
That function could then talk to another object in the room, such as a key.
So, in the Initial Demogame, you would be at-> (psuedo code included)

{
Object Key = new Item;
Object Ego = new Ego;

Scene(This).setbackground("Swamp.jpg");
Scene(This).setmusic("70sJazz.mp3");
Ego.Lookat(Key);
}


And defining the Lookat would be equally easy..
Ego {
Void Lookat (Item X)
{
MessageScreen ("It's a key!");
}}



So, I guess what this rameling is about.. Is why is it done the way it is? Everyone seems to be doing it, but I'm not entirely sure why.

[Mnemonic]

That's a good question. Well, incidentally I wrote an article about game scripting about two weeks ago. The article was written for a czech gamedev webmag, hence it's in czech, but I will translate the first part which explains what game scripting is about.

disclaimer: I translated the thing very quickly so I apologize for any misspelling and grammatical errors ;-)

We all know the computer games are becoming more and more complex. Players' demands are getting bigger and so are demands on the iternal game logic. There were times when all the logic has been "hardwired" directly into the game code, but thoose times are gone. Todays trend are game "engines", which are as generic as possible. They provide a stable program core, which is then used by the game designers as a tool for creating their games. The advantages are obvious; by simply changing the game data we can use the same engine many times in many very different games, without the need of changing the code considerably. The engine core is completely separated from the internal game logic of an actual game, and that's the goal. The programmer is creating the core; the designer is creating a game. But how to ensure this core separation and in the same time to provide the designers with all the functions and features of the game engine? Yes, as you've already learned from the title, the solution is a scripting language.

But what should we imagine under the term "a scripting language for a game"? The idea is simple; the engine provides a large set of various functions, let's call them "low level functions". Those functions are programmed the old fashioned way we all know, for example in C++. They work directly with DirectX/OpenGL, they are scanning the keyboard for input etc. Those functions are then "exported" out in some way, so that it's possible to call them from a game scripts. The scripts are basically also simple programs, but they are written on a considerably higher level. It means the script programmes has no longer deal with "non-important" things, such as vertex buffers, texture loading, sound buffers filling etc. Let the engine deal with that; the designer has high-level objects in his possesion. Objects like "the player character", "the door", "the medikit" and he works with them in his scripts. I'm sure I don't need to name the advantages any longer: simply said, the designer can fully concentrate on creating the actual game and he leaves the implementation details on a programmer.


To better demonstrate the described approach, I will show you and example of a game script:


  Player.GoTo(100, 200);
  Player.TurnTo(Door);
  if(!Door.Open)
  {
    Player.Talk("I have to open the door first.");
    Door.PlayAnimation("open_door.anim");
    Door.Open = true;
  }
  Game.ChangeScene("inside_house.scene");


The above script snippet will do the following: the player character will walk to the position at 100, 200. The character will then turn to the door and if it's are closed, he will open it. He will then walk into the door which will result in loading another map. Commands like "GoTo" or "PlayAnimation" are those low-level functions, provided by the engine. They can be quite complex inside, but to the designer they appear like these simple one-line commands.

The conservative programmers can object that this piece of code might as well be written in C++. It's true to some extend, but...

We said earlier that out goal is to "shield" the designer from the game code. Me must realize that the designer doesn't have to be a hard-core programmer, he might not be able to work with a compiler of a programming language, he may not even have it installed on his computer.

Next thing we must be aware of is that there can be multiple such scripts running at the same time (and there are ususally lots of them). The above script handles the player charater's behavior. But there can be another character in the same scene, which, for example, walks around and swears :-) We will need a second script to handle that, which will run concurrently. There can be a cuckoo clock hanging on the wall, and every hour a cuckoo jumps out of them. And here we are with a request for another script, which will track the time and after a certain time period will pass, it will play a cuckoo animation. And I could go on like this, but you get the idea.

I think I don't have to emphasize the fact that this example would be much harder to do in C++. Yes, of course, we could use multithreading, but we all know it's not exactly an ideal of simple game logic programming we are after.

If some of you still doubt about the advantages of the scripting language usage in game development, then know that most of todays games use some king of simplified scripting. One great example could be the Unreal Engine with its excellent UnrealScript.

...

Of course the article only says briefly why should we prefer scripting to low level programming languages. I could add some more advantages, like the ability to change scripts "on-the-fly", thus tweaking the playability without the need of recompiling the engine (it can take a while for large projects). Also the script language can be used to define the game data (definitions of animations can be actually scripts - but WME doesn't use this approach which is criticized sometimes).

Needless to say the designer's separation from the core engine is especially important in case of freely available engines like WME, AGS or AGAST, when the majority of users are NOT hard-core programmers and they probably wouldn't be too happy if they had to purchase a C++ compiler to make their games.

[Mnemonic]

I'm not attacking the creator, I'm sure she had great reasons for doing it that way.. I just am REALLY curious to hear what they are.

Oh, and by the way, I'm a man

[Someguy]

I will translate the first part which explains what game scripting is about.

Thank you very much for taking the time to reply. I hope you don't midn if I address several points-

They provide a stable program core, which is then used by the game designers as a tool for creating their games.

I agree with this strategy, but I still contend that if a programmer properly separates out functions, and provides only the necessary APIs, the underlying nastiness can be shielded from the user, without going through the rigamarole of re-implementing a scripting language.

But what should we imagine under the term "a scripting language for a game"? The idea is simple; the engine provides a large set of various functions, let's call them "low level functions". Those functions are programmed the old fashioned way we all know, for example in C++. They work directly with DirectX/OpenGL, they are scanning the keyboard for input etc. Those functions are then "exported" out in some way, so that it's possible to call them from a game scripts. The scripts are basically also simple programs, but they are written on a considerably higher level. It means the script programmes has no longer deal with "non-important" things, such as vertex buffers, texture loading, sound buffers filling etc. Let the engine deal with that; the designer has high-level objects in his possession

This is where I lose you, however. If the code is properly abstracted, and properly object-focused, you shouldn't ever need to deal with Vertex shaders, and can still work directly in the language. The vertex shading code can be completely hidden from the main body of the game code, yet still allow the game to be written in an existing language.

 Player.GoTo(100, 200);
  Player.TurnTo(Door);
  if(!Door.Open)
  {
    Player.Talk("I have to open the door first.");
    Door.PlayAnimation("open_door.anim");
    Door.Open = true;
  }
  Game.ChangeScene("inside_house.scene");

That entire segment would look very similiar in Java, or C++, or any proper OO language..

They can be quite complex inside, but to the designer they appear like these simple one-line commands.

You are describing methods and functions

I know what you are trying to get across, but I'm still not sure that the conventional wisdom, that the only way to expose this functionality easily, is via a scripting language.

We said earlier that out goal is to "shield" the designer from the game code. Me must realize that the designer doesn't have to be a hard-core programmer, he might not be able to work with a compiler of a programming language, he may not even have it installed on his computer.

There are many free compilers, including the GCC series from Gnu, The Python language, Java VMs, and the like. Downloading and installing Eclipse wouldn't be in a different league than the WME tools..

Next thing we must be aware of is that there can be multiple such scripts running at the same time (and there are ususally lots of them). The above script handles the player charater's behavior. But there can be another character in the same scene, which, for example, walks around and swears :-) We will need a second script to handle that, which will run concurrently. There can be a cuckoo clock hanging on the wall, and every hour a cuckoo jumps out of them. And here we are with a request for another script, which will track the time and after a certain time period will pass, it will play a cuckoo animation. And I could go on like this, but you get the idea.

I think I don't have to emphasize the fact that this example would be much harder to do in C++. Yes, of course, we could use multithreading, but we all know it's not exactly an ideal of simple game logic programming we are after.

But again, if it were abstracted away from the user, they wouldn't need to know they are using multiple threads, or that there is a loop polling objects 20 times a second. They would just create a new Object (of a pre-defined type), and then write it's reaction. It would be far simpler to try to create a clock that syncs with real-time using an array of time keeping libraries(in C++/Java), then it would be to try to read it in from Who-knows-where in an engine. Not to mention that adding DLLs to the problem re-adds the complexity you had hoped to avoid.

Of course the article only says briefly why should we prefer scripting to low level programming languages. I could add some more advantages, like the ability to change scripts "on-the-fly", thus tweaking the playability without the need of recompiling the engine (it can take a while for large projects).

I don't know about WME, but most game scripting languages are still compiled. QuakeC, Unreal's Scripting language, Agast's..

Also the script language can be used to define the game data (definitions of animations can be actually scripts - but WME doesn't use this approach which is criticized sometimes).

Actually, I agree with this part. Defining an object outside of the code proper is a good idea. But it is possible to define it, and then deal with it directly later on.

Needless to say the designer's separation from the core engine is especially important in case of freely available engines like WME, AGS or AGAST, when the majority of users are NOT hard-core programmers and they probably wouldn't be too happy if they had to purchase a C++ compiler to make their games.

Fair, and Again, I'm not trying to attack in any way. I'm just trying to gather information and make the right choices. But it seems that with the prevaility offree compilers, including decent IDEs, There might not be a need for language re-implementation. Perhaps the next major revolution in Adventure Game Engines will be a step Backwards.. To being glorified collections of libraries to abstract away all the stuff like Inventory, Scenes, and the like..


Just some more thoughts,
Colin

[Mnemonic]

This is where I lose you, however. If the code is properly abstracted, and properly object-focused, you shouldn't ever need to deal with Vertex shaders, and can still work directly in the language. The vertex shading code can be completely hidden from the main body of the game code, yet still allow the game to be written in an existing language.

Yes, you are right, of course. I only tried to emphasize the contrast between low-level and high-level programming.

But to get this straight, I never said the approach you described is impossible. Actually, AFAIK it's been used in Quake2 engine. But I believe the scripting way is far easier (ok, not necessarily for the engine developer, but certainly for the end users). I'll name a few reasons:

The modern script languages are usually untyped. I know it has its pros and cons, but it generally allows for easier and faster scripting.

In scripting languages, you usually don't need to care about allocating/deallocating memory, something that's a major pain in the ass for a C programmer. Ok, you could use various macros and "automatic" classes, but it would make the "scripting" harder to do anyway.

I already mentioned the multithreading.

They would just create a new Object (of a pre-defined type), and then write it's reaction. It would be far simpler to try to create a clock that syncs with real-time using an array of time keeping libraries(in C++/Java), then it would be to try to read it in from Who-knows-where in an engine.

I'm afraid it's not as simple. The multithreading needs to be an integral part of the whole system. It's being used all the time. Methods like "GoTo" or "PlayAnimation" need to suspend the thread. And while implementing a simple cooperative multitasking for a virtual machine is very very easy, writing a complex system based on native threading functions would be far harder to do (IMHO), not to mention I'm not really convinced about the resulting performace.

And it relates to another major problem: serialization. Your engine must be able to save all its data at ANY point of execution, and to be able to restore them again to exactly the same state. To be honest, I don't have a clue how would I do that in C. On the other hand, it's relatively easy to serialize stacks/variables/objects of your virtual machine, because everything is under your control in there.

I could list some more less important issues, such as being able to trigger some action by setting a member variable of a class (which is not quite possible in C++ without using a method), but I think I listed all the major problems I can think of right now.

There are many free compilers, including the GCC series from Gnu, The Python language, Java VMs, and the like. Downloading and installing Eclipse wouldn't be in a different league than the WME tools..

Note that I'm only talking about C/C++ above. Using Python/Lua/Java is a very different situation. It's the alternate to writing your own scripting engine (I should have translated the rest of that article, I'm mentioning those :-))

Yes, there are free C++ compilers, but the engine would have to be written to support such a compiler. For example WME is writen in Visual C++ and it would probably take a lot of tweaking to make it compile under a different compiler. Or are you thinking about extension DLLs? (the way Quake2 works).

I don't know about WME, but most game scripting languages are still compiled. QuakeC, Unreal's Scripting language, Agast's..

That's right. But it's different whether you compile a simple text script, or a complex C++ project. Plus, you can compile the script "just in time" (that's what WME does when running in dev mode).

 

Actually, I agree with this part. Defining an object outside of the code proper is a good idea. But it is possible to define it, and then deal with it directly later on.

Actually, I was talking more about data files, defining the properties of your objects. You'd have to use some parser anyway, so why not to use the parser provided by your script compiler? (I say again, WME does NOT do that, I'm so ashamed ;-)

Fair, and Again, I'm not trying to attack in any way. I'm just trying to gather information and make the right choices.

Sure, no problem, I don't take it as attacking. Actually, I'm very interested in various game scripting solutions, therefore I welcome this discussion :-)

[creatorbri]

Well, here's a suggestion -- although I'll admit up front that this idea could detract considerably from the credit given to the author of the engine.

Since WME is free, why not release it alternatively as a well-documented C++ API, for those who would prefer to develop their games the old fashioned way?

Hey, it's just a idea.

[Mnemonic]

Well, here's a suggestion -- although I'll admit up front that this idea could detract considerably from the credit given to the author of the engine.

Since WME is free, why not release it alternatively as a well-documented C++ API, for those who would prefer to develop their games the old fashioned way?

Hey, it's just a idea.

But... please note that the above discussion is *not* about WME, since WME already does support scripting. We were talking more about general design considerations when it comes to in-game logic implementation. I'm a supporter of custom scripting languages, while Colin prefers the "natural" way (I wouldn't call it old fashioned). If I understand it right, he asked because he is about to design a similar system, not because he'd like WME redesigned (right, Colin?).

[e1ven]

Clever Boy ;)

Ok, I guess I'll have to log in, and admit who I am.

My name is Colin Davis, and I am the head producer of the SQ7.org project to create a free game in the line of Sierra's popular Space Quest series.

We've been working with AGAST for.. quite a while, but consistantly run up against shortcommings, because of it's design choice to include home-brew scripting language. Their engine does not properly support Arrays, structures are frustrating, the object system is broken, the parser doesn't work, and none of it is fixable.

So, although we have invested a good deal of work in AGAST, we will likely be forced to abandon it as a development platform.

Leaving AGAST, I looked out for what other possibilities were around, and heavily considered wintermute. It has a saner scripting language, ARRAYS WORK, as do Strings (Another Broken AGAST "feature").

But with Wintermute, we were again locking ourselves into a Closed Source engine. And while we did like the engine, it seemed far too risky to invest time and effort into an engine that we could not modify. If you are going to base the core of your game around and engine, It's hard to trust something you do not have the source to, even if it's as well built as WinterMute.

(Not to mention WinterMute is a great name ;)

I had asked if the source might be released for WM, but things seemed rather unlikely, so we began looking at other options.

We looked at the open-source MAD engine, and again, we saw people building a scripting language, lua, over a c++ base, and the problems that come with that. Looking closer, we saw fundemtal architectual flaws, and knew we couldn't use the language.

So, with AGAST, WinterMute, AGS, and MAD in mind, we started looking into designing Yet ANOTHER engine.

We wrote up a design document that breaks the engine development up well, breaking the component pieces up so that they can work properly. We began coding the engine in Java, and debating using either Python or Lua for the scripting language.

But that's where we paused.. In two weeks of work, we already had a engine that was moving sprites, playing multiple mp3s at once, crossfading between them, and supporting panaramoric backgrounds.
We've split object defination off into XML files, so that you can say define the "Look" responce on a ball outside of the language. This is extended to support defining animation rate, and other various properties.

Behaviors, such as causing Roger to display a death message, would be written in java, and then called as methods.

But as we looked at things further, Kevlar-our lead coder and I began a discussion of whether or not we really needed a scripting language at all.

By defining the objects outside of the real code, and using a GUI editor to place them, we had vastly simplified the work of the game-writing team. Almost everything they would have to do would be available from a GUI tool.

Simple commands, such as Walking to a place, and they saying something, or a dialog tree could be done in Java as simply, or simplier than they could in a scripting language.

And that not only saves /us/ the work of adding one, but it saves the game developer the work of having to be constrained by one.  I'm sure everybody has run into problems with a game-scripting language, where the need feature X in a lanauge, but it hasn't been implemented yet. We avoid that entirely.
By coding in Java, we gain the support for everything the language supports, as WELL as one of the industry's finest IDEs, Eclipse.

By using Eclipse, even scene defining writers have the beniefit of code completion with tabs, and easy lookups of the right command.

Everything is just as simple as it would be if we were to include Lua, but still retaining flexibility.

Now, admittedly, This would be harder to do in C++. Java eases memory management, allows us to use custom formats for animation (animatted gifs work great as sprites) and Music (mp3 and ogg), and allows us to pull from a large pool of programmers. Java is a great language for Adventure games because it can do so much natively, while still being sufficently fast (Adventure games are mainly file dependant, not CPU dependant). We gain Agility and Speed of development, and I think it's showing.

As I mentioned earlier, we've been working on our SLAGE[1] engine for two weeks. In that time, we've generated an system that can deal with a great deal of the requirements of an adventure game. Event handeling, object defination, Sprites, Movies, Background loading, Panaramoric background, Sound support including multiple looping tracks at once.

We're making great speed, and will likely have a fully-working engine within a few months.  It's not slowing down the project because of our design decisions. We can continue to develop the resources, and port them when needed.

And we'll be releasing both the engine and the source code for free. We're developing using an Open source license, which means whomever wants to will be free to download the source, play around with it, and hopefully contribute back some code.


We're not trying to compete with WinterMute, as much as get our game done in a way that we can work with. I really wish we could have used the WM engine.. I'd love it more if Mnemonic wanted to volunteer to work on SLAGE as a project for WM2 ;)

While I am sure have  munged  the definations and ideas in this message a bit, as Kevlar has a far better mind for code than I. But in looking at our plan, I really think it may be the best way to proceed forward.

I'd be glad to have any volunteers who would like to work on our engine (or game) with us, or any discussion about how best to implement a game engine in general. Hopefully people more clued-in than I can have this discussion ;)





[1]- Sierra Like Adventure Game Engine. Or SLage Adventure Game Engine, for the Recursive name fans ;)

[Mnemonic]

I just wanted to point out I was talking about C/C++ all the time. Java is a whole different story, because it's actually sort of a scripting language itself (it's been used as one in Vampire: The Masquerade - Redemption).

Just out of curiosity, did you resolve the serialization problem yet? I'd like to know how did you do that (although I'm not very familiar with Java).

[e1ven]

I realize Java is different in that manner, which is one of the reasons I wanted to come clean.

I know this is something we were worrying about, but I believe it is handled within the java environment. To quote Kevlar's post about the subject-

Java Object Serialization, as per the Sun Java Object Serialization provides a way to be explicit or implicit about what fields are serializable.
 

This is something which is out of my league, but it does appear to have been solved on Friday..

Colin
 

[Kevlar]

The Serialization issue was a big nut to crack... specifically how to implement it in such a way that it hid the uglness of it from the end-user (game developer).

The 'Object Serialization Issue' is solved in kinda a 4 part solution.

First of all, 'model' objects are kept strictly seperate from 'game' objects, such as the actual sprites being displayed on the screen. By providing a standard way of creating a sprite which suports being extended by either subclassing or through runtime assembling of object heircharcy (described in XML), we maintain a very clean break between 'describing an object on the screen' and 'putting an object on the screen'. This approach is adapted in all aspects of the game, from sprites and behavior to sounds, event handlers, events, images, etc., and implemented in such a way that it's completely transparent to the end user.

Secondly, 'model' object all make references to their associated 'resources' through global stores which implement a Map (dictionary, tuple, key/value, etc.) style interface. This allows us to seperate resource data from model data in a very clean way; The model objects just store the keys (read: String) to the resource. The Stores themselves are implemented as a reference counting cache, so as game components use and stop using resources (which is kept seperate from accualy putting them on screen for pre-loading purposes), each resource is loaded in memory once and only once, allowing us explicit control over resources management. But I digress.

Thirdly, model objects are stateful proxies of their in-game representations (sprites). The stateful proxies are implemented in such a way that they're completely hidden to a game developer: He can just make his objects which implement the Actor, Behavior, or Scene interface and his stateful data is automatically persisted when the game is saved, and restored before 'load()' and 'run()' are called. Implementing this in such a way that it didn't 'break' or 'require a change' every time a new piece of functionality or state was added was the main challenge, but it's been solved.

Finally Java Serialization has wonderful support for doing all the whacky things you might concieve of when doing object serialization, the least of which is the (third-party) support for XML as output. This has a number of advantages like being able to specify explicitly or implicitly what is and isn't transient in a model, offering an object the opertunity to update it's state before it's persisted, allowing an object to do custom handling of it's state persistance allowing you to make associations at de/serialization time, the ability to do post-processing using an XSL transformation, human readable/modifyable output formats, cross-versioning deserialization support for when an object changes, etc. We actually will use very little of this, but it's a wonderful thing to have if you end up painting yourself into a corner and don't have an easy way out. Mostly, you grab the top level object of your model and shove it through the serializer.

As a result the uesr is able to use either code or XML (which can be generated by a GUI) to describe his game, and write code in an entirely intuitive way: When you add a behavior to an actor at runtime, the Behavior (from the coders perspective) appears to be the Actor itself (so use of 'this' in the context of the Actor is valid). This allows for very rapid, intuitive, and reusuable modules to be developed which can be strung together in a GUI like interface, or in code. Any fields (Class level variables) are automatically de/serialized for you, so your state is maintained for you. Your Object Oriented design won't ever be compromised, allowing you to build some very complex behaviors very easily.

The end result is a framework which can be used, and more importantly extended in a very intuitive way without ever touching the underlying framework.

I just finished up this piece, and were moving on to adding event types, and implementing some of the event handlers. (well, that's the piece of development I'm concentrating on. Others are working on other things like understanding the collision manager and window popups, and scene order/loading/unloading mechanisms).

We'de love some help from experienced Java hands so drop on by the site if you'de care to try runnin with us. We could definately use the help.

-Kevlar

[Mnemonic]

Hi Kevlar, thanks a lot for your detailed answer. I'm still missing one thing though. One problem is serializing the data, but how about serializing the state of the execution? I suppose you have to use some sort of multithreading in an adventure game, right? How do you interrupt a thread in the middle and restore it later?

[Kevlar]

Because were seperating the model, which contains ALL the state (or a proxy of it in some cases) from the 'Engine thread', the classes which 'bridge the gap' between the model and the view know how to recreate their sprites, and readd them to the playfield.

Everything is event driven: there's a thread off in the Engine generating ticks every X milliseconds, and calling 'tick()' on all registered tickables. Therefore when the model is saved with all it's state in place, it's a simple matter of firing up a new Thread after everything's been loaded back up and resuming the sending of ticks, and reregistering it's listener interface for events. At first I thought this approach might be a little 'heavy', but as it turns out the JIT VM is able to reduce the most common case down to nothing. Because there's not that many events being generated per second on average (just how often are you clicking that mouse?), things actualy move at lightning speed. We ran some tests with creating and having at first 50 moving sprites (each moving a random fraction of a pixle per tick so the computations would be heavy) on the screen. When this didn't phase it we uped it to 200. This accualy took about 180 milliseconds (0.18 seconds) to create all the sprites and get them on screen, but it was totally smooth after that. At around 500 the limitations start to show themselves ever so slightly, but I personally suspect it's my laptop's video card that's introducing the penalty. At 2000 we did see than things were slowing down, until they started to move offscreen at which point they resumed normal speed. And if you've got a game with 2000 moving sprites on the screen, chances are your making an arcade shooter, not an adventure game, and should be using something else.

The API exposes everything concerning the 'passage of time' as a floating point 'seconds' and does all the computatations necessary to convert 'time to ticks', so things always 'move' at a consistant speed, regardless if the time between ticks changes.

Thus the need to serialize the state of the thread becomes unnecessary: Anything which requires notification of the passage of time just needs to be a Tickable. Everything else is event driven.

That make sense?

-Kevlar