1,489
edits
Difference between revisions of "About"
Jump to navigation
Jump to search
no edit summary
m (→Where does ScummVM fit in?: typo) |
|||
| Line 19: | Line 19: | ||
** Voices | ** Voices | ||
Apart from the resources themselves, almost all games have their own scripting language. This simplifies things in the whole development process, as it's then easier to assign tasks to specific people. Programmers deal with the code itself, game designers deal with writing scripts using the language that the game interpreter understands, graphics designers deal with the artistic part of the game, music composers with the audio and so on. | Apart from the resources themselves, almost all games have their own scripting language. This simplifies things in the whole development process, as it's then easier to assign tasks to specific people. Programmers deal with the code itself, game designers deal with writing scripts using the language that the game interpreter understands, graphics designers deal with the artistic part of the game, music composers with the audio and so on. Although the basic elements of each game are standard, each game implements them in a very different manner. The most important aspect of adventure games is the way they work "behind the scenes", which includes the kind of logic used and how this is implemented in each game, the kind of interaction expected from the user (e.g. some games allow you to use verbs on objects like "use object 1 with object 2", whereas other games just allow the user to single click on objects). The resources themselves are not useful at all without the game logic, which is the most difficult part to implement in a game. In fact, there are many resource viewers which can be used to view resources from a large number of different games, but they don't deal with the logic behind those resources at all. A brief introduction to how logic works in each game is explained in the next part. | ||
=== The scripting language of a game === | === The scripting language of a game === | ||
| Line 60: | Line 60: | ||
* In some games, ScummVM offers added functionality which did not exist in the original games. For example, it offers full mouse functionality in older Sierra AGI games, which had no mouse support | * In some games, ScummVM offers added functionality which did not exist in the original games. For example, it offers full mouse functionality in older Sierra AGI games, which had no mouse support | ||
* It's possible to listen to a supported game's MT-32 music score (if present) without an actual MT-32, via a sophisticated system which emulates it | * It's possible to listen to a supported game's MT-32 music score (if present) without an actual MT-32, via a sophisticated system which emulates it | ||
* ScummVM needs much less CPU and system resources than an emulator, as games run directly in ScummVM and not through an emulated platform (which might have a different CPU, different memory management and so on) | |||
...and many more. | ...and many more. | ||
The approach that is taken when implementing a game under ScummVM has some disadvantages: | |||
* Because the logic of each game in ScummVM has been rewritten from scratch, some bugs which were not present with the original game interpreter might exist in ScummVM. For this purpose, there is a bug tracker in ScummVM, where users report such findings to the ScummVM team, which are then usually fixed. Such issues surely exist, as it's impossible to check every single aspect of each game, and a full rewrite of the game engine means that there might be issues which the developer didn't find out originally. | |||
== Supported games == | == Supported games == | ||