Hi,
I've got a general question.
Which one(s), in your opinion, is (are) the ScummVM engine(s) that implement basic Point-n-click features and/or 2D game engine features in the "most natural" manner?
Those features include, but are not limited to: cinematic start/stop (and all associated timing events), all basic interaction events (pick up, look at, etc.), inventory management, dialogs, etc.
I'm talking about abstract features here, independant from the rendering or the sound.
For example, in many games (not necessarily in ScummVM, that is) the timing functions are very important, but many games poorly implement their events-related code, or Observer design patterns, etc.
So do you think that one of the engines makes the difference because it uses, for example, a particularly robust underlying library for generalist, abstract structures? Or do you think they're pretty much all equivalent to each other?
Or at least, do you think some of them are quite clunky, or would be inappropriate for some specific reason (very unusual gameplay, absence of inventory, absence of on-screen character, etc.) ?
You can present some pros and cons if you want.
Also, I don't now how much of it is managed by the core of ScummVM itself, as opposed to the custom engines.
Structural comparison of ScummVM engines
Moderator: ScummVM Team
-
monsieurouxx
- Posts: 80
- Joined: Fri Oct 19, 2007 5:48 pm
-
monsieurouxx
- Posts: 80
- Joined: Fri Oct 19, 2007 5:48 pm
I'll just prentend I didn't read that.
Unless you can provide the entire UML diagrams and dependencies of the ScummVM projects, you'll probably agree with me that it'll be hard for me to see how much each of the engines relies on ScummVM's core, and what is the approach and peculiarities of each of the 15+ engines (each of them being really different, both in implememtation and philosophy).
That's not something you can just "read" from the source code, or that's written black on white in the Wiki. It will take weeks and I will probably still miss something obvious.
However, someone who's been around ScummVM for the last 5 years will probably have intuitions on that.
And, once again, I'm not asking for a definitive answer, I'm just asking for personal opinions (You can be pretty sure each opinion on that matter will be different), that I'll match with what I saw by myself in the engines.
Therefore, I find it insulting to call me lazy frontally, the way you did.
Anyone else, who has a better understanding of general design paradigms?
Unless you can provide the entire UML diagrams and dependencies of the ScummVM projects, you'll probably agree with me that it'll be hard for me to see how much each of the engines relies on ScummVM's core, and what is the approach and peculiarities of each of the 15+ engines (each of them being really different, both in implememtation and philosophy).
That's not something you can just "read" from the source code, or that's written black on white in the Wiki. It will take weeks and I will probably still miss something obvious.
However, someone who's been around ScummVM for the last 5 years will probably have intuitions on that.
And, once again, I'm not asking for a definitive answer, I'm just asking for personal opinions (You can be pretty sure each opinion on that matter will be different), that I'll match with what I saw by myself in the engines.
Therefore, I find it insulting to call me lazy frontally, the way you did.
Anyone else, who has a better understanding of general design paradigms?
The answer to your question is: None. To quote yourself: It's impossible to pick one, due to "each of them being really different, both in implememtation [sic] and philosophy". OK, so you also said you don't expect a definitive answer, just personal oppinions.
But consider this: What one code may consider the "role model of programming", another may consider as clunky / overly abstract / not abstract enough, etc. What they teach you in 101 programming is only theory, but far from practice.
For *reverse engineering*, general design paradigms in general are not that helpful or important as usual. Sure, they play a role. But esp. in the beginning, you need to implement the features of the original engine 1-1, and trying to force them into the corset of specific programming patterns (from OOP, from functional programing, or wherever from) is usual more a hindrance then helpful. In fact, usually a good approach is to first implement a working engine, and only once you are sure it works pretty accurately. After that, you can attempt to refactor it into something more "elegant" that uses whichever paradigms you personally happen to like
.
I think that your real question is: "Which engine should I take as role model for my own engine?". My suggestion: Look as many of them as you can. But don't try to emulate any of them too closely. Rather, do what your engine requires. E.g. you asked about "timing functions". Well, every *game* has different needs for timing. So what is good for one game/engine may be completely inappropriate for another.
Try to get away from textbook solutions, formalism, and copying role models, and rather try to implement working code.
But consider this: What one code may consider the "role model of programming", another may consider as clunky / overly abstract / not abstract enough, etc. What they teach you in 101 programming is only theory, but far from practice.
For *reverse engineering*, general design paradigms in general are not that helpful or important as usual. Sure, they play a role. But esp. in the beginning, you need to implement the features of the original engine 1-1, and trying to force them into the corset of specific programming patterns (from OOP, from functional programing, or wherever from) is usual more a hindrance then helpful. In fact, usually a good approach is to first implement a working engine, and only once you are sure it works pretty accurately. After that, you can attempt to refactor it into something more "elegant" that uses whichever paradigms you personally happen to like
.I think that your real question is: "Which engine should I take as role model for my own engine?". My suggestion: Look as many of them as you can. But don't try to emulate any of them too closely. Rather, do what your engine requires. E.g. you asked about "timing functions". Well, every *game* has different needs for timing. So what is good for one game/engine may be completely inappropriate for another.
Try to get away from textbook solutions, formalism, and copying role models, and rather try to implement working code
.Anyway, I realize that we have many *many* engines and making a good select is difficult. So, while I can't really give advice of the kind you ask for, I can tell you some hints on which engines to look at and which to maybe not look at.
Some engines are very small, which helps to get a good overview. The two smallest engines when it comes to number of source files are probably touche and tucker. But tucker contains tons of hardcoded game logic, so avoid that.
For game detection, you'll most likely want to use the Advanced game detector code, which most of our engines use.
As for generalist, abstract structures: You can use anything in the common/ directory freely. If you need more, well, we are very strongly restricted on what external libraries to use, normally this is a no-go (for various reasons; e.g. portability, minimizing the size of the binary etc.). If you need a specific data structure and can't find it in common/, I'd recommend that you ask for advice; maybe some engine already implements such a data structure, or maybe somebody on the team is willing to add it from scratch.
Things like cinematic start/stop (and all associated timing events), all basic interaction events (pick up, look at, etc.), inventory management, dialogs, etc. are *highly* depended on your needs. Usually, they follow automatically from the reverse engineering process. It makes no sense to look at existing ScummVM engines as "role models for this -- rather, you should look at the engine you want to RE as your role model (and then, later, once you completed your engine, you can think about how to refactor this, if at all).
Well, one word on event handling on timing stuff: ScummVM provides a TimerManager that leads you schedule stuff to be run at specific intervals. However, this is not for use for event handling. Handling events is done via a polling approach, essentially; and you *must* invoke certain system functions (pollEvent / updateScreen I think), else on certain ports the user will experience hanging mouse cursors etc.
Some engines are very small, which helps to get a good overview. The two smallest engines when it comes to number of source files are probably touche and tucker. But tucker contains tons of hardcoded game logic, so avoid that.
For game detection, you'll most likely want to use the Advanced game detector code, which most of our engines use.
As for generalist, abstract structures: You can use anything in the common/ directory freely. If you need more, well, we are very strongly restricted on what external libraries to use, normally this is a no-go (for various reasons; e.g. portability, minimizing the size of the binary etc.). If you need a specific data structure and can't find it in common/, I'd recommend that you ask for advice; maybe some engine already implements such a data structure, or maybe somebody on the team is willing to add it from scratch.
Things like cinematic start/stop (and all associated timing events), all basic interaction events (pick up, look at, etc.), inventory management, dialogs, etc. are *highly* depended on your needs. Usually, they follow automatically from the reverse engineering process. It makes no sense to look at existing ScummVM engines as "role models for this -- rather, you should look at the engine you want to RE as your role model (and then, later, once you completed your engine, you can think about how to refactor this, if at all).
Well, one word on event handling on timing stuff: ScummVM provides a TimerManager that leads you schedule stuff to be run at specific intervals. However, this is not for use for event handling. Handling events is done via a polling approach, essentially; and you *must* invoke certain system functions (pollEvent / updateScreen I think), else on certain ports the user will experience hanging mouse cursors etc.
-
monsieurouxx
- Posts: 80
- Joined: Fri Oct 19, 2007 5:48 pm
Your answers are very helpfull. Thanks a lot.
The Advanced Game Detector tip is essential, because I remember that part caused me trouble in the past. thanks a lot for that.
I'll have a look at the small engines.
About the data structures present in /common/ : There semt to be everything one needs when I checked about 2 years ago. I was wondering if the classes were homogeneous, or if someone used them in a particularly elegant (let's say "consistent") way, but I guess that question doesn't make much sense, it's really too vague.
> "Usually, typical point-n-click actions follow automatically from the reverse engineering process."
The reason I asked was to figure out if one of the engines took some distance from the original script system of the original game engine, and duplicated those features in a modern code, that I could then re-use (I know that wouldn't be the case for all SCUMM-based games, because the SCUMMM script is at the heart of everything, but I couldn't tell if it was the same for other games). From what you say, the answer is no.
> "Handling events is done via a polling approach"
That's what I saw. And I infere from your message tthat this approach is fairly consistent (e.g. no lunatic implemented a whole new multithreading system next to it, just because he needed it)
Really, really useful answers. Thanks!
The Advanced Game Detector tip is essential, because I remember that part caused me trouble in the past. thanks a lot for that.
I'll have a look at the small engines.
About the data structures present in /common/ : There semt to be everything one needs when I checked about 2 years ago. I was wondering if the classes were homogeneous, or if someone used them in a particularly elegant (let's say "consistent") way, but I guess that question doesn't make much sense, it's really too vague.
> "Usually, typical point-n-click actions follow automatically from the reverse engineering process."
The reason I asked was to figure out if one of the engines took some distance from the original script system of the original game engine, and duplicated those features in a modern code, that I could then re-use (I know that wouldn't be the case for all SCUMM-based games, because the SCUMMM script is at the heart of everything, but I couldn't tell if it was the same for other games). From what you say, the answer is no.
> "Handling events is done via a polling approach"
That's what I saw. And I infere from your message tthat this approach is fairly consistent (e.g. no lunatic implemented a whole new multithreading system next to it, just because he needed it)
Really, really useful answers. Thanks!