Tale – Big Game Project

Hello! For the last three weeks I have been working on a Third person action adventure game called Tale for the course Big Game Project. This is the first time im working with Unity 5 3D and it has been a challenge! I have had to learn some new math and a lot of Unity’s 3d syntax.

During these three weeks  I have been working on a couple of features:

• The character controller – Movement
• Bow Aiming and Shooting
• The Camera

The hardest task I had was the Camera. The camera of the game has to show all of the action on screen without annoying or disturbing the player at all, if the camera is good the player wont notice it. The camera we had decided on for Tale feature three major behaviors:

The first one was a standard third person camera that follows the player and rotates with her as she moves while staying at a certain distance. For this I chose to use a pivot that the camera rotates and moves around and with a pivot that is bound to the player.

Example of the standard camera

 

The second camera behavior we needed was a camera that would flick back to the player if the player starts moving, it has to smoothly move behind the player. By using a timer and a smoothing function the camera smooths to the wanted angle over time.

Auto Follow Camera

 

The final camera mode I worked on was the bows aim camera. When the player wants to fire and arrow the camera zooms in behind the players shoulder at a specified point to help the player shoot

Aiming Camera

Team 12 Report 6 – The Finishing Touches

Hello everybody! It is finally time for the last blog post for this course! A lot of time has passed and I feel like have developed a huge amount during this course and it is a really fun thing to see!

Anyway let’s talk about the game and how it turned out and what I have been working on this week. This week we in the group decided to put in all of the effort so we would be finished with 1 spare week for emergency changes if it would be needed, there has been a lot of optimization, polishing and just a lot of small things that we have added!

The major feature I added this week was the web obstacle! The web obstacle is a obstacle that is stationary which the player can collide with! The player has the option to dodge below or above the web, he or she also has the option to dash through the web, thereby destroying the web in the process. The web is one of the few stationary objects that can be destroyed by the player. This is its main feature, it gives the player choice if he or she wants to dodge or go right through. The fits well into the game considering there is a spider enemy so it fits aesthetically into the game!
The cobweb obstacle works like most features and was pretty easy to implement, the only hard part was to make it so that the player could dash through it, thereby changing the sprite into a ruined version of the cobweb.

So besides all that I have been working on a function inside our AnimatedSprite manager, this function would get the current frame playing inside of an animation. So for example, we have an animation with 10 frames, and after 10 frames you want the sprite to disappear and stop repeating itself. This function was mainly created by that need. In our game we have ice stalactites that fall from the ceiling and if they hit the floor or the player they shatter. When they shatter they play that animation but it should only play once, that is the main reason I created this function. In all honesty the function was quite easy to make, it just check inside of the frame vector which frame it is currently on and returns it as a number! Even though it was not a difficult challenge to make it is a very good function to have and gives the animateSprite manager more flexibility and gives us as programmers more options and control.

So the final thing I worked on this week was the spider. The spider has been a real pain in the ass top get right but I think I finally managed to make it work as intended. Now you can dash through the web string holding up the spider in order to kill it. Once the string is destroyed the spider falls. I also made it so that the spider ”dangles” up and down to give it a more natural feel.

That is about it! The next week will be dedicated to optimization and project report writing! Thanks for reading and have a good one.

Here, have the AnimatedSprite function!    int AnimatedSprite::GetAnimationFrame()
{
return m_frame;
}

Very difficult isnt it? 😉
See you next week.

Team 12 Report 5 – Beta Polishing & Problems.

Hello everybody! This week has been a tough one filled with hours upon hours of work for us! The beta presentation has always been like a shining light at the end of the tunnel for us and we really wanted something nice to show during the presentation. Unfortunately this week has also been plagued by a lot of problems and communication errors between the programmers and the graphics artists. But problems aside this week has been very productive and we have gotten a lot of artifacts and features completed and polish.

This week is quite hard to describe by only talking about one artifact or feature so I will go through some of the things I have been working on for the beta presentation.

So first off I have been working on the spiders movement and finishing it up. It now hangs in the ceiling and dangles up and down when time passes. This was done by just having a speed variable that can be positive and negative, so when it is positive it goes down and when it is negative it goes up! I also tried to make it more menacing by making it so that the spider would leap towards the player when he or she was close to it. This feature was scrapped because it did not fit the game and it made the spider way to hard to dodge.

The second thing I worked on this week was the troublesome geysers. This artifact is the one that I disliked the most in the entire game. So my task was really to make the geyser a fun and challenging obstacle for the player. The geyser is a ground based obstacle and acts like you would think that a  real geyser would work. It has an internal timer that makes it change animation into an attacking animation. The geyser attacks with a beam of hot water that sprouts out of the ground towards the player. The real challenge here was to make it so that the geyser would only be dangerous towards the player when it’s attack was active. This was a challenge since I had to time the hitbox for the geyser with its animation. The end result was that the geyser too was way to strong of an obstacle.

