Depth – postmortem

Hiiiiiiiiiiiiiiiii!

Welcome to the last blog post assigned to me by school. It is so bittersweet :’-)

In this post I am meant to write a postmortem of my groups now finally (!) finished game. I will discuss what went right, what went wrong, and then close with a conclusion, but I will start with a brief description of the product we ended up with.

Depth is a platform shoot ‘em up, where you play as a research submarine escaping a long and narrow underwater cave. The player is chased by a large whale-like creature, and the chase is obstructed by several smaller enemies and cave walls. The aesthetic goal of the game is for the player to feel like they are on their last leg, or in other words, that they are barely surviving by a thread. We interpreted this to mean feeling under constant pursuit, in danger, constantly pressured and overwhelmed. It has a coherent pixel art style, and a low-key threatening soundtrack, which can be more described as sound rather than music. The player can shoot small torpedoes to destroy obstructive enemies in their way. They have unlimited ammunition, but the trigger needs to be released between firing. The player also has a speed boost which can be used for two seconds and then needs to recharge for ten seconds before it can be used again. The player is slightly slower than the creature, which means that the speed boost needs to be implemented in order to escape. However, the architecture of the cave walls are narrow, which means that a misplaced speed boost can send the player crashing into the walls and therefore slowing them down rather than speeding up. Because of this the player needs to perform with accuracy and make quick decisions in order to win the game. There are also checkpoints present in the shape of underwater mines, which means that the player doesn’t necessarily start over from the beginning, should they loose the game.

 

gif-of-the-game

the alpha version of Depth

game-final2

the final version of Depth

What went well

  • A fun game!

During the production of Depth it goes without saying that certain aspects of the production went well, where as other aspects went worse. But most of all I am so very proud to have a working, playable game, which is actually fun to play! During the final play-test we got a lot of feedback saying how fun and challenging the game was, and I also heard witness testimony stating that many players stayed for a long time at our station. Even if I should disregard this, I personally enjoy playing the game, although I am not very good at it yet haha. I believe this is in part thanks to us taking the feedback we received from play-testing into account, as well as focusing on making a short, polished game with fewer assets rather than a complicated one. We also achieved most of our aesthetic goals.

  • A coherent visual style

As Lead Artist I feel almost obliged to mention the graphics of our game as my personal proudest success. I believe that the assets made by me and Ben (I mention him in like EVERY previous blog post in case you don’t know haha) are both coherent in style, as well as skill level. An they are (mostly) beautiful! I believe this coherency to be due to the limitation of pixel art, in combination with mood boards provided for most assets, as well as frequent communication. Additionally, I have received help from Ben when I have struggled with aspects of my work load, and I hope that he felt supported by me as well.

  • Collaboration

I personally experienced that we tried hard to support each other in the team, although there is always room for improvement. As I’ve already mentioned countless times, I received help from Ben on multiple occasions, and I tried to be transparent with my vision from the beginning in order to lessen the risk of him making assets I would object to. I also did my best to make sure Ben didn’t feel like he had a too heavy work load by encouraging him to assign tasks to me if he needed more time. Although I personally was very little help in Unity, our programmer (Wiktor), was supported by both Ben and our designer (Hampus), in Unity collab to ensure that too much work was not pushed on one person. Our project manager (Edvin) took care of tasks such as power presentations and credits.

 

What went wrong

  • Focusing on minors led to less focus on design

I think that most of us in the group wanted to bring our very best to the table, however this might have caused tunnel vision on our varied minors. For me it was very important to make a ”good looking” game, since I regard visual aesthetics as a major priority. However, as we are often reminded by our teachers, we are all majoring in game design and not in our minors. Most of my time went into making sure the assets looked good, whereas had I taken some of that time to learn more about unity, I could have helped making the game longer or with a more smooth and challenging gameplay. It is true that I am pleased with what we accomplished, however, I would have liked to see more levels. In addition, as our teacher Mika pointed out, making obstructions which slows the player down, such as entangling seaweed, could have helped to emphasize the feeling of being pursued by one ultimate danger which would be in line with our aesthetic goals. As our game is now, the player take damage from the obstructions, which makes it feel less like a chase and more like escaping damage from all directions. This seemed obvious when it was pointed out to me during the last play-test, however the main thing I had been concerned with until then was how unpolished the final creature animation was.

  • slow start in working with SCRUM

