BoltBoy: A Retrospective

 During this project, I, as well as my teammates, experienced many trials and tribulations while creating our game. Much was learned, and much has yet to be learned, and so I have decided to catalogue my end of the process on my blog.

Our first step was to write out a list prioritizing certain things over others, sorted into Must haves, Should haves, and Could haves. Though I no longer have this list available to me, some examples of its contents include "basic character movement", "simple obstacles" and "ability to die" in the must have section, "wall jump" and "advanced obstacles" in the should have section, and "collectible nuts" and "death counter" in the could have section. This directory assisted us in prioritizing what to implement and create first, and what should be left for only if we have extra time.

Next up was where my job began. my first task was to create the concept art for the titular character; bolt boy. The initial design I concocted for bolt boy was far too complex. it had a rather complex body, which would take far longer than we had to properly recreate in pixel art and animate into sprites. I resolved this issue by scrapping the body, and attaching little legs, and eventually tracks, to the head, producing the simple yet recognizable bolt boy we have today.

After this came the sprite creation process. Originally, my process contained only unshaded block colors, however, over the animating/spriting process, I learned to add darker and lighter shades to parts of my model, as these add detail and depth to a sprite while keeping the sprites composition relatively simple. I believe this has greatly improved my pixel art skills, as the current bolt boy sprites look far more vibrant and alive than previous iterations, which look flat and dull in comparison.

After creating the walking sprite, my next tasks were to create the jump, wall grind and idle animations. When creating these, I wanted to be a little more creative with my usage of bolt boy's components, particularly the bolt in his head. I resolved this by having the bolt move up and down at various speeds, adding distinctive differences between each animation, making them far more recognizable

Next, I created a Spinning Sawblade animation, which would represent the main hazard and source of death in most levels. though the pattern in the center was hard to make spin, I compensated by at least making the outer rim spin, giving the illusion of rotating saw teeth.

Finally, My last tasks were to create platforms, backgrounds and other assets for the levels, including broken bridge sprites for the falling platforms. In this task, I decided to go above and beyond, creating 5 different numbered stage backgrounds, as well as a door, platform sprite, platform end sprite, and 6 connecting broken bridge sprites for each stage, each tinted to the stage's colour. Each background also had a yellow and black hazard banner below it, serving as a simple form of environmental storytelling, communicating to the player that falling out of the world will result in death.

The intention of these background was that each stage would have a few levels using variations upon the same background. for example, stage one could be the introductory stage, introducing movement, wall jumping, and basic obstacles, like falling off the edge, whereas stage two could introduce the saw, and force the player to platform around circular saws, and stage three might introduce the falling platform.

However, almost all of this work ended up wasted, and the time I spent on it sits among my greatest regrets regarding this project. this is because one of our tutors suggested to our programmer and level assembler that instead of using a fixed background, they should have tiles that make up the background and can be repeated indefinitely. This somehow resulted in the project having a monotone grey background, and in cutouts of the bottom of the background being used as the platforms. ultimately, of the 40 bridge sprites I made, only one was used, that being the first connecting piece of the stage one falling bridge, which was used for every falling bridge piece.

A mock-up of how I expected my assets be used, with spirals in place
of the collectible nuts, which were never implemented 

This issue likely could have been remedied with better communication between team members regarding the current vision of what the game should be, and what assets are intended for. In the future, it may be beneficial to establish regular communication with teammates, and ensure that Design intentions are understood between teammates.

Another thing I learned is that it can be beneficial in the long term to acclimate oneself to better software and technology rather than sticking to more familiar systems. For example, all sprites made during this project were made using Piskel, a free-to-use online pixel art software that I used to middling effect in prior projects. However, after the project was complete, it was brought to my attention that a software called PyxelEdit could have been a lot more useful to my project, as it had features that make shading a lot easy, which was something I was doing manually up until that point. Had I used this software earlier, I could have shaded with much greater accuracy, and could have made more sprites in the same amount of time.

Overall, I've found that communication with teammates greatly adds to the cohesion of a team, and allows for greater team cohesion, and that acclimating to new software can free up time in the long run. This wisdom will help me in future endeavors, as I work on larger teams, on more complex projects, and with tighter deadlines.