Alberto wrote: ↑December 31st, 2023, 10:21 am
Oh wow, so the main code is 'unchanged' (as in faithful to the original) and you upgraded the level loading? Nice!
It would be funny watching the guards stand one foot away making eye contact with the Kid, but not following him because he is in another 'room'
Or it would be interesting watching how the Kid phases through the gate in Level 5 (
trick 35).
My gameplay code is very faithful overall, but it's structured differently than the original game. One big difference is that a level isn't divided into rooms in my project. Original POP has to look up information from other rooms when the player is off-screen, but in my project I always look up absolute tile coordinates no matter where a player is positioned. So I'm 99% sure that gate bug you linked won't happen in my code. I assume it happened in the original code because it failed to acquire information about a specific tile from a different room, but my code always does tile lookups the same way.
That said, my code does calculate where the room boundaries are supposed to be and it's used for various checks. So, you'll see an enemy completely lose interest once you cross the magical room boundary (assuming he's not too close, in which case he'll keep chasing the player just like the original game). Of course, it's also used for the camera to ensure it's focusing on the room the player is in.
I'm not completely sure how I'll handle things in the long run. Right now, I'm trying to make sure gameplay is as faithful as possible (though I'm completely okay with bugs being fixed), but there are some changes I wouldn't mind seeing personally. I think it could be fun to have guards chase you indefinitely once they spot you. Right now, the collision code works the same way as the original game but I wouldn't mind rewriting it from scratch so it's easier to work with, and that would also fix some rare bugs related to collision.
This shouldn't change gameplay, but I got one idea when looking more closely at the combat animations. Enemies and the player use the exact same frame data for every combat frame, but there's one visual difference: the prince has 2 frames of animations for parrying ("start parry" and the "actual parry" frame), but the enemies only use one (they show the "en garde" frame instead of "start parry" if I recall). I think it would be interesting to see that expanded so they also show 2 frames, but that would require new graphical assets.
On a related note, I'm planning to make it possible to make the enemies playable. The enemies are controlled a similar way as the player (the AI simulates key presses), so it wouldn't be much work to make them playable (the downside is that they don't have many movement options available, but it could be a fun competitive mode maybe to have one player control the prince and another player control a guard).
Since I haven't written an update on the project in a while, I can quickly mention my current schedule:
- Finish up all gameplay functionality in POP1 (right now, that means finishing up enemy AI and adding a proper death state for players)
- Start implementing support for POP2 gameplay (I've been looking at David's POP2 disassembly and that's been an extremely helpful resource. My plan is to expand on that and map out more POP2 gameplay code that I'll need to reference)
- Implement "scripted events" in POP1 and POP2 (ie, the shadow prince stuff in POP1)
- Rewrite some code so it's easier to work with (for instance, re-write collision check code)
I'm not sure what pace I'll be working at, though. The amount of time I can allocate to this project varies greatly, so it's hard to judge when I'll hit the various milestones.