Scripting languages in games - question

Started by
14 comments, last by Ekim_Gram 20 years, 2 months ago
I''m just curious, I''ve been told to use Python or Lisp as a scripting language in my games. Why not just make everything the API''s your using and C/C++ (if that''s what you choose to use). What is so important about scripting languages. R.I.P. Mark Osback Solo Pa Mi Gente VG-Force Ekim Gram Productions
Advertisement
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.
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
-david
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.

Game Programming Blog: www.mattnewport.com/blog

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...
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
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.
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)
Alternate hard and soft layers.
Alright, I''m thinking Python for a scripting language. Now, my next question is, since it''ll be used to hold variables of different objects of my game(s), how do I incorperate it with C/C++?


R.I.P. Mark Osback
Solo Pa Mi Gente
VG-Force
Ekim Gram Productions

This topic is closed to new replies.

Advertisement