Project Reflection

Now that the project is over I thought I'd give a brief reflection over my thoughts on how my first client project went. It was a great project for me and the rest of my team as well as a vital learning experience. We were able to receive the requirements from the client and proceeded to do our best to fulfill them. The communication started out great in the first couple of weeks. We had game industry professionals as our client and they were helping us out with this project on their spare time. That being said, it was hard for our clients to give this project and our group the constant attention. We received great feedback at times and it was what made our project that much better. Towards the end of the project phase we ended up losing that connection for unclear reasons. Although this was unforeseen, our group was still able to stay together and continue our project. I hope this client project can serve as a learning experience for each of the team members and have us better prepared for the events that can unfold in the real world. Although we did not get the full requirements done, we got a nice acceptable build that was ready to go and show off at our presentation.

Beta Phase Wrap Up

So this week was the ultimate crunch time as we were pulling out all the stops to get a nice working build ready to go for the beta presentation. There was multiple parts of the projects that various members had so integration was very difficult to do properly.
As my final task for the build, I was working on setting the camera matinees for each of the levels as I mentioned in my last post. There were so many problems arising with this matter. Even though our level designer set up the matinee correctly as to what I needed, the camera for some reason was following a slightly off path which resulted in showing too much of the level or not ending in the correct position that I needed it to.
After many trials and tribulations my final attempt to solve this for the beta build was to hard code the position at the end of the matinee cycle. Although this worked for most levels, a few of them still bugged out on me. It wasn't too bad of a bug for the build, so it sufficed.
Once the matinees were done I sent them over for integration and the final pieces of the puzzle were put together.

Level Camera Matinee Revisited

Over the week I have looked into what possible steps can be taken to address our level camera matinee sequence issue.

The problem: Level camera matinee plays every time the level is loaded or restarted which turned out to be a nuisance when it was play tested.

Intended solution: Establish a procedure to check if a level is being loaded the first time or not. If it is then play the level camera matinee. If the level is restarted or is being loaded a second time, then skip the level camera matinee.

I did some research in regards to see if I can find a set up that will work with what I need to accomplish. I found a nice Kismet sequence set up that can trigger our matinee through an UnrealScript function. You can see below to accomplish this I needed to use a Console Event that triggers the matinee and also sets a boolean variable to true/false via the Console Command to see the if the matinee is playing.

Kismet Sequence for Level Camera

What I need however is a set up in the level scripts to have a boolean variable to check if the level has been loaded previously or not. I'll need to collaborate with a fellow programmer who set up the level scripts to see if he can set this up for me. Once he does, I can begin implementation of this solution.

QA Testing

This week we spent playtesting the other senior projects. This was a good opportunity to see what external testers thought of the game and what bugs we missed. Our build consisted of about 16 levels and some were not completely playable. We knew of most of the bugs that were present in the build, so it was rare to find a bug that one of the testers reported which we were oblivious to.
We did receive feedback on the user interface as well which mainly consisted of making the buttons larger since on the ipod they are all a bit small to touch the intended button.
We have are starting up week 6 and are in a critical part in development. We should have most of the game developed, but we are not near that point at all yet. We are behind in development and we really need to make a push and start pushing things out soon. We've been behind with the object replacement for the levels and the object interactions have been slow to implement as well. A lot of this work had members relying on other other member's work and this has really taken a toll on the overall project. We'll see how much we can finish up in the coming week.

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.