Post mortem: Team Bugbear Umibozu

My previous posts have been detailing the design and production process of a game me and a couple of fellow students have been producing for a course in game design. Now the project is over and it is time to reflect on the experience.

In the end I think most of me group are feeling a bit disappointed with the end result. We ended up having to cut a bunch of features due to time pressure, whilst also having to hastily add features as the deadline got closer and closer. What we ended up with was a game with the the basic components we set out to add, but without much else. Features like a second enemy type, a boss fight, or a story told by the level design, were things we wanted to add but didn’t have time to.

Screenshot of the start of our game

Most of the problems we had could be attributed to inexperience. Starting out we had a concept document which was written by someone else. Instead of sitting down and creating our own more detailed version of that document we went into production quickly using the already made concept document. This meant that we had to make up design decisions on the spot, and when we didn’t write these decisions down it created confusion later when two different people said that it was supposed to work in two different ways. This would’ve been solved by having a master document where all the design decisions were documented, instead of wasting time arguing about what we decided last week.

We also had a hard time adapting to feedback we got during or playtesting sessions. I talked a out in my previous blog post if you want to read about it, but to sum it up: The testers didn’t understand how to play the game, and instead of making changes to address that, we assumed that it would all make sense to them when we fleshed out the game a bit more and improved the tutorial. This lead to the game stagnating due to the basic mechanics and gameplay being flawed. If we addressed it earlier we would have been able make our game play better and more intuitively.

These problems, combined with a lack of time due to all of us having other lectures and assignments, meant that in the end we only managed to build a game with a the basic components. The goal is to go from point A to B without getting sunk by sharks attacking you, if they reach you they slam into your boat and deal damage to you. The sharks are covered in a cloud of mist. There are also items that are covered in the same clouds as the sharks. To tell them apart you have to the spotlight attached to your boat to shine a light on the cloud, revealing what is hiding inside.

As for what I’ve learned personally this project has been pretty beneficial. The things mentioned above are great to have experienced because now I know how important proper planning and listening to your testers are. This project also gave me the opportunity to put some things I’ve learned into practice, the biggest has been animation. This is my first time creating a high quality sprite animation for a game and I’m very happy with how my process worked, and the resulting animation. I’ve talked about animation for the enemy shark in previous blog posts if you’re looking for the process.

The finished animation of the enemy shark.

With this project being over, that is all for now, Esbjörn out!

How (not) to Handle Playtesting

During the development process we had a couple of playtesting sessions where me and my team, together with all of the other teams, gathered to show and play each others games. The reason we did this was to give us an outsider's perspective on how the games felt to play. Things that are obvious to you when you are building the game might be completely alien to someone who isn’t involved in the creation process. This is something we struggled with a lot.

In our game you’re playing as a boat. Your goal is to move forward and get as far as possible whilst attacked by sharks hiding in the mist surrounding you. In order to protect yourself against the sharks you have to shoot them with your harpoon. In the mist you can also find helpful items to pick up, the problem is that in the mist they look the same as sharks and if you shoot the items they get destroyed. In order to see if it is a shark or an item approaching you have a rotating spotlight attached to your boat. You can turn it on and off, and when it is turned on it drains energy. More energy is one of the benefits you can get from picking up items.

The problems we had during the playtesting was that none of the playtesters could figure out the controls worked and had great difficulties understanding what was going on. They had trouble shooting the sharks because the way the harpoon projectile worked was different from how projectiles usually work in games like this. The testers also never found or noticed items because the placeholder shadow they used looked way to much like a shark. This lead to all of the testers destroying everything approaching them. Even when we told them how the game worked many testers found it difficult to understand the game.

The tutorial screen of one of our early playtesting builds

My point with this post is not to discuss the exact problems we had, but rather point out how our attitude to them were wrong. After the playtesting ended we all sat down and looked at the feedback we received and we could clearly see that the testers had a hard time understanding our game. Instead of identifying that, and making changes to the game design and how the game communicates the mechanics, we shrugged it off and assumed that the testers would get it when the game was more fleshed out. Of course, when we came back two weeks later the testers still didn’t get how to play the game. It was only in the final weeks that we started to take it seriously and made changes that actually made the game more intuitive. We simplified the harpoon and made the shadows covering the sharks and items more ambiguous, which is something that we should have done after the first playtest.

