   Scripting confusion, how far and how?
  Well I've done my own versions of blocks, a pac-man and asteroids.  Next on my list is something that requires more of a game world and some extra added challenge.  As I really enjoyed the game Dragon Warrior I was considering it as a project (2d top down scrolling rpg with random monster encounters).  I'm trying to get a high level overview before I start into it.Considering the amount of content a game like this would have I decided a scripting engine would be much better than writing everything in code (that's why I'm here).  What I'm curious about is how the script and game will interact and how much to script vs code.So for an example when I press the up arrow if there is a menu on screen the cursor should move up but if not then the character should attempt to move up, should this be handled in script or is it better to allow the code to do it?I'm going to guess that the maps should be scripted somehow as well though I'm not quite sure to go about it at this point.  It should probably provide the terrain, NPC locations and so on right?Last thing I can think of at this point would be when you want to speak with an NPC, walk up to hit, hit enter (or whatever), how do you run the script for this particular NPC?I've been reading as much as I can find about Lua but I can't seem to find a small or sample game written with it (just examples like Warcraft... not so helpful at my level).  I'm not tied to Lua or any particular script language though so any recommendations (free please!) would be considered.Any and all help is appreciated and if you happen to be able to recommend a good book on this subject that would be great as well.  Thank you!   
  this is a game state switch where the state changes between the in-game ui and the actual game well thats if you have it code as such. Have that in scripting should ok and easy since its scripted.   ;  Your question isn't really about scripting but more so about how to program a RPG, which is a big project in itself. RPGs do use scripts at many levels. RPGs and other large games ( ie games with lots of either procedural or handcrafted content ) use various forms of data driven design to reduce the problem space into something more manageable.Imagine you want to make a sword in ur game would u make a class for each sword type? (short sword, long sword, great sword, etc.. ) Or would you make 1 class which can potentially be any type of sword, how would u define all these swords using this method? That's where scripts come in ( or some other configuration file such as xml or a database table ). So these type of games create generic configurable systems which are driven by external data (scripts, xml files, database, etc..). In your case a RPG would need to have subsystems for handling NPCs, dialog, items, spells, crafting?, AI, experience leveling, armor, weapons, quests, etc.. That's just off the top of me head.Each would use some external data in some form, from that data it would then create in-game objects which are exposed to other systems.The how and what of it is up to you, you can implement almost everything in script and leave only the barest blocks in C++, or you can implement almost everything in C++ and only use the configuration files for trivial aspects, or you can go somewhere inbetween.Good Luck!-ddn   ;  I've been going through Lua myself for the past couple of months. From what I've read so far (Lua Programming guide, Lua Programming Gems, various online articles) there's a number of different things you can try. Scripting in itself is a wonderful way to store data that affects how the game plays instead of running the game engine. For instance, say you are loading a town there are several tiers of data you need to interpret. The town has a map, which consists of general layout, collision information and art assets its tied to. Instead of creating a class for each and every different map you have and its different constraints, create an interface to handle data that you store into a Lua file. Then, that map information can be loaded into a given map object that you've implemented in C++. From there, you can handle this with some sort of manager in your game engine that reads that data from your Lua file. Do the same thing for NPCs in that area. Each NPC has assets such as name, first thing said, second thing said, an event trigger, etc. All of this, including movement logic, can be defined as a table and stored into a NPC class. This way when you're editing the game script or balancing weapon stats, you're not recompiling your entire project; you just load the file, change the data, and re-run the executable.I unfortunately don't have to experience to tell you if you should access this information from a Lua state as you need it, or if you should come up with a level of abstraction of your data organization such that you can load all the needed information into C++. I'd say with my current knowledge: it depends on the type of the problem. There's no worry in waiting a fraction of a second to access a long bit of text from an NPC, but if you're defining the player's movement movement logic running a game at 60hz, that should probably be in the C++ stack.As for the difference in control logic between menu, game, battle states, I believe you could use polymorphism to define a current_state to your engine that you can change. That way controls can get passed to that object and the current state will handle them accordingly. Though, I doubt this to be the best solution.I hope this helps.   