Postmortem
|
We are at the end of the road after several months’ hard work, being happy and satisfied for finishing Aetherial on time. Making Aetherial has taught me many things both in and outside the art field. From the art perspective, I have learnt how to create assets that are coherent with the theme and the other artist’s work, the importance of picking the right colours, lighting/shadowing and animating. To be honest, animating was not my strongest side at start, and I have not created the easiest characters to animate. Often my characters didn’t have smooth moves. I struggled a lot, watched the same videos over and over again to create better movement, have problems with the sprite sheets and got lost in a little bit of chaos. One thing we could do better is to communicate better as artists to have a coherent style, or maybe sit down and draw together when needed. In general we did a good job, but we encountered some problems also. For example there was one time when I was supposed to draw the aether bar, and the other artist HP bar. And they turned out to be totally irrelevant, we decided not to use the HP bar. This would also prevent wasting time on assets we wouldn’t use. I can criticize myself for not creating coherent looking icons in game for pickups. For example I had to replace the original dash icon with an irrelevant one, because group’s opinion was it not communicating clearly that dash can be performed in all 4 directions. In the final presentation day it dawned on me that we could give that info by other means when they pick it up, like arrow symbols on the bottom of the screen. It was not worth to use an irrelevant icon. I also noticed it is equally important to spend time with programmers in order to implement the art into the game. When not explained properly, they can put assets to irrelevant places, or at wrong sizes. Outside the art field, it was interesting to work with the scrum and see how it affected our development process. I can tell it helped us to plan better, develop more flexible and work more systematically. Because of lack of experience, most times we were not able to estimate our actual working hours, or sometimes not be able to finish all the assets we picked up within a week. I noticed it is not good to estimate the time optimistically, because often unestimated things occured, i.e photoshop crashing, coffee in the house depleting, photoshop file corrupting. Mentioning corruption, another problem we went through was other artist drawing everything into single photoshop file without a backup, and photoshop file getting corrupted towards the development end. It was hard for him to redraw everything, and for this we had to skip putting some things we wanted in the game (like ship animations, because he had to redraw the ship all over again). This taught me to be more cautious. In the current game I’m working, I’m backing up the photoshop files in Google Drive and updating them periodically. Our scrum master also helped us with some tips and set more realistic goals. It was definitely useful to have someone with more experience showing the way. Stand up meetings and sprint plannings/reviews provided clear communication between team members, allowing to see where each member is at developing process, and schedule the tasks accordingly to work together. Playtesting sessions were useful to see how people react to our game, and get valuable feedback for both good and bad sides. The feedback we got graphics and programming-wise was usually positive, critics were mostly based on level design and difficulty. It was the hardest to adjust. Since we spent so much time with the game, it was easy for us to get lost in the process. Therefore having an outside perspective also helped us to see some things we overlooked. By analyzing the data from playtesting, we were able to optimize the assets, balance the mechanics and provide the players more visual feedback for their actions. Towards the end, we had the issue of our more experienced programmer leaving the team. This led to the conclusion of developing alternative solutions to our actual plans and not being able to put everything we created into the game. Our remaining programmer had little programming experience, therefore had problems with sprite sheets, so everything that was animated we had to exclude from the game. This was a bit upsetting after spending much time on creating some assets, but I try to see them as an exercise for creating better things in the future.  End result in my opinion was not bad, but it fails to satisfy me %100. It is hard to build a game as we exactly want in such short time, but it could be a lot better if the problems explained above didn’t occur. We also wanted to add a little narrative at start for people to understand the story, but we had to skip it due to lack of time. Nevertheless we had no fights or unpleasant moments within the group, which was a positive experience. It was nice to work in an environment where people listen and respect each other instead of creating drama. The experience I gained from making Aetherial is surely helping me at the moment when working on the arcade game.
// Merve Metinkol  |