When we put our first prototype out for others to playtest we had most of the basic mechanics implemented, but when they didn’t work we didn’t try to fix them, we instead chalked it up to the testers being stupid and that they would understand if we made a better tutorial and when the game was more fleshed out. This is a dangerous thought because you are trying to protect your ego instead of realizing that your basic mechanics are flawed and you’ve made a mistake, but as long as the basic mechanics are flawed, the game as a whole is flawed. It is only when you realize this and fix it that the game becomes better, and sometimes you learn it the hard way, like we did.

With this lesson learnt we strive forward, that is it for now!

Catching up

Describing Scrum and me and my groups experience with is all well and good, but I also want to go over some of the things I have been producing these last two weeks. Right now we are coming up on the Beta deadline for our project, and, due to some of the reasons stated in my previous blog post, we are a little bit behind in terms of art assets. Which meant that it has been the time for me to increase my production pace a bit.

Last week I worked on the death animation for our shark enemy. The process of how I made it is very similar to how I created the swimming animation for it. I started out by figuring out the movement, added the rest of the body, drew the outline, and lastly added some color to it. If you want a more detailed description of how I created it check out my blog post from two weeks ago.

That took up most of last week and didn’t leave me with much time to work on other assets. The good news is that this week that is exactly what I have been able to focus on this week. We started out this week by discussing what art we needed in the beta during our monday meeting. A few of those things had to be kept as a placeholder for now, and I don’t feel like they are that valuable to share. Therefore I will instead show you one of the things that I actually put some effort into.

In the original concept of our game you are meant to set sail and find Umibozu, and then escape from it when you manage to find it. One of the main topics during our monday meeting was whether or not we should include the escaping part. In the end we decided that including that segment would take too much time and effort compared to what it added to the gameplay experience. We now needed a way to signal to player that they had reached the end and that that they’ve found Umibozu. In order to show this we decided that we wanted an illustration of the player character in front of Umibozu.

I created this fairly quickly in Photoshop, which is why it feels a bit rough still. I tried taking a speed painter approach to how I created this image. Starting out my blocking in the shapes of the objects with their base colors, adding elements such as textu

re and lighting after the general composition was finalized. Because I needed to complete it quickly I also relied heavily on custom brushes in order to create textures and effects. I would love to revisit this before the project is finished and give it the touch up I think it deserves, but due to needing to complete other assets, this is how it will look in the beta.

That’s it for now, Esbjörn out!

Ready, set, Scrum!

In order to keep track of our progress and make sure that we keep on schedule me and my group have been using an Agile development methodology called Scrum. The goal is to constantly work towards creating a minimum viable product, and iterating on that until the product has the features and quality desired. It is also characterized by working in small teams with short daily meetings in order to make sure that everyone knows what is going within the project.

For our team Scrum has been a bit of a mixed bag. Mostly stemming from our inexperience with the method, and also because of the circumstances of the project. We’ve been good at grouping up and having meetings with each other. Most weekdays we meet up in order to have our daily stand up meeting where we discuss what we’ve been doing since yesterday, and go over what we’re gonna do until tomorrow. This has been helped by the fact that we’ve been meeting up to work together on the days we don’t have any lectures.

The lectures are however a part of one of the problems we’ve been having. At the start we estimated that each workweek we would spend 20 hours each on the project. However, due to lectures, meetings and other classes, the time that we’ve been able allocate towards the project have been lower than that. At least if we aim not to work during the weekends. This makes the initial planning we did at the start of the project inaccurate, and we’ve had a hard time meeting the 20 hour work hours that we plan for. As the project has progressed we have been scaling down the planned work hours for each member so that we can get a more realistic estimate on the amount of progress we are able to achieve during each week.

One thing that could also help us is to get better and get a better routine on how to work with Scrum. For example, both our sprint planning and review could be completed quicker in order to give us more working time. Right now, due to our inexperience and poor execution in how we’ve set up our backlog, we spend a lot of time discussing and figuring out what needs to be done each week. This is something we all agree that we will work on for our next projects, where we might also be able to have sprints that are two weeks long, instead of one week sprints. Having sprints last two weeks would halve the amount of big meetings we have, and also allow us to have a better flow when working. Right now it feels as if we don’t have enough time to really start working on something before a sprint review is coming up.