As I have mentioned in my blog post about SCRUM, I didn’t feel like we lived up to the requirements. And since it was part of our assignment to work with SCRUM I feel like it’s appropriate to bring up here. I also believe that had we managed to work with SCRUM efficiently from the start, we would have had less wasted hours and less frustration in the group. We completely lacked any retrospective sprint meetings and our daily stand up meetings were badly organized, however this improved with time. We also failed to fill out the backlog individually in the beginning, although also this aspect improved over time. I believe part of this is due to individual personal reasons like lack of communication, lack of commitment to the SCRUM aspect of the assignment etc. Although I think we would have benefited from getting taught SCRUM in more detail earlier in the program so that we would be better prepared to implement it during this course.

  • inability to accurately estimate time

On numerous occasions the tasks which was assigned to me ended up taking much longer than estimated. I think this was mainly due to the fact that we were all in many cases performing tasks for the very first time. This made it difficult to accurately estimate what problems might occur. This could have been avoided, albeit not completely, had we put more effort into a more precise risk assessment.

 

Conclusion

In the end we ended up with a fun and visually pleasing game. Although I have mentioned many problems with our game in this post I think it is important to remember that problems and even failures are to be expected during the development of a game. Taking into consideration that we are all first-year students with no previous experience in the field I think we did a very good job. And most importantly, any failures or challenges has turned into our most valuable lessons. The lessons I will bring with me to the next production as an individual, will be to focus less on the visuals and more on the game design in general. I intend to study more of the materials provided to us by our teachers (especially about SCRUM and level design), and to familiarize myself more with Unity in order to be an efficient asset to my new team. This has been the most challenging, but also enlightening experience in the program so far, and I can’t wait to start making arcade games!

 

Byyyyyyyyeeee!!!

 

Annonser

Play-testing

Hiiiiiiiiiiii!

This week we are required to write about play-testing and how it has affected the development of our game.

During the production of our shoot ‘em ups we have had two play-testing opportunities. One right before the Alpha deadline and the second right before our Beta deadline. The play-testing is basically a workshop where every team set up at least two laptops with their game for all the other teams to test. At least one member of the team is present in case the testers have questions, but we are encouraged not to explain the game in too much details to the tester in order for them to give genuine feedback. The feedback is collected after the testers try the game, usually through an online survey but I have witnessed other teams asking verbal questions and either recording or writing down the answers. The members who are not responsible for guiding testers are free to explore other teams games, and in most groups the members took turns so that everyone could try out the other games.

At the first play-test all games were in Alpha condition and therefore there was much to be improved, however, it was still possible to get a feeling for which games were fun and which games needed more fundamental changes. In our case many testers seemed to enjoy the gameplay, and most of the critique was in relation to the GUI. For example, the health bar which I myself had created was not necessarily interpreted as health. Another problem was that the shield pickup we had implemented was presumed to be hostile according to many players.

This was of course very useful feedback. When designing the shield pickup we had designed it to be coherent with the shield (which is pink <3), but many players thought the color to be a shade of red which by semiotics rules implies danger to many people. The health bar was also designed to be coherent with the light steampunk feel to the game, which is why I made it look like light bulbs that go from lit to unlit when the player looses health. after receiving this critique I changed the color of the light bulbs to red to remind players of hearts, a common symbol to use for health bars in many games. The color change also made it easier to distinguish between a lit and unlit light bulb.

the different versions of light bulbs, from left to right original lit, original unlit, updated lit and updated unlit

For the second play-test I was prepared for similar critique, mainly pointers to what GUI should be polished. However, when our teacher Mika finally got to playing our game it was like getting a bucket of ice water over me. I genuinely feel like the critique was valid though so I am not trying to throw shade at anyone, I simply got a reality check hehe. I was responsible for our station at the moment so I personally received the critique and wrote it down in my notes. (For students critique we relied on an online survey). Most of the pointers Mika had for our game I could immediately agree with and I forwarded the critique to my group. The for me most logical critique was the position of the speed boost button. In our game you control the player avatar with the WASD-keys and you use the SHIFT-key to activate the speed boost function. When I tried this myself I had problems with it but I just assumed that I was a worse player than my team mates. When I heard it from Mika I got validation for my own issues with the function, but when I told my team the immediate reaction was surprise. I am not a PC gamer myself but it turns out that a lot of PC games use the SHIFT-key for speed boosts and my team mates were all very used to these controls. After thinking about it though I believe they realized that keeping the speed boost on the SHIFT-key makes more sense if you have many other functions already implemented on other keys, and it limits the game to be enjoyable only to those who are already used to these specific controls. In the end we decided to change the position of the speed boost to the SPACE-key instead.

