• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

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

Do00d

Why scripting?

12 posts in this topic

seems odd but every tut ive seen on scripting goes on about how to implement but not on why whys isnt this for every other tutorial anywho what is the point of a scripting lenguage thingymamob? why cant all this be contained within some file and then read upon start up/level load can someone plz tell me what im missing here? what is it that a script thing can do that there is need for so much complexity for it thanx in advance if anyone botheres to answer
0

Share this post


Link to post
Share on other sites
It is important to have a scripting language because when you are in a develeppoment, it is extremely usefull to provide your scenarists, level designers and others with comprehensible tools. They don''t understand C++ and DirectX, they probably never heard (vary from one to another)...

The reason why it seems complicated, it is because it must builded in a way wich is very flexible since you will have to support and adapt it to any changes. This flexibility is very cool when you reuse your engine for another game.

The scripting machine must build in a way where there is a kind of stream. This stream of information can be wide or thin (ie yuo can send lots of commands or few) so it must adjust itself and provide a fast message processing and this complicates thing up.

So that''s it

Cya



/* Bullmax */
-------------
Reality has many forms : good and evil, black and white, ying and yang.
0

Share this post


Link to post
Share on other sites
so waht u mean is that its useful for others so that they have access to the engines things without the need to know ... bahh
but what i dont get is whats with all the complinig and turning it into byte code
why not just load it into something in the proggy
that way u wont get that slow down
why not that?

also what is the point of it if ure a one man team like me
and only do it for fun?
0

Share this post


Link to post
Share on other sites
I don''t get that. Why should plain text be faster than compiled byte code? The text would have to be parsed over and over again, where bytecode tells the virtual machine in a computer friendly way what to do. Compilation only happens once (at build time of the script or at load time of the script,...). So you have to parse the text one time and can store all your stuff in a way that your programm can deal with it without doing a lot of additional work.
0

Share this post


Link to post
Share on other sites
I think the two most important reasons for scripting languages are:

- they are Dynamic.
Meaning you can have the game running and change around code, without having to recompile. This speeds up development.
Scripting languages do not need to be fast. ie 90%/10% rule. where 90% of time is spent in 10% of your code. If something is too slow in the scripting language, rewrite it in a faster language.
- Scripting languages are usually easier to learn.
Especially if it is one of the allready known ones(eg python, lua, perl etc) where there are lots of docs/books on it allready.



-- Suffer in your jocks, dick head.
0

Share this post


Link to post
Share on other sites
argh noone seems to answer my question

VolkerG
my point was that id have some structs classes etc that handle everything
so why jnot just read in a text file and its all ready
no need to re read and re read
its in the code but not hard coded

but then annon says scripts can chagne at run time
but how can they if u have to recompile them ?

cmonn ppl
0

Share this post


Link to post
Share on other sites
I''m using scripting (with Python) in my project for the following reasons:

- Development time. For most tasks, it''s much faster to write something in a higher level language. If your game has a lot of game logic (by that I mean a lot of different enemies or objects to interact with), you''ll save a serious amount of time. Additionally, by having a language that''s closer to the problem domain than a general purpose language, you save even more time.

- Flexible. With a scripting language (at least the way I have mine set up) it''s easy to extend the system by adding a new script file. I can quickly change and tweak various bits of game logic on the fly, without rebuilding the project.

- Dynamic. If you do your game logic in C/C++, you pretty much have to decide ahead of time how that logic is going to work. As you said, you''d store all of that info in structures, which are then fairly static. With a scripting language, it''s easy to add custom behavior to any object in the system. For instance, in my editor, I can select an object and add some custom code to it, that will affect just that one object, not the entire class of objects.

There seems to be some confusion over compiling vs interpretting. Typically, a script file is interpretted. Most systems only read a file once, storing a tokenized version in memory for the next use. It *is* slower than native compiled code, but this is rarely a bottle neck.
Some games have used a scripting language which does need to be compiled. I think QuakeC worked that way, and a few games that chose Java as the scripting language. In my mind, this defeats some (but not all) of the benefits of using a scripting language.

If you have a very simple game, then it''s probably not worth it to worry about a scripting language. Otherwise, it''s definately worth the time.

Hope this helps.

Take care,
Bill
0

Share this post


Link to post
Share on other sites
in-game scripting allows you to separate programmatic development of the game from design and implementation of that design. In a one man team, scripting probably is overkill. Where it adds value is in a large team with people that don''t have well developed programming skills. An in-game scripting language provides them with a more limited set of functionality (when compared to what C++ gives you) tailored specifically to their needs and the needs of the game itself. Scripting can make testing and tweaking game balance easier as well. I''d even go so far as to say storing easily modifiable game properties in text files that get read in during initialization is the most rudimentary form of scripting (such as a text file that defines player speed, weapon damage, player health, etc.) Expanding this analogy to why bytecode is preferable over text parsing is the same as storing this values in a struct or array instead of reading them from the text file every time you use that value in your code. It''s simply a speed issue.
0

Share this post


Link to post
Share on other sites
When I spoke of compiling the script I meant turning the script into a byte code (well, not necessary at all, but I prefere this sort of scripting languages). And this sort of compilation of a single script file is usally less time consuming than changing something within the sourcecode of your game engine and recompile the project.
so, compiling the game != compiling a script file
0

Share this post


Link to post
Share on other sites
ahhhh
finnaly
thanx guys, i appreciate it
didnt think anyone would answer after my last post =)

guess i wont bother with it then
maybe later on in the future if i just oculd get an artist or a modeller or someone besides meself
0

Share this post


Link to post
Share on other sites