Archived

This topic is now archived and is closed to further replies.

Scripting languages in games - question

This topic is 5042 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So you don''t have to recompile your project everytime you make changes. If you work in a company, communication between programmers-artists-designers-musicians can be very minimal. It is very impossible to finish a project with such a minimal communication between them. For example, a designer wants to change something in a game. Without the presence of a programmer, he couldn''t do it, he is not a programmer. So, the better way is to have the programmer implement the scripting engine, and give the program to the designer. Then designer could tweak the program by using the scripting language in whatever way he likes without having to tell the programmer what he wants to do.

Share this post


Link to post
Share on other sites
Don''t forget lua. I''m having good luck with it, and its learning curve might not be as steep as Lisp''s. Scripting languages are really useful even if you''re a one man show, because they let you preserve a rigorous seperation between code and content. From an organizational standpoint, it''s a nightmare if your core game application and game content bleed into each other. Additionally, if you''ve got more people on your team, you might not WANT those shifty content designers mucking around with your source code, who knows what kind of mess they might leave behind

Share this post


Link to post
Share on other sites
The theory is that you can be more productive with a scripting language because it frees you from a lot of the low level details you have to worry about when coding C/C++ (memory management, pointers, etc.) and often offers higher level constructs than C/C++ which let you accomplish tasks in fewer lines of code (and with less debugging) than if you used C/C++ for everything. C and C++ were designed for maximum runtime performance rather than maximum ease of use or maximum programmer productivity. Because of the old 80/20 rule of optimization it can make sense to only code those parts of your game that really need the speed in C/C++ and use a higher level scripting language for the rest of the code.

Another advantage is that scripting languages are generally interpreted which means much faster turnaround than the compile/link/execute cycle needed to make changes to C/C++ code. If you build a console into your game you can actually enter script commands whilst the game is running which can be really useful for tweaking things and quickly testing stuff out.

Share this post


Link to post
Share on other sites
quote:
Original post by mattnewport
C and C++ were designed for maximum runtime performance rather than maximum ease of use or maximum programmer productivity.
While I agree with the rest of your post in general, this is completely false. C and C++ were designed to increase programmer productivity, given the tools programmers used and the problems they needed to solve at that time. Prior to C, the process of creating an operating system had to be done from scratch for every new architecture - in that architecture''s assembly. C allowed you to have to reimplement only about 5% (give or take another 5%) of the overall codebase to port to a completely new machine.

C++ was created to address object modeling concerns. At the time the de facto industry standard was C (it should still be, to a large extent, IMO), which was inappropriate for large scale object modeling projects. Remember, C++ was initially called "C with classes."

As you were...

Share this post


Link to post
Share on other sites
Scripting really ties in well with the data-driven rather than code-driven philosophy, which actually has varying relevance to different developers and projects.

If I write an RPG and hard-code all weapon damage values, all enemy behaviors, all possible item-activation results and behaviors, etc... into the code, then decide at some point to extend, expand, or make a sequel to the game, I am facing a serious job of work to go through all that code base, find where I hard-coded something, and change it. Rather than being able to build an expansion merely by bundling all of the various data into a new data pack for download, now I have to re-build the application from scratch to take into account the many sweeping changes I made, and every quality tester I can bully into helping me will require a new executable build for every infinitesimal change or bug they report.

With all enemy and object behaviors scripted, testing for those poor bullied quality testers (read: my friends and family) is easier. Rather than download the full executable for every change, they merely have to download an updated script or mission pack here and there, and it plugs seamlessly into the game. The more programmatically savvy among them can tweak the scripts as they see fit, make a few changes, and report back to me on their results--rather than requesting I make the changes to the code-base, recompile, then make the new build available to them.

Scripts can be changed at run-time, while the object is on screen. I can change a script, force a re-load, and see the new behavior in action all with a few commands from the console, rather than a quit, re-compile, re-start from saved game, etc...

Now, on the flip side, if I were making a vanilla Tetris rip-off, scripting would obviously be unnecessary. Scripting has its benefits, and its complexities, and seems to become more relevant the more complicated a game gets. Scripting something as simple as *tris or Pong is wasted effort. Scripting for an RPG, however, can be very useful due to the intertwining complexity of the genre.


Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller

Share this post


Link to post
Share on other sites
I was originally going to use lua scripts to control various game aspects but at some point I realized that for me, it made no sense at all. And at this point I don''t really see who it would make sense for.

Take lua for example, you can bind c/c++ to it, then use those things in scripts. That''s great but if you have some class that you make available to lua, you could use that same class in pretty much the same way in c++, and it''s faster, and easier to debug problems. Realistically to a designer if you construct things well, there is little difference between writing in lua and writing in c/c++. There''s no reason they have to deal with the more complex things like pointers etc.

As far as recompiling and seperating things, the solution is the same, the engine can be one piece and the gameplay/content can be a seperate component. Recompiling a few thousand lines of c/c++ takes just a few seconds and can pretty much be setup to not require more understanding than a scripting language would.

