Max_Payne
It took me one single afternoon to interface LUA into my engine.
It took me a non-dedicated week to export the most important stuff into LUA.

Level designers DONT code in scripts, but if they can manipulate simple variables, great! if they can write small scripts that control how a light behaves, even better!

In fact you'll be hard pressed to find anyone related to the gaming industry that hasn't touched a bit of programming...

quote:but nevertheless, cutscenes *dont* have to be scripted

In a RPG, where target bot moves from x,y to x,y, does T action, and says S string, i think it would be for the best to have it scripted, its actually the perfect example. Coding the sequence in C++ is language-overkill, but is doable of course, but it requires a recompile each time you alter the engine-rendered-cutscene.

If instead you use a scripting language, the director for the scenes can instruct how the scene will go, and if there are changes, that department doesnt need to wait for the next game build, they can just write the scripts and fire it up.

quote:It doesnt reduce development time

Wrong! it does. If i'm developing a MOD for any game, and I want to balance the gameplay by altering the strenghts of the weapons, i can just call the console (which talks to a script parser), or alter the weapon details on the apropriate script. If i had to recompile my plugin each time, then call the game, create the server, and email all the team for another test run, do you imagine the wasted time that would be?

quote:There is no actual proof that scripting brings any benefit at all

Wrong! Any game developer will disagree with you all the way.

quote:takes flexibility and freedom away from you.

Wrong! It gives flexibility to the programmer, to the game designers, to the level editors, to the mod makers, to the gamers themselfs each time they call a console, i think even the Pope enjoys scripting

quote:You see me as an enemy because I disagree with you

Wrong! lol, I'm not judging you as a person, but you show a lot of ignorance on this field of game-programming. Makes us wonder what else you might be ignorant about...

quote:Half-Life used a game library written in C and was very successful as well... Half-Life is probably the game with the largest amount of mods made for it.

Another logic error. You equate game success to technologies used, so if game is unsuccessful, then the technologies it used sucked. Thats the same as saying that because Sin was a comercial failure, DirectX is too... flawed logic of your part.

You can export the whole engine capabilities into a lib, and distribute it so that people can write their own plugins, fine.

But if you also have access to a scripting language, you'll be amazed at the number of things that can be automated with it.

You just have to be watchful, if a script starts to get too complex, maybe you can analise it and convert some portions into the engine itself, so that the script can call the engine, therefore reducing script size, and gaining a small speed increase...

BTW, in longhorn, the next version of windows, all code will be basicly scripts... that will get compiled at runtime to the machine's capabilities... quite something for someone that doesnt believe in script, hmm Max_Payne?

EDIT: prob with quote tags...

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven't contacted us!

[edited by - pentium3id on January 30, 2004 12:30:42 PM]

quote:Original post by pentium3id
i think even the Pope enjoys scripting

Dont even get me started on the pope


Max_Payne: Im sorry if you get the impression that I view you as an enemy. I dont, this is not war. If I thought of you as an enemy I wouldnt have bothered helping you out in other threads. What I think of you has nothing to do with this thread and is off topic. However, I did address all your arguments, I even quoted outside sources and highlighted the important bits to save you some reading, you simply chose to chuck them out the window. It seems like Pentium3id has added a lot more that you should listen to. Also one last thing that I will have to address: RPGs are not simple beasts at all, it''s argued that they are probably the toughest games to make, and if you think hours of cut scenes are boring then I really couldnt care less, it''s just a matter of opinion, and an opinion cant be wrong, I certainly enjoyed Most of the Final Fantasy series (all that I played in fact), I even enjoyed Metal Gear Solid, and many other games that had hours of cut scenes.



| C++ Debug Kit :: GameDev Kit :: DirectX Tutorials :: 2D DX Engine | TripleBuffer Software |
| Plug-in Manager :: System Information Class :: D3D9 Hardware Enum | DevMaster :: FlipCode |

