I just implemented a scripting language(LUA) for my 3D fighting game. The purpose is to use it as a basis for character design and give end users the ability to add new characters/fighting styles to the game. So far it has turned out to be invaluable. Most of the scripting is done in a

if this_state then
shootfireball
new_state = ready
end

sort of deal. It interfaces with the engine by modifying player positions and calling C functions bound to script functions. So my script can say.

If player.state == hit then
animateModel(player.modelInst,"falldown");
addParticleEffect(player.position,"blood_drops");
end

This sort of system all in C code would have gotten very old very quickly. The best part is that each player can have a file like this, and I would just need to change the file to execute. Sort of like a plugin system for games.

Chronos, I''m curious about your approach--do you do the "if this_state call then..." script every frame? If so, what kind of performance hit (if any) are you taking?

The scripts are executed once per frame. As far as performance hits go, I haven''t seen one yet, but if it remains that way I can always compile the scripts to bytecodeWhen you call the execute func(lua_dofile()) from C.
It doesn''t care wheter its bytecode or not, so before I release anything I''ll definitely go and compile all of the scripts.

quote:Original post by Sneftel
Oooh, so clooose. You got it with the babelfish, but the precise work with that sequence of actions?

The Hitchhikers Guide to the Galaxy?

Back to scripting. One of the most underrepresented uses in this discussion is prototyping. If you''re aiming to break new ground in your project and have time constraints (most of us, being hobbyists, don''t, but we may one day find ourselves in that situation), a scripting language allows you to concentrate first on functionality - testing that an algorithm generates the desired effect, for example - which can then be reimplemented (once, without logical errors) in your primary pedal-to-the-metal language (eg, C++).

The second major use I find for scripting languages in game development is flexible logic. In a team environment, giving your "designers" or artists the ability to trigger existing behaviors and create new ones without delving into the core engine can be a massive productivity boon. The fact that the scripts are interpreted also means that new logic can be tested without rebuilds (if you have scripts handle loading of assets or structure your asset loading mechanisms similarly, then essentially all content is dynamically bound and can be tested without necessitating an engine rebuild, which is a real productivity benefit).

Not all games require scripting, though, and deciding when your project will actually profit from its use is still largely a judgement call.

$0.04 Cha-ching!

So, am I being cynical here in suggesting that scripting languages allow programmers to (somewhat) drop the rigorous software engineering rules of analysis->design->implementation->testing->maintenance, in favour of a simple implementation<->testing cycle? No more detailed planning of the implementation stage, just change the code until it works.

And more seriously, if this is true, is this necessarily a bad thing? Perhaps the old paradigm mainly arose due to the glacial speed of development before interpreted languages were capable of running serious applications? A lot of game programmers are certainly ''hack-and-test'' addicts, who are better at testing and fixing than anticipating and planning. Perhaps it''s playing to our strengths, then.

Of course, there''s never going to be a substitute for a reasonably thought-out design, but rapid prototyping could signal the end of needing to plan out every method of every class in advance, as many methodologies currently require...

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost

Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

I am a bit suprised no one dug up Ousterhout's paper on this...

http://citeseer.nj.nec.com/ousterhout94tcl.html

and then there's...
http://www.tcl.tk/advocacy/choose.html
http://www.tcl.tk/advocacy/whyscript.html

If you didn't know about citeseer, now you do.

[edited by - flangazor on March 19, 2003 6:23:58 AM]

Isn''t that paper just a language guide though? And the other two links say, in total, that scripting languages are good for linking things together because they''re untyped and therefore can easily bind components together. Hardly a detailed argument for the benefits of such languages

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost

Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

refactoring: by martin fowler is an excellent book which develops a method of software development rooted in testing. You write the tests first and once they pass you stop coding!

See also this chapter from dive into python

Thanks, Kylotan, for quoting me earlier.

I''ll describe what I''m doing with Python.

My company develops analysis engines and at the time of their creation there was also a piece of software developed, called QDTest. It''s a Quick and Dirty Test runner.

All our engines have C apis which are called by QDTest. It does a bit of setup and cleanup but then all the required functions are called from a text file. Every new engine and function that is added to our suite needs each function adding by hand. It is very creaky - more Dirty than Quick. For example, if you want to call the same function with increasing values you have to create a text file with those function calls repeated. If it was a scripting language we could create far more flexible and easier to maintain test suites.

At the moment I am moving in two directions to address the problems we have. Experimentally, I have wrapped one of the engines in a C++ class and exposed it to Python using boost.python. I can now write python scripts to test it, take the results, put them in an excel spreadsheet, create charts etc.

The other direction is to automate the creation of the text file that QDTest uses by creating it using Python and then calling QDTest with the file. At some point I hope these two efforts will meet and mean that all testing can be done without qdtest.

Finally, in relation to the thread Kylotan refered to, my efforts have been successful. My company are going to use Python to replace another proprietory macro language which was showing its age in one of our products. They were considering licencing the whole VBA environment!

quote:Original post by Kylotan
So, am I being cynical here in suggesting that scripting languages allow programmers to (somewhat) drop the rigorous software engineering rules of analysis->design->implementation->testing->maintenance, in favour of a simple implementation<->testing cycle? No more detailed planning of the implementation stage, just change the code until it works.

No, you''re basically correct.

quote:And more seriously, if this is true, is this necessarily a bad thing? Perhaps the old paradigm mainly arose due to the glacial speed of development before interpreted languages were capable of running serious applications? A lot of game programmers are certainly ''hack-and-test'' addicts, who are better at testing and fixing than anticipating and planning. Perhaps it''s playing to our strengths, then.

But even moving outside of game programming, I read a book by Mike Gancarz (one of the principal developers of X Windows 10 - the current release is 11 - and a former employee at Digital Equipment Corp - so you can guess his affiliations with Unix and Alpha) called The Unix Philosophy, and he states that overdesign is a problem with a lot of today''s applications. In the Unix environment where intellectual property per the source code to utilities usually isn''t a big problem, it''s often a better overall development strategy to continuously prototype because you receive valuable user feedback much more rapidly. He also advocates using shell scripting wherever possible, preferentially over C! (Shell scripts are more portable, easier to comprehend and thus to transfer responsibility for, and therefore easier to maintain. The same arguments hold for just about any scripting language.)

quote:Of course, there''s never going to be a substitute for a reasonably thought-out design, but rapid prototyping could signal the end of needing to plan out every method of every class in advance, as many methodologies currently require...

Yep. Being able to prototype rapidly is critical in today''s environment (you can show prospective clients a decent implementation in days instead of weeks and receive critical comments on design, usability and functionality requirements, as well as actually have them use the product and observe any complications or inefficiencies that arise). Scripting languages, particularly when providing a robust and portable GUI development toolkit like wxPython (Python binding for wxWindows) or Tk/Tcl, are a massive boon to the application developer.

I''d recommend reading Blue Tongue Software''s Jurassic Park: Operation Genesis post-mortem on GamaSutra. They talk about how prototyping allowed them to simultaneously develop for three platforms and develop various system components in parallel. I think that demonstrates the importance of prototyping tools to game developers (note, however, that they did not state which specific tools/methods they used to prototype; any implications made are mine).