All in all, there are definitely benefits working via Scrum, but right now we are having some troubles getting it to work because of the circumstances of the project as well as our inexperience. We are learning a lot about what is working and what is not, which will help us as the project continues, as well as for future projects.

That’s all I had to say for now, Esbjörn out!

Swimming in the Right Direction

Lately I’ve been working on a swimming shark that is going to be used for two different school projects. It is one of two animations I’m doing for an animation assignment, and it is also going to be the animation of one of the enemies in the game I am making for another course. The biggest challenge when working with this animation has been to balance the different criteria that this animation needs to fulfill. I want it to look good for the assignment, but spending too much time polishing it for the hand in takes away time that would be better spent developing other assets for our game.

Another problems I’ve had is to animate the smooth wave motion of the sharks’ body. When I sat down to start I had no idea how to tackle it, and I had to spend a lot of time experimenting and tweaking as I went along. With that out of the way, here is how far I’ve made it.

At this point I’ve just started working on the final outline of the shark. The animation is created in Adobe Photoshop using video layers, and the built animation features available inside Photoshop. To start out I created and animated the head of the shark. I figured that I would be able to use the head movement to create the follow through of the body, which is what I tried to figure out next. After that I made the spine. Using the onion skin function in Photoshop I tried to simulate how the head affected the movement of the spine frame by frame. This took a couple of attempts to get reasonably correct. The hardest part was making the spines in each frame the same length. In the end I made them a bit longer than they should, and erased the unnecessary lengths.

With the movement taken care of I added mass to the shark. I did not use much in the form of guidelines doing this, it was mostly done by eye. This approach was pretty quick because the shape of the shark isn’t that complicated. There was still a fair amount of small issues that needed to be fixed afterwards. Issues that could’ve been solved by creating a more in depth skeleton. In the end however, I think doing it by eye was the best approach in this case. With the main body complete I only had to add fins in the correct places, and then it was time to ink, which is where I am at now.

During this weekend, I’m going to finish the outline and add some color to it. I’m not expecting it to take that much effort because the groundwork is already completed. The movement, shapes and masses are all completed. All that’s left to do is to fill in the lines and then color inside them.

That is it for now, see you soon!

Enemies lurking in the mist

In game design, the enemies that you create might in some cases be more important than the player character. Right now me and a team of five other people are developing a game based on a game concept someone else created. The game is called Umibozu, and you play as a curious fisherman trying to find the mystical creature called Umibozu. Lost in a dense fog you have to avoid obstacles, pick up energy crates to keep your floodlight running, and shoot down any vicious sea creatures trying to bring you down to the ocean floor.

The concept document we were given described most of the mechanics necessary to create the type of experience we are after. However, it only describes that there is supposed to be enemies attacking you. It doesn't describe exactly what the enemies do. This meant that it was up to me and my team to design the enemies.

We all agreed that one enemy should just be trying to ram you. It is easy to implement and adds stress and time pressure to the player. We then felt like we needed to come up with one or two other types of enemies in order to make the gameplay more varied. A few months before this project, the team I'm a part of participated in a workshop about a concept called orthogonal unit differentiation, or O.U.D.. The workshop was based on a presentation by Harvey Smith from 2003. It can be found here. The point of this workshop was to show how giving different units different abilities is an inexpensive way to add depth in gameplay. For example, creating a second enemy that also rams the player ship doesn't really add anything new to our game. It does the same thing as the first enemy, but it requires us to create a new sprite and animation, which in the end gives us little gameplay improvement for the time invested. This why we set about to create enemies that created new gameplay opportunities.

After some brainstorming we ended up with a couple of different ideas for how these new enemies could behave. Our most popular ideas was to have one enemy throw projectiles that you could avoid, and another that hid next to rocks and other obstacles and ambushed the players' boat if it got to close. The problem was that we didn't really know what kind of creatures would fit with these abilities. The ramming enemy would work great as a shark that swims towards you. Our new enemies weren't as straightforward. This is where my role as an artist came in to play.

I started creating concept images of different creatures that could possess the abilities we wanted. The original concept document showed a giant squid as a possible enemy, which I felt would work great for our projectile throwing enemy. It could try and hit the player ship with one of its' two long tentacles, or it could throw ink which blocks the players' vision. Whilst not fully realistic it could definitely be believed in a computer game.

