Week 7. End of part one.

This week is the end of the work that we are doing for the class this section. I look forward to the break, and I don't mind the idea of working on the game on and off over vacation. It's good to be in code again, so it'll be fun later. Now it's just figuring out what needs to be done then.

The presentation went well, and I think we did good. There was a few tweaks that needed to be done that were not in yet, and a few things that need to be added to the list. But all in all, it was fairly easy fixes. Now we just have to finish the rest of the game, as well as add a few cool new features here and there.

Week 6. Closing up work.

This week we had to finish a lot of stuff for the project. A lot of the AI and level work needs to be done. As well as porting in sounds to make the game feel more finalized. As for the menu however, I have pretty much covered all that I need to cover. All that I have left to technically do is the help menu and make more achievements for the game. But with them being end game stuff I'm not sure if they will be completed for this half of the project. The reason is that achievements and help may change as new features start to emerge from later work. Something that would really change the help menu is an idea about groups of penguins working as a team. Should team stuff be implemented, it will need a different help menu. So that may not go through this half because it will be demonstrated by us and isn't finished enough to be completely concrete.

As well the help menu will be pulling pictures from game play. So we need finished stuff to show how to use them and what needs to be done. The good thing is that our game may not really need a help menu because it is fairly intuitive. So long as you know that the mouse is the only control, you shouldn't have to much trouble playing it.

Week 5. Tooltips.

This week was interesting. I did a lot of work to get the shop up to par, and I feel I've done a pretty good job at the moment. After finishing up the last parts of the shop I moved on to my next difficult task, tooltips. I wasn't quite sure how I would go about making it, but I found a tutorial of sorts that helped me come up with an idea of what I had to do.

That picture looked a lot like the image I made above.

The back has two movie clips. One called TooltipBack and one called TooltipFront.

The text is HeadingTxt and BodyTxt.

The code that I wrote looked like this:

//Code for mouse movement
mouseListener.onMouseMove = function()
{
 if (_xmouse + TooltipBox.TooltipBack._width <= 800){TooltipBox._x = _xmouse + TooltipBox.TooltipBack._width/2;}
 else {TooltipBox._x = _xmouse - TooltipBox.TooltipBack._width/2;}
 if (_ymouse + TooltipBox.TooltipBack._width <= 600){TooltipBox._y = _ymouse + TooltipBox.TooltipBack._height/2;}
 else {TooltipBox._y = _ymouse - TooltipBox.TooltipBack._height/2;}
}

//Object that the tooltip shows information on.

StorageItem7.onRollOver = function()
{
 _root.attachMovie("Tooltip", "TooltipBox", 50);
 TooltipSetup("Fire Ball", 0x0073b5, "Attack Damage = High\nAttack Speed = Low\nAttack Range = Medium", 0);
}
StorageItem7.onRollOut = function()
{
 removeMovieClip(TooltipBox);
}

//Setup function
function TooltipSetup(A:String, B, C:String, D)//(Heading text, Heading color(optional), Body text, Body color(optional))
{
 TooltipBox.HeadingTxt.autoSize = true;
 TooltipBox.BodyTxt.autoSize = true;
 TooltipBox.HeadingTxt.text = A;
 if (B == 0) {TooltipBox.HeadingTxt.textColor = 0x000000;}
 else {TooltipBox.HeadingTxt.textColor = B;}
 TooltipBox.BodyTxt.text = C;
 if (D == 0) {TooltipBox.Body.textColor = 0x000000;}
 else {TooltipBox.BodyTxt.textColor = D;}
 //Set box and word max width
 TooltipBox.HeadingTxt._width = 300;
 TooltipBox.BodyTxt._width = 300;
 TooltipBox.TooltipBack._width = 310;
 TooltipBox.TooltipFront._width = 300;
 //Adjust text to left side
 TooltipBox.HeadingTxt._x = TooltipBox.TooltipFront._x - TooltipBox.TooltipFront._width / 2;
 TooltipBox.BodyTxt._x = TooltipBox.TooltipFront._x - TooltipBox.TooltipFront._width / 2;
 //Adjust textbox y when multilined
 if (TooltipBox.BodyTxt._height > TooltipBox.HeadingTxt._height)
 {
  TooltipBox.TooltipFront._height = TooltipBox.TooltipFront._height + (TooltipBox.BodyTxt.textHeight - TooltipBox.HeadingTxt.textHeight);
  TooltipBox.TooltipFront._y = TooltipBox._y;
  TooltipBox.TooltipBack._height = TooltipBox.TooltipBack._height + (TooltipBox.BodyTxt.textHeight - TooltipBox.HeadingTxt.textHeight);
  TooltipBox.TooltipBack._y = TooltipBox._y;
  TooltipBox.HeadingTxt._y = TooltipBox._y - TooltipBox.TooltipFront._height / 2;
  TooltipBox.BodyTxt._y = TooltipBox._y - TooltipBox.TooltipFront._height / 2 + TooltipBox.HeadingTxt.textHeight;
 } 
//Adjust to distance to screen sides
 if (_xmouse + TooltipBox.TooltipBack._width <= 800){TooltipBox._x = _xmouse + TooltipBox.TooltipBack._width/2;}
 else {TooltipBox._x = _xmouse - TooltipBox.TooltipBack._width/2;}
 if (_ymouse + TooltipBox.TooltipBack._width <= 600){TooltipBox._y = _ymouse + TooltipBox.TooltipBack._height/2;}
 else {TooltipBox._y = _ymouse - TooltipBox.TooltipBack._height/2;}
}

