Open Quaker762 opened 5 years ago
I suppose that was a necessity for the original engine because it was a PS2 game, with very limited RAM. and all
We can probably put some stuff, the level transitions for instance, in a simple file that is parsed on startup. But for more complex game logic I agree with your suggestion to have a class per level. At first glance at least it doesn't seem like a bad idea.
I suppose that was a necessity for the original engine because it was a PS2 game, with very limited RAM. and all
I'd be inclined to think that too, that or they had the classic 90's Japanese programmer mentality of 'write once and don't bother about it if it works'. I suppose as well this took a lot of work away from the artists, so they were free to just work on their art instead of any kind of game logic.
We can probably put some stuff, the level transitions for instance, in a simple file that is parsed on startup.
Yeah I like that idea. I think we're going to have to do some 'offline' like this to save a lot of global hardcoding. It's unfortunate that this might take a lot of playthroughs to achieve.
I'm going to open this issue now so everyone that's watching the repo, e.g @piratesephiroth @belek666 can discuss how we might overcome the hard-coded in game logic. Things such as events, level transitions etc are ALL hard-coded into the Silent Hill 3 executable. As @jokiew discoved and shows here, it's possible via memory editing to trick the game into changing levels for certain actions, such as in this case, viewing the mirror. There is no data driven programming at all in the original, C based engine.
The idea I have (@z33ky will hate me for this, but I can't see another way besides disgusting global lookup tables) is to have one class PER LEVEL. Obviously, this is very bad, and we'd need to have a complete list of level transitions, but I feel this would clean up a lot of the lookup table spaghetti that TEAM SILENT created. This way we can contain all hard-coded stuff in the class that it is needed, instead of having it spread out all over the place (and violate the nice OOP we have going).
Obviously way in the future, but it's probably good to at least discuss it.