The third enemy was a bit trickier. We couldn't come up with any real sea creature that would fit the bill as something hiding next to rock. I then recalled seeing crabs and other crustaceans with rocky formations as the top part of their shell in other games. Shamelessly using these games as references I started creating my own versions.

All the art is created in Adobe Photoshop CC 2015. Using wither a hard round brush, or a custom textured brush I first blocked in the general shape with big strokes, adding a few layers of shading and lighting on top of it in order to define the shape more properly. Since the point of these concept images was to provide our group with different ideas for later discussion the art isn't very polished. Spending a bit more time on them would improve the quality of them, but that time would be better spent doing something else.

That's all for this time, Esbjörn out!

Big Game Project, Week 1-2

Hello again, it is once again time to fill this blog with some content.

A couple of weeks ago I started a course in which we students are tasked with creating a game during this time. The game is supposed to have market viability, even though we aren't expected to have a complete game at the end of the course. Instead we are a creating vertical slices or demos of our games which showcase the essentials of  the game.

At the start of the course you either had a game concept already approved, or you could apply to join a group that needed more people. I didn't have a group at the start of the course so I applied to join a couple of different groups as an artist. Fortunately I found a group that were interested in my talents. I was accepted into their group last week and I met with them last Wednesday so that I could be properly introduced to the game concept. The rest of the week was spent trying to create concept art for the game.

This week we set up our scrum documents, creating a project backlog as well as doing a quick sprint planning in order to determine what every one was going to do this week. I was tasked with creating concept art for the spirits that the player team up with in our game. These spirits are elemental forces which aid the player in combat and journey with you through the game.  There are three main types of spirits that we want in our game, a earth spirit, a fire spirit and a water spirit. Unfortunately I haven't progressed much with these concepts´, and I'm gonna have to put in some extra time during this weekend. It is important to get most of the concept art done this week as we're going to start production next week.

We are a bit behind schedule when it comes to making the game. We were unsure whether or not we were allowed to progress with this project until earlier this week which means that we are a week behind the groups that got green lit earlier than us.

That is all for these two weeks.

Upgrades for Everyone!

Last week I talked about the picture I made that shows how much you've upgraded your character's outfit. I only talked about the first one last week so it seems fitting to talk about the other two levels this week.

These pictures are supposed to show progression as you upgrade your character. The reason why we decided on adding these pictures is because it is hard to tell exactly what happens to your character's sprite because it is so small when you look at it when you are playing. Considering this, the number one thing I had to keep in the back of my mind when making the higher level pictures was "upgrade". If you couldn't tell from the pictures I made that you had upgraded the whole point of  the pictures was lost.

All the pictures I've made next to each other showing the progression from level one through level three

The level two upgrade was fairly straightforward. When I first started making concepts for the different outfits I quickly decided on having a scarf or something similar to show progression as it would be quite visible even from a top down perspective. With that in mind it was just a simple process of opening the level one photoshop file and start adding onto it. It was very easy because I had a clear vision of what I wanted to do and also because I had the level one photoshop with all layers separated to work with.

Current version of the level 2 sprite

The level two picture was made without causing me much trouble, the same can't be said about the level three picture. Like the previous picture, I had a good grip on what I wanted to do when I started out working on the third one. At level three the sprite in the game gets a big glove as well as some arm accessories. While it works when you look at the sprite, adding these details to the picture turned out very unremarkable. The change wasn't as noticeable as the one from level one to level two. This is were things got though.

Unlike the prep work I had for the level two sprite I didn't have any concept pictures that fit perfectly. There was some ideas from the concept stage that I considered, but nothing that really stood out as a perfect solution. In the end I ended up just drawing things and seeing what stuck. What I ended up with was a more intricate robe and a new bag. They aren't groundbreaking additions, but they help add to the feeling of progression. I haven't asked for any feedback on it yet though so we'll see if it stays as it is or if I'll have to change it.

How the level 3 picture turned out

That is all from me this week. Hope you enjoyed reading this and hopefully you'll be back next week.

Let's Talk About Something Else

At last I am free from making sprites. For now at least. Last week I made every version of the main character sprite, nine in total. If you are not sure what I mean it is as follows: In our game we have a main character. You can upgrade her clothes and weapon independently, with three levels each. This means that I had to create sprites of the main character with a first level suit and weapons one, two and three. Then do the same for both the level two suit and the level three suit. I've attached a image below showing how the main character's sprite changes if you only upgrade her weapon and not her suit.