The result of the code is what is below. This code creates a tooltip box from where the mouse is and adjusts it to deal with the screen and more text. Only the body text can expand, which means you have to have a header that can fit within the textbox. Another good thing about the code is that there is an ability to pass to the function color choices. As shown below, the TooltipBox.HeadingTxt.textColor was changed to make the header blue.

Week 4. Menu work.

I've been working hard on my menu lots of times this week. In fact I feel like I'm a little ahead at the moment. While I may have more difficulty making more work with what I have at the moment, I think this is good because it allows me to refine a few more features of my menu and HUD. Something I've been thinking about is tooltips for the achievements and the shop. This means that rolling over the button will allow you to see information, as well as how to get the item you are looking at.

I've also ended up taking more of the shop task as part of mine, mostly because I felt like the feel of the menu should be very consistent. When I saw it last, it seemed against my basic flow feel. But the good of this is that I will have control of the flow and Wes will be able to work more on the characters, their weapons, and possible animations(a newer idea to come into play). By also taking in the shop I will now have to come up with a plan for the buttons and HUD/UI for the shop, but I've got something in mind.

Week 3. Working on menu and HUD.

This week was big on working on the HUD and menu. Unfortunately, a holiday also kept me from working on it. But now that I'm back, there should be more work done. So far though, I have a lot of my part set up. I have basic menu use, player save input ports, and cheat input capability. Now I just need to know what we need for the load and cheats to set them up fully. As well I need to add save ability, a tutorial (help button. Probably late game implementation for when everything is set up), button assets (also a bit later because I need input from shops), and achievement planning (not a core part so last on my list really).

During my work I found that the photoshop mock-ups I made could be imported and used to create the menu. This helped to save some time, though the coding set me back a bit. My knowledge of flash is on the lower side, but nothing that google can't help me figure out. One major problem I was having was with player save/load. I needed a structure to hold the information, but google told me that flash doesn't use structs. This meant that I needed to make classes, which is fine, but they needed to be in another flash code file. Luckily I figured out how to get it set up and working with the main code layer via the import code.

This also reminded me that flash has a different use of code than C++. It doesn't have floats or ints, which leads me to believe that number supports both. As well I found that creating arrays in flash is actually pretty easy. All you need is a var Something:Array, then set Something = [#,#]. Though I might want to look into how it works with parallel arrays.

Week 2 blog. A new game.

This week me and my group went over our new game and how we would work on it. Many parts were taken to be worked on and I have picked the menu, UI, and achievement section for my task in the group. There was a lot of discussion on what we would do with our UI because it requires so much of the gameplay be very solid. This meant that my questions on what we would need to display to the player and what the game needed to work was hammered out. Now with my better understanding of the game and its parts I can get stuff together to make the game nice and functional.

With that said I have plans for how I will work on the UI system. At the moment I only have blueprints for how the UI should look at the end of all the work. It will look like this:

The top left corner of the screen will have the tabs for the menu, the shop, and achievements. The shop will only be usable from the main map screen, which means only a set amount of items can be brought to battle and should be planned and purchased beforehand.

The top right corner of the screen shows the number of units from each of the five types of basic units that you have purchased. Say that you have 10 of the first unit type and 23 of the second unit type, you can click on the one that will be active at the moment in constant build and know how many of that type of unit you have until you have to switch units or until you lose all your units.

The bottom left corner of the screen is the five shop items that you have bought and brought to the battle. Here you can select the type of item the basic unit sent out will have to fight with.

The bottom right corner of the screen will be a console that displays game events. Things like units created, units defeated, and other event things as such. This console will also be used to utilize cheats when they implemented.

