Well, my edit button died, so here's a new post. Woot. I'm such a waste of bandwidth. Also sorry if this is turning out to be more of some sort of random "Alex is talking to himself again, isn't he?" sort of post. Talking about this stuff helps me figure it out. I think.
So, multiple instances. Reading back, I guess that's what you were talking about when you mentioned a "template." I'm going to assume that this involves using DMA too. Something like
Code:
new object
object.read_in_data{I'm going to pretend that the templates getting passed in or something even though that's probably not how it works.}
Of course I totally suck at using DMA but now that I have a context to work with it in -- assuming I'm on the right track -- it should be easier.
I think I would be able to do this without setting up a template like the kind you suggested and just using another object or something for this. I don't know if that would be as efficient, but I think that it would work. On a similar note, I should probably start reading in room text from external files instead of storing it in various #defines in my headers. Although I don't see anything wrong with that other than it probably causing noticable overhead and also being sort of goofy and probably also unreadable.
Anyway, back to that messages thing. Does part of this involve creating a base... I don't know, "message" class, and deriving numerous other classes from it, and having them act sort of like scripting commands or something? I'm going to assume that the global script is just a long list of code that gets called at various points based around these messages? I think Zork had something like this, although Zork's source code strikes me as really indecipherable. It also used a lot of gotos.
"Windows passes messages to your window and the LPARAM and WPARAM meanings are relative to the message being passed."
That sounds like function overriding or something.
Anyway, I don't think that using messages and a global script is really viable for the dialogue setup I'm going for. It's only going to be a one on one conversation between the main and an NPC. Automated dialogue will... be treated as an event, and I'll probably just have it be a single chunk of text instead of several lines fired by various "actors."
It could have applications for switching the menu mode around though. My plan was to half a bunch of whiles in sequence. This would work and probably wouldn't be really slow, but it's ugly and stupid. I could possibly store each menu mode in a function or something but I didn't want to do that for some reason. I think it's because I'm thinking I need to pass a lot of variables although something tells me that I probably just have poor data management issues.