Weapon progression from level one to level 3.

However I feel like I've talked enough about how I make these sprites and that it is time for me to talk about something else, so that is what I'm going to do.

To upgrade the character you enter a menu and select what aspect of your character you want to upgrade. To show which aspect you can upgrade and what it will change we have pictures in this menu. These pictures are not pixel art like the rest of the game. Instead they are straight up painted images me and my team members have made. We choose to it this way because none of our artists are really comfortable making large scale pixel art. It also meant that we could use any concept we made and turn it into an in game artifact.

Seeing as I had made all the things related to the main character up to this point I felt it was fitting for me to take on the responsibility to create these upgrade images. I had already made the concept art for her level one suit which meant that most of the work was already complete and all that was left was to colour it. When I first started planning this I had it in my mind that it would be fully rendered with material and lighting. My producer however was shocked by how long I estimated it to take and said that it wasn't acceptable, so I proposed to only add some flat colours and and some shadows to that which wouldn't take nearly as long. This my producer thought was more reasonable.

The steps I took to get to the final product. I think the colours are a bit off though.

In the end I'm quite happy with the result even though I only put in a couple of hours into it. There is definitely improvements to be made if I wanted to but time is becoming sparse, and I will probably not be able to implement them because there are more important things that needs to be made/improved.

Sprites again?

If you've been following this blog, you will know a fair bit about the sprites I've been making. Last week I talked about the level two sprite. The logical progression is that today I will be talking about the level three sprite, which I will.

The level three sprite was a mixed bag of obstacles. The weapon she would be using had no clear concept at all, the only thing that was set in stone was that it was supposed to be attached to the main character's arm. There was also the recurring problem of not having enough room on a 64x64 pixel big sprite to show any significant progression. What worked in my favor was that since the gun is attached to the character's arm I could use the level one sprite as a base on which the level three sprite was made. I only had to move around her arms a bit to create the pose and from there on out it was smooth sailing. You can see the similarities below.

Level three (left) compared to level one (right)

Making the gun was interesting because, as I said, I had no direction to start in. This meant that I had to experiment quite a bit. Unfortunately I have nothing to show from those experiments but there are still some remnants in the final version. The spool of thread on side was one of the first things I added. Maybe it has some interaction with the weapon or maybe she uses it while she works, since she is a tailor. The spool felt a bit too heavy on it's own, so I added a counterweight to the other side. The pipe was originally bigger, but it felt to cumbersome to be carrying around on ones wrist, so I made it smaller.

If you look at the image I've provided you can see what I've done to show the progression of the character. The scarf/blanket on her is added at level two, which I unfortunately don't have a picture of at hand. In my previous post there is a picture of the level two sprite, but it is not the most updated version. Anyways, what is added at level three is most notably a leather glove with brass clasps that covers her whole lower arm. She also has a piece of cloth attached with brass bracelets on her right arm. It is still fairly hard to tell what they are supposed to resemble, but in the game we will have some high resolution pictures which hopefully will make the player understand what everything is supposed to be.

Level Up!

Keeping with the theme I've set these past two weeks I'm going to keep talking about the different artifacts I've created related to the main character in the game me and my group is making. Last week I talked about how I made the first sprite of the main character, the level one sprite which you start out as. This week I'll talk about the level two sprite, how I made it and what challenges I faced while working on it.

After I made the level one sprite I immediately moved on to making the level two sprite. At level two the character has some more stuff on her and is carrying a gun instead of a pistol. Having a gun instead of a pistol meant that I couldn't  recycle the level one sprite to create the level two sprite. There was also a problem making the main character look stronger because the character is both top down as well as only 64x64 pixels big. The limited size of the character means that anything I add has to be fairly big, because you wouldn't be able to tell what it is supposed to be otherwise. Furthermore the only area that I'm able to add detail on is the on top of the arms, shoulders and head.

The steps I took when creating the level 2 sprite were the same as the ones I described last week when I made the level one sprite. I start out by sketching the pose and making it look anatomically correct. After that I add some flat colors, boxing in the shapes of the character. I then add a black outline around it and add some texture to the colors.