Week 1. A new class.

This week was the start of a new class. There isn't much to cover at the moment. Got a group all set up and came up with an adventure idea for our game. We plan to use flash to make the game, which means I'll probably have to look at some online flash syntax. But flash should be pretty good. We are also planing to do it in flash actionscript 2.0 because it is better for working on each piece without over complicating the overall task. Wes has the majority of the game plan down. It is a tower offense game with penguins. There will also be special loot and units that can be gained along the way. I think that it will be an interesting game because I don't think there are many games like it.

Week 7 blog. Last day of class.

This week is the last week of class. So we had to show off our games. I saw many good games presented by other groups and got feedback on my groups level. Our level wasn't too bad, but a large setback with udk problems one of our members had caused us to fall a bit behind. As well there wasn't always a lot of time to work on it. But for the most part I like how the level went.

The last part I went over when working on the level was making guns and sounds. The guns were pretty simple, and the code was pretty general. But I found that my gun was not designed to the game like I had thought it was. The ammo it could hold was low, and the enemy was numerous. Because I wasn't as sure of how many people we were going to fight or the pickups that would be available, we had to make a shortcut that would give you infinite ammo. I had considered the idea of the weapon having infinite bullets seeing as to how it was a energy weapon, but I wasn't sure of how to code for that in script.

As for the sounds, They were all set up correctly, and I believe they were working. But when we presented the level the sounds seemed to have disappeared. I wasn't able to test the sound before hand to tell if the different way I did it would work. The way I did it was to copy the UTPawnSoundGroup files and rename them to our custom game. Then I installed them in the custom game, which may not understand that it is suppose to use the custom sounds from there.

Me and my group are hoping to get more work done on it and polish it up a bit. But with other finals and stuff like that, I'm not sure if we will get around to that.

Week 6 Blog.

This week we went over adding new guns, vehicles, and packaging. For the most part everything went pretty well. I ran into a few problems when working on everything. It turns out that most of the time importing things into unreal makes them have a rotation of -90 in yaw. By setting it to 0 I was able to make the gun face forward and the car drive forward.  My car also had a problem with some of its tires going backward and wobbling. I fixed this by setting inverse wheel rotation in the anim tree for the car, and adjusting the bones for the tires to stop the wobbling.

After those were done, all that was left was to package everything. I had a few problems where I had to go through the maps and reset the names of the maps to things that wouldn't cause problems. They can't have spaces or they will brake during cooking. As well, I needed to have the prefix to make it so that the maps would use my custom game type. After all that was set it packaged fine.

Week 5 blog. Work with a camera.

Today i finished some of the coding things we had to do for the class ilab. It was for the most part pretty easy, but the sound part was the most time consuming of all of it. Though the final outcome of the sounds in game were pretty nice, so I guess it's not that bad. Another of the tasks I had to do was make a custom camera. I always liked isomorphic style games, so I wanted to make mine with that view type. The code online gave me a pretty nice one, though I had to adjust the pitch angle a bit.

I had to customize the code a bit, so I was thinking about what could be improved. While moving around I noticed the camera didn't stay behind you, which is often a problem in a game with shooting. This would have made it impossible to work with a gun, so to fix it I had to change the code to rotate the camera around the character. It was a pretty simple fix by using sin and cos to get the new x and y location for the camera based on the characters yaw rotation.

The code looked like this at the end:
//The "Rotation" is the player's.
out_CamLoc.X -= Cos(Rotation.Yaw * UnrRotToRad) * CamOffsetDistance;
out_CamLoc.Y -= Sin(Rotation.Yaw * UnrRotToRad) * CamOffsetDistance;
out_CamLoc.Z += Sin(IsoCamAngle * UnrRotToRad) * CamOffsetDistance;

//I also adjusted the camera yaw so that it would keep an eye on the player.

out_CamRot.Yaw = Rotation.Yaw;

/*This part of the code was just a little bit of something I found interesting. When turning with the mouse or a little with the left and right button, this would make the camera tilt in the direction you were turning.*/

out_CamRot.Roll = Rotation.Roll * 2;

There was also a small bug that I needed to fix. When I was playing with the camera I feigned and found that getting back up broke the character. I fixed this by making "var UTPlayerController UTPC;" declared at the top and writing in the code:

if (!bFeigningDeath) //bool if not feigning   {
     UTPC.SetBehindView(true); //reset to behindview. feign resets to FPS view when in behindview.   }

After fixing up those few things I found the camera pretty well set up and ready to go. But then the obvious came to mind about what happens when a camera so far away is blocked.

After doing some searching I found that there is a trace function that will check if there's any collision with anything between the camera and player.

