quote: Original post by thehurricane

--OnDeath Function-------------------thisMonster.OnDeath =  function()    newMonster = Monster:new(thisMonster.X+20,thisMonster.Y)       newMonster.AI = AICollection.lizard2    newMonster.Sprite = SpriteCollection.lizardred    game.state.scene:AddObj(newMonster,true,true)  end-------------------------------------   

What you are doing here could have been done in the normal exe code and the code would look more like the rest of the code. Only if non-technical people need to create something or if you want to be able to expand the game later without recompiling does scripting have a use...right ? Or ?

My point is, don't spend time implementing scripts JUST because it sounds cool.





[edited by - granat on March 17, 2003 1:34:01 AM]

quote: Original post by granat
[...]
What you are doing here could have been done in the normal exe code and the code would look more like the rest of the code. Only if non-technical people need to create something or if you want to be able to expand the game later without recompiling does scripting have a use...right ? Or ?

My point is, don't spend time implementing scripts JUST because it sounds cool.

Summary of the following:
Scripting is helpfull because of the flexability and locality it creates. It is also good because it allows for extensability which makes a game more enjoyable and gives it a longer life.

I agree that you don't always need a scripting language, but the flexibility is helpfull for most 'big' games. What if you just wanted any monster of type T to respawn on level 4 under condition C and T? Well, you could go into your game code and make an "int level" global, then in your T::Death() function add
if((level == 4) && C && D)
{
...
}
But if you decide to make monster type S respawn under condition E and F on level 6, you have to either duplicate the code, use more generic programming, or end up with some other kind of mess. You would probably duplicate the code, which isn't so bad, until you have 50 levels each with one monster type that respawns under certain conditions. With a scripting language, you can localize such conditions to the level itself, which means you have 20 lines of code that depend on the level stored inside the level itself instead of 1000 lines of code that depends on the level spread around your game engine (which will probably be harder to debug than a small script in each level since its spread over a lot of code rather than being localized).

'My game' is going to be an RTS, and I think scripting will greatly benefit it in several ways - It will be easy to create campaigns that depend on certain events for victory, in-game cinematics will be fairly easy to create, and it will be highly modable by any community that developes around the game (which almost always has the effect of prolonging the game's life and making it more enjoyable because you can take a break from the standard game without giving it up entirely).

[edited by - Extrarius on March 17, 2003 1:51:58 AM]

i guess scripting not just come in for the designers. any part of an application that requires tqeaking multiple levels of variables could utilize scripting. i think this is most applicable in alpha/beta testing where, for instance, game balance is involved. instead of tweaking each units stats individually and recompiling, scripting can achieve it with the avoidance of time loss for compilation.

its true that natural language scripts are more applicable towards designers and artists whom are assumed to be less capable at handling cryptic codes. but the average scripting functionality can by all means be an equal counterpart of the actual language.
this means for programmers too, it would be interesting to just define a game engine to handle all events and rendering and etc. but every object placements and event routing is defined purely by scripts. imagine a script driven game... one engine can theoretically produce a huge number of games with little similarities in content!

A more pointed technical critism, for the particular example posted above, is that you are using script as a substitute for a data-driven design. You have more flexibility (thus complexity) than you actually need.

Until you start using control structures (for, while, etc...) scripting doesn''t buy you anything.

Most Quake mods are done using dll extentions. The bot AI is the only significant item that uses the scripts (and it''s ignored, because interpretted C is probably the last choice one would make for writing AI scripts).

MKH just hit on one of the big caveats of scripting: it's only useful where game content is procedural, and cannot be easily represented by data.

My adventure game engine is a good example of what does need scripting. Push the button on the wall? maybe it'd make a sound... maybe it'd make the robot walk three feet to the left... maybe it'd slip a fish in your ear IF the mail was on the drain and the bathrobe was on the hook and a few other items were in place, otherwise the fish would escape. (brownie points to the first guy to get the reference) The only efficient way to code that is to have a specific procedure for THAT BUTTON ONLY, which is where scripting comes into play.

Pacman? Quake? probably no scripting needed. Scripting is content in the form of instructions.

EDIT: oh, so an example from my game engine. This is just typed off the cuff, so there may be problems.

object {
name = button
DO_press = function(self, event)
if(currentroom.objects["mail"]) then
doevent(currentroom.objects["fish"], {verb="fly"})
end
end
}

How appropriate. You fight like a cow.

[edited by - sneftel on March 17, 2003 2:18:08 AM]

Sneftel; two things. First, "You fight like a dairy farmer!". Secondly, I''m tempted to guess Starship Titanic (Fish in ear -> Babelfish, and Douglas Adams)

quote: Original post by Wyrframe
Sneftel; two things. First, "You fight like a dairy farmer!".

Okay, so you get the other prize.

quote: Secondly, I''m tempted to guess Starship Titanic (Fish in ear -> Babelfish, and Douglas Adams)

Oooh, so clooose. You got it with the babelfish, but the precise work with that sequence of actions?

How appropriate. You fight like a cow.

All I''m really seeing then, is "scripts are good for your development team / modders" and "scripts can be good where a data-driven model would be too complex" perhaps. Nobody is finding using a higher level language to have a significant positive effect on the actual development of the main code then?

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Are we restricting ourselves to games here?

I personally would use Python to code a game in part or whole only if a) one of the primary features of the game is its customizability (such as one of those glorified engine demos like Quake, but probably for another genre, or perhaps something like Earth 2150''s customizable AI -- rather than inventing "EarthC", they could have simply integrated Python) or b) if it''s going to be a small, relatively simple game that would run at 1000 fps on my P4 (the threshold is probably around something like a SimCity or Civilization I game). In some cases, it won''t be as slow as you probably expect because rarely does someone think in C to use a hash map, whereas they''re the basic type of Python.

