Blog Post #5

“Chill Week”

Since the beta presentation, I have felt a huge relief both for the better and the worse. The current version of the project is on my laptop which I sadly don’t have in reach right now so there will be no pictures in this one, but will edit the post once I get the chance and add one.

I feel like the game is almost done, all that is left is some minor bug fixes, animations and a complete pause menu and therefore I have taken this week just to relax and do things in my own stress-free pase. I feel like this was a good decision so I have now gathered all my powers needed to finish the game over the weekend and next week before the official presentation.

Things I’ve done:

• Implementing all animations
• Bug fixes (Including re-scripting unwanted NPC behavior)

Animations

The animations that were left to implemented were: Player shooting animation, player walking animation and boss animations.

I added Boolean conditions in the animator attached to the game object that should animate, and depending on what key is pressed – the Boolean for the wanted animation is set to true or false.

Implementing the animations for the player was very easy. Depending on what key is pressed, the player sprite will animate fittingly. In this case – WASD will trigger a walking animation while any of these keys are held down, and the left mouse button will trigger a shooting animation.

The boss was more of a challenge. It needed to have an indicator that its about to charge followed by a charging animation followed by a still sprite when it’s rushing towards the player. This required three different animations that are perfectly timed in order for the sequence to be executed in a fair and good looking way. So basically a lot of enumerators and Booleans were used to achieve this. I believe there are better ways to do it but whatever that technique is that is something I have yet to learn.

Charging indicator -> Casting charge attack -> Charging

Bug fixes

I fixed a bug where the player object slowly floats around when no keys are held down. What I did was to add a higher mass to the player objects rigidbody, making it heavier.

I fixed the fly enemy. It was a total disaster during the beta presentation and that is something I was truly ashamed of. It’s activation trigger was unstable, only making the flies sprite visible sometimes. This was fixed by activating/disabling the game object instead. I have no clue why I didn’t do that from the start since that’s what I did to many other objects in the game. Then it flied uncontrollably sometimes, making it completely impossible to kill. That was fixed by lowering the range of the fly, always keeping it closer the player and also adding colliders on the sides of the level which prevents it from exiting the screen and the players range.

I will give it all from now on until Thursday. I feel like we are in a really good position right now and I believe our finished game is going to be super awesome-amazing. xoxo ❤

 

Blog Post #4

What have I done?

Since last blog post, my team have been focusing entirely on getting the game ready for the beta presentation next Monday. This is what I’ve done to fulfill my part:

• Finished Boss Mechanics
• A third enemy with its own unique behavior
• Power-Up

How and why did I do the things mentioned in the list above?

Finished Boss Mechanics

The boss and the third enemy was definitely the toughest things to code this week. AI needs to be very polished for the player to feel both fairly treated and for him/her to have a sense of fun while encountering it. The boss has three abilities so far.

• A charging attack that targets the player and rushes rapidly towards it.
• A projectile attack that fires three fast projectiles in unpredictable directions.
• If the charging attack misses the player, the boss charges into the arena wall which causes an earthquake. This will make random eggs scattered on the sides of the arena hatch and therefore spawn additional enemies.

The charging attack is quite straight forward, it rushes in a fixed velocity and direction where the player is at. The projectile is also simple, the boss has three spawn points in its front which instantiates projectiles while it is in the idle state (often after a charge). Each time the boss enters this idle state, the numbers for in what direction the projectiles launches in will be slightly different. If the boss misses the player with its charge, it will proceed to collide with the boundaries of the arena. If it does so, the camera will shake intensively. There are currently four eggs that will hatch one at a time in a random order if this occurs and when they hatch, they instantiate an additional enemy.

A third enemy with its own unique behavior

We decided the third enemy to be a flying type. In this case, it is a fly that kind of behaves like a real fly. It flies around unpredictably with its only purpose is to be distracting. If the player don’t manage to kill it right away, it might reappear soon from any angle. Each time it enters the screen and manages to get close enough to the player, it will launch a projectile towards the player but the direction may vary. I implemented many layers of different ranges to it in order to achieve this behavior. For an example: If it is 100pixels away from the player, it will attempt to dash back towards the player, if this thrust manages to reach within 30pixels of the player, it will start doing a zig-zag movement between 30&4o from the player until a timer tells it to fly away again to repeat this behavior. While the fly is absent from the screen area, it will circulate around the player where it cant be seen until it thrusts towards the player again which results in the unpredictable attack angle I mentioned.

Power-Up

We have an energy bar in our game which represents both the players HP and also the players ammunition. The player will be able to gather crystal shards while playing and if the player manages to gather enough to reach 10 energy, the player will enter a power up state until the player goes below 10 energy again. While in the powered up state, the player sprite will evolve into one with more glowish details to indicate that the player is powered up and also an option to fire a cone attack in front of the player when pressing the right mouse button.

That is all for now. Never stop rocking ❤

Blog Post #3

What have I done?

This week has been a bit less productive than the previous ones. I’ve been pretty busy with complementing my old incomplete courses so have put more effort on that.

Summarization of what I’ve done this week:

•  Enemy/player hit feedback
• Started on boss mechanics
• Player UI

How and why did I do that? (Described in the same order as in the list above)

We got some feedback from the alpha presentation regarding the feedback of things getting hit since apparently (and obviously) the bullets just disappearing when they hit something wasn’t enough. I therefore made a flash script that makes the object that is hit blink once in a desired color on impact with anything of an user-specified tag to resolve this issue.