All in all I think the play-testing has been very useful to our team. For me personally it gave me a fresh look at the design decisions I had made along the way, and to many of my team mates I think it opened their eyes to how players who are unused to PC controls will experience the game. Along with what I have mentioned before we also realized that we needed to balance the game better, our group had become very good at playing our game and didn’t find it very challenging, but this was not true for new players. (We had been warned that this might happen but it is still easy to become blind to flaws at home). The experience with play-testing has really opened my eyes as to what a fresh pair of eyes can bring to a finished product and I think the feedback you get is to be taken seriously. Because we have listened to the voices of our testers I feel even more confident in our product… but I am really looking forward to be finished with it and continue on to the next project.

That’s all for this week.

Biiiiiiiiiiiie!!!!!

Animation cycles

Hiiiiiii!

This week I am going to write about last weeks art assignment (as I imagine many Graphics minors are). We were supposed to create at least two animation cycles of the same character, and we were encouraged to pick a character from our shoot ‘em up. Surprisingly enough, I ended up animating my beloved pink Fish (!!!!). I decided to make a death animation, idle animation and a turn-around animation.

I started with the turn-around, because I figured it would be the simplest. I, like many of my classmates, had no real prior experience with animation. Right away I had some difficulties, and I could easily identify the problem. As I have written in an earlier post, the design of my Fish does not follow the ”maximum 5 colors”-rule that I read about in a pixel art tutorial. This turned out to complicate things when animating. In pixel art, literally EVERY pixel counts, that is to say every pixel has an impact on the final image. Though pretty, the fish that I made was way to complicated to animate smoothly, since I would have to consider how to change the position of every single pixel. I tried to bypass this problem with the use of the transformation tool (a tool in photoshop which allows you to stretch or shrink your artwork in any which way), however, as I’m sure you can imagine, stretching or shrinking pixel art in this way does not work very well. My attempt was no exception.

Although this miserable fail, I did not give up hope to somehow short cut my way to a beautiful animation °˖✧◝(⁰▿⁰)◜✧˖° I immediately tried to animate the Idle state of my Fish, using a similar technique. I call this technique cut,-copy-paste technique… ¯\_(ツ)_/¯  I cut out parts of the fish, copied them and pasted them. I then moved, mirrored and placed these parts, and then I painted around the altered part to make it fit with the surroundings… It was not a beautiful sight. I knew I needed to change my ways if I was to learn and grow as an artist (pass the assignment)!

When making the third animation, I decided to make a sketch of the animation. I also finally accepted that I needed to make some alterations to my original design, to be able to animate it. I traced the outlining of the fish, then based on that I drew new, original silhouettes  for every key frame, and made a frame-by-frame animation with only line art. This proved not only to be the best way to make a smooth animation, but it was also the least time consuming way (surprise surprise). Maybe that’s why all the teachers recommended it???????        ∠( ᐛ 」∠)_  After I made sure that the line art animation ran smoothly and included all the principles of animation (arc, timing, anticipation, squash and stretch ) I colored all the frames with local colors, then shadows and finally lighting. This way I could compare each frame to the next, step by step, as opposed to finalizing the first image before coloring the next and getting lost in the process. The animation turned out pretty well.

half-way into our assignment we had a presentation to show what we had made so far, I made it a point to emphasize that I had learned by my mistakes and improved my skills. Our teacher seemed to like my final animation and encouraged me to revisit the earlier ones. I decided to follow his advice, and I am glad I did because they look so much better now. I guess the major lesson I learned was to follow the advice (instructions hehe) of my teachers, and not short cut my way to a sloppy product. I’ll try my best to remember this lesson in the future.

Thanks for reading!

Biiiiiie!

Comments

This post is a collection of the comments I have made on my classmates posts as is required for this blog assignment. I will update it with a new comment each week.


 

This week I have commented on Isak’s post

Also this time I chose to sign the comment…

My comment was as follows

