IGB120

On the back of the playtesting and iteration - we completed all three levels. All bosses have unique abilities, all levels have a unique style and feel, the game plays a lot smoother and a lot of the bugs are resolved.

This was an intensive project, As I was primarily focused on coding and implementing new features, it was at times a bit overwhelming juggling deadlines for this project while also my actual life i.e. girlfriends, work, rent, cooking etc.

As noted in a previous post I think we were very ambitious for the scope - I think we achieved everything we set out to do however I think in future it would be a wise choice that we revise the MVP to be smaller in scale. If it were smaller it would allow for us to improve the existing features to a better extent, while also giving us the opportunity to add more in later as we would have a larger amount of time to develop.

I get the feeling this is what it must be like in the industry some times. Where the scope gets too big, creeping out of what was originally thought to be a contained idea. There are a considerable amount of moving parts when developing a game and honestly a fair few of those things don't get fully realized until you start working on it i.e. some of the bosses attacks were revised and designs were changed as we realized the capabilities of our team and the software we were using.

Ultimately I had a great time making our game - I think it has legs and could be made into something further :)

See it here on my Itch.io

From the playteesters we had our work cut out for us. Some of the major items we focused on fixing as per the feedback while also just incorporating the later levels.

Some of the notable features we changed were;

visuals

healthbar to bosses

a mini tutorial/hotbar with key button controls

feedback to the player so they knew when to pick up items vs what to avoid from enemies.

These items of iteration were things we were mildly aware of, the intention was always to change them but after hearing from outside testers it made it all the more prevalent that we needed to focus on them.

As mentioned before we also incorporated the two later levels, these were inclusive of entire new scenes with different backgrounds, different enemy types, new boss experiences.

We had multiple other students and friends playtest our game in various states. from this we obtained quite a lot of data thorough a Microsoft forum.

This is detailed heavily in our report so I will do my best to summarize it here.

We had various types of players ranging from people who play under ten and over 40 hours a week. Of this demographic not many were consistent players of our style of game 'bullet hell shooters' (think cup head).

From these playtests some of the biggest take aways we had were that items were tough to see on screen and discern from enemies, health bar needed for bosses, indication that you and or the enemies were taking damage and overall fixes to bugs.

We were also able to take away what features people thought were best, it was fairly split across the board - the visuals seemed to be the standout while the audio needed some touching up.

one of our playtests can be seen below:

As we approach the end of semester, we are working on assignment 3. This assignment is a group assessment item. My teammates are Isaac, Mazhar and Nishant. We are each studying different things, I believe Mazhar is studying a tech degree and Nishant a maths degree.

We have gone through some internal discussions on which assignment to take forward, as we each like our own projects putting it forward, we are all putting 3 pros and cons to each assignment and taking a vote. We wont be able to vote for ourselves to make things equal across the board.

Ultimately we are taking forward Isaacs project. His game is almost like a mixture between the asteroid style game and the racing game (A bullet hell game). We have each thrown our hat into the ring for separate roles we will take on, I myself will have a focus on programming, while assisting in areas such as the playtesting and artwork.

The games current state has some good bones to it. However our MVP has quite a large scope. I am hoping that I will be receiving some assistance in regards to the programming as both Nishant and Mazhar said that they would also be working in that area.