My opinion is that many times, even myself included it''s the programmers who want to add scripting because it is an interesting topic, but in just about every case I''ve looked at, things could have been done pretty much exactly the same, except faster using native code.

Share this post


Link to post
Share on other sites
Most of scripting done in games is actually used to set various game variables, object properties, etc. This is IMO way better than having them hard-coded.

But for an example of an insanely scripted game check out Far Cry. These guys have LUA all over the place. And they have XML maps 8)

Share this post


Link to post
Share on other sites
quote:
Original post by Cor
Realistically to a designer if you construct things well, there is little difference between writing in lua and writing in c/c++.


Counter-examples:

1) Iterating over a structure is far easier in Lua:
> table = { sword=10, axe=15, mace=20 }
> for key,value in table do print(key,value) end
mace 20
sword 10
axe 15


2) Returning multiple values is simpler:
> function getposition() return xpos, ypos end
> x, y = getposition()
> print(x)
1
> print(y)
2


3) Simulating multithreading with coroutines for ongoing events
> function talk()
>> print("Good to meet you.")
>> coroutine.yield()
>> print("Hello again.")
>> end
> co = coroutine.create(talk)
> coroutine.resume(co)
Good to meet you.
> coroutine.resume(co)
Hello again.


All the above are possible with C++. But even with Boost, STL, and friends, you're not gonna achieve any of the above as cleanly or as quickly.

For what it's worth, I could do all the above in Python too, with next to no change in the syntax; I just chose Lua as that seems to be the language discussed in this thread.

quote:
Recompiling a few thousand lines of c/c++ takes just a few seconds


With Python or Lua embedded carefully enough, you could even make the changes without restarting the program, never mind recompiling. See your changes in real-time. View complex expressions from the in-game console.

quote:
My opinion is that many times, even myself included it's the programmers who want to add scripting because it is an interesting topic, but in just about every case I've looked at, things could have been done pretty much exactly the same, except faster using native code.


This much is probably true. You really need to have worked with other languages for a while before you can truly appreciate the benefits they can bring. Only then will you be likely to get the full benefit from using one.


Ekim_Gram; take a look at the FAQ in the Scripting Languages forum.

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


[edited by - Kylotan on February 21, 2004 9:01:30 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
quote:
Original post by mattnewport
C and C++ were designed for maximum runtime performance rather than maximum ease of use or maximum programmer productivity.
While I agree with the rest of your post in general, this is completely false. C and C++ were designed to increase programmer productivity, given the tools programmers used and the problems they needed to solve at that time.

My original statement was probably a bit of an over generalisation but if you read ''The Design and Evolution of C++'' by Bjarne Stroustrup he is very clear that certain design decisions in C++ were taken because performance was considered more important than ease of use or programmer productivity. Stroustrup felt (probably correctly) that C programmers would never accept C++ if it imposed a significant performance penalty. There were other languages around at the time that influenced the design of C++ (Smalltalk for example) that were not widely adopted because their performance was seen as too poor for many applications. Certainly C was a step up from assembly language but higher level languages have failed to replace C and C++ in many domains largely because of performance concerns. Whether those concerns are justified in many cases is another question...

Share this post


Link to post
Share on other sites
quote:
Original post by Cor
I was originally going to use lua scripts to control various game aspects but at some point I realized that for me, it made no sense at all. And at this point I don''t really see who it would make sense for.[...]
Consier RTS games, where scripting is quite common. A semi-recent example would be warcraft 3. When you''re making a level, you can create a script to make the level do more interesting things, such as make a lever open a door, or spawn 50 monsters, or set a variable such that you have to hit a specific lever next to open a combination lock of some kind. You can use the script to make monsters move a certain way, attack certain units before others, etc.

The custom maps not made by blizzard are what kept the game alive for me as long as it was. Without them, I wouldn''t have bought the game at all. Not only do the scripts allow such customization, they also allow it safely. If you were to replace the script with SDK source like many FPS have, and just have the dll attached to the map, then you have security problems since the maps are automatically downloaded by users if they try to join a game with a map they don''t have.

It also makes sense for RPGs, where you want the same kind of flexability (in developers'' levels or those created by fans).

Share this post


Link to post
Share on other sites

I think Python is a hell of a language, and since it ties so nicely into C/C++ it makes it that much more sweet.

One thing to remember as well, once you start down the path of scripting and embedding you can start to appreciate how quickly you can prototype things out in a language such as Python ( like Kylotan''s examples above as a real minimal example of how concise the code can be ).

I haven''t used LUA really, since Python has fulfilled 100% of my needs.. but it seems decent from what I''ve read-up on it.

.z

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
At the time the de facto industry standard was C (it should still be, to a large extent, IMO)


I agree with your statement concerning C, even though I am one of the Lisp proponents.

Any language can interface to a library or DLL if it has a C API. C is the common denominator. Trying to interface to libraries that export a C++ API is just a pain. And I''m not just taking the Lisp viewpoint here. Delphi<->C++, Java<->C++ etc. it''s a pain. All libraries should have, at a minimum, a C API.

Share this post


Link to post
Share on other sites