Hello Isak,

I’m happy to hear that you are pleased with the outcome of your game 🙂

Although I can relate to many of the difficulties you bring up in this post I would have liked the text to be more well structured. The issues you faced are mostly vaguely described such as “misunderstandings” and “setbacks” and they are all mentioned in different parts of the text. I would have liked to hear more in detail about these struggles and how you dealt with them, as well as what you will think about in the future. However, I believe that if you did not wish to explain them in detail, this problem could have been bypassed with a more structured text where you bring up the issues in one section and proceed to go into detail about only a few of them. This would then be followed by a section with things that went well structured in the same way, rather than mixing it all up.

To sum it up, the problem lies more within the structure of the text, not the content.

Apart from this I enjoyed your post, especially the part about making clear silhouettes to work with the fog in the game. This was a good example of a detailed problem with a though out solution, even though not yet applied. Furthermore, I did not get the feeling that the bad outweigh the good by reading your text at all, so don’t worry 🙂

I hope you don’t feel like I was too harsh with my critique.

Ellen


 

This week I have commented on Jesper’s post

(I don’t know why I signed this particular comment)

My comment was as follows

Hello Jesper,

I truly enjoyed your post. I especially liked how you decided to explain your experience from the perspective of a developer as well as a play-tester. It is easy to get stuck with a tunnel vision seeing as we are students with an assignment to fulfill, however you analyzed the testing from several perspectives and seem to have learned a lot from it. Although your text was detailed, it felt coherent and easy to read, and I personally appreciated the humorous tone in your text, which felt appropriate for the blog format.
I also found your approach to play-testing very interesting. Granted it might help you to give more elaborate or precise feedback if you know more about the circumstances surrounding the faults of the game, but I can’t help but wonder if you are not jeopardizing the ability to give objective criticism. I obviously have no right answer to this question and as you write briefly about in the beginning, since we are all students of the same course,( many of us even developing the same game), I guess we can never be truly objective. That’s why it’s great to see your family trying out the game in the pictures XD

To conclude I appreciated your post very much. It gave me some insights I had not considered, and I appreciated the lightheartedness of the text, at well as the important factors you brought up.

Keep up the good work!

Ellen


 

This week I have commented on Merve’s post

My comment was as follows

Hi Merve, and thank you for this entry.

I think your jellyfish design is very beautiful and it’s interesting to read about the process you went through while designing and animating it.
As a game designer I appreciate your explanation for your choice of colors and amount of tentacles, which proves that you had logical motivation behind every decision. This, as we have been taught, is the essence of design. Also the speed of the jellyfish’s movement is tweaked to fit the aesthetic goal of your game.
As a graphics minor, I like how you reasoned about color based on what we have been taught in class, and how you solved the “problem” of making a transparent jellyfish using an optical illusion rather than actual transparency.

The only thing I would have liked to hear more about is how you solved some of the difficulties you seem to have faced, or more in detail what you learned from animating the jellyfish.

All in all it was a very enjoyable entry, and I look forward to see more of your work after the game is done 🙂


 

My third comment was for Johan’s post

My comment was as follows

Thank you for this post. It was interesting to see what aspects of scrum has worked for your team, as well as what has been more challenging. I agree with you that a “fun” development process increases the chance of a good product.

As mentioned in the comment above, your post did not give me a “ranty” impression, and for the most part I had no problem following your thought process. However, your descriptions of your struggles with the sprint could have been formulated differently. I understand what you want to express, but I believe the sentence “The weekly sprints makes for a lot of time being time for meetings.” is a bit confusing. If I am to give you an example, I think “A majority of the time intended for the sprints, is instead spent on several different meetings.” is a better way to phrase this thought.

All in all it was a very enlightening post, and it is good to see that you can identify the problems of your working process in order to successfully improve your team’s efficiency.

Keep up the good work 🙂


 

My second comment was for Felix’s post

My comment was as follows

Hi Felix.

I was able to read your post without struggles because of the clear divisions between the different features you’ve worked on. The text is coherent which means I can easily follow your thought process, and your reasoning seems logical and on point. The description of your process was detailed, but without unnecessary ramblings of text. I especially appreciate the decision you made to put less pressure on your programmer, as it implies you know how to listen to your fellow team members and ”kill your (own) darlings for the benefit of the progress of the whole group.

