Blog #6 The postmortem 2

After all these weeks of stress and hard work, the project has finally come to an end. In my final blog post I will cover what both the team and me individually have learned throughout the development process of Into the fog.

Where to begin? At the beginning! Very early into the project during a design meeting the group had a discussion about scoping. We have chosen a concept document of Umibozu, as we believed it was designed with small teams like ourselves in mind. We desperately needed something that could be coded by a sole programmer, as we didn’t want to put too much pressure on him. It later turned out to be a good choice, as with some changes to the original concept we were able to scope the game perfectly to our respective skill sets. I can gladly say that we were able to implement all the features that we have originally planned without cutting any content at all. What we have learned from this is that it’s important to be aware of our own limitations and be realistic when planning the project. It’s most likely better to use extra time to add extra features or polish existing ones rather then deliver an unfinished product.

Another thing we have learned is the importance of learning at least the basics of more then one fields, especially when working in smaller teams. One of our group members has completely disregarded the project and refused to work throughout most of it’s duration, and the rest of us was forced to finish this members sprints for him. This resulted in many after hours spent doing things outside our respective minors, and thought us the value of becoming cross-functional individuals.

Additionally, I myself have learned the importance of hard work, and it’s superiority to talent. Our programmer (for clarification, I am not by any means saying that he is not talented!) was the only person in our group with any knowledge about coding, thus he was left alone with a huge amount of work which none of the group members were able to help him with. As a result, he was spending many additional hours after our group meetings to work on the game. Before the Alpha presentation, I have learned that he has spent the entire night working on the game so that we would be able to present all the required features and avoid being terminated as a group. Even though because of this I have gained a lot of respect and appreciation for him, I also grew very concerned for his well being. Later that day we had a conversation regarding it and from that moment I would routinely check up on him to make sure that he wasn’t working too much. Over the course of the past few months, I have seen him grow from a beginner to a seasoned programmer, which he has earned with hard work and dedication, and thus I learned that as a manager I will rather surround myself with individuals with ambitions and determination to reach their goals rather then people who rely on their natural talents.

Apart from more personal experiences and lessons, I have very mixed feelings about the end result of this project. On one hand, we managed to implement every feature we have planned for in the beginning, without having to scrap any ideas. On the other hand, the game ended up feeling more like a visual novel with gameplay on top of it rather than a traditional shoot-em up. It still had all the elements of the genre, however due to lack of experience among the team members everything was always finalized last-minute, thus we didn’t have enough time to properly test the game. In the end, it turned out visually pleasing and atmospheric, but it didn’t give players the experience we originally aimed for. We ended up creating a shoot-em up game that felt differently then it’s equivalents, giving it a unique touch. Nonetheless, I am personally happy with the final result knowing the game was finished in such a short period of time with a team of merely 3 people.

To conclude, throughout the development process of Into the fog I have learned a lot about group dynamics, importance of planning and scoping, value of individuals and hard work, how crucial it is to know ourselves and our own limitations and finally what it truly means to become a team and care for one another’s well being. However, the most important lesson I have learned related to game design is that sometimes it’s better to scrap an idea or a feature to be able to iterate and test the remaining content and polish it properly before deployment.

Mateusz

Blog #6 Comment

Hi Siri!
First of all, I really like how you were able to recognize your mistakes and find something positive about them, like the confusion regarding navigation through the level. I have also enjoyed the fact that you were able to bring in the MDA in to the picture, as I occasionally found it difficult to do it myself. Being a member of a small team myself, I can relate to the section were you mentioned the importance roles and responsibilities. I believe these situations are when cross-functional teams always shine above the others, at least to a degree. I can also relate to the section about the value of sharing a work space. In my group we have neglected this early on, and once we finally found time to work together the efficiency skyrocketed through the roof! The amount of tweaks and additional features you can do within minutes while everybody is present in the same room can be quite astonishing.

To conclude, I really enjoyed your post as you not only included pictures, but also mentioned many things I could personally relate to. I can’t point out any mistakes or flaws. Good job!

Blog #6 The Postmortem

After all these weeks of stress and hard work, the project has finally come to an end. In my final blog post I will cover what both the team and me individually have learned throughout the development process of Into the fog.

Where to begin? At the beginning! Very early into the project during a design meeting the group had a discussion about scoping. We have chosen a concept document of Umibozu, as we believed it was designed with small teams like ourselves in mind. We desperately needed something that could be coded by a sole programmer, as we didn’t want to put too much pressure on him. It later turned out to be a good choice, as with some changes to the original concept we were able to scope the game perfectly to our respective skill sets. I can gladly say that we were able to implement all the features that we have originally planned without cutting any content at all. What we have learned from this is that it’s important to be aware of our own limitations and be realistic when planning the project. It’s most likely better to use extra time to add extra features or polish existing ones rather then deliver an unfinished product.

