With the game finally being released and everything polished to an acceptable standard its time for me to ramble about how this project has shaped me as a developer over the last six months, if youd rather just play the game you can find it here – https://spritersblock.itch.io/blink-blade

Where to start… this last 6 months I have learnt so much about myself and where I want to be in the industry, originally I enjoyed programming and still do but I think my true passion may lay in design after this project, planning out levels on a whiteboard, coming up with new mechanics, enemies and experiences for players was extremely fun and challenging and something I now wish to pursue as a career. Over the last 6 months I’ve had the pleasure of working with a group of amazing peers to create something we can all be extremely proud of, I’ve learnt to trust my designs and have confidence in my ability to create things like levels and mechanics and also took on level design, something I did not want to try again after failing spectacularly in a previous project.

A big lesson I learnt during this is that its OK to scrap an idea that’s not working for the team and start fresh, I can’t imagine what would’ve happened had we stayed on our initial RPG project but I doubt we would have anything close to what we produced in Blink Blade. Scoping is something I am starting to get a bit more confidence in now as I am starting to understand my own work capacity and when things start stagnating for me creatively. I’ve found that taking some time to work on another level or design really helps me find my creative flow again.

This project has been awesome to work on and its a set of lessons and experiences that I will no doubt find invaluable in my career moving forward.

This was it, the last level the player would face, and you bet I wasn’t pulling punches with difficulty on this one, the mechanics for this level would change how the game played a small amount, instead of going at your own pace you are forced into moving with the boss as he progresses through the level, at various intervals he would throw mechanics at you that you already had experience with but with less time to react, this level would not be timed due these restrictions but instead was a test of endurance and skill for the player as there were no checkpoints, if you died you started again.

The Boss would have 4 stages, he started with summoning enemies to hinder the player, this wasn’t anything special as the player had dealt with worse before in previous areas, the boss then proceeded to an open room filled with imps and wood, he would then start firing at the player, this seemed to be the hardest part of the level, with both myself and most people failing on this part multiple times, this was followed by an area where the boss would flip gravity on the player every 5 or so seconds, this wan’t difficult on paper but by this point the player would be feeling the pressure and make very small but fatal mistakes, this area was less effective at defeating the player but proved to be difficult nonetheless. The final stage was the showdown between the player and the boss, the boss would lunge at the player and deflect any swords that hit his front side, the only way to beat him is to bounce the sword off the wall and hit him in the back, this stage of the level was extremely easy and more of a moment for the player to finally say a big **** you to the antagonist for what they just put the player through, this would be followed by the end game credits.

This level was sooo much fun to make, it was difficult enough that even I had trouble beating it while still being very achievable, there were no areas where the player didn’t know why they failed and most people would either push through with unwavering determination or cave and admit defeat.

Area #3 was exciting and worrying for me, we introduced the concept of gravity flipping on a timer and switches the player could use to flip it themselves, this brought up an point of interest for us on whether the players controls should change to mirror the current gravity state, after many discussions the controls remained the same so as not to confuse the player when nothing else in the game changes the controls. We also introduced the new enemy: the Gargoyle, this enemy would be still and inactive until the player got close, at which point it would animate and smash the ground, sending shockwaves in both directions, we found this paired well with the gravity flipping and the player would need to navigate around them with care as the gravity could send them straight into the Gargoyle if not careful.

When designing the levels for this area it was originally only going to be on a timer, but we soon found that switches gave the player freedom to explore the mechanic at their own pace, designing the levels in a way that the gravity wouldn’t make players wait was tough, again one of my focuses was sticking to my 30 second speed runs of the levels, to do this I needed to make sure the gravity would flip in a way that lost the player as little time as possible. I think the levels we ended up with for this area could have been better but time was running out and I couldn’t be as perfectionist as I was with the other areas.

Area #2 introduced two new things to the player, the first was a new wall tile that the sword would bounce off, the second was the new enemy: the Imp, this enemy would shoot at the player after a small delay when they get too close. The bouncy tile was something that was easy for me to design levels for on paper, but once I started testing the mechanic out it quickly became clear that in our game of speed and precision this mechanic was very chaotic and proved to be hard to get used for new players, I even found my success with some of my levels was lower than expected when testing them, eventually after getting some feedback we lowered the amount of bouncy tiles to allow for the player to more accurately know where to aim for the best results. I also tried to avoid the player having to wait for the sword to bounce between multiple tiles as our game felt best when the player was in a constant state of movement. To do this I tried to design the levels in a way that the player would only require a max of 2 bounces in most cases to navigate an obstacle, this proved effective but I think if I were to design them again I could further improve on this area.

Something that I got to do during this time was create a very basic set of design guidelines for the levels as other members of the team would jump in when they could to help, this consisted of things like how long the level should take, various tile arrangements that would cause issues and checkpoint frequency. This was something I hadn’t done for someone else before and I quite enjoyed the process of making it, I believe it helped a great deal as the levels that the other team members were able to make fit nicely with the design of my own.

Overall this area was both the most fun and hardest to design for out of our areas, the Imp wasn’t too hard to fit in but the bouncy tiles turned out to be harder to implement in a fun way than expected.

