FMP Evaluation

Project name: Bullet Switch

Project period: 29/04/2019 – 14/06/2019

The end of the project is just around the corner with just the last view write-ups to do. To see how I did overall, read this post: FMP Update: How I Did Overall and to find out how all the levels look in its entirety, read this: FMP Update: New Levels and an Overview of the whole game.

Project concept

The project concept I made was not as clear as it could have been, because I didn’t explaining the type of research I would do or the mechanics in enough detail. I adjusted this a little after finishing it, which now includes the missing information and a more detailed purpose of the project.

The research I did, mostly related to my project concept, but some of them may have looked like it was for another project. This was because, I was exploring game design as well as level design.

Planning

The planning in my project was done was at a reasonable pace. I may have planned a bit too slowly at the start, including missing a few weekly tasks, but after I got to the fifth week, I filled in the rest in. The tasks then were asking myself for a bit too much.

When I planned the tasks I wanted to achieve, I did also plan for the practical aspects I would need, like on the 27/05/2019 (week 5) task, which was sketching level layouts. The practical aspects of that was paper, rubber and a pencil. The one things I didn’t mentioned, was I also needed cardboard and/or other objects for representing the objects in the game.

Here is the full plan filled in (except week 7):

I stuck to the plan almost entirely, but some of the times I did go a bit off track and added in more mechanics when it wasn’t in my plan. I did this because, it increased the quality of the level.

Not sticking to the plan fully maybe seen as a negative, but by not sticking to it entirely, I was able to improve level designs, puzzles and my knowledge much, much more than if I stuck to the plan.

What went right?

In the past couple of months I have made tremendous strides towards creating an amazing game. The following is what went right:

• Level design – The main purpose of this project was level design and I believe I did this correctly. The levels had a consistent goal and always kept challenging the player.

• Fairness – Continuing with level design is fairness of the game. I have tried to make the game as fair as possible.

• My original goal – I believe I have did most if not all of what I originally sent out for; A puzzle game that uses a small amount of mechanics in a multitude of ways.

• Mechanics – This wasn’t that necessary, but by creating a reasonable amount of mechanics made creating more puzzles easier and made them more diverse, which could be a problem if done too fast or/and incorrectly.

• Puzzles – The puzzles I made were good in my opinion and others. All that was needed doing was a little bit of tweaking.

What went wrong?

Even though so many things went right, there were somethings that didn’t go right. Here they are:

• Bugs/glitches/errors – The main issue I had were errors, but I did encounter some bugs with the software, which I did fix. It wasn’t all bad though, because I learnt how to solve them for future projects.

• Using mechanics – In the most part I used all the mechanics in the game to a large degree, but I could have used the slide and teleport mechanic a bit more. I would if I was given more time.

• Player feedback – I did include player feedback in the game audio-wise, but I didn’t include much visual player feedback.

Following on from the bugs/glitches/errors I had, these were the problems and solution (in no particular order):

• Shoot at mouse location not working properly – The solution to this was to learn about the Mouse Location node and work out how it could be done on my own.

• Teleporting infinite loop – A Boolean variable and a branch sorted this out.

• Character movement not working – By adding in the character movement to the level blueprint whenever I had a jump wall (technically a jump door) or slide fixed this issue, this is because, by giving the level blueprint the jump key, it takes ownership of that key, meaning no other blueprints can use them.

• Moving platform is buggy – The fix to this bug was very weird. To fix it I needed to reset the platform location and then start the movement, befote it goes back to step 1, otherwise it will go in the opposite direction than requested.

• Character jumping too high – A fix to this was adding a collision box in that when overlapped will reduce the characters velocity, which means that they will start falling faster.

• Music track mixing together/overflowing integer – The fix for this one is to create a controller, store the variables there and use a cast to retrieve the integer, which will be used to chose the song for that level. This will also stop overflowing from happening. The overflow bug seems to happen when you use a random integer node in the criteria of an equation.

What would I change and improve upon?

If I was able to edit the game more then I would change and improve the following:

• Improve player feedback – Adding more visual feedback in.

• Utilise mechanics more – I would start to use the mechanics I haven’t used that much to create more levels.

• More levels – I would add in more levels with more visual dialogue.

• Bigger music track – Increasing the size of the music track, but only adding suitable music.

• Make puzzles that trick/think out side the box – I didn’t really know what made a good level specifically and now I do I would deliberately try to trick the player or try to make players think outside the box.

• More puzzle combinations – I would also further develop the combinations of the mechanics to create more complex puzzles. I was starting to do this, but not in the same degree as I would like to if I had more time.

How important was the dialogue?

After talking to my colleagues I decided that it was not that important, but I should keep it in for the player to figure out the story.

A few comments I got were:

• Mathew, “I hate dialogue shoved in his face.”
• Thoughts – I have put this into my memory and will always try to make dialogue optional, unless it is important.

• Rhys, “I Like dialogue, but not when there are pages of it“
• Thoughts – I know where he is coming from with this comment, but sometimes pages upon pages of dialogue is necessary, but I will try to keep all dialogue small with only keeping in the important parts.

What have I learnt?

I have learnt a huge amount from this project from all areas in level design, game design and mechanical wise. Here are the following:

• Mouse events and inputs – I’ve learnt how to enable and disable mouse inputs and events. I used this for the shoot at mouse location function.

 

• Storing variables throughout the game – I have learnt how to store and use variables in any map in the game. This can be used for a currency system.

 

• Saving and loading – I haven’t used this yet, but I know how to save and load a game with any amount of variables I want stored

 

• HUDs – With the knowledge on knowing how HUDs are made and used, I know can make more advanced UI screens.

 

• Alter text – With this I can add in story and lore of a game.

 

• Good puzzle design – My puzzles have became more fun and challenging.

 

• Location change – I’ve learnt how to alter and set the players or object position. That is how I made moving platforms and portals.

 

• Arrays – I knew this already, but I have realised how useful they are, even with just 2 objects.

 

• Expand on a mechanic rather than make more mechanics – I have learnt how useful building on top of a mechanic can be. It is much easier building on top of a mechanic than making loads of nechanics to do the same thing.

 

• Paper prototypes importance – I have learnt how useful paper prototypes are, even though I like to just jump straight into things. I normally did just add in level designs straight away, but occasionally there were some I ignored or altered a bit. This showed me no matter how successful my level designs always are, there will always be one bad one or more in the bunch, which can waste a lot of time. The only downside to paper-prototyping is a ultra close deadline, which can be 1 day or lower. The reason for this is because, the time taken to get everything setup or made. In some cases the paper-prototyping will still be important in an ultra close deadline situation.

There are probably more, but I can’t think of them currently.

I am extremely happy with my results and wouldn’t have been able to learn as much if I didn’t deliberately focus on adding a mechanic in.