You have it set up pretty good, except I would change two things. You have position and orientation in both contexts (engine and script). You should instead store the value in the engine only (so each frame the engine doesn't ask your script object where it is and the orientation - SLOW), and have accessors in the scripts that can retrieve and set the position and orientation values if needed. Don't keep things synched between contexts. Not all scripts care about those things, and that would just slow it down. Accessors should do the trick.

In my script engine, I only store values script-side if they are temporary (calculations, etc..)

Anything I generally report back to the engine is with accessors. Some scripting languages are slow manipulating datatypes locally, sometimes breaking out of the virtual machine just passing values back and forth is better.

Some scripting languages, like Lua, have built in math functions like sin and cos. I placed an assembly version with lookup tables in my engine and use that method. That was one method of improving speed by a little. Optimizations like that all over tend to help.

~Graham


----
while (your_engine >= my_engine)
my_engine++;

[edited by - gwihlidal on January 30, 2004 1:31:51 PM]

Arwin:

Glad you're getting some ideas

quote:
Just a few more things, Do you have your script entities to be object oriented? Do the script entities access methods of c++ instances?

Whether your scripts are OOP or not is up to you (and your scripting language)

I personally like OOP, as things seem less messy if done well.

The same things could be done using a non object oriented approach though too.

OOP Example:

Entity myEntity = Engine::SpawnEntity(ENTITY_DOOR)

myEntity::Open()

or

Non-OOP Example:

Entity myEntity = Engine::SpawnEntity(ENTITY_DOOR)

Engine::RunEvent(myEntity, ENTITY_DOOR_OPEN)


Depends how you design your script engine (or which one you used), and what syntax you like.

quote:
Higher level classes such as NPC exists just in the script engine and the 3D engine is just for rendering them? Or the 3Dengine does have classes for higher level entities?

Again, up to how you want the language to work. You could just have a base mesh entity that can load a model, with the filename specified in the script, set some render attributes, and you keep certain values in the script that the engine doesn't care about (mana points for a potion, etc..), and the engine just renders the potion model at the specified position and orientation. You could however, move mana points for that entity into the engine if many entities use that type of value (for example, if your engine targets the fantasy RPG genre).

Atlay:

Thanks for the kind words, I don't mind helping out with discussion on these interesting topics. I'm not an expert, but hopefully my experiences help out.

Gotta run to a Java seminar right now, but I'll be back online in a bit

~Graham


----
while (your_engine >= my_engine)
my_engine++;

[edited by - gwihlidal on January 30, 2004 4:45:24 PM]

Hehehe... Ok gotta mention a quote about level designers...

"a good designer will not depend on the AI to do what they want
it to do, a good designer will be able to write the script to do the job" - John Carmack (Note* I can't remember his exact words,
but this is close enough). Hmm, beside for the saying that good designers will be able to write there own scripts, what does that suggest about the doom3 engine?!

I can not see why max_payne, your saying scripting is so slow and crappy. Even with an approach like the half life engine,
the engine will still need a way of reading the entity types
and properties off of the level file and then you still need
an interpreter to parse the file, thus there is simple scripting.

Even if you write all of the code in c++ including the game play/ npc behavior, you still need to call the functions, so
how is simply calling them from the script going to slow things
down that far?

Say you write a game that does not support external map loading
and parsing, in the main file, you have setup an level sytem so that you go to a hard coded level each time you win the last level. In each one of these level functions, you define object properties, you call maybe some simple ai function you wrote,
etc, and then say you use an if/else statment to check certain conditions like win/loss... Now include lua just say, in that same game and instead of making the levels in the hard coded functions, you put them in the level file (granted you use maybe tolua to interface the classes with lua) and then you added the
if else functions to the level and made a function in the engine to handle the init, draw, update, free functions in the script...

Thats how I see it anyway and is the basic idea behind my design.
Some of the if/else statments maybe defined as triggers, but the logic and such isn't much different. For example:

pseudo:
if(player_is_close_to_me)
prompt("press 'u' to use this object...");
if(player_presses_the_use_key)
tell_the_player_to_get_into_me;

Now to evalulate that...
*functions in capatle are bound to lua and are found in the c++ code...

if(GETDISTANCE(player_object, this_object)    DISPLAYSTRING("Press 'u' to use this object");    if(player_object->USEDKEYDOWN())         USEOBJECT();//not sure how I would handle this...

Anyway, most of the AI would be handled like that. Things such as
path finding will be handled in c++.

Alrighty, I must go.
talk later...

[edited by - no one on January 30, 2004 6:06:48 PM]