Level Properties & Camera Matinee

This week I spent time going through the levels that require my working panning camera implementation. In each of the levels, I tested the camera to see what values are going to be needed for the maximum and minimum panning distance for the X and Y axes of the level camera. Once I had those values, I filled up the archetype for the appropriate level and moved on to the next level.

This process will be repeated for each level, but the downside is that I have to wait for the levels to be completed. Once our level designer completes a level, only then can I continue with my implementation of the panning camera. Hopefully, I will not have to wait long for the next levels to be ready to work on.

Although I mentioned that I will address the matinee camera issue last week, I was unable to address it this week. So this upcoming week I plan on looking into it. This issue requires both the level designer and my cooperation so that it can be properly addressed, so we'll see how we can attend to it. It's the level designer who is setting up the camera matinee in Kismet as shown below and that is what needs to be accessed in code.

I have a simple solution thought up in my mind, but I'm not sure if it will be as simple as I am thinking. If I can just get access to a simple boolean variable that can check if a camera matinee is playing then maybe I figure out a way to effectively use it to  govern whether or not the camera matinee should replay again or not based on the level restart. We'll see if it's as easy as I think...

Panning Camera...Check

So after some more digging and consulting with the other programmers in my team, I was able to set up the conditions that I needed for my camera set up. One of our packages for UDK, we have archetypes for each level. Each archetype has the same variables but different values associated with the variable to accommodate for the appropriate level. It was here where I can find the connection that was needed between the level currently in play and my camera code.

In this package I created a boolean variable that simply requires the level designer to enable the check box to indicate to my code that the panning camera is needed for the current level. The max and min amount that the camera can pan in the X and Y direction also have variables to be filled in for each level archetype. This archetype set up allows the level designer to freely create the levels and if he feels the need for a panning camera for a certain level then all he has to do is check the box. It's that simple.

You can see the archetype for level one in the above picture. In it, you can see the variables that I have set up for my panning camera functionality.

Now I am tasked with going through the playable levels we have and setting up the values for my variables in each archetype. This way we can have each level functioning properly and using the right camera set up. There's also a matinee sequence for each level that needs to played only at the appropriate time and not consistently upon entry into the level, so more work ahead.

Beta Phase Started

The Alpha stage has been completed and development has moved to the Beta phases. After a week off, I'm excited to dive back into development. This week the group got together and composed a statement of work to outline what needs to be completed and by whom by the end of these next eight weeks.

As we have projected since most of the mechanics has been completed, we have mostly bug-testing to do, new levels to create, and improve the audio and visual assets.

What we initially scrapped back in Alpha has come back to haunt me in the Beta stages. The panning camera functionality was something that we decided against as a group, but now that we have moved deeper into development we have a need for it. Our level designer is creating larger levels that just will not look well with a centered camera set-up.

I quickly got to work on this, but with a new approach. Instead of spawning a new camera through code, I decided to use the camera actor already in place for each of the levels. My main problem was how to identify the dragging touch input on the screen. After a little research on the UDK forums on iOS mobile gestures, I was able to construct a set-up similar to a thread post that I read over that would help me identify the drags and their direction. The link to that tutorial is here: Epic Games Forums: iOS Gesture Tutorial.

After being able to read the drag input, the panning was fairly simple to implement. I had the functional panning camera set up, but there were no limits to it.  Below is the rough testing of the panning camera.

Original camera position 

Panned camera to the left

Panned camera to the right

There were a couple of things that my code needed to know before we actually utilize the panning feature of the camera.

1. Is the level large enough that it needs the panning feature?
2. If yes, then how far can we drag the camera in the X and Y directions?

These are the conditions of my camera having the panning feature. I will need to consult with our level designer to see if we can set this information up through the level itself.