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.

Alpha in Sight

Over the past week, I have been trying to get my part of the alpha build ready for integration. We have about seven different parts of this alpha build that needs to get integrated and the more prepared my part is the less trouble we may run into...hopefully. We managed to get another build on the device to test some more aspects out. We finally got our group member who has an iPad to register his device onto the Apple Developer license. Now we have a fairly wide range of devices to check all sorts of compatibility issues which is definitely a plus.

I also received the final versions of levels one, two, and three. I spent some time trying to make sure that everything that I needed in the level was being used by my code correctly without any problems. There are some issues that still need to be addressed for our alpha build. The goal to reach in each level, which is the bed, needs to trigger the end of the level completion which we have not implemented as of lately. That is basically our win/lose condition there so definitely need to get a move on with that. There are tweaks that I need to make to my code now that most of my code works as needed. For example, the roll sequence:

event cat tapped
{
       check to see if cat isn't rolling
       {
              change camera to rolling camera and follow cat movement
        }
}

The (poorly written) pseudocode above is my implementation of the camera change which I have discussed in my earlier posts. Now that this works, I need to restrict the changing of the camera to occur only once per roll. At the current state, the code allows for the user to tap the cat as much as they want and change the camera at will. This is a simple fix that will basically be governed by a boolean variable. That is just one of the things that I need to do this week to set up for alpha.

Along with Integration...comes more bugs

This week we have tried to focus in on integrating our different parts together. For the most part, each of the coders have been working implementing their systems separately. Now that they all do work, we have begun trying to combine our code into one. The first approach to this was taken this week by me and a fellow team member who was working on the physics and the objects. We started combining code and using each other's set up and of course ran into some problems. We had an issue where the cat KActor object would not be detected by my PickActor function. We ended up altering my function for the input to be able to recognize the object and solved that issue. I had to throw away the place holders that I was using and now use the cat kActor's positions for my camera set up. This was a relatively simple change however, I have a problem with the rolling camera now. It follows the cat like it is coded to do, but the camera ends up moving in a circular motion as the cat rolls around. It's an extremely annoying bug that I have been working on trying to fix.

http://bestragecomics.com/3424

Well hopefully I don't go through the above scenario, but I'm sure it's a simple fix...hopefully. We are nearing the end of alpha stage, so it is critical to get our integration done and a nice build onto some of the devices. After we get the cat in and working properly, we will move on to incorporating the tool box feature into our game which is a major mechanic of the project.

Test Porting onto iDevice

This week I was able to get some coding done regarding the input. I don't have a lot to work with so testing mainly consisted of place holder items instead of our actual game assets. Our place holder for our cat has the functionality to get "touched" by the user via touch input on the device and that triggers our roll camera functionality. Through the UDK Editor, I was only able to test this through with the mouse click acting as a touch input. So it came time to try to port something to an actual device to ensure that the functionality is operating on an actual device.
There were many steps to go through to actually get permission for developing for the iOS platform and creating builds to use on an iOS device. You have to go through the Apple developer web site and get all of your certificates and credentials to actually begin testing on devices. Once I went through all of that, I used the UDK Editor to install the current build that I have onto my device and voila! It worked! Although the steps were tedious and somewhat confusing at times, the process went a lot smoother than I anticipated. After getting my build on my iPod, I was able to check my touch functionality and that also worked as expected! I believe I'm making some good progress, but there's definitely more to work on! I'll have some more development information for you guys next so see you then!

Here's a peek at the test build on my device:

Builds on iPod

Ignore the duplicates

Roll Camera works on touch!

Camera Set and Input Coding Ahead

As I explained last week, I have been working on the camera set up this week. There were many things to consider when trying to implement the main camera set up. I needed to extract information from the actual level that we are dealing with so I know where the camera has to limit itself.
To do this, I edited the level files and added in invisible actors that were placed accordingly for my scripts to deal with. The positioning of these actors helps me identify the current level's dimensions and the center point of the level. Since I was only dealing with level one, there was going to be no panning of the camera because the entire level was small enough to encompass the entire screen.
So there's my decision logic right there:

if (current level is small enough)
{
      focus the camera on the center point of the level
}
else
{
      offset the camera to focus near the player
      set up panning within current level dimensions
}

Here's the camera set up thus far:

Main Camera in fixed position

Roll Camera following actor position

However, since the panning will be dealt with by the user dragging with his/her finger, then I need to address the input functionality with the device. My camera set up as is works well with the current level given its size, but once I dive into the input coding I should be able to add in the panning functionality to finalize the camera.

So I will be putting the camera coding to the side as I start on the input aspect of the coding. I'll be looking at the UDN documentation guide for mobile input as some of my members mentioned that it has some great information on setting up the input code for mobile devices. 
 

Camera Prototype Set Up

This week I was able to finalize the basic functionality of our gametype. There are things that will definitely be added as we move on, but I have the base of it laid out. As I mentioned on my last post, I have also been working on the camera set up. I managed to get a simple camera set up that is based upon a specific actor's position. It is a basic scrolling camera that follows the position of the actor that it relies on. Although this is only a rough set up of our camera, I believe this is the eventual functionality that we will be needing for our game. Our game will basically have two camera set ups during gameplay. An initial camera will be the default camera that is showing more of the level in the view space and will have panning functionality to explore the level. Once the main action is initiated, we will switch to the 2nd camera which will follow the actor on screen based on it's position. Looking at this rough camera set up, I think this will be a great fit for our 2nd camera set up. I might still make some changes here and there, but it seems like a good version for the 2nd camera set up we are aiming for. Below you can see a screen shot of the camera set up I have so far. Ignore the aesthetic detailing that has been left out. This is all for testing purposes with placeholders for the initial build.

The 1st camera which will be the default camera is a little tricky to figure out at the moment. I have to decide how much of the level we want to show the end user. I also need access to the dimensions of the levels that will be created from the UDK editor so that I can account for all the various sizes in my code. Using that information, I want to create a camera set up that will show the character and a good amount of the level in the initial viewing space, but also be able to pan around all within the level's dimensions.

Definitely have some more work to do!

Researching and GameType Scripting

This week I was doing some more researching to start my UnrealScript portion for the game. We have assigned the major tasks to each individual person for our statement of work, but still need to clarify some additional tasks. I'm in charge of the game type, player controller, and the game play programming. There are many concepts that I want to be careful about when implementing. This is the first type that I am programming with an iOS device, so there are many concepts that I want to make sure are applied correctly like the camera implementation and game type class. I visited the the UDK forums constantly over the week and have looked in many documentations like the UDN Mobile Input System.
I also looked at the Camera Technical Guide for help on how to set up the camera. I know our camera needs to be in a fixed position, but we are not sure if we are displaying the entire level or only parts of it for the view.
What I did notice is that many things have changed with the iOS programming from when I did some exercises before using the Beginning iOS 3D Unreal Games Development book. The mobile aspect of UDK is more integrated now into UDK itself as a whole instead of a separate entity now. Some variables types have changed or have just been omitted. The following function deciphers the user's input.

function bool SwipeZoneCallback(MobileInputZone Zone, float DeltaTime, int Handle, ETouchType EventType, Vector2D TouchLocation)
{
    local bool retVal;
    local Actor PickedActor;
    local Vector HitLocation;
    local TraceHitInfo HitInfo;

    retVal = true;

    if (EventType == Touch_Began)
    {
    // if screen touched then pick actor
        PickedActor = PickActor(TouchLocation, HitLocation, HitInfo);
        // Display coordinates of user touch and if actor selected
        WorldInfo.Game.Broadcast(self, "TouchLocationX = " @ TouchLocation.X @ "TouchLocationY = " @ TouchLocation.Y);
        WorldInfo.Game.Broadcast(self, "PICKED ACTOR = " @ PickedActor @ ", HitLocation = " @ HitLocation @ ", Zone Touched = " @ Zone);
    }
    /*else if (EventType == ZoneEvent_Update)
    {

    }
    else if (EventType == ZoneEvent_UnTouch)
    {

    }*/
    return retVal;
}

In the example above, the "ETouchType" variable was a new thing for me. For the longest time, I was trying to make this function work and discovered that the variable I was using no longer existed. Instead the set up was changed to how you see it above.

Project Babycat!

Okay everybody, Adnan Rashid back here for your look inside my development of game projects. If you are familiar with my previous project, Arrival: From the Unknown, then welcome back! If not then you can visit this link [http://aftuproject.blogspot.com/] and see my development process for that game. We are planning to visit this project again in the future, but production has paused for the moment.

This time I'm here to inform you that I'm involved with another big title: Project Babycat! This is a client project from Boston for me and my team of six other members. I will be a part of the programming team on this project mainly handling the game type scripting. Our team and I have been just doing some researching so far to try to make this project the best it can be. Information for now is on the hush hush, but I can say that the game will be aimed for the iOS mobile platforms. I'm looking forward to this project as this will be for our Senior Project assignment as well.

So visit me often for my updates about the development process and Project Babycat updates!