The level two picture in this post is not completely accurate as I've made some corrections to it, mainly changing the shroud on her shoulders from blue to an almost scarlet color with a golden border. The green has also been made a bit more saturated to stand out better from the background. You can see that green color in the second picture.

The second picture might be a bit confusing if you read last weeks post as it looks more like the level one sprite than a level two, or even a level three sprite. The reason is because it is a level one character, but with an upgraded gun. It is the same base as the level two sprite but I've removed the shroud and added the bag from my level one sprite.

In the end I not really pleased with how the level two sprite came out. Especially the arms I think could use some work, but at this point it is probably more important to make sure all the art assets exists instead of polishing a single artifact to perfection.

Head First Into Making Sprites

These lasts weeks I've mainly been working on the main character. Last week I discussed how I designed the main character and showed the different stages she went through during the design process. This week I'm going to talk about how I turned the concept art into the sprite that is in the game at the moment.

The sprite I'm mainly going to talk about is the level one sprite that you see when you start the game. I'm almost complete with both the level two and three sprites right now, but I think the process of making the level 1 sprite is more interesting as I had no experience making sprites when I started out.

The level one has her holding a a pistol with both her hands. The game is top down so the only things you see is the top of her head, her shoulders and her arms. Starting out I made a new 64x64 canvas in photoshop which I then sketched the the main character's pose on to. I used a small brush tool with a lower opacity for this as I didn't need to define the lines at this stage. In hindsight I should've probably started out with a bigger canvas and then scaled it down to 64x64 when I was happy with the proportions. When you are working in such a small size as 64x64 it is hard to make lines the way you want them to, which is why I think that starting out bigger would've been easier.

When I finished her pose I made a quick outline and started to put down color on her just to experiment with her color scheme. I may have done this a bit backwards as I put down the colors before I had a final outline to work with. Instead I put down the colors on top of the half-assed outline and then created the final outline by painting a darker color around the main color. E.g. to outline her green clothes, I took a darker shade of green and created a one pixel wide outline around it. At this point I was using a one pixel big pen tool in photoshop.

This technique of making an outline looked good in photoshop, but when it was put into the game it didn't provide enough contrast to stand out. To fix this I made the outline pitch black which made everything much clearer in game.

It's still not absolutely final as some group members still have some problems with the colors, but at this point I'm starting to feel I've put more than enough time on it and that my time could be better used on something that is yet to be created. That is something that I will have to speak with the rest of group about though.

Sprinting Into Pre-Alpha

At the moment we are creating games based on the concepts we did a couple of months ago. My group is creating a "defend the objective" type game where the player is tasked with defending his/her truck from waves of bandits. The most off the cuff mechanic in this game is that you are only allowed to move in a circular arc around your truck. To make sure we are going to complete the game before the course is finished we are working by using scrum, a framework designed to constantly update and iterate what you are producing. In scrum you work in sprints. Each sprint is a set amount of time in which you set out to complete goals you made at the start of the sprint.

I took on the role as lead artist again and these first couple of sprints I've mainly focused on creating the main playable character. I had a lot of freedom when designing her as we hadn't come up with any specific details that she had to have. The only directions I got was "anything is fine as long as it isn't revealing". Although there were still some contextual guidelines. Her clothes, for example, should be easy to move in and not that delicate since she is a traveler, they should however be a fairly good condition as she is a tailor.

Another challenge designing her is that in the game you are supposed to have three different levels, represented by different clothes. This means that I have to design three different outfits for her which makes things a little more complicated.

Above I've attached a couple of different concepts I sketched. To make the process of designing them faster I made a base human which I then used as a mannequin that I was able to just draw different clothes on. The one furthest to the left is the first one I did. It is a bit of a mess because I just drew whatever came to mind, but it has a lot of elements which carried over to the rest of the designs. The one in the middle is probably the sixth or something I made. I'm quite pleased with it as it shows a lot of intricacy, with different patterns and details. However it is a bit to much for a level one outfit, and as that was the one that the most important at the moment I didn't end up going with it. The last one is the final concept of her level one outfit. It isn't flashy, which is what I want, and I think it fits someone who travels about.

There are still some problems that needs to sorted out however. The biggest is that because the game is top down you aren't going to able to see any details that are not on the head or on top of the shoulders and arms, but I'll be able to overcome it.