Other than that I worked on level design, fixing the sonarbeam, tweaking the speedpowerup. This week has been a challenge but it has all been worth it considering that now we almost have a completed game!

std::cout << ”kim” ” ” ” Out!” << std::endl;

Team 12 report 4 – Angular object placement

Hello everybody! This week has been quite rough and the task I was presented with was a real challenge. This week I tackled object placement in our 2D sidescroller. The objects in our game should be placed dynamically to fit into the levels we create. The levels will not only be on a horizontal axis, they will angle down and up to create a better gameplay experience. This was a very challenging task and down below I will describe what I have made, how I made it and why I made it.

Why our game needed a dynamic object placement: The game will as above stated feature angled backgrounds and segments that will go up and down. To get all of the objects placed in a good fashion without ”hardcoding” their placement a system will be needed to find out where the objects should be placed within the level.

So what is this that I have made? I made this system that reads the backgrounds orientation, placement and angle in order to place out the objects and obstacles in our game in the right X and Y coordinates.

Here is the interesting part and where most of the blogs content will be. How I made the system and how it works on a more technical level. I will try to describe it as down to earth as I can but it is not a simple system and to be honest I don not understand it myself 100%, I just know in theory how it works.

The backgrounds are the key to this system. Marwan Al Salman in my group made the background change their position and angel using the law of cosinus. This made it so that the backgrounds where placed ontop of each other while overlapping to create a fluent level.

The system I made was an extension to his system and builds ontop of his code. What it does is that it has functions that gets the backgrounds angels from the backgrounds while also taking the top left position of the background. When the functions have taken these variables I place out the objects on the top left corner of the backgrounds, after that I get the angel from the background and use it in a function which uses the law of cosinus to calculate how much the X and Y values of the objects are going to change. In practice this creates a line where all of the objects spawn.

If my explanation of the object placement system was unclear I hope this awsome paint picture can do some talking and give a visual representation of how it works.

Team 12 Report 3 – Including animations and implementing it into our engine.

Hello! This week I will go through what I have been working on for this week. This week my task was to implement an old Animation skeleton from the SDL library to our new engine that is SFML based. This task proved itself to be a very hard challenge, my initial prediction of the time it would take was around 20 hours but that was a way to positive and naive prediction.

What I have made: I have converted the old SDL Animation skeleton to our new SFML based engine. This is so that we will have an easy to use way to implement animations and it will give us a great deal of flexibility and control over the animations. With this new skeleton we would only have to write a minimal amount of code to be able to use animations and it would mostly be filed based.

Why I chose to pick the animation implementation: I chose to start working on the animation skeleton since I wanted to challenge myself and see how much I could to in c++ and SFML. The reasons are more personal than optimal since I am not the best programmer in my group. Another reason I wanted to work on the animation skeleton was because I have worked a lot of programming game mechanics but not as much on the engine based things inside of our game. This lead me to be a bit afraid of falling behind on the more technical aspects of programming and I wanted this as a learning challenge.

How I made and implemented the animation skeleton: In order for me to explain how I made the animation skeleton I will need to explain the very basic foundation of how it works.
An animation works by taking multiple pictures and playing them one after another in rapid succession. To do this you need to do a couple of things. The first thing you need to to is to load a sprite sheet into the program, a sprite sheet is a picture with multiple sprites in it. for example a walking animation can contain 5 pictures and a sprite sheet with all of them in it would be a walking animation sprite sheet. The second thing you need to do is assign which parts of the sheet should be what picture, you need to put them in order so that they are played one by one after another. In order to play them one after another you need a timer that keeps track of which  picture you are on

.picture of a sprite sheet.

All of these things that were needed were inside of the old SDL engine and my main task was to convert SDL based functions into SFML based functions that would work in our new engine.

A lot more could be said about this topic but I feel like that would go way to deep into the programming lingo. Overall this was a very difficult challenge for me and as for the time when im writing this the animation skeleton is about 80% done.
Thanks for reading!

Team 12 Game Development Report 2 – Sonar projectile

In this weeks development report I will go through the creation of the sonar beam artifact, its purposes in the game and how I made it in c++ with visual studio.

What the sonar beam is: The sonar beam is teams 12 games only projectile. It is a projectile which will travel from the player through out the screen, clearing and destroying all of the enemies present on the current screen. The sonar wave will be what is called a ”smart bomb”, a screen clearer. It will act like a power up in the sense that it is available at all times.

Why I made the sonar beam: In order to finish the design course and pass the assignment each game was required to have a projectile in the game. At first we did not have a projectile in our game and we had some troubles deciding on how we would implement the projectile. We ended up with the sonar beam because of these reasons:

1. The game play will be quick and action packed and the player will be put into hard situations, having a screen clearing bomb will help players get some breathing room.