//If you search for trace function in unreal, you will find out what these parameters mean.
if ((Trace(HitLocation, HitNormal, out_CamLoc, Location, false, vect(0,0,0), )) != none)
   {
     out_CamLoc = HitLocation; //this sets the camera to where the collision happened.
     out_CamLoc.Z = 100; //this was just to keep the camera at a head level height when against a wall.
   }

Fourth week's blog.

This week we covered more interesting things. I wasn't too into the 3D work, but now it's heading back to the 2D programming. Now I just have to worry about the whole new set of syntaxes and other things that the new code language has.
The problem with 3D work in this lab was pretty big with level streaming and cameras. It was almost impossible to keep the camera from no clipping through walls, so I had to keep it nearer to the player. As well, when the character dies the actor freaks out, so I had to deal with that by adding a special camera setup for it. It worked out pretty nicely I think.
But I think what took the most time, was the level streaming. In a map that is well planned out it would have been a piece of cake; too bad I had a week and only 2 levels to use. I ended up having to mostly put the shell back together on the persistent level to keep from having graphic glitches and to keep from noticeable objects missing. If the building had more stuff in it, I would have felt more like I accomplished something. It may not have saved much space from the map to the buildings side, but at least I know the building to the map saved space.

Third weeks blog post.

This week we had to work with terrains. I remember working with them before so texturing and height mapping them was pretty easy. But then we also worked on particle effects and skyboxes. Skyboxes are always hard to deal with because the player can get to the edge of the map or see into the void if the sky isn't connected to land. But I came up with a pretty simple and fast solution. Seeing as to how we don't have to make anything fancy, I decided that cliffs would make it easy to hide the void from the player. So the player enters into a medium amount of land surrounded by cliffs. This makes it much easier to work with the boundaries of the map.

In a normal map that couldn't use such a simple blocking plan, I would have to have the land stop the player before coming to close to the edge. It could be done with a bunch of bushes and trees, as well as some other unnatural building. Some fog and foliage would help to hide the back walls of the skybox as well. No doubt things like this will have to be dealt with in the course project seeing as to how it's outside.

As for particle effect work, I didn't remember any work with them if I have done any. They seemed pretty simple and fast to make. But they add a lot to the game. I wish I could put lots and lots of effects in the maps because they do a very good job of making realistic map effects. But that would likely slow down gameplay. Which reminds me that I may not have been the easiest with the amount of stuff in my map. I fear I would have a harder time feeling the effects of the particles and graphics because my computer is so powerful. I know the effects of these kinds of computer differences from moving games that worked fine to the school computers to find that they are unbearably slow.

One problem I ran into when working on my rain particle effect, was that the lifetime I had given it caused it to have a odd delay. I guess it was the effect of the rain falling to the point that the particle max would be reached and the rain would wait for deleting to respawn. I had to fix it by lowering the lifetime, which worked pretty well and made the particles have no delay when respawning.

Second weeks blog post.

This week I worked on my level. I added Interp actors and coded a win/loss condition for my game. The interp actors worked pretty good after I got them set up with matinee. I used kismet to get the doors to open when shot at with a plasma gun. For the door to work forward and back I had to create a bool that would tell it when it should reverse and when it should play forward.

For the win/loss condition, I had to set up a time amount to get the items required and get back. It took a little bit to come up with a good number to deal with getting the items and fighting the bots. But I came up with 40 seconds as a good time. For the items and win condition part I set up a integer comparison. When someone triggers a trigger it will add to the total amount of items they have. Then if they get back to the car in time and have 2/2 items, they win. Now and then I've seen it glitch and not let you win, but I had a hard time narrowing the reason because it's on and off. It should be fixed now though, it might have been the trigger was set to only trigger once.

First week blog post.

Work on the course project went fine. My other group members and I have come up with an RTS game. We've also been working ahead a bit to get resources to use on our map.

As for work on my lab project, it is coming along. I have the house I decided to make pretty much together, I just have to worry about what I'll be putting into it exactly. The custom meshes and characters will no doubt take some time, as well as adding materials to the house. As well, the dimensions I had planned were a little bit more inaccurate than I expected. In my plan and in the game seem to be two very different things. But so far things are coming along.

I also have to try to come up with what the true goal and win loss of the map will be. So far my idea is that you have to get some items and leave before time is up.

First Blog.

I'm starting up my first blog today. I'm still not sure what exactly goes into blogs, but I'm sure it will come along.
My first blogs will be about my working on programming projects for school. While I haven't gotten much under my belt to talk about yet, I should find more soon enough.