manshgames

The final week of development came with many quick changes in the groups schedule and in the projects overall layout. At this point the need to actually finish the implementation of all our assets in the game became all the more pressing as we rushed towards our deadline. Even at this point in development some last minute changes were made to our game, affecting our levels layout, mechanics within the game and overall visuals. There were two tasks that called for my attention during this time. The first one was the completion of all the animations we needed and the second one was the new task of creating the sound effects for our game. Throughout the project the topic of who was to take care of the sound effects had been somewhat unclear as we pushed the issue back on our priority list. Though not a particularly good way of scheduling tasks our reasoning behind this behavior justifies it somewhat. None of us had much prior knowledge in with developing sound effects for games or anything similar and as such none of us fitted the role better than the others. On top of that we all considered the best method with which to create our sound effects was to make use of royalty free sound-files from audio libraries on the internet. Which is exactly what i ended up doing. The problem with relying on online audio libraries is the fact that you will be entirely restricted by what exists on said library. Often times however this would produce a better result than if we ourselves tried our hand and creating the sound effects we needed by hand.

In the end we just barely had the time to implement all the assets we needed, a major factor to this being the fact that we worked throughout the night prior to GGC. This too isn’t an all that healthy practice but the group considered it necessary for the sake of having a presentable project.

We are drawing nearer to the deadline of this project, something that many times reveals whether or not one has over-scoped or stayed within realistic margins. As it turns out we have over-scoped to some degree. Something that is made apparent due to our need to cut a feature from our game, that being the pliers. This decision was pushed by the coders and then agreed upon by the rest of us. From a practical perspective the choice is a good one at this point, at least as far as I can determine. From a designer perspective the choice is not as appealing however, seeing as it removes something that was considered rather important to the games aesthetic goal. It is however important to know when to ”kill your darling” as the saying goes, to know when it is wiser to abandon what could be a good idea for the benefit of a project as a whole.

On the more animator oriented side of news, recent changes in the design of the game has resulted in the need for more animations for the orc character, the patient, than what was previously anticipated. This partially comes in the form of a new character, the orc war-boss that will act as the adviser during tutorial level in our game. Further decisions regarding what happens with the treated orcs resulted in even more animations being needed. It might appear a bit ironic that we cut off parts of the project only to add new ones but in the end it is often a question of how complex the task is rather than how many tasks one has that makes the most difference in my experience.

Another topic that has gotten increasingly prominent on my working schedule is work towards our PR endeavors. What started out as little more than one of our group members finding himself with a fun idea and a bit of spare time has resulted in an increased amount of outwards aiming material being produced for the purpose of increasing the excitement and awareness of our project for those not taking part in it. What struck me was when the realization that what we had viewed as shenanigans on our part actually was a form of commercial kicked in. This was an exciting idea which has made the gaze of some group members turn towards the possibility of dedicating further effort into making sure that our work in this area reaches an audience bigger than those within our own class. Whether or not we find the time to go thru with this endeavor is a question that is unclear as of now however.

After having tested our engines, Unity’s, IK system the results have turned out rather poorly. It would seem like there are a couple of reasons for why this is the case, most of which stem from the simple fact that Unity’s Built-in IK system is somewhat lacking. To explain the first one I will need to describe the basics of how to prepare a character in Unity for animation. As per the methods I have seen you can go about two ways. The first one is to import an fbx file containing your character with it’s mesh, rig and animations into Unity. The second option which is much more common, although I am still not quite certain why this is the case, is to import two separate fbx files. One containing the mesh and rig and another containing your animations. In the latter method you use the fbx containing your mesh and rig as a form of skeleton onto which you project your animations by way of the second fbx file.

Regardless of which of these options one picks one will then have to define the character to unity as either ”Humanoid”, ”Generic” or ”Legacy”. The first one is rather self explanatory and tells Unity that the character is of humanoid nature, meaning it’s bipedal, has two arms and a head, in other words that it follows human anatomy and proportions. This is the option that is supported by Unity’s in-built IK system. Only if you define your character as ”Humanoid” will it be possible to use their IK system. The problem is that we were unable to use the ”Humanoid” definition due to it being rather finicky and precise about what proportions it will accept and work smoothly with. Our character is humanoid in it’s anatomy but it’s proportions are a far stretch from what the average human would look like which results in Unity making some unwanted alterations and transformations in things such as animations. This left us with the option of either ”Generic” or ”Legacy” where we picked the former.

