Release Devlog

After many painstaking hours of programming, drawing, testing, bug fixing, and redesigning, here we are. Version 1.0.

This is an assessed piece for a University Assignment and as such may not be a standard devlog in design, although perhaps the process at which a university student may be interesting to the people browsing Itch.io

The game has turned out somewhat different than the original concept. It's hard not to be too ambitious when trying to come up with ideas for a game and naturally, I fell short of the content that I planned. That's not to say that I feel like I didn't do enough, as I still feel plenty proud of what I have made.

Game Concept Comparisons

Comparing key features.

Firstly the number of planned bosses was reduced from three to just one. It turns out that trying to balance 3 other units at University and making a game in around a month is quite difficult. I underestimated the amount of content you need to develop for just a single boss. This includes things from creating new sprites, objects, attacks, interactions, mechanics, animations... e.t.c, the list really goes on and it's a bit into development that I realized this. I imagine that if I had planned things out a bit more thoroughly it would have been an easier and much smoother experience.

I believe the controls for the game are how I wanted them to be. They feel responsive and it feels nice moving around and shooting at the boss. The flashes on hits with enemies and on the player add just that little bit of feedback that helps create a nice game feel.

I mentioned straightforward progression in my features, I explained this as having minimal "frivolous" activities between boss fights but seeing as how there is only one boss, that feature kind of doesn't exist. Nonetheless, I kept the idea alive by making it so the player can get straight into the action within 5 seconds of starting the game (assuming they know what they are pressing.) Going straight from the main menu to the first battle is three clicks plus a skippable tiny cutscene.

Clean and simple was a feature that in retrospect I am glad that I planned. It allowed me to keep a very simple, defined look for the game which played both into the fact that I am still practicing how to draw art assets and allow for visual elements in the game to appear distinct and readable by the player. This is important because a lot is happening at once in the game and the player needs to attempt to keep track of everything that is happening at once, which causes the need for carefully planned and designed visuals for the game.

The last feature is that the game is "short and sweet." I believe I successfully accomplished this. The game probably only takes 5-10 mins to complete, maybe even less. It could take longer if someone were to try and beat every difficulty, however.

Concept Art

In the end, the game actually ended up looking pretty much exactly how I wanted it to. The bosses and enemies all have this robotic dark metal sort of look I was going for, the general aesthetic is somewhat dark and oppressive with a small side of mystery.  significantly surpassing the general feel of the concept I had personally drawn in quality, atmosphere, and detail.

I ended up reusing the general design of the second boss for the enemies in the first boss which ended up working out quite well.

I did however remove the missile launchers from the boss's shoulders. while I believe this would add a lot visually, I didn't end up having the time to implement it.

Implementing the telegraphing for enemy attacks ended up working significantly better than initially planned, creating a smooth-looking system that shows where attacks will land.

Feedback and Testing

One of the most important things about the game to me was the balance. making sure that everything felt right to play and that the players felt like the difficulties were appropriate.

Results from the survey showed that most people thought that the difficulty was in the right place, so in the last week of finishing everything up, I tried to keep the difficulty pretty much the same for each difficulty level.

Another question I asked was if the players felt as if they understood how the game mechanics worked. In which everyone was saying yes they did. The game is relatively simple to understand but I still felt a moment of relief seeing it.

On the questions about how fun people thought the game is, most people seemed to rate it relatively highly.

When asked about what features to fix or add, most participants didn't note chose any of the options with only 2 people answering, picking that enemy variety was something they wanted. Unfortunately, I wasn't able to fit a new enemy into the boss fight as there just simply wasn't any way to squeeze in another mechanic without messing with the balance, and that's not to mention the limited amount of time I had left to create more content.

When asked about people's opinions on the art style of the game I was met with a variety of positive responses. some of which provided nice feedback on specific elements of the game such as "Visually appealing, the boss in particular has a menacing design. The graphics are simple, but well done, and allows many bullets and missiles to be on the screen without it being too cluttered."

Although only mentioned once, there was a trend in the attacks to force the player into the bottom center of the screen. I introduced some new attacks that forced the player out of the center which I feel made the fight feel a bit more interesting.

Assets

To start with I want to note that nigh everything, bar a shader, was hand-made by me. Unfortunately, this means that the game lacks sound, I had trouble sourcing audio that fit the game feel and actions in the game unfortunately the game, in its current state, lacks sound.

All of the art assets were drawn by me in a program called Aseprite, a pixel art software.

Enemies Sprites: consists of sprites for the Robot Boss, Robot Boss's hands, the drones, the missiles, and bosses laser beam attack. This also consists of the animations for each of these sprites.

Character Sprites: As I have used a somewhat unique method (and mostly unnoticed) to make it so the player can turn and face one direction while running in the other, the body and leg are split into different sets of sprites. There are exceptions where leg and upper body movements are never separate and as such are not separate sprites, in which I use the leg "object" to display the whole character's sprite.

Environment Sprites: This includes background assets, tile sprites for the tutorial levels, as well as the floor in the main scene.

Title Sprites: This includes the main title banner and the test tube/tank that is displayed on the main menu.

Tutorial Images: Includes screenshots of elements in the game, used for thumbnails in the tutorial menu.

UI Sprites: Includes health bar segments for the boss and the sprites for the instructions in the tutorial. This game didn't really use many custom UI sprites.

Etc: Other sprites include things such as masks which are used to hide certain UI elements or the telegraph sprite which loops on the object it is on. As well as the projectile sprite used for most projectiles in the game.

Scripts: Just where all my scripts are stored. There are 64 scripts so I don't plan to list them all, especially as not all of them are used in the final project due to changes in things used or perhaps some scripts made redundant by other features. Here are some of the more important ones:

• Basic movement - A script controlling the player's movements,
• BossOneAI - Contains most of the functionality of the Boss, including attack phases, attack timing, and various messily used variables.
• DamageEnemyOnCollision - Used on projectiles so that they damage enemies and destroy themselves
• DamagePlayerOnCollision - Used on enemy projectiles so that they damage the player and destroy themselves
• Fade - Controls the fade object used in most scenes to fade to the next scene. Also handles level transitions.
• FlashOnHIt - Used on any object that can be damaged to allow for the hit-flash effect.
• HealthDamageInteractions - Used as a base class for many objects' health scripts.
• LayerOrderByPlayer - Displays an object either in front of the player or behind, used by objects that the player can walk around.
• PlayerHealth - Handles more than just health, handles a part of how some of the animations work.

User Guide is in the description of the game

although I'd like to think that the in-game tutorial provides ample opportunity to find out how to play the game.