2. We discussed having a normal projectile that would be able to kill some enemies and destroy some obstacles but after some discussion we came to the conclusion that the player might have a hard time navigating the environment and shoot and tackle obstacles with precision at the same time.

3. The last and final reason would be that we wanted simple and easy controls and adding a fire button that the player would constantly use would be distracting.

How I made the sonar beam: I made the sonar beam using timers and distance measuring. The sonar beam will get the position of the player and when the player is pressing the fire key a sonar beam will be created. The sonar beam will grow in size as it travels away from the player by increasing the scale of the sprite.
The second the wave starts traveling a clock starts ticking inside of the sonar beam. The beam will grow in size and be visible until the clock has reached 3 seconds. After 3 seconds it will be invisible and another timer will start. This timer is the cool down timer that makes it so that the player will not be able to shoot multiple waves in a short time frame. The sonar beam attack will be used as a power up and therefore it should not be something that you can use all the time.
When the sonar beam collidies with obstacles and enemies they will be destroyed.

This is one of the main features I made this week.

Team 12 Game Development Report 1 – Traps and mechanics

What I made: This week my big focus was on making traps and obstacles for the player to dodge.

The spider: The spider trap is a trap that will be somewhat hidden for the player and once the player is within striking range. Once the player is within striking range the spider will lunge downwards towards the player, the spider will charge downwards really quickly and once the spider has completed its charging cycle it will slowly reel back in to its original position and resetting its attack.
The spiders speed and and trigger distance is directly related to the players speed. This is so that the trap will not become obsolete if the player is traveling really quickly or really slowly.

How I made the spider: I made the spider in Visual studio in c++. It has several functions that are dependent on the players properties, I did by linking the players values to the spider so that the spider can read the players values.
The spider measures the players speed and distance and triggers once the values are optimal. Once it triggers an internal timer inside of the spider starts that decides how long the spider will charge. The timer starts at 0 and counts up to 9 seconds, the spider charges for 3 seconds and the reels back up for  6 seconds, once the 9 seconds has passed the spiders internal clock will reset and it will go back to 0 so that the cycle repeats.

Why I chose to implement the spider: I chose to implement the spider into the prototype because it is a trap that would be more interesting than just normal falling traps. Before I started to work on the spider I had made a falling stalactite and the choice was between the stalactite and another enemy and I made the decision to make the spider.
Why we wanted to have a spider inspired enemy inside the game: The team wanted a spider themed enemy because it would match the aesthetic style in the game. A lot of power ups are based on fireflies and a fireflies natural enemy is a spider. From a coding perspective I chose it because it would be an interesting challenge to have make an enemy that would have a charging attack and timer implemented into its trigger mechanics.

The end result with the spider was an enemy that was somewhat scary looking with and unpredictable behavior

.

The third week of game programming

This week we have started studying object oriented programming. We started with classes. Classes are a way to group together different methods to create independent objects that work together to make beautiful things happen.

This week was not quite as hard as the former week. That however doesn’t mean it was even close to easy. I spent a lot of time on the different assignments we were handed and I finally completed most of the second week and I have now slowly started with week 3. It’s quite hard but I am picking up all of the information quite rapidly I feel like.

This week has been very straightforward and I don’t feel like there is a lot to comment about!
See you next week!

The second week of programming, also known as hell.

So going on into the second week I felt very confident, I had picked up all of the required material and I had a good grasp of everything we had gone through during the lectures. I felt like that week was maybe a 5/10 on a difficulty scale, doable but hard.

Now that the second week is done I can confrim that we have now started going with a speed very close to the one of light. This week we went through this:

Functions – a function that does something, for example an addition function would add togheter 3 nubmers of the users input

Arrays and multidimensional arrays – these boys store more than one variable.

Strings – This is just text.

Pointers and refrences – how to accses forgotten variables and how to forget ones that exsists.

This week has been very hard because of all of the information we have gotten and all of the very hard assingments we had to do. As someone who has never programmed before this was very challenging, my peers also seemed to have trouble with some of the assingments.

PONG.

During the lectures we also made pong. I probably understod about 15% of everything we went through. This was a real jump in knowledge and I can not in my mind understand how someone would be able to do this in 2 weeks. We have had 2 days to learn how to make inputs, collision checking, drawing boxes.

This week was incredibly hard but I feel like im still hanging on. I feel like I could handle a bit of a quicker phase but I would not enjoy it.

First week of programming

So the first week of the programming course has gone by. This week we have gone though the very basics of c++.

I went into the course with little to zero knowledge of programming at all. At first it was very intimidating but after putting some work into the different assignments we got handed out I now feel very capable of writing simple code.

I think now I can make a simple calculator.

Here are some screenshots of the code for the assignments. I feel like during the different tasks I learned a lot and it was really fun to code actually.

In these pictures you can see how much I learned during this week, the first task was very simple and the last one was more advanced.