Sorry I dropped off yesterday. Work and all that.
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")
GameEngine.DisplayText("Oh, those .'s are actually the numbers 1-2-3-4");
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");
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: