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.
Sunday, April 21, 2013
Saturday, April 13, 2013
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.
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.
![]() |
http://bestragecomics.com/3424 |
Saturday, April 6, 2013
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:
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:
![]() |
Ignore the duplicates |
![]() |
Roll Camera works on touch! |
Monday, April 1, 2013
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:
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.
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.
Subscribe to:
Posts (Atom)