Although I appreciate the clarity of the post, there are some additional aspects I would have liked to see. Most importantly I think it would have benefited you to include some images. It would not only have been interesting, but also very enlightening to see the process you went through, especially as a fellow graphics minor. If there were no concept sketches or similar for you to include, one suggestion could be to use images of what inspired you (like an image of a howitzer gun, which I have no idea what it is so it would also have been enlightening for me personally haha). I think images would have helped to highlight and underline the basis for the decisions you made, and even if (I’m guessing) it is already depicted in the background/top of your blog, I would have liked at least an image of the final design of the Behemoth.

If I am to be nit picky, I would also have appreciated an explanation for the word Mech, which I had to google to fully understand (but that might just be my own fault haha) and I am also curious whether you decided against two guns on your own, or if it was a mutual agreement after consulting with your group. However, I enjoyed your post and if you had included pictures there would have been very little for me to criticize.

I hope you wont take this critique too personally or feel like it was too harsh. Your post has made me very curious about your design as well as concepts, and I really look forward to see your artwork!


 

The first week I commented on Maries post

My comment was as follows

First of all I would like to say that I love the line art-style, together with the papery background it gives a calligraphy feel to the game which feels appropriate considering the Japanese theme. It seems like a wise choice to set your design apart from the other groups considering the fact that so many chose the same concept doc.

It was easy to follow the process you describe in the post, you show relevant images to help illustrate the process further and you provide reasoning without including unnecessary masses of text. Your decision to use png assets to move around in a psd document felt thought through and I will take notice of and maybe use this process myself in the future, which makes this post valuable to me.

As a graphics student, it would have been interesting to hear the reasoning behind the menu background and the starting area of the game being the same, as well as the reasoning for the art style choice apart from it being “different from other groups”. However, as a whole I found the post enlightening and throughout.

SCRUM

alaska

This week our assignment is to write a blog post about how Scrum has affected the development of our game. I’m sure most of the readers of this blog are already familiar with Scrum however to be thorough, I will first briefly explain the basics and then explain how Scrum has been implemented by our group. Specifically, I will write about all the meetings associated with Sprints which I will soon explain in more detail.

Scrum is an agile framework meant to help developers maximize efficiency by reducing waste and creating predictability of how the development will proceed. It is an iterative framework where every task that needs to be done is planned beforehand by evaluating the risk, estimating how many work hours will need to put down, and distributing tasks to the different members of the team. All of these aspects are then documented in a backlog, in our case it’s a google document we refer to as our Scrum doc. This planning is done during a ”Sprint planning meeting” and then executed during a ”Sprint”, the Sprint is then followed up by a ”Sprint review meeting”. During the Sprint review you are supposed to evaluate the Sprint and check off what has been completed from the backlog, and how far the progress has come with the uncompleted tasks. In addition to this, you are supposed to hold a ”Sprint retrospective meeting” where you identify which practices has been ineffective and come up with solutions accordingly. This is very important since one of the key elements of Scrum and Agile is to react to changes in contrast to sticking to a plan at all costs. So called ”Stand up meetings” are also held every day (about 10-15 minutes) in order to keep the team updated on the progress of the different tasks.

In our case, we hold a Sprint planning meeting every Monday, followed up by a 5 day long Sprint, and then finally conclude the Sprint on Fridays by holding a Sprint review meeting. This particular framework was assigned to us and is true for every group. I believe some groups have been more successful with keeping to the Scrum framework where some have been having more difficulties. To be honest, I don’t feel like my group has been able to implement the Scrum framework as well as I had hoped. Although my group has been consistent in holding Sprint planning, and review meetings every week, when it comes to the daily stand up meeting we have experienced some problems. In the beginning, we decided that the stand up meetings should be held at the same time every day of the week. It seemed simple enough to put into practice however almost immediately meetings ended up being canceled because members of the team who had class later or earlier in the day, or simply not at all didn’t want to go all the way to school for the purpose of such a short meeting. In one member’s case, it takes an hour of traveling to get to school and back so it makes sense to be hesitant to attend these meetings. Although I can understand this point of view, unfortunately this hesitancy was often expressed earlier the same day of the meeting and therefore meetings ended up simply being canceled instead of rescheduled. Another problem was that in the beginning no rooms were booked for the purpose of the meetings. In some cases this was true for our Sprint planning and review meetings as well. This resulted in a lot of time wasted on finding a free, preferably secluded spot to hold our meetings on, and if these conditions were not met, I personally felt that it had an impact on the quality of the meetings. Lastly, and I am personally very guilty of this, some team members (on some occasions all members) have difficulties with being on time. This also impacts the meetings since frustration is built up if the team has to wait on members who are running late. If the team choose not to wait however, the late participant has to be briefed about things brought up early in the meeting, which is a waste of time and also a cause of frustration.