Another thing we have learned is the importance of learning at least the basics of more then one fields, especially when working in smaller teams. One of our group members has completely disregarded the project and refused to work throughout most of it’s duration, and the rest of us was forced to finish this members sprints for him. This resulted in many after hours spent doing things outside our respective minors, and thought us the value of becoming cross-functional individuals.

Additionally, I myself have learned the importance of hard work, and it’s superiority to talent. Our programmer (for clarification, I am not by any means saying that he is not talented!) was the only person in our group with any knowledge about coding, thus he was left alone with a huge amount of work which none of the group members were able to help him with. As a result, he was spending many additional hours after our group meetings to work on the game. Before the Alpha presentation, I have learned that he has spent the entire night working on the game so that we would be able to present all the required features and avoid being terminated as a group. Even though because of this I have gained a lot of respect and appreciation for him, I also grew very concerned for his well being. Later that day we had a conversation regarding it and from that moment I would routinely check up on him to make sure that he wasn’t working too much. Over the course of the past few months, I have seen him grow from a beginner to a seasoned programmer, which he has earned with hard work and dedication, and thus I learned that as a manager I will rather surround myself with individuals with ambitions and determination to reach their goals rather then people who rely on their natural talents.

To conclude, throughout the development process of Into the fog I have learned a lot about group dynamics, importance of planning and scoping, value of individuals and hard work, how crucial it is to know ourselves and our own limitations and finally what it truly means to become a team and care for one another’s well being.

Mateusz

Blog #5 Comment

Hi Alec!

I’d like to start by saying that I can really relate to your post. In my group the situation with playtesting was reversed, as we were in need of extra time during the Alpha playtesting, while we were fairly prepared for the Beta playtest. Playtesting doesn’t always serve it’s purpose when the product isn’t quite ready yet, and it can be very frustrating when you know you won’t be getting the feedback you’d hope for because of this.

Outside of that, I really enjoyed your post. You clearly took your time to give proper examples so that the reader would understand what exactly was the issue and what you have learned from your alpha playtest session. To my understanding you really took the feedback to heart and did your best to improve your game based on it. As we have been told over and over, it’s crucial to adapt to the situation and make the best of it.

To conclude, your post was very well written, and I can’t find anything to complain about. Good job!

Blog #5 Playtesting

In this blog post I will cover my experiences with both playtesting sessions of Into the fog.

Firstly, I am very grateful that we got an opportunity to conduct playtesting during the course, however I believe that making it mandatory isn’t the greatest idea. Because of it’s small size, my group has run into many obstacles during the early stages of development, most of which were code-related. Unfortunately we have arrived to the Alpha playtesting with the bare minimum amount features in place, and we were aware of every issue mentioned by the playtesters. Because of this, the entire playtest session turned out useless, as we could have spent that day creating more content rather then nodding continuously as we were given the very same feedback over and over again. Putting all that aside however, having your game tested by people outside the development team is a great opportunity to learn and gather important data, which will later help you improve your product. Gaining perspective is crucial as there is only so much you can foresee when playing your own creation. Every individual that gets a change to play your game has different experiences and a different approach to each respective genre, thus you are almost guaranteed to receive some constructive criticism, which is always greatly appreciated.

After the first playtesting session, the group has decided reallocate some of the responsibilities among the team members, hoping that it would maximize our efficiency. It turned out to be a good move as the game has gone through some very drastic changes within the following few weeks and it was barely recognizable when people got a change to play it during the Beta playtest. This time around we were able ask playtesters much more valuable questions and as a result gather far more useful feedback. The data we have gather included feedback about the player movement, enemies, projectiles, power-ups, level design, UI and the fog feature. This playtesting session left us with a lot of great new ideas and solutions to issues that have been on our shoulders for quite a while, giving us an opportunity to tweak the game to improve the player experience, as well as learn a lot about different ways people choose to approach certain obstacles in video games.

To conclude, even though first time around we didn’t have much to present, the playtesting overall has turned out very helpful not only for improving our game, but also for drawing conclusions from our design choices so that we can learn from our mistakes and use these new experiences in our future projects.

Mateusz

Blog #4 The cutscene

In this post I will be covering my process of creating art for the final cutscene for Into the fog. Since we are a small group with only one artist, I have decided to help out with drawing illustrations to maximize team efficiency.

In the beginning, to speed up the drawing process I began by browsing through my folder of concept arts which I usually use for inspiration, however this time I decided to use a technique common among concept artists, which is using a picture or a collage with desired values as a base for your drawing. This is usually done to speed up the early stages of creating a concept art, as conceptual artists are often working under enormous time constraints. I have decided to use the piece below. Unfortunately I do not know the artist’s name, as my inspirations folder is a gigantic unorganized mess.

After finding a base for the illustration, my first step was to figure out the perspective and the composition. I really liked the camera in the original and I decided to keep it as it was. As they say – if it’s not broken, don’t fix it! Next, I started drawing out all unwanted areas to get sense  of space and composition. I drew out the character and the massive trees and added mountains in the background to give it some additional depth, and then added a few trees using a simple tree brush.

Next, I added a water texture to get rid of the platforms by pasting in a photo of water and skewing it with the selection tool. I have also added a foreground tree to indicate the distance between the camera and the background. Once again I used a tree brush to save time.

Since the basic composition was done, I decided to finally add in the star of the cutscene – the monster. The concept art for this creature was done by our lead artist Kaspar, however I had to alter it a little to make it work with this particular scenery. I have also added a few more trees behind the monster to fill out the empty space.

At this point I have grown a little dissatisfied with values of the trees and the monster, so I decided to darken them up a little to give them an extra push. A little touch-up with a smooth round brush to create a fog gave it an eerie atmosphere. I have also added black stripes to give the scene a cinematic feeling.

In the next step, I added in a hovercraft in the foreground, as it was very important to include the player in the scene. Little touch ups were done here and there to push extra details and hide various imperfections and brush strokes.

At this point, most elements were already in place, and only details were missing. I have added new details to the creature, as I felt as it didn’t pop out as much as it should have. Some shadows, details around the eyes and raising tentacles gave me the desired results.

In the last step I added water dripping down the monster to emphasize it’s size and the  impact of it emerging from the water on the surrounding environment. I also decided to erase one of it’s tentacles, as it felt a little out of place. Lastly I have added extra water ripples for the dramatic effect.

Done! 🙂

Mateusz

Blog #4 comment

Hi Anton!

I understand your concerns with leaving the island during such and important moment, it’s not exactly a dream come true for someone responsible for the team, nonetheless I can tell you have prepared well. Letting your team know about your departure a month before it happened was very wise, preventing any bad surprises. In my opinion allocating some of the responsibilities among the lead roles was a great idea, since it not only took some of the weight off your shoulders, but might have also been a good learning experience for these individuals.

It’s very difficult for me to comment your post any further, as I find it difficult to point any mistakes or anything I’d like to see improved. One thing I felt was missing is information about your sprint during the week, however it’s not exactly what your focus has been, thus I don’t see it as a necessity. Overall it’s a well written post, with no typos or any other mistakes. Good job!

Blog #3 comment

To begin with, I find that your post is very straight forward, and there isn’t really much I’m able to comment on. I enjoyed the fact that you have bothered to explain the basics of Scrum, as proper explanations are something I have definitely missed in my own posts. Also, I can very well understand the confusion regarding using a new framework, as we’ve been thrown into it without having a course dedicated to it, or even at least a proper introduction. Nonetheless, as I have understood from your post, seems like you have handled it very well without any major issues. Mentioning how daily meetings have helped you recognize and solve issues quickly assures me that agile frameworks are worth exploring – it truly makes our lives easier when we get updates on daily bases. Outside of that, besides a few small typos I can’t really find anything to complain about, good post! Cheers!

Blog #2 comment

I’m gonna start by saying that it’s a very interesting choice of topic. Being responsible for sound in my project, and having a little bit of experience with it in the past I know exactly how important it is to put in the time and effort if you want the game to feel as good as possible. I also understand how tedious and boring it can be, though I never had to mix the sounds within code (not for long).

When it comes to writing, I have little to none reasons to criticize your post. The introduction was very clear and well written, including a brief description of the task at hand and the importance of it being done right. You have later described the entire process very thoroughly, guiding the reader through every step of the way. I like that you have given multiple examples of the lines of code, described the their basic functionality and even included a picture. It has definitely made it much easier for me to understand what you have done. Finally, the video showing the results of your work prove your previous reasoning from the introduction. All those visual examples you have used made me realize how I have shot myself in the foot not including them in my own blogs. Big mistake.

I’m glad I had a chance to read your entry before I began implementing sounds myself, as I have been told in the past that sounds in Unity can be edited in the preexisting editor, which made me underestimate the workload necessary to tweak the details which are supposed to enhance the player experience. I also appreciate the warning about the Unity Collaborate feature, it has been noted! I will definitely go back to this blog later on to seek guidelines, as I want to take as much weight as I can from my programmers back.

To conclude, I there is nothing I can really complain about your blog post. The information was well written and clear, and so were the different examples. The writing could have been a little more formal, however since scientific writing was not a requirement for this assignment, I’d say the entry was quite flawless. Good job!

Blog #1 comment

First of all, a great post! You seem to care a lot for proper preparation and team feedback before any works gets done, which is definitely a big plus for your group. I really enjoyed the overview of your key features, and it’s a really interesting example that you have used as well. Breaking down artifacts into smaller components seems like a great way to reduce possibility of miscommunication/misunderstanding, and I will definitely try it out as well.

The writing is great, and besides a little typo I really have nothing else to point out here. Also, The way you have presented the example from your document (the key features section) was very refreshing, and I think it’s a great substitute for pictures, as it is difficult for us managers to showcase our work with visual mediums.

To conclude, I could not find anything to really critique, as the writing is great and the post seemed very straight forward. Good job!