My concern is that the teams eyes may have been bigger than its collective stomach... There is a lot to implement in a short time... I am also not known to program (I have done some in C# and Unity), but I will take it in stride as its a good learning opportunity.

I once again have had a playtest of the racing game. I got Holly to play it and provide some feedback on how best to improve the game.

As can be seen from her comments there is a problem with difficulty. I need to balance the game further, provide some sort of indication when objects are going to appear on screen. Especially the ones that move faster than the rest of the obstacles. I also could see that she struggled to understand the controls right away, this would be benefitted through a tutorial which I will implement just to give newcomers an easy understanding before they start the actual game.

Regarding my one sheet and one page

The final version of my one sheet and one page stayed relatively true to the original design. I tried to keep it consistent so if anyone were reading them one after another there wouldn't be any sharp juxtaposition.

The third project came together quite cohesively. As can be seen from the video below, you are a skateboarder who is bombing down a hill. As you go down the hill you gain more speed and all the obstacles on the road come at you faster. These obstacles consist of potholes, cars, fallen over logs, animals off the from the side etc.

The goal is to go as long as possible, that is why a timer begins at the very start, and also encourages players to try again to get a better time. It seemed a little difficult at first just swerving left and right, so to add a bit of player control and another layer of gameplay, the player can ollie over oncoming obstacles. While they have ollied and are in the air, they lose all ability to move (as would happen in real life).

Additionally I completed some of the work for Assignment 2, I have decided that my platformer was the strongest of my gamers that I have designed. I also think narratively it has the most legs (pun intended). I figured it was easy enough to convey my game as a platformer even if I drew it all myself, I also believe my one sheet explains the game fairly well and anyone who were to pick it up, would have a full understanding of the game.

The Third project I will be making in IGB120 is a racing style game. I found this to be the most difficult idea to come up with, so I took inspiration from real world sports.

Similar to my previous Prototype, this will be more player-centric and cater to a wide audience. This will be designed with an emphasis on building to a higher score, with powerups to assist the player in surviving for as long as possible.

Thus the game will need to have tight controls that are easy to understand and can be picked up at any time. Aesthetically, I have learnt from previous prototypes that it is important that objects are easily identifiable to ensure the narrative is clear. For inspiration, I used games that were easy to pick up and function as endless runners i.e. temple run, subway surfers, doodle jump etc.

Title: Bombing Bandits Pitch: The game is a top-down racing game, where you are skateboards going down an increasingly dangerous hill. The game is an endless runner where you get increasingly faster as you race down the hill. Obstacles and powerups are randomly generated as the layout of the road changes and curves. Controls: Move around with W,A,S,D. Camera is top down over the player. Unique selling points: • Fast paced game where you try to get the best score. • Requires precision responses quick reactions • Taking a dangerous real-life sport and gamifying it.

As per my playtesters comments I have refined the game further. I focused on the gameplay aspects and the narrative. I still am to refine the graphic facility however I believe the title screen assists me in this aspect.

Gameplay refinements are as follows:

updated spawn locations, it makes it feel fairer. Everything should have a better spread across the board so they player feels more enticed to move around.

updated special attack, so it is not overpowered. It now acts as a cannon, slower fire rate but shoots through all floating objects.

updated lives to read as health, so it is easier understood.

The intent is to refine the graphics of the game, specifically the crackers that are flying around as they are not reflective of actual crackers.

I had two other playtesters reach out to me Evie C & Acelin B. They provided feeback without the template.

--------------------------------------------------------------------------

For Acelin: "The controls are easy to understand (I never read controls, they should be intuitive)

The level itself is a bit confusing, is it a bread board? A pizza? Felt like a pizza, but looked like a bread board, didnt really understand why it was either, maybe add some narative to this??

With everything spawning in random locations, it felt very chaotic & there was little reason to move. This kind of made it more feel like a tower defence game, but with nothing to defend.

Lives?? I assume this was meant to say "Health" or something like that

I like that the Olive goes for the Player, but it would often spawn right infront of the player & even when it spawned far away there did not seem to be a way to destroy it."

-------------------------------------------------------------------------

These were some very insightful comments from Acelin. I intend to go back and fix the lives to say health or even a health bar. I will need to increase the distance of the olive from the player as it is intended to make the player run away. As to the overaching narrative, I agree the visuals need further refinement, I think a title screen could assist with this process! -------------------------------------------------------------------------- For Evie: "the game was fun the fast paced nature was v enjoyable the olive rolling towards the player was a nice addition, I liked that difficulty

the only bug I found was that the special could spawn outside of the level bounds, and thus be inaccessible. The special could also be toned down a bit It is just completely broken"

--------------------------------------------------------------------------

Ok so kinda combining two elements here. First the development and the playtest! So development, I decided to see my prototype through and have a focus on progression instead more than anything else. This was achieved through the player getting 100 points respectively by destroying the objects on screen. These included cracker variants, cabonosi and the olive. They each gave different points with relation to the difficulty they caused i.e. large crackers are worth 1 point because they are simple, slow and easy targets while the olive, chases the player causing the player to flee while shooting and is worth 5 points. Additionally if they player gets the olive to half health it speeds up - if the player gets hit by it before its destroyed, it will damage the player and result in no additional score.

The other flying objects also inflict damage to the player. To make this simpler for the player I gave them 25 hit points and again the different objects/enemies resulted in different amounts of health lost.

Aside from a graphical overhaul (was a bit rushed, could definitely use more work), the other element that can be seen are the different scenes. There are 3 levels in this demo plus a victory screen/death screen. I felt this was necessary to ensure the player was aware of a goal.

Now for the playtest... My playtester again was my girlfriend Holly. It should be noted that she went into the game with an understanding of the elevator pitch.

The following can be found from her time playtesting.

My takeaways from her playtest comments are: 1. Obviously make barriers! 2. Create a more consistent style graphically! 3. Clearer instructions!

The second project I will be making in IGB120 is a asteroid style game. This was difficult to come up with an idea...

Again it is a bit of a ridiculous concept but I again have leaned into the readings to have some inspiration and guidance.

My game this time will be more player-centric and ideally cater to all, regardless of skill level. I want this game to be more fun and cozy, have an emphasis on getting to the end rather than slogging through a difficult mechanic. This design will be catered to those who just want switch their brain off and relax.

Thus the design and style of the game will be the most important aspect of my game, which will revolve around a cute art style and relaxing music. For inspiration, I was trying to think of a goofy game - I kept going to Binding of Isaac, which was the wrong kind of goofy... So ultimately I cam up with this.

Title: Char-Shoot-Arie

Pitch: The game is a top down survival shooter game, where you are a sentient piece of cheese. Your goal is to be as inedible as possible while defending edible combinations of food that make you more likely to be eaten. You will let flies land on you to power you up, while avoiding and destroying pieces of crackers, jams, meats etc. As you progress you will move to larger and more complex charcuterie boards.

Controls: Move around with W,S,A,D. Shoot with left click, special attack with right click. Space to dodge roll.

Unique selling points: • Cozy/silly game style for easy engagement with both younger and older people. • Progression through levels, to more difficult and exciting challenges. • Quick and fun gameplay like ‘Binding of Isaac’.

After having the playtesters play, there are definite attributes to improve upon when taking this game further.

The most glaring elements I see, are the lack of indication when it comes to the parry mechanic, the limitation regarding verticality and variety when taking the game further.

Thankfully, I have some ideas for how I will tackle these.

Firstly the parry mechanic indicator. I think this can be resolved with a background/subtle tells through heights of objects. I would not want to explicitly tell the player how and when to parry but if I can subconsciously tell them, I think that will be a great improvement. To add to this - I think an animation in the character for the window when the parry is actioned. That way again it teaches the player without expressly telling them.

Secondly verticality. I actually think this will be the hardest but the most rewarding update. My idea is to have the character be able to parry in 360 degrees. How will this be achieved? Well, the intent will be that the mouse will act as a directional tool while the player is in the air, and so they will be able to rotate the character and deflect in any direction. I think this will also assist in improving the movement system i.e. a well timed parry will direct the character.

After implementing my tutorial section, and some audio, I got two playtesters to play through the game.

One was a classmate (Gabe Falconieri) and the other my girlfriend (Holly Dorsett). Unfortunately due to how the playtesting was done, I was unable to review Gabes experience first hand, but based on his scores I would say he enjoyed his experience and came away with some great insights for me and how to develop my game further.

Gabe - Playtest

He easily understood the main mechanic of the game and enjoyed the concept as a whole. I agree that to improve elements of my game is probably the timing window of the parrying mechanic (this is also something I witnessed first hand with Hollys experience). Additionally I agree with the inclusion of some vertical hazards and potential for vertical mobility - I haven't yet figured out how to code this in. It is something Ideally would like to incorporate, similar to the game "Getting over it".

Holly - Playtest

Holly had a bit more difficulty with the game overall, and I did have to tweak the timing window for the parry mechanic. I think she still enjoyed the experience overall, but did have some trouble leaving personal bias at the door.

As per her comments, she understood all the mechanics as the tutorial was clear and concise. I did note that one of the text notes can be easily missed, so in future I will extend the timer so the player can read it for longer (in case they miss it).

I agree with her comments of elements to improve. It appears mainly to revolve around level design that revolves around the momentum gained by the parry mechanic. I again concur with her thoughts on overall aesthetics being overhauled and more story driven elements. I have ideas for how to incorporate the story beats and as per the "Game Design Workshop" book, have more dramatic elements to involve the player.

Ok so some bigger updates plus a minor play test in class which I intend to explore further with more playtests before going into huge detail.

Firstly I have read through chapters 3,4, & 5 of Game Design Workshop book. There is quiet a lot to touch on so I will try and make this as cohesive and concise as possible.

The larger elements I have covered in this update that is referenced by the book is the objective based game design. Providing clearer instructions to the player in regards to rules, systems and mechanics within the game. This is in the form of a tutorial section - enclosing the player in a space until they fulfill a certain amount of tasks. This is so they get a basic understanding of the game with the boundaries that are built into it i.e. movement, obstacles, enemies etc.

Regarding chapters 4 & 5, I feel like my game will come to explore these elements as the design progresses. Dramatic elements for example, I figure would best be told with character back story and the drive of their character.

As the game is a bit bare on that front, how I would like to show it thus far is the challenges presented, so the player can fill in the blanks. I.e. you are a knight that has swords for legs and no arms, yet he is crusading around as an adventurer. Where they take it from there is truly up to them.

Chapter 5 went more into system dynamics. This is an element I excited to work on further! At the moment, the changes in environment is purely from different obstacle variants and added complexity.

Eventually I would like to incorporate different materials that effect the character and alternative pathing for them to get from the start to the finish.

Just wanted to jot this down before the thought leaves. I have been considering the playability of my game, an item of note is that the parry window when falling onto the spikes feels somewhat unfair/hard to determine.

I have thought of two potential solutions:

have an animation play when space bar is pressed. this will be representative of a parry, when the connection to the spike happens a secondary animation plays to show a successful parry

having an indicator of when to hit parry (this can be removed later when players get a feel for the game). Say for example you can time it with a bacground texture.

I will probably have a combination of the two, so it feels fair to the player.

Additionally there is another element of the game which I think is unfair to the player, and as the textbook says - the player needs to come first - I do not need the game to be DOA...

when the player falls onto the spikes, it; firstly doesnt feel like the connection is there (there needs to be a minor bit of overlap), secondly if the player falls from higher up, the recoil needs to be relevant with the inclusion of gravity i.e. you fall 3 meters, you bounce back 2.5m. You fall 10m, you bounce back 9m. It needs to be relevant and not a fixed number as it currently is...

Ok so there are still a bunch of things wrong with the prototype, but I am still working through them. Otherwise I have made some updates:

it so the player can only press space once in the air, if they mistime it they will hit the spikes.

There is a new obstacle, it is positioned to shoot at the player and the player can parry off of them

The player must also time their parry/attacks to defeat enemies.

This will hopefully open up a bucnh of level design creative options. However the biggest difficulty I am facing at the moment is that the player can hold down space bar when over the spikes... Kinda defeats the purpose of timing anything.

Anyway that is a future problem to resolve, in general sense, majority of the game is functioning correctly, it just feels very 'proof of concept' phase.

It has been about a week, and I been learning Aesprite to make a character model. It has been tough learning to animate, especially when your character does not have conventional moving methods. Having no arms and stiff legs made it difficult to convey the movement so I ultimately decided upon the inclusion of a cape as well as a feather in the helmet to give the appearance of moving clothes in the wind.

I also added an idle animation for when the character is still, it is subtle but I prefer characters doing something other than standing in a T-pose.

I additionally have added a swipe of the sword while in air, this will function so that when the character bounces off spikes, it will give the illusions that they are (for a lack of a better term) parrying.

I have been fiddling with the code so currently the jump mechanic is not working. Ideally I want it so that the player cannot hold the space bar, instead they need to rely on their own timing. This is a work in progress, so my next update will ideally fix that and will have some level design implemented.