After quite a bit was spent trying to manually script a custom made solution to this problem the group decided that the best course of actions would be to simply buy a script from Unity’s web store which solved this problem for us in order to save valuable time. The solution worked quite well albeit it being a bit pricey.

An increasing amount of complications have arisen as the question of how we implement our animations into our game engine, unity, becomes more prominent. That is to say, the problem does not lie with the prospect of implementing all of the animations but rather  specific group of them. That group is the one that has our character, the goblin, interact with the tools in the game. Items such as the pliers, the stretcher and the axe are problematic due to the fact that they will have to follow the players movement while also using their own independent animations. The real problem comes into the picture when we have several layers of movement as we do with the stretcher.

As previously mentioned the stretcher will be steered by the player and as such it needs to follow his or hers movement. This wouldn’t have been a problem if the handles with which the players characters hands are attached to were stationary relative to the main body of the stretcher but per our design they will move in relation to the players movement in the left and right directions.

 

The easiest solution to this dilemma would be to use an IK (Inversed Kinematics) which, among other things, lets one lock a for an example a hand onto a specific target. If one was to place this target onto the stretchers handle this would in this case force the characters hand to stay positioned against the handle, making it ignore the animation the rest of the character is playing. In our case we might encounter problems when we try this method out however seeing as unity’s IK system is notorious for its inadequacy.

With my role in this project being the lead animator it isn’t all that surprising that most of my time has been spent with our main character and the many animations he needs for the finished game. Much of that time was spent trying to work out the various little difficulties that tends to arise when someone deals with software one is not an expert with. Seeing as our game is made with 3d assets we and mostly i get the terrific opportunity to improve my knowledge around the topic of 3d animation, an area i have previously been rather uneducated and inexperienced in.  Coming from a background of having worked with 2d animation the basic concepts and principles as to what makes an animation good are still very much the same although of course the tools, and thereby the workflow has changed quite a bit. Things such as feet skidding across the floor despite my best efforts to make them stop and a tendency of the software i am using to produce strange and unnatural stops and pauses in between my key frames are issues that have been encountered quite a bit as of late. As previously mentioned however most of this is more a result of my inexperience than anything else.

 

 

 

Specifically this week i have thus far been spending time with the animations regarding the various tools that the players of our game will be able to use such as a pair of pliers, a stretcher and an axe. Animations in this category include such things as a pick up animation for the pair of pliers, walking animations in all directions with each individual tool, animations for using the tools on the patients and so forth. When it comes to things such as walking animations for the tools a design decision needed to be made. In the name of saving valuable time one might argue that you should try to reuse your assets to as high a degree as possible, a statement that indeed is worthy of consideration. Say for an example that you want to make a walk animation where your character holds a heavy object and you just so happen to have a walk animation without it.  It would not be all that hard to use the original walk animation and simply switch position of the characters hands and add a few details to make sure that everything works. What is also worthy of consideration however is whether or not you want your characters various animations to feel unique or not. When reusing your work, especially if you do it to a high degree it is usually a good idea to think about whether or not you are getting enough variation between the individual animations. In the end i made a sort of compromise by using what animations i already had that fitted the new ones i needed to some degree and then make sure that they got their own look to them. Things like making the character pause slightly between each step to bring across the point that he’s carrying something heavy, having him lean back considerably more to stabilize himself and counter the weight from the object he carries in his arms. These are the kind of details that helps making a motion believable and readable.

Officially the Big Game Project course started a dew weeks ago but unofficially work for many students began several months ago by way of the ”Road to GGC” As it was called which presented an opportunity for students who wanted to prepare for BGP early. A lot of time in my group was spent going back and forth between various concepts, many of them seeming like they could be interesting and worthwhile one day only to look unimpressive, boring or impossible to see through to their completion due to time restrictions or lacking knowledge. Eventually however we decided on the concept of Goblin Doctors, a name that is rather telling of what the game is about and what the player does in it, namely take on the role of a goblin who is a doctor. The concept derived from an idea of a more realistic setting taking place in a hospital. However, upon deciding that the setting seemed a bit dull we changed it towards a more fantasy esk theme and aimed to go for a less serious tone.