When designing these levels I was constricted to only using the core mechanics of the game, with this in mind I grabbed a whiteboard and started making single sketches of small platform puzzles, this was so we could potentially combine or edit these any way we like or just scrap them if they wouldn’t work, this design process helped me immensely throughout the rest of the project as it made making levels so much easier due to just pulling small sections from the whiteboard and adding in small connecting sections between each one. I also settled on a minimum amount of time the player would need to complete each level, the time I went with was on average 30 seconds for the fastest players, this meant that should hardcore players want to restart the level due to a mistake they wouldn’t be losing minutes of progress while still having enough level for the more casual players to experience and enjoy.

Area #1 really helped me to push what was possible with just our core mechanics and helped me make levels later on more difficult and fun. In my opinion these levels are the most polished in the game as I spent much more time with them discovering what our systems could do.

We decided that having a hub world to go back to after each level would be optimal for the style of game we are going for, we designed a few concepts including one where the player would hop between floating islands, each representing a theme for that set of levels. Eventually we decided on a smaller, more compact version with the setts of levels in each corner, this had the downside of needing to be rethought should we surpass four areas but it was a good design for what we needed at the time.

The Hub was also our show and tell platform for each of our weekly show off days in class, if we had mechanics or art that was not present in a level yet we would put it off to the side in the hub so everyone could see our progress even if it wasn’t in a fully made level.

The hub world would over go one final redesign and transformation into one that was very compact and featured each areas levels in the four corners, with the final boss door looming over the player right in the middle, I also had each areas art bleed into one another which i thought gave a really cool effect that is also shown in the final boss level.

After getting the movement mostly solidified we found we had no one specifically designated to designing and creating the levels for our game, as we already had a competent programmer I decided to take this role on as we did not think we would need two programmers on the project anymore. We started with a brief design day where we discussed how we wanted levels to play, then I started on designing our tutorial level. I designed the tutorial a bit haphazardly but with teaching the player the games mechanics in mind, this lead to mostly having floating text telling the player the controls paired with small challenges throughout to help prepare the player for the levels to come.

There’s been a solid amount of progress since my last post, the jump and movement has been completely overhauled to now include acceleration/deceleration and a much more tight feeling jump that doesn’t look or feel as floaty.

Something else I also got implemented during this time was the ability to speed up your decent while falling (hereby known as quick-falling), this was to give the player a snappy way of landing that was quick and precise, this came with some problems in terms of the players downward velocity increasing too much over a long period. I fixed this by limiting the players downward velocity and setting the players current velocity to max when quick-falling, this allows for easy balancing when needed.

This week is going to be a lot of bugfixing and getting a test level in to really push the limits of our movement system, I will post more progress shots at that time, see you next week!

So… After trying to design an RPG where the player stacks his party on top of each other, we realized that both the scope and design were causing us more trouble than it was worth to continue with that idea. After another ideation day we have decided to go with a new game, a 2D pixel art action platformer, where the player throws his sword and teleports to its location to navigate the level and defeat bad guys.

The last few days we got started on the prototype and already have the core mechanic working to an extent, the player shoots a projectile in the direction of the mouse and can teleport to it within a set time before it despawns, or hits a surface that it can stick into.

We hope to implement some fluid movement mechanics to compliment this along with adding enemies that the player can interact with. We want the overall feel of this game to be fast, fluid and most importantly fun!

So… its been a while since my last post on this game, but I finally have the combat at a stage I’m happy with! As much of a headache as it was I learned a lot and feel as though I’ve made great strides to improving my knowledge and skill in programming.

The combat now progresses through a state machine that tracks who’s turn it is and holds their chosen action and target, once the player has chosen for all three of his party members the enemies will then choose a random action with a random target. A problem quickly arose when i realized the enemies and players would beat the crap out of the fallen opposition doing essentially zero damage if their target gets defeated before their turn to attack it comes round.

To counter this I decided to have the game check each targets state before trying to damage them, and change targets if the one they have chosen has already been defeated (the headache this caused was immeasurable but we ended up figuring it out) this now happens for both enemies and players to keep things even.

So, a quick refresher for those that don’t know how our combat works:
-At the start of a round the player assigns each party member an action and a target.
-The actions are either SWORD, SHIELD or MAGIC.
– Combat then begins, the order of actions are as follows:
-Ally SHIELDS get applied, Enemy SHIELDS get applied
-Ally SWORD attacks, Enemy SWORD attacks
-Ally MAGIC attacks, Enemy SWORD attacks
-There are a few interactions that can occur during this time:
-If a SWORD attack hits a target that is about to use a MAGIC attack, the MAGIC attack is interrupted.
-If a SWORD attack hits a target that is SHIELDED and the users ATTACK stat is lower than the BLOCK stat of the person that shielded the target, the SWORD user will be STUNNED for the next turn and can not act.
-If a MAGIC attack hits a target that is being SHIELDED, the attack bypasses the defense of the target and deals normal damage. (Magic attacks can not be blocked)

As you can see I have a very unappealing UI set up until I get the art and 3D models from my artists but it functions mostly how the end product will (bar the animations, particle effects, damage numbers ect.)
Hopefully by the end of next week the game will be in a state where we have all the art and animations in along with some sound! I’m not sure whether we will be able to have everything else we wanted such as the event system ect. But at the very least the hardest work is done and we will get as much of the rest working as we can over the next few weeks, so watch this space for a build when its ready!!