I don't really follow your design here. What does LookAt() do? What does it operate on? What kinds of parameters would it take?

Sorry I dropped off yesterday. Work and all that. :P

So, a concrete example. You'd like to write scripts to access and modify game states and game entities. Let's say we want this. A numpad console beside a locked door with some paper taped next to it. By default when you look at it, the writing says: "The pass code is...." But if you're wearing the coke-bottle glasses you assembled earlier, looking at it will display some different text. It tells you the .'s are the numbers 1 2 3 4.

I really started going crazy with this and the post was getting away from me. I had to start overFun problem to solve! :)

Let's say we already have our GameWorld loaded, we have a Room or a Scene object, Game Entities know how to draw themselves. etc. You've decided on Lua for your game scripts. That's a decent choice because after your game gains popularity you'll be rolling in the dough from all the community created mods driving up the sales of your engine. We can dream can't we? :)

So you've got your input manager wired up. You've selected look at, and somehow identified that we've clicked the PassCodeText GameEntity. I'm picturing the World creation loaded up all the Rooms/Scenes/GameEntities with all the knowledge they'd need. So there'd be some script equivalent for LookAt defined in your world data files.

// This code would be associated with the PassCodeText game entity.
// I'm writing in C# because I don't know Lua yet.
if(verb == "LookAt")
{
    if(StateManager.HasState("COKE_BOTTLE_GLASSES_EQUIPPED"))
        GameEngine.DisplayText("Oh, those .'s are actually the numbers 1-2-3-4");
    else
        GameEngine.DisplayText("The pass code is ....");
 
    // In actuality your script might look like this. Your script writers don't need to know the guts of your program.
    if(HasState("COKE_BOTTLE_GLASSES_EQUIPPED")) // HasState would somehow be interpreted as "Use the state manager to check for the state "blah"
        DisplayText("Oh, those .'s are actually the numbers 1-2-3-4");
    else
        DisplayText("The pass code is ....");
 
}

Side note, this could just as easily be mocked up in XML data files rather than scripts.

You basically need to figure out what you want to be able to drive via scripts and come up with an interface for your game's soft-code. So after your input manager knows you've clicked the PassCodeText entity with the LookAt verb, it triggers the associated script.

• In C#, your GameEntity class would have a LookAt() function. (or a DoVerb function with the verb as a parameter).
• It probably needs to take your StateManager and your GameEngine classes as parameters as well
• When its interpreting the GameEntity's script, you'll be mapping from the script construct over into your code.

I don't think you'll need delegates or generics here at all. :) You're world loading will have associated the script to your PassCodeText GameEntity. When you're interpreting your Lua scripts, you'll be mapping them to calls into your StateManager and GameEngine code. It's pretty much a data driven game at that point.

I wouldn't be concerned about passing the huge "state manager" class around. It's a class and thus - a reference type. Passing it around won't be slow because you're not copying the data every time. You're passing a reference to it.

Yes, I think a SCUMM adventure game is doable for a one-man team. You'll need the following skills: art, sound, creative writing, sense of humor, puzzle creation, and standard game dev stuff.

This article might get you going too:

http://www.gamedev.net/page/resources/_/technical/game-programming/using-lua-with-c-r2275

- Eck

So, how familiar are you with Lua?

Honestly not much. I'll be learning it soon and I've been using your questions as an excuse to start some research. :)

The article I linked earlier has some neat stuff:

http://www.gamedev.net/page/resources/_/technical/game-programming/using-lua-with-c-r2275

After doing some searches, it looks like there's a LuaInterface C# wrapper library. I found this post when I googled: C# LuaInterface documentation

http://stackoverflow.com/questions/1339917/luainterface-docs

Specifically, the guide.pdf link has a section on calling lua from C# and C# from lua:

https://bitbucket.org/maxint/luainterface/src/7b4bd173ecfd/luainterface/doc/guide.pdf

To do this, wouldn't I have to create a wrapper model to run concurrent lua scripts along with XNA's Update and Draw loops? Maybe something that stores a list of currently running scripts and executes one line on each one, return control to XNA loops and then executes the next lines? Then clear those scripts when a new screen is loaded and load a new bunch of scripts?

There are a million ways to skin this cat. I wasn't picturing multiple concurrent scripts running in my "design" (my shoot from the hip initial thoughts). I was thinking the world loading would build your level. Each room would know what game entities it had, and each game entity would know which verbs it could handle, and each verb would be tied to lua scripts that would interface with your game engine:

• checking and setting states - In the example above, reading the note with the coke bottle glasses equipped could set a KnowsSecretLabPassCode state, and the keypad could check that state in it's "use" script
• creating/destroying objects - Once you have the wire, and two coke bottles, you could use the "combine" verb to create the coke bottle glasses game entity, destroying the wire and coke bottles in the process
• special states tied to graphics - SecretLabDoor - open vs closed, player wearing coke bottle glasses
• trigger an animation/cut scene

But these are just my initial thoughts. I haven't done any deep thinking about this.

By the way, there is no professional goal with the project. This is purely a hobby enterprise where I am just curious about how this stuff works and am hoping for a learning experience.

Cool. It's pretty much the same for me. You had some interesting questions about generics and delegates that evolved into lua scripts. Any more in that direction and we should probably start a new thread. Thanks for the cool problems to explore. :)

- Eck