Here I was bracing myself for the imagined complexities of movement logic, and it turned out to be a whole lot simpler than I imagined. Probably blame it on the other two engines I've had experience with path-finding for: Lure, and Tinsel, both of which have their share of complicated logic. For Rex Nebular, though, the implementation was a lot more elegant than I'd expected.
What the MADS engine does for walkable areas is to have two parts. The first is a priority/depth surface, which had already been previously implemented. This is a surface which both specifies the walkable areas, and is also used to determine which parts of an object, at a given 'depth', should be drawn on-screen. In the first room, for example, the area comprising the chair has some varying levels so that the player gets drawn behind it.
The other part to the movement functionality is a series of 'scene nodes'. These are a series of points distributed across the scene to represent appropriate intermediate points in movement. If a straight line between the start and end point isn't possible, because of a marked obstruction, then the engine calculates the distance between each node in the scene, including both the start and end points as two extra nodes. It then calculates which series of nodes will take the shortest amount of time to traverse, and uses that as the basis for movement - the actual walking then moves the player from node to node until the destination is reached.
This works well for the game since, unlike in Tinsel or Lure, there aren't ever any moving actors that could interrupt the walking path. The only NPC character movement that ever happens is in cut-scenes, where the player is either not moving, or is being controlled by the computer (such as when Rex is taken to the cells).
Now that I've got Rex moving around on the screen, the next immediate step is to get the hotspot and selection code working. Somewhat ironically, this is turning out to be more complicated than the walking code itself. I'm currently working my way through disassembling the various routines and implementing comparable code. Hopefully, I'll soon have enough implemented that I can properly implement some actual actions in the first room.
Tuesday, July 27, 2010
Monday, July 12, 2010
MADS/M4 engine now has cutscene support
Well, it's been a very productive month for work on the MADS/M4 engine.
Since the last posting, I started working on the cutscene animation system. This is a separate module to the basic cycled animations that get loaded into a screen.. rather, the game uses an animation manager to handle so-called 'cutscene animations', such as that of Rex waking up in the first room. In this case, the animation manager handles the work of animating the sequence of frames of Rex waking up, looking around, and then getting up. Given that this was the fist major action in the game, it made sense to have that properly implemented first.
Above and beyond that, the animation manager is also used for handling all the full-screen animations done in both the introduction and ending sequences, so once I had Rex properly animated in the first scene, I moved onto implementing proper support for them. With some help from Md5 on the handling of digital voices during the intro, the introduction sequence now plays completely if you press 'F3' from the main game menu. There are only a minor few issues remaining with the introduction, in that:
The obvious next stage for me to look into is actually starting to give some movement control for Rex, and have him be able to walk around on-screen. This is where I'll need to worry about figuring out the pathfinding algorithm, and how actual movement is done. I've already identified some of the methods associated with handling Rex's movement but, as I expected, there's a lot of calls to unknown sub-methods that I'll need to figure out the purpose of. Since the MADS engine was designed to be generic for multiple games, there's a lot of complexity in both the movement and pathfinding code that I'll need to figure out.
I'm really looking forward to this. It'll be another major milestone reached when I can move Rex around the room. At that point the game will finally be properly interactive. I'll then be able to work on interacting with objects, which I already understand a lot about, and maybe even moving between rooms and/or teleporting.
Since the last posting, I started working on the cutscene animation system. This is a separate module to the basic cycled animations that get loaded into a screen.. rather, the game uses an animation manager to handle so-called 'cutscene animations', such as that of Rex waking up in the first room. In this case, the animation manager handles the work of animating the sequence of frames of Rex waking up, looking around, and then getting up. Given that this was the fist major action in the game, it made sense to have that properly implemented first.
Above and beyond that, the animation manager is also used for handling all the full-screen animations done in both the introduction and ending sequences, so once I had Rex properly animated in the first scene, I moved onto implementing proper support for them. With some help from Md5 on the handling of digital voices during the intro, the introduction sequence now plays completely if you press 'F3' from the main game menu. There are only a minor few issues remaining with the introduction, in that:
- The tempo of the intro isn't quite matched to the original yet; I'll need to properly calibrate the timing loops at same stage
- I haven't implemented palette cycling, which is used by some scenes within the introduction sequence to simulate basic animation.
The obvious next stage for me to look into is actually starting to give some movement control for Rex, and have him be able to walk around on-screen. This is where I'll need to worry about figuring out the pathfinding algorithm, and how actual movement is done. I've already identified some of the methods associated with handling Rex's movement but, as I expected, there's a lot of calls to unknown sub-methods that I'll need to figure out the purpose of. Since the MADS engine was designed to be generic for multiple games, there's a lot of complexity in both the movement and pathfinding code that I'll need to figure out.
I'm really looking forward to this. It'll be another major milestone reached when I can move Rex around the room. At that point the game will finally be properly interactive. I'll then be able to work on interacting with objects, which I already understand a lot about, and maybe even moving between rooms and/or teleporting.
Subscribe to:
Posts (Atom)