It’s been a few weeks since my last Escape from Alcatraz update, during which time I have implemented a camera system based on multiple fixed cameras, and point-and-click movement with navigation mesh pathfinding.
Week Two – Springfield
As an exercise to become better acquainted with the ins and outs of the Unreal Editor, a group of more than twenty students teamed up to recreate (parts of) Springfield – The Simpson’s fictional home. The group was sub-divided into four groups, each with its own leader. I was the leader for the Evergreen Terrace group. It was our job to recreate the Simpson’s home, Ned Flander’s home, the Simpson’s other neighbour, and the President’s Mansion opposite the Simpson’s. The latter was my task:
Week Three/Four – Cameras, Point-and-click
After blocking out some basic levels (like the one you can see in the video above) I implemented a simple fixed camera system using Kismet. Essentially, whenever the player walked into a trigger volume, an infinitely looping matinee sequence would activate, changing the perspective to a camera actor object placed in the level. While this worked well enough, it was pretty messy Kismet logic, and it’s not particularly flexible.
Eventually I decided to rewrite this system using UnrealScript – storing a reference to a camera actor in a custom CameraTriggerVolume object and dynamically switching camera in the code. Not only is this approach cleaner, it also allows me to be more flexible about when I update the camera. When it comes to movement, for example, I can instruct my main camera class to update to a new viewpoint when, and only when, the player has stopped moving.
The most interesting task this week was implementing point-and-click movement. I began by deprojecting the 2D mouse coordinates and tracing from (read: near) the camera through the resulting 3D position to find the location at which my cursor “hits” the world beneath it. With this information I was able to make sure the player always faces the cursor, and also move to the position under it, assuming there are no obstacles in the way (verified by an additional ray trace).
With this basis in place I looked into the ways in which the Unreal Engine 3 handles pathfinding. Prior to the UDK, pathfinding was achieved solely with the use of way points and path nodes placed in the editor, but this is no longer true. UDK now supports pathfinding via navigation meshes – a representation of the world made out of convex polygons. Not only do navigation meshes result in more realistic AI pathfinding than do way points, they can be automatically generated in the UDK editor!
The AIController class features an example of navigating via NavMeshes, which I was able to use and learn from. The result can be seen in the previous video. So, what’s next? With point-and-click basics in place I can start looking into implementing some actual gameplay, something for the player to do. My intention is to start with item collection and/or some simple NPC interactions. Until next week!
Topher Cox
I’m curious how you got your CameraTriggerVolume class to work. I’ve tried implementing something similar, except the touch event when the level starts fails to change the camera. All ones after it work as expected. Is this an issue you ran into at some point, or am I doing something terribly wrong?
Karn Bianco
I had the same issue. The trouble is touch events don’t get fired if you spawn inside a volume. As my game changed from being in one level file to many (and back), I used a couple of different solutions:
– Create a custom camera actor class and add a ‘Default Camera’ Boolean property to it. Tick that in the editor and use it to find the camera in code/Kismet at the game’s start.
– Spawn your player slightly above the first volume, so the pawn falls into it. They’ll be a delay at first while no camera is active (I covered that up with a cut-scene).
Topher Cox
Actually, the touch event does go off, or so my logs would like to claim. It just seems to not acknowledge the change. But I will give those ideas a try, thank you.
Karn Bianco
Interesting! Which version of UDK are you using, out of interest? I had to develop this with the August 2010 build and I’m sure Touch events weren’t firing for me. Perhaps that’s been changed? Either that or I’m going mad.
Topher Cox
I’m using the December 2010 version, so I suppose it is a possibility it has been altered.
Topher Cox
Actually, on a whim I moved my debug log from Touch to SetViewTarget, and it turns out SetViewTarget was being called 4 times, the final call resets the camera. I just tweaked it to only process if the actor it is passed is a CameraActor, and now it works.