Personally, this affected me by giving me anxiety. I am not sure if it actually had an impact on my work, but either way it stressed me out a lot and since I am very uncomfortable with confrontation I did not feel like I could easily express these feelings with my team. I DID bring it up but maybe not in a well-phrased, constructive way. I believe the rest of my team had similar frustrations. We tried to deal with it by scheduling our daily stand up meetings on discord (an app similar to Slack where you can hold voice calls), however not all team members seemed to be in on this idea and we were not able to implement this until yesterday even though it was brought up from week one. I believe some of our team members, including me, were more comfortable and motivated by personal meetings, but since I have the privilege of living very close to school I also felt that I should be able to compromise.

Recently, our project manager has been doing a good job of booking rooms every day and holding the meetings at the same time regardless of who shows up. We have also kept up a habit of keeping the room booked so that those who want can work there after the meeting is over. This has helped improving the consistency and quality of our meetings, as well as my personal efficiency since I am prone to procrastinating if I stay at home and work. However, I believe there is still room for improvement in this area. For example, communicating the scheduled meetings to the rest of the team on Slack, even though it’s been mentioned vocally already, and to mention it on time instead of one or few hours before said meeting is taking place. Showing up to the meetings on time (again, I’m very guilty in this area) is also something that still needs work.

Finally, I want to mention that we have not implemented any Sprint retrospective meetings what so ever. I did not even really know about their existence until today (forgive me!) or at least I had forgotten about them, but I feel they would have been very helpful to us. For example, the problems we experienced with the meetings could have been brought up earlier and in a more official manner so that we could come up with and try out solutions quickly and improve our efficiency.

All in all I think Scrum, if implemented correctly, is a very useful tool and I want to underline that our errors are to be expected considering the fact that we are students trying out this framework for the first time.

Sorry about the long post!

rupaul-byeeee-drag-race

the role of a Lead Artist

Hiiiiiiiiiiii!

Today I would like to discuss the role of a Lead Artist (from here on referred to as LA) as I have implemented it during my work with Depth.

Our group (Ettin) has two graphic designers (blessed), so it was not a clear choice who should take on the role as LA. Since there were only one of each other minor in the team, we reasoned that the ”extra” artist would be Lead Sound Designer. Truthfully, I don’t recall exactly what was said, but it was fairly quickly agreed upon that Ben would be Lead Sound Designer and I would be LA. Personally, my biggest motivation for this was to challenge myself and step out of my comfort zone. Until very recently I have been suffering from a major art block which has made me uncomfortable with coming up with original ideas and I rather take directive from someone else, however, since the beginning of this course I have felt an improvement in this area and I thought that this challenge would be the perfect opportunity to grow even further and improve my confidence. I also strongly felt that I wanted to use pixel art and as a LA I would have the final say in case someone in my group would disagree (hehe) fortunately, I didn’t need to convince anyone as they were all on board from the beginning.

In hindsight I can see two problems when it comes to the choice of me as the teams LA.

First of all, the fact that I have struggled with an art block and used this as my opportunity to grow personally can be seen as a bit selfish, since it is a risk for not only me but the other team members as well. However, when I considered my previous experience in working with my group, I felt confident that they would back me up in case I would have problems with this task. Ben and I have communicated well before when working on the concept document and I trusted him to support me, which made me feel confident I would not fail. So far, I think it has worked out 🙂 (Phew!)

The second problem would be that compared to me, Ben has more experience and skill when it comes to pixel art. Therefore, it might have been the wiser choice to pick him as the LA. Truth be told, I feel like he has more skill when it comes to animation as well (and tiles, unity, etc… haha) but I chose not to let this stop me from challenging myself. Again, this might be seen as selfish but since our team work has worked well so far, I think we will be all right. In addition to this, the role of LA is not the same as Artist Dictator (haha), I am trying my best to listen to all the group members opinions and wishes and make the decisions together as often as possible.