Once the concept was decided upon we began the work of actually fleshing out what the game play should center around. Some general thoughts and goals was to make it a fast paced, light-hearted experience which players could get into without having to dedicate much time or effort, a so called ”party game”. We aimed to have the game center around a cooperation element, meaning that we wanted our players to have to work together as much as possible. As for the actual game and what the setup revolved around a general summary of it is that it is a 2 player cooperation game where the players work together in their role as goblin doctors to help and heal as many orc patients throughout a level, which we decided to make roughly fifteen minutes long. As for game play mechanics we wanted to focus on three major ones, those being the use of a stretcher with which to move the patient about, an axe to amputate damaged limbs on the patient and a pair of pliers with which to pick up and fasten a prosthesis as a replacement for said removed limbs. After some feedback from fellow students and teachers we also added a mechanic for crafting new prosthesis from resources found around the games environment.

When the process of making the game moved from a theoretical design phase to actual production i encountered some difficulties. The player character of our game had been designed and produced as a rigged mesh, meaning a 3d model with a skeleton used for animating said model, in an earlier course.

 

 

Most of previously mentioned issues were encountered when the need arose to start sharing files and keeping track of what version was the correct one between the groups members. This can result in quite a lot of trouble if not dealt with properly from the start, something we as a group did not do. This lead to asset files seemingly going missing and old, incorrect ones being used without the knowledge of the group members. When these errors were detected it most of the time became obvious that we would have to redo quite a lot of work, sometimes, in extreme cases, even to the extent of redoing some assets from the ground up.

At this point however most of those issues have been resolved. The general confusion and issues we encountered made it clear that we needed to rethink our approach to the administration of the project and its assets.

This week has been spent entirely on polishing the assets of the game. This includes doing things such as animating what’s left of the different characters states which up until now only had keyframes to act as placeholders. Polishing has also included coloring the animations. One of the assets i worked on was an animation that is to play as the protagonist of the game, captain noleg gets electrocuted. The player gets elecrtocuted when attacking a specific part of one of the games enemies, namely the jellyfish. During development and then later while letting people test the game we realized that it was somewhat unclear to the player why he suddenly took damage, resulting in the need for us to explain how the jellyfish worked. This is less than optimal since we want our game to be understandable without us guiding the player from the backseat throughout the entire ordeal. One of the measures we took to ensure that the player would have an easier time understanding the game through visual hints was to rework the jellyfish visually. We also decided that we needed a clear animation to act as visual feedback for the player to help him or her realize what was happening with the main character since we noticed that the player sometimes didn’t even realize that he or she even took any damage when hitting the jellyfish. The animation bellow is what i created in order to make it as clear as possible for the player that something, probably bad, was going on.

So yeah, it’s kind of exaggerated but when it comes to games that is to be preferred rather than not giving the player enough feedback to be able to register what is going on.

When creating this animation i worked i photoshop, as i have done with all of the animations for this project. I animate by using photoshops time line function. There i create as many frames as i deem necessary and then get straight into animation. While photoshop definitely is not a program that works well with animations or makes the process of animating easy, it is a program that has many tools and when it comes to exporting the images and using them in different formats it’s superior to many other animation softwares i have used prior to it. I then export each frame separately to then put them all together into a spritesheet using the program glueit.

 

This week, like the one before, has been dedicated to making the final animations for the main character of our game: Captain Noleg. This week i have started on several of the animations we will need for the captain, one of them being an animation of him throwing his harpoon. This animation could be seen as one of the ”core animations” on account of it being visual feedback that is triggered when performing a core mechanic of the game. Namely throwing the harpoon.

 

As the more attentive of you might see, the captain has seemingly misplaced his right arm. This is because there has been some changes made regarding how i animate the captains sprites. Previously (as seen in last weeks post) i have animated and exported the entire animation in one image. Continuing to do this would however result in a lot more work than necessary. The reason to this is that the captain will have two possible appearances so to speak. One where he ha his harpoon over his back and one where he has thrown it. Since he can swim around with or without the harpoon we would need at least two separate animations for when he had the harpoon and when he had thrown it. Unless we split the animation up that is, which is what you see above. From now on i will put the right arm (and the harpoon it’s holding) in a separate spritesheet. This animation will then be anchored to the captains and voila. No need to export every frame of animation for the captain two times.

Now regarding the animation itself. When making an attack animation (for the player character) it is important to keep in mind not to make the animation too long. If the player hits the attack button and it takes ten seconds for her character to actually attack she will be frustrated, at least in a game such as ours where the players movements is somewhat restricted in the first place and she is constantly being attacked by enemies. If that’s the case it doesn’t matter if the animation leading up to it looks good, it will still only be annoying.

Also for the first time i tried to add a bit of motion blur in order to make the transition between the most extreme arm positions smoother without removing the sense of speed and force int the throw. I’d say it turned out pretty okay.

So this week i actually worked on something else than the enemies for our game. This week was dedicated to the animation of the games protagonist himself: Captain Noleg himself

Up until this point we had only made keyframes for the captains different states. These were all we needed in order to test the game out and see if his design and color scheme would work in the background. However, at this time all the keyframes for the games different enemies and the captain himself are complete. This means it’s time to move on to polish and adjustments in order to improve upon the games current assets.

The image shown above is one of the placeholder keyframes we used up until this point. As you can see, I’ve chosen to adjust the animation from the keyframe slightly. Namely by changing the position of his right arm. A core mechanic in our game is throwing a harpoon. For this reason i decided to adjust his arm so that he would constantly be holding the harpoon, ready to throw it. This is an improved design for two reasons in my opinion. Firstly: He looks much more trigger happy and prepared for any threat that might appear. And in a game where you will run into enemies non stop this feels like an appropriate stance. The second reason is that it simply makes the transition between the swimming and throwing the harpoon much smoother. This makes a lot of difference since we cant have the animation of the captain throwing the harpoon take up too much time and having the captains hand move from his hip to his back takes much more time than simply having him hold it from the start.

Now onto the walkthrough of the process. Though the process in itself isn’t that complicated, i fear i might fail to explain it in simple terms. But here goes: The program i used for this animation is photoshop. When i started working on the full animation i began by copying one of these keyframes into a new file. After that i set the layer containing the keyframe to a low opacity, around 30%. I then created a new layer and started drawingthe lineart over the keyframe, changing and adjusting things in order to improve on the previous design. Some changes weren’t improvements in a visual sense however, but rather improvements in the practical sense. For an example to change the placement of the harpoon and the rope attached to it so that it disappears behind him rather than having it show on his hip. Changes like these are simply time savers. After redesigning it and creating the first new frame i created a new layer and using photoshops timeline function i added a new frame. On this frame i drew the pose that would be furthest away from the first one. To explain what i mean i’ll use an example. Say for an instance that i move my hand left and then right in a pattern. The first frame i created could then be when my hand is furthest to the left and the second would be when my hand is the furthest to the right (or vice versa). I can now flip between these to poses and see the frame of movement within which i can work. After that i ”simply” redrew every new frame in between the first two frames. After doing this i created new layers for each frame and filled in the line art with color. One thing to consider and remember when working with animation (or anything art related when working digitally) is to use more than one layer. Whenever i want something to overlap in animation, i draw them in separate layers. This way you can easily erase and make changes as you go along.

Excuse me if the explanation was overly complicated.

This week we focused on adding the last features we deemed worthwhile into the game before our feature freeze. In my case that meant, again, more enemies. This week iv’e focused on two in particular. The seagull and the angler fish. Of these two, the seagull is quite uninteresting from a graphical view since it will only contain three frames of animation. Let us therefor instead take a look at the angler fish as shown bellow.

 

 

Like most other enemies the angler fish will need three animations for it’s idle swim, it’s attack and death. In the final game the angler fish will be the only enemy that appears from behind the player. On account of this, i thought it appropriate to aim for it to look as threatening as possible. As those who have seen a real life angler fish will know, you don’t really have to change much in form of the appearance from the real life specimen if you want it to look scare since it’s not exactly a pretty fish to begin with.

One thing that i had in my mind during the process of adding color and shades to this enemy was the effect shadows can have to make a character look more menacing. I’ve experimented slightly with this idea as i started shading and coloring the different enemies and realized that it actually does make quite a difference (what a surprise).

While on the subject of color, something i wondered while choosing the colors for the angler fish was if i wanted it to be clearly visible, or blend into the background. When designing enemies and different aspects that the player will need to interact with you usually want to make them pop out from the background and attract the attention of the player. However with this enemy i wondered if maybe doing the opposite would be more fitting and make for more interesting game play. This depends very much on how you want the enemy in question to be perceived. For an example, if i want it to appear more insidious and cunning, it might be a good idea to give it a color scheme that works more as a camouflage. However in the end i figured i’d stick with the norm and make it more visible against the background and maybe give it a more feral look by going heavy with red colors.

Now i just need to fully animate all of it.