Hard Coding or Script Engine
Author
Okay I want to start work on an RPG I''ve been designing. I''m going to have lot''s of dialog and hidden easter eggs in it, forks in the road for the players involving decisions that will effect play later on and/or change the way events occur. My question is, would it be better to hard code this all into the game or do a script engine for the game to handle dialog and decisions. I''d probably do a script engine based on the docs at Flipcode. I know hard coding is faster, and that script engines are easier to change if I decide to change part of the story or something. Besides those pros/cons what else should I be basing my desicion on?
Keep in mind how long your game will be. If it is going to be quite long and complex, you will almost be forced to do scripting. If it''s pretty short, hard coding it would probably work better.
Drakonite
[Insert Witty Signature Here]
Drakonite
[Insert Witty Signature Here]
Bear in mind that writing a scripting engine is not that easy, and the tutorial at Flipcode is quite complex and not entirely ''complete''. (It is more of a case study than a tutorial in places.) If this is your first attempt at an RPG then I''d recommend hardcoding most of it to begin with.
If you do write a scripting engine, don''t think that it has to be so complex and ful featured as the one on flipcode.
The one I am writing in my rpg is very simple, and just has a few functions it can do, but gets the job done.
Drakonite
[Insert Witty Signature Here]
The one I am writing in my rpg is very simple, and just has a few functions it can do, but gets the job done.
Drakonite
[Insert Witty Signature Here]
It will be faster to use a script engine (assuming you create a *suitable* one). The time taken to write the scripting engine will be saved during the development and modification of the script.
Make sure the script language is of the highest level of abstraction as possible, and any errors in scripts are reported/logged. Also make it as simple as possible.
You might be surprised at how low some of the productivity rates are for hard-coded stuff.
Make sure the script language is of the highest level of abstraction as possible, and any errors in scripts are reported/logged. Also make it as simple as possible.
You might be surprised at how low some of the productivity rates are for hard-coded stuff.
I disagree. A hard-coded engine/story that''s built around a proper story engine can be easy to maintain. It takes the same skill to write a good compiled engine for this kind of thing that it does to write a good scripting engine.
Scripting allows you to make changes without recompiling. That''s pretty much the entire point of scripting anything. If your development cycle is getting bogged down by recompiles, or you would like to add features in the future without redistributing the executable, or you would like users to be able to change things themselves, use a scripting engine. Otherwise, stick with an internal engine.
Scripting allows you to make changes without recompiling. That''s pretty much the entire point of scripting anything. If your development cycle is getting bogged down by recompiles, or you would like to add features in the future without redistributing the executable, or you would like users to be able to change things themselves, use a scripting engine. Otherwise, stick with an internal engine.
I think that in this situation dll code would be a good comprimise between having to write a full featured scripting language\compiler\VM and hardcoding everything. The ony problem with dlls (that I can think of) is security. But if you're using them for internal use only, then it shouldn't be a problem.
And if you're just planning on using the scripting language for the story and not basic gameplay, it may be possible to just use configuration files (that aren't compiled, just read.)
Edited by - impossible on August 10, 2001 12:33:24 PM
And if you're just planning on using the scripting language for the story and not basic gameplay, it may be possible to just use configuration files (that aren't compiled, just read.)
Edited by - impossible on August 10, 2001 12:33:24 PM
Hi there,
I would stick with LUA (www.lua.org) a FREE scripting language that has been used by e.g. lucas arts'' Grim Fandango or for Baldur''s Gate, which might be especially impressing/important for you since you want to write an RPG.
I myself implemented a scripting engine from scratch using flex/bison and agree that this indeed is a hard thing to master.
So if you don''t want to spend to much time on your scripting language (mine took me more than half a year) stick with s.th. like LUA!
Good luck
Scoop
I would stick with LUA (www.lua.org) a FREE scripting language that has been used by e.g. lucas arts'' Grim Fandango or for Baldur''s Gate, which might be especially impressing/important for you since you want to write an RPG.
I myself implemented a scripting engine from scratch using flex/bison and agree that this indeed is a hard thing to master.
So if you don''t want to spend to much time on your scripting language (mine took me more than half a year) stick with s.th. like LUA!
Good luck
Scoop
Hi
Pros of a scripting language:
Don''t have to recompile every time to view a change.
Relatively easy to maintain.
You can actually set up a relatively useful one rather easily. Also, if that''s not your fancy, Microsoft created a Microsoft Script Control which lets you use VBScript or JScript as a scripting tool ( mainly for Visual Basic, it''s a pain to get working in VC++ ).
Cons:
If you don''t encrypt it well, every hacker and his grandson can fool around with your game.
Might be a little slower than hard-coding, but in an RPG it shouldn''t kill you.
Complex ones can be difficult to create.
Other people working on the game might have to learn you scripting language ( which may not necessarily be bad ).
Well... that''s all I can really think of right now... I may be wrong in some of those, but they seem right enough to me. ;-)
--Nairb
Pros of a scripting language:
Don''t have to recompile every time to view a change.
Relatively easy to maintain.
You can actually set up a relatively useful one rather easily. Also, if that''s not your fancy, Microsoft created a Microsoft Script Control which lets you use VBScript or JScript as a scripting tool ( mainly for Visual Basic, it''s a pain to get working in VC++ ).
Cons:
If you don''t encrypt it well, every hacker and his grandson can fool around with your game.
Might be a little slower than hard-coding, but in an RPG it shouldn''t kill you.
Complex ones can be difficult to create.
Other people working on the game might have to learn you scripting language ( which may not necessarily be bad ).
Well... that''s all I can really think of right now... I may be wrong in some of those, but they seem right enough to me. ;-)
--Nairb
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