I coded a base for the bosses mechanics and implemented it in a way so that it specifically reacts to it’s current position in an arena that an artist also created this week. It currently just chases the player and occasionally charges in a faster fixed velocity/direction towards the player to add a bit more challenge. I have planned to make the boss shoot projectiles, and also be able to collide with eggs that will hatch smaller enemies. These eggs will be randomly spawned and regenerated across the arena area. The reason for why I’m eager to work on the boss is because of the fact that we don’t currently have a win condition. When the boss dies, the game ends and the player wins which covers this.

One of my graphics artists created an “energy/resource” bar that I put a mask over in order to give the player a more clear idea of how much health is left before death. The resource bar also comes with a numeric value on the side of it that tells the player more precisely how much health there is left. This was also highly prioritized this week because of the feedback critique we got during the presentation, it is very clear now how life is handled and I hope that people playtesting our game in the future will understand that.

That is all for now. Rock on. xoxo ❤

“5sd06” Everything is falling together #2

Blog Post #2

My last blog post was a bit messy, so I’ll make sure to structure it better this time.

Summarization of what I’ve done:

These are the following things that I’ve since the last blog  post.

• Learned about and implemented particle systems
• Added a main menu
• Added a pause menu
• Added a death menu
• Restructured the folder hierarchy with my project manager.
• Re-scripted the perspective camera.
• Re-scripted all Game Objects & added configurable properties for them in the inspector.

Those are the major features that I have added then there’s a whole bunch of other things that I wont bring up.

How and why did I do what is mentioned above?

I suddenly felt an urge to add more “appeal” to our game since it looked kind of boring. Particle systems were quite simple. You basically just add the component from the scene-hierarchy and from there you can simply do anything. Change sprite that is being emitted, change how it is being emitted, change speed, gravity.. ANYTHING.

During the alpha play-testing, some people complained about the fact that you couldn’t pause. The only way to restart the game or pause was by using Unity’s built in play and pause buttons. So at the next testing session we want to be able to build the game and play it in full screen, therefore we will need menus so that were able to restart, pause or exit without having to be in the unity editor. This was fairly simple to implement. What I did was to add a game object that has a canvas as children, which in order has panel as children that has the buttons as children.

PauseMenu -> PauseCanvas -> PausePanel -> Buttons

When they all inherit each other in this way, I can easily move it around on the screen and set the game object active or not depending on what button is pressed or if something is triggered. This menu setup was used to create the main menu, pause menu and death menu.

I’ve mostly been working by myself inside of unity so far. But now that were getting further and people are using my objects to design their own levels, we needed some restructuring so that everyone can easily navigate. I don’t have much more to say about it since everyone probably knows how to create folders.

The perspective camera has been a big problem for me. I use a perspective camera in order for different textured layers offset to differentiate from each other That results in a cool, attractive depth if you’re using several backgrounds or whatever. This technique also known as a Parallax.  Implementing this resulted in a bunch of problems with all Game Objects I had in the project so far. It took a day of pure agony to make it work, while scripting the camera I also took the opportunity to move the player character a bit more lower on the screen instead of in the middle. It didn’t feel right to have the player character in the middle, the field of view were too compressed.

As I mentioned above, I added public properties for every single variable that made sense to have a public variable for. So now everyone can drag in game objects and change their properties so that they can design their own levels.

That’s it for now! 🙂 xoxo

 

“5sd06” successes and setbacks #1

My first blog post.

I haven’t made any blog posts for the last three weeks of the course since I haven’t been aware of the fact that all group members had to do it. (For Reasons, don’t judge) I’ll try to summarize what I did during that time on this post as well as what I done this week(Week 3).

Alright.

The first week was messy, mostly because of the fact that I wasn’t just the only programmer of our group, but I also overrated my ability to program in C#. Programming in Unity requires more than just general C# knowledge because of the fact that it comes it’s own built in library that features tons of truly necessary functions that the user needs to have knowledge of in order to be effective.

By the time that I came to realization after the first week, I decided to scrap all my work so far to start over from the beginning. Note that I did all that first weeks work, twice as good in a couple of hours this time when I had gripped the right general understanding of how unity works.

So to summarize the first week; All my work was in “vain” but I learned an important lesson.

And to summarize week 2; I spent two nights to go through the whole Unity 2D reference section, and went through a number of tutorials to get a grip of what I was messing with. This led to some awesome smooth progress with flexible mechanics that will work as a foundation for the future implementations of the game.

Now were all caught up with the current time.

Week 3: As i become a better programmer for each day that goes, i’ve been focusing on polishing and refactoring my previous work so that the looks of it represents my current level of programming and implementation. The final boss has been the goal for me this week and that is also mostly done and the overhanging mechanic of the game that lets the player exchange health for ammo, and to be able to surge power(health) from other enemies is done. So now that the game is completable (playable) I will be focusing on animations, polishing, and implementing new mechanics and power ups beyond the concept document. We have plenty of time left for the project deadline so i’m feeling very relaxed and feel like we will really be able to out-do ourselves at this point beyond my wildest expectations that were really low during the first catastrophically aweful week.

PS: Our graphics people started hearing frequencies today which is deeply worrying. I will make an update on this topic next week, I am planning to bring tin foil hats to our next meeting in an attempt to counter the problem.

rock on