There are two niches adjacent to game programming in which Python is useful: self-educational purposes and content creation tools. As an example, I didn''t know a thing about how bezier curves worked. After reading some math on the subject, I coded a very simple program to allow me to play with bezier curves. I had a nice, flawless-but-simple program in two hours. It only took that long because I wasn''t familiar with functional language techniques at the time, nor was I familiar with the libraries I was using (libraries in Python are much easier to learn than libraries in C++, which all seem to use either very primitive types like char* (as opposed to std::string) or some type unique to the library -- Python''s types are very flexible and libraries all seem to be able to work with whatever types you give them. Also, never underestimate the use of introspection for this purpose. Typing code into IDLE to see what it does simply has no parallel in compiled languages for learning a library). I played with that program for a while. Three or four days later I came back to the program I had written and extended it to work with arbitrary chains of pairs vectors instead of simple points. It took half an hour.

Content creation tools like map makers or anything else unique to the game should probably be written in Python if you''ve got anyone who knows it. It''s just faster (to write, I mean) and easier to understand. (these things are part of game development too, you know) It might not be in your best interests to distribute code written in Python, though, because it''s easier to reverse engineer than assembly (or C, or any other native compiled language), even if you don''t include the source code.

quote: Original post by Kylotan
All I''m really seeing then, is "scripts are good for your development team / modders" and "scripts can be good where a data-driven model would be too complex" perhaps. Nobody is finding using a higher level language to have a significant positive effect on the actual development of the main code then?[...]

If by "main code" you mean the "engine" (graphics, sound, input, etc), then you are correct. Scripting languages are usually used for game logic and not the processor intensive parts(the engine).

quote: Original post by Magmai Kai Holmlor
[...]Most Quake mods are done using dll extentions. The bot AI is the only significant item that uses the scripts (and it''s ignored, because interpretted C is probably the last choice one would make for writing AI scripts).

Quake 1 had a scripting language called Quake C, (don''t remeber quake 2 modding), and Quake 3 has an X86 assembly VM (it might not get used, but it is there and the Mod SDK includes tools for compiling the mod code to it). Also, the Unreal engine uses scripting almost exclusively for all game logic. Many RTS games include some form of scripting for the single-player campaign, and almost all cRPG games use some form of scripting for much of the logic and data.

Half-Life used a DLL for modding, and I found it to be much more difficult than modding Quake 1. It has a fairly simple object hierarchy, but with all the single inheritence it isn''t easy to know what functions any object has available.
Since scripting languages are usually less complex(and higher level) than full languages, it is generally easier to figure out what code does and modify it.
Since a scripting langauge is usually interpreted, it isn''t too hard to build an editor into the game, which allows modifying the logic in realtime, which should decrease the time it takes to to fix logic errors since you can see the result almost instantly you know if its fixed, and if not you can change something and see the effect almost instantly again. If you hardcode the logic, it can take a long time to fix, especially if compile times get long. With compilation taking 1 minute, that means it will take at least 1 minute to test even the smallest of changes.
Also, as has been discussed in threads on Lisp, it often takes less lines of code to produce a given effect in a higher-leve language. Since there are less lines, there is a smaller area to search when a bug shows itself, and there is less are to make a mistake.

Yes, scripting is essentially just a more flexible form of data-driven design.