I have never before been assigned this role, and I imagine that I’m not the only one in our program without a 100% clear understanding of exactly what is expected of me. As I mentioned earlier, I have tried to include everyone when making any decisions and asking before finalizing any designs throughout the whole project. My first “move” as an LA (apart from deciding on using pixel art which you can read about in my previous post) was to distribute the graphic assignments to myself and Ben. I decided that we each take one of the main assets that were the most “fun” to create (I got the big boss sea creature and Ben got the avatar submarine), then I got to work on the smaller enemies and Ben started working on tiles for the level design. The rest of the assets were distributed as we went, since I wanted to see how quickly we worked individually and to make sure that adjustments could be made in case one person had too much of a work load. I then preceded to make two extremely quick “place holder” sketches that we could implement in Unity right away, so the project wouldn’t be slowed down by us artists. I also made a mood board for the cave (background and tiles) for Ben to take inspiration from, this was to make sure he didn’t spend too much time making assets that I would later want to reject. Unfortunately, when it came to the submarine I had not yet made a mood board and I was not completely satisfied with the first design. I made sure that Ben was OK with me rejecting it before I proceeded to make a mood board for the submarine as well and had him make a new design. The new design was perfect!

protagonistSubv1protagonistSubv2

 

 

 

To the left; Bens first submarine design. To the right; Bens second submarine design.

Learning by my mistake I created a more detailed mood board for the cave as well and uploaded it to our shared google drive folder.

109243                           IMG_4428M

Above are two examples from my ”Cave Mood Board”

As far as my role as LA goes I have not done much more. From here on I will continue to produce mood boards and be transparent and communicate with the whole group to prevent having to cut more designs. I am of course also working on the other assets in the game and not only directing and deciding things (hehe).

That’s it for now I think. Sorry for the long post!

 

Byyyyyyeeeee!

Pixel Art

HIIIIII! Welcome to my short entry about Pixel art! ellen pixel test LARGE

Pixel art as implied by its name is limited to use only a few pixels when creating an artwork. the popular style has its roots in early video games when the designers were limited to 8 or 16bit graphics but it is still widely used in many platform games and RPGs.

As the Lead Artist for this project I immediately made the decision to make our game using pixel art. My main reasoning for this decision, apart from the fact that it appeals to me personally, is that it is easy to create coherent art between artists if we are limited to pixel art. In line with this I also theorized that the use of pixel art will make any difference in skill when using photoshop less visible.

To start off I asked Benjamin (see first entry) about his first approach to pixel art. I knew he was a beginner as well but he had already created some beautiful sprites. He recommended me the tutorial So You Want To Be A Pixel Artist by Author Tsugumo. As it turns out, there are endless of great tutorials on Pixel art just one google search away! Another tutorial I found helpful was this compilation of Pedro Medeiros GIF tutorials.

After that I tried to make my first pixel artwork, I kept the following key rules in mind that I had picked up from different tutorials;

  • use 2-5 colors per tile, the key is to use colors wisely as opposed to a lot
  • Mind the grid, try and make tiles which can be put next to any of the other tiles without creating a line or a gap where tile meets tile
  • Try to avoid monotony, if you make a few tiles with different oddities they will look more interesting AND realistic (relatively haha)

cave fish enemy large

This was the result, a blind cavefish. It has a little more than 5 colors (oops) but I am still pleased with my creation (especially the palette haha)

Other rules we decided on during pre-production was the size and resolution of all assets. Since every pixel counts it is difficult to alter a pixel designs size later on. Therefore, to avoid wasting time and effort to redraw any sprites, we decided on exact size and resolution before creating the finalized sprites.

The fact that I decided to use a style which my team have no or very little experience with is referred to as a ”Risk” within the SCRUM framework. I considered the severity of the risk beforehand. Based on what I had seen of Benjamins pixel sprites, combined with the experience I had with my own first attempt at creating a pixel sprite, I decided that it was worth it. When following the guidelines I had accumulated, it was neither overly complicated, nor time consuming. We also made a point to practice pixel art by making sprites for our game, which in worst case could be used as place holders if we for some reason decided to switch styles. So far I am very pleased with what we have created and I see no indication so far that we have taken on a too difficult task.

BYYYEEEEE!