Comment #6: Felix Rahm

Uncategorized

https://felixrahmvideogameblog.wordpress.com/2018/03/22/postmortem-on-behemoth/comment-page-1/#comment-27

Hey Felix!
Overall I think that the post mortem report that you wrote clearly describes the struggles that many of us, game design students, can relate to. Firstly, having to go through the development process with having all the graphical responsibility on your shoulders, might prove quite the challenge,especially on your first video game project But nevertheless, you managed to pull through and do a really great job. I really enjoyed the animations that you created for Behemoth and I am very impressed with the amount of detail you put into your work.
Secondly, after playing your game at the playtesting sessions, all I can say is that art-wise it looks very good. Even though you had to rely on your team´s game designer for some of the artwork, the final result is remarkable.
Finally, I respect your attitude towards the assets you made for the game. Despite the fact that the project is fairly done, it seems that your are unhappy with how everything turned out. Which only shows how ambitious and hard working you really are and that you never settle for less quality even when time is running out, or worse people drop off from the project.
Good luck in the development of your next game!
Cheers!
Petrut

Post Mortem

5SD064

LOGO

After nine weeks of continuous frustration, hard work and dedication, the Aetherial video game was finally realized. It took a lot of determination from every team member, but in the end the results paid off. Our group managed to finish the development of the shoot ‘em up project in time and the upcoming gradings will show if we succeeded or not in fulfilling the requirements.

During the process of development, I managed to encounter many unexpected difficulties that could have resulted in a backlash regarding the completion of the game. First and foremost, while the sprint planning gave a very exact idea of what was expected for the upcoming week, estimating the hours it would take for the completion of every asset proved to be hard. As a consequence, many of the art assets that were required in the days before the sprint review were not completed, therefore I felt the need to work on weekends to prevent falling back on schedule even further. This was mostly due to the lack of experience in creating the in-game sprites and animating them. Constantly underestimating the amount of work hours that were needed for each item created stressful situations which in turn resulted in the necessity of finding shortcuts. If it were not for the urgency of the weekly sprint review checklist, I would still not have learned how to use software such as Adobe After Effects, that helped in creating quick animations and that to this day proves to be indispensable in my workflow. Being fairly new to digital drawing and forced to create art assets for video games without specific technical knowledge given to me, I had to teach myself how to use different art creation software in order to achieve the given goals. This was one of the positive things that resulted from this process.

Secondly, it became very clear that in order to create a well balanced game, it is absolutely necessary to have several playtests with people outside of the development circle. Being in contact with the game you are making at a daily basis, leads to getting used with all the aspects, even the bad ones. The game difficulty could also be included in this category, since most of our playtesters from the second session reported that completing all the three levels was practically impossible. Therefore, it was needed to reiterate the level design and adjust the health system and damage settings for the final presentation. But this was not the only issue regarding game mechanics. Testers have also helped us in tweaking the movement of the ship which the player controls, by giving us necessary feedback. Another mistake that was done as a result of in group playtesting was not providing a control scheme for the playtesting session. For us, the developers, the controls felt quite intuitive but apparently that was not the case. As a consequence, a short tutorial was introduced in the final build in the form of gameplay, where we showed illustrations that represented the buttons the player had to press.

Finally, the game development process was heavily influenced by the group dynamic and at the same time suffered from it. In some specific cases, because of the lack of communication between the members of the group, several game ideas were not suggested properly therefore resulting in work conflicts, such as two programmers coding for the same item in the sprint planning which resulted in a serious waste of time and eventually having to reiterate each other’s progress in order to reach a common ground.

In conclusion, during these past two months I managed to conceive an approximate image of what is needed for the production of a video game. From artistic skills, the ability to master different software packages in short periods of time, to the importance of playtesting outside of the group and, the most important, making things work within the team despite of the personality clashes, being part of group Archon has proved to contribute quite massively to my development as an individual artist, as well as a team member. The knowledge that I have gained producing the Aetherial game will be of much use and value for the upcoming development of the arcade game.

The final result proved to be a game that I was proud of.  It was unfinished from many points of view but a great piece of work for being the first full length video game project that any of the members have ever made. It had a few bugs in which the player ship would collapse into the game objects or beyond the outer frame of the game area. It was also poorly balanced from a game design’s perspective. The power up bar depleted too fast and the power pickups were not spawned often enough to help the player survive through the levels. During the final playtest, not too many players managed to reach the final level, not to even mention defeating the final boss and completing the game.  From a graphic point of view the game lacked some animations states for one of the enemy. The timing of the death and dash animation of the player was off by a couple of seconds due to my lack of experience in implementing assets into Unity and leaving that task at the hand of the programmers who were already to busy with other items on the backlog list. Many of the particle effects in the game were made in a hurry and did not exactly fit with our predefined aesthetic.

Nonetheless, considering the fact that we had so little time to work on a 2d shoot’ em project with other colleagues that shared the same experience in making video games, the final result turned out to be something to be very glad of.

Comment #5: Marie Colin

Uncategorized

https://mariecolingotland.wordpress.com/2018/03/07/playtesting/comment-page-1/#comment-11

Hey Marie!

I really enjoyed reading your blog post about playtesting and how it helped you in making decisions regarding the development. I have always liked the idea you and your group was pushing forward in terms of the aesthetics for the game.
Unlike other versions of Umibozu that I have seen, the way you have implemented the paper textures and the book pages concept, made it very unique. I also appreciate how you took every feedback you got from playtesting into consideration when making graphical decisions. For example, in the case of the “pick ups”, the transformation you made from the simple black and gray boxes to the water lilies, that represented the separate abilities, was very inspired and I think it suits the general mood of the game quite well.
I wish you great luck in this last week of production and I hope you will be able to implement all your ideas into the game despite the short time you have on your hands until the deadline.

Bye!

Playtesting

5SD064

Having our game played by other students has been a great opportunity for us to receive a lot of constructive feedback, which was taken into consideration and later analyzed in order to make the right adjustments to the game mechanics in accordance with the advice we received following the playtesting session. Being one of the developers of a video game means that you often get the opportunity to playtest it in the hopes of finding bugs or other strange behaviors that need some twitches to improve the game. It is essential that you get a good sense of how playing the game feels so that you can make changes along the way accordingly.

However, being constantly in touch with the game you are creating and playtesting it every day means that you also get really used to some of the bad mechanics, like movement or shooting for example. It is not until your game gets played by other people outside the development circle, that you realize some things are slightly off. For example, it did not occur to us to give playtesters a tutorial regarding the control scheme as we were already quite used to it and did not feel the need for that. Some played through the whole level without even being aware of specific features. We just relied on the fact that the control layout was intuitive for someone who has played shoot em up games in the past, and we assumed that everyone had the same naturality when it comes to figuring out how to control a video game. However, this is not always the case. Considering the feedback we got from the players, we made sure to include instructions to guide and to provide the players with enough knowledge for them to be able to take on the challenge.

So to answer this week’s topic request, playtesting is the only way for us to discover what is not working properly in the game and what needs to be done to correct the issue. It has proven useful for tweaking certain values such as: fire rate, damage, enemy spawning, movement and so on. What needs to be remembered from now on is that we also need to let other people have a go at it, otherwise we will trap ourselves in a bubble thinking that the game is perfect just the way it was developed, and we will not be able to improve the final product.

See you next week!

Comment #4: Ellen Wetterholm

Uncategorized

https://buriburifarm.wordpress.com/2018/03/01/animation-cycles/

Hej!

Reading your posts feels like being part of whatever you are doing, they make the reader feel like going through the same troubles along the process as you do, which makes them become more active, rather than just a passive reader or a responsible and conscious Graphics minor reading this because they must. It also feels very relatable because, as you have already touched on, we are all amateur designers and we are continuously seeking ways and methods to ease our work, and more often than not we end up using the harder method, rather than just following the recommendations and instructions that we are given. From the perspective of a graphic student, it is nice to see that other people try to save up time by using shortcuts and wind up opposite to where they have started, the same way I do, heh. Animations do require a lot of effort and attention, and the way you write about your experience with it, it makes it feel like it is a very easy job to do. Your writing flow is very nice and pleasant and it seems like you really enjoy blogging your way through Game Development, which is worthy of appreciation. It is also admirable that you acknowledge and own up to every mistake you make and you are very eager to improve yourself and your work. I could easily see how an ordinary person with no experience in the field of game design could also relate to what you are expressing through the post and that is a very helpful skill in communicating with people who may have different interests than you.

It has been a light and very enjoyable read!

Petrut

Background layering

5SD064, Uncategorized

Entry Journal 2018/03/01

In this week’s blog post I will be touching upon the background sprites that I have created for Aetherial. As you probably know by now, the game me and my group are developing is a 2D side scrolling shoot em up, where the player controls a flying vessel that shoots down aliens from the sky.

In order to create the feeling of depth, the background had to be drawn by using multiple layers of content. Much as in the example below.

hqdefault

That is a screenshot representing the same technique used by the animators from Disney. By stacking up multiple layers of drawings and moving them separately at different speeds, it gives the illusion of a 3D picture.

 

pxVijIt

Picture taken from here.

As you can see in the GIF above, although what you are looking at is a 2D image, not a 3D one, using the parallaxing method creates the sense of depth that we are trying to replicate in our game.

Creating the background sprites for the game proved to be simpler than I had previously imagined, probably because I used a different approach. Instead of drawing small sized images that could have been easily attached together to create a long side scroller on which the player had a lot of free space to roam in, I wanted to create the whole scene at once.  This way everything would have tied in together perfectly and would have looked consistent throughout the process. Hopefully, the performance of the game won’t be affected too much by the big images that have to be rendered. Since the player would have to have a lot of space to travel before getting at the end of the game play scene, I decided to create the background ten times bigger than the Full HD screen. The sprites in question have been made on a 19200x1080p canvas with a resolution of 300dpi.

BACKGROUNDMOUNTAINSCLOUD2CLOUD3CLOUD1

These are just a few of the background layers that will be implemented into the game. As you can see, the background turns from the lighter colors representing the sunset into more darker tones towards the end of the game, where the player will meet the final enemy boss. I wanted to give the player the feeling of fighting at high altitudes in a quite epic environment. Besides adding a lot of clouds to the background, I also wanted to add snowy mountain peaks at the bottom of the screen. This is still a work in progress and there will be more elements added for the final background scene. At the moment, the layers work very well in creating the depth feeling when tested in Unity, so fingers crossed everything will work just fine until the game is finished.

That was it for this week’s blog.

See ya!

Comment #3: Carl Leong

Uncategorized

https://carlgraphicscourse.wordpress.com/2018/02/22/the-scrumptious-parts-of-scrum/

Hi Carl!

Overall I liked your blog post describing the way the SCRUM method works for you and I generally share the same feelings regarding this subject. However, when referring to how the development method is based upon previous cycles I find it quite hard understanding the issue of not being able to work on specific goals until the sprint is completed. From my point of view the whole basis of Agile planning is to revisit some of the items, that have a high priority and have not been completed in time, in the upcoming week. This results in progress being made until the item in question respects the definition of DONE. What I have learned through this way of working is that no matter if the asset in question is completed, implementing it into the game and testing could lead to you (as a graphic artist) having to make slight changes in order to fit the criteria. And that is where we share the same feeling of frustration.
Finally, I would like to point out that the way you described how SCRUM has influenced your work flow is pretty good and gives insight on how working with a team for game development really is.
Good luck with your project!

Raileanu Petrut

Comment #2: Alexander Sinn

Uncategorized

https://shirovfx.wordpress.com/2018/02/15/creating-an-unfogettable-ambient/

Hallo!

This blog entry is very cool! The way you describe what you are doing is both a narrative and a technical description, which is very pleasant and enjoyable to read. You describe very nicely each step that leads to the final decision and seeing that you are not really content with the result (even though the fog looks pretty damn nice and it expresses a lot of feeling), but you are eager to improve in the future is a useful skill that will pay off in the end. The fog seems to express a serene and peaceful feeling, like the calm before the storm, which undoubtedly sets the player on the edge and brings mystery and adrenaline to the experience of the game. I have really enjoyed reading this post and I am very excited to see what you come up with next. Keep up the good work because it looks beautiful so far!!

PS: Sick FX skills by the way!

Petrut

Comment #1: Mikael Ferroukhi

Uncategorized

https://gamedesignbugbear998722415.wordpress.com/2018/02/07/game-design-journal-1/

Bonsoir, monsieur!

I have really enjoyed reading this blog entry. The writing style is very concise, explanatory, and easy to understand, which I think makes your post accessible to a larger group of people, not necessarily just your group members or other Game Design students. You present a clear explanation of the process behind coming up with this idea, even though I would have liked to read more about the decision of using contrasting designs to express different feels. It feels like the post suddenly ends, since there is no specific conclusion or ending point, just a little piece of advice to keep in mind in the future. Personally, I would have also preferred if you had elaborated more on how you and your team came up with the game aesthetic. Blurring the characters is a very interesting and good idea, which makes the whole game experience more appealing and mysterious and it keeps the player on the edge. The post flows nicely and the photos help create a good image of the whole game. Very well done on your first post and I am looking forward to your next one. Good luck with the game!

Petrut

Nothing to see here

5SD064

Today I am going to touch upon the framework that has helped us successfully progress in creating our game, Aetherial. The thing that has our backs all the time and keeps us all organized and continuously engaged with the game is Scrum.

Scrum is an agile framework used in product development, where teams make use of sprint goals in order to achieve a common goal. Each product is divided into user stories, which are a representation of what the team expects from the final product. According to the established user stories a goal is set, which means splitting the user stories into assignments. A sprint is the basic unit of development in Scrum. The sprint represents a time boxed assignment that each member of the team establishes for themselves at the beginning of one week and continues to carry on throughout it, in order to achieve the pre-established goal. It is a time restrained assignment that the members set for themselves and take the responsibility to fulfil in a specific duration of time. For example, every Monday, me and my team have an one hour sprint planning meeting, where we discuss and decide upon our tasks for the next days. My assignment for this sprint was to make animations for the player’s avatar death, dash (special ability) and idle, which I have already finished. Another target is to make the game background, as well as parallax players, which are in the making at the moment. To keep track of the progress we make, there is a 5 minute stand up meeting everyday, where we go through the following questions:

  • what we did the day before
  • what (if there are any) problems we encountered
  • what we are doing today

picFrom my perspective, the Scrum method is very useful. It has helped me become more time conscious when I am working on something, hence I am more organised and productive. Moreover, it has motivated me to challenge and push myself even more in order to finish work in time, or even earlier than expected. It is also a way of developing better relations with the other team members, as we communicate and collaborate most of the time.

However, this does not always guarantee success. From personal experience I can say that underestimating the time budget is a constant problem. After getting appointed with a specific development task, I find myself quite optimistic regarding the progress that has to be done until the sprint deadline, but as time passes, I come to the conclusion that a greater amount of work hours is needed.

That’s it for this week. Until next time!