rileym-igb220

[rileym-igb220]

Assessment 3 - Postmortem

Application of Reading During Our Design Process

Our main inspirations from the readings during the design process came from the iterative design process Fullerton (2018) described within her book. We, as seen in the playtesting post, performed early playtesting to try and fix issues and refine mechanics prior to performing deep playtesting. This was a very good choice as there were some major issues with the game’s visual warnings and communications to the player (the colors and card countering). Overall, this application of the readings was a great choice by the team; as we managed to put forward a more refined and playable prototype for deep playtesting than we would have.

What I would change about the Development Process

The main factor I would change about the manner in which we underwent the development process would be the iterative design element. It helped immensely with identifying and removing issues early in development; but applying it further would have greatly helped I believe. As we may have been able to remove the issues with the tutorial before performing deep playtesting; hence allowing us to further investigate other issues with the design of the game, rather than the communication of it.

What I would change about the Final Prototype

Honestly, I believe, from seeing the playtests, that the main gameplay loop may get tiresome and repetitive after a while; leading to stagnation and boredom from players (Fullerton, 2018). As a result of this observation, I would have liked to diversify the obstacles more; hence providing a variety of challenges for the players to face, and diversifying the experience. This does not mean adding additional card types, it means adding multiple types of offensive/defensive/neutral obstacles for the player to face. Overall, however, I was pretty content with the final prototype, and I am looking forward to applying all the experience and knowledge I have gained to all my future projects.

[rileym-igb220]

Assessment 3 Iteration & Playtesting

Early Playtesting

During the beginning of our development, we took after Fullerton’s (2018) idea of iterative “playcentric” design and continuously play-tested and modified our game’s systems, visuals and mechanics.

A good example of this is the card system and its countering effects towards obstacles. We decided, after a small playtest with our tutor and some other of our peers, that it required a simpler approach and visual indication. This lead us into adding colored banners that appear when an obstacle approaches; indicating what type of card to use. After explaining the system to one of my roommates, and allowing them to playtest the prototype, it appeared to work in a much more effective and successful manner.

Planned Deep Playtesting

Once the prototype was refined enough, we began our deep playtesting stage. This involved approaching individuals, who were naive to the existence of our project, and allowing them to playtest the game. Tymon brought together a variety of materials for these tests; including scripts, questionnaires and surveys. Whilst he did this, Michael and I performed some final changes to the prototype and set up recording programs to record the player’s gameplay.

The playtesting went very well, with most playtesters being very happy to try out our game. Tymon read through the scripts whilst I took notes and ran the players through the survey and questionnaires; and Michael recorded the timing.

In total, we recorded 12 total play-tests; with 2 of those being shallow (with the players not playing past the tutorial). During this process, we identified many issues with the game’s design and prototype. These included:

- The Tutorial Lacking sufficient guidance to the players

- The game’s controls not appearing to be easy to learn and,

- The “Scatter” Defensive Obstacle being too difficult for player to dodge when they are traveling slowly.

These issues were later addressed in the playtesting report, in which we proposed a variety of solutions. Overall, however, the game was received mostly well by the playtesters; with most stating it was very enjoyable to play.

[rileym-igb220]

Assessment 3 - Development

Game Concept Selection

For the third assessment, I formed a group with Tymon C and Dong (Michael) D; two fellow students whom I had met previously.

We decided, after some discussion, that we could combine mine and Tymon’s ideas into a single concept; my idea, as seen in assessment 2, being the card-based racing game and Tymon’s being a platforming zombie shooter.

In the end, we utilised the concept of Get Gone and injected a zombie apocalypse scenario into the story-line; in turn, creating “Car-ds”.

One major change, we also incorporated, was the ability for the player to counteract the obstacles they face utilizing their power-up cards. This was based around a “rock paper scissors” system, with cards and obstacles taking the form of Defensive, Offensive or Neutral (the throws).

We eventually simplified this to have certain colored cards be most effective against their corresponding colored obstacles. For example; a yellow card would be most effective against a yellow obstacle. We made this change as a result of a naive playtest with our tutor; which demonstrated some confusion with the “rock paper scissors” system. Such as seen below:

Development and Preparations for Playtesting

To start, we organized an online spreadsheet to keep track of our work; delegating work evenly to each of us. In summary, Tymon was in charge of artwork and the playtesting report setup, Michael was in charge of most of the programming, and I was in charge of sound design, the trailer and the remainder of the programming.

As of this post, the game is completed to a play-testable state; with 3 functional levels (with a difficulty curve), 7 unique power-up cards (in 3 different types), 3 different obstacle types and some basic sound design.

In addition to this, I scripted an “AI Director” in a similar, yet much simpler, vein to Left 4 Dead 2 (Valve, 2009). This was based around slightly increasing and decreasing the difficulty based on the player’s performance. It also contained a bias variable, meaning that it preferred certain obstacle types depending on what level the player was playing; allowing the them to predict, and hence, outplay the Director, and possibly, feel a larger sense of achievement.

Furthermore, I also created a cut scene that play’s on the game’s opening; it purpose being to set up the story-line and give the player context on the game they are about to play. It is not of the highest quality, but other areas of the game also required time to work on; hence, certain aspects were rushed.

Overall, I am looking forward to the playtesting phase of development; as we will be able to perform some more iterative development, hopefully, allowing our game to reach an even higher quality.

[rileym-igb220]

Assessment 2 Progress

Prototype Choice and Alterations

I have decided to use the “Get Gone” prototype as the basis for my Sell Sheet and One Page. I will tweak the idea slightly, however, with the power-up system being changed into a card based system; allowing for a more real world equivalent for the players to draw connections to. Aside from that, the prototype will not change much; with only additional levels and a more in depth difficulty curve being possible additions.

Progress on Overall Content

So far I have created a 3D Render to place in the background and planned out all of the content for the Sell Sheet and One Page and sketched out basic design ideas.

Here is the 3D Render:

[rileym-igb220]

Get Gone - Postmortem & Playtesting

Design Process and Application of Readings

The main application of the readings occurred in the conceptualization phase of the design process; with Fullerton’s (2018) theory of types of decisions and iterative design model having an effect. The main concept of synergistic power-ups mixed with car racing action was an attempt to mix fast-paced gameplay with meaningful and informed decisions; conceptually forming a mixed and more engaging gameplay experience (Fullerton, 2018). The iterative design process, on the other hand, mainly influenced the process of coming up with the concept; with constant checks with others in my degree and my peers to check if the idea was of any value before I developed.I also play-tested with my peers during the earlier stages of the prototype; mainly to ensure that the gameplay was what I intended it to be.

Considered Changes to Overall Design and Process

As far as considered changes go, I think the design and development process was quite successful. I, again, utilised Trello and iterated on my prototype as it was developed; in turn, organizing my time efficiently and fixing any design issues as they appeared. This helped when there was an issue involving the car’s movement speed, which lead to me introducing a drifting mechanic; where the player can move sideways faster at the cost of speed.

Playtesting Results and Reflections

Sienna Wilton

Found the style very game-boy-esk, and very polished. Found some of the power-ups confusing, and could not discern their purpose. Found an issue with the bounds of the game, discovered that you could leave the screen and not have the grass slow you down. Overall, this playtest was enlightening and very good to hear; as alot of effort was put into replicating the pixelated and 8-bit aesthetic.

Dong Dao (Michael)

Found the main mechanic, artwork and sound design very engaging. Felt overpowered compared to the obstacles that faced him due to the lack of balancing with the power-ups.

Overall, this playtest, aside from the balancing issues, turned out pretty well. Michael also found that the lanes were too wide, allowing him to drive forever; but luckily this was not an issue with the main mechanic or design.

[rileym-igb220]

Get Gone - Development

GDevelop Struggles

Concerning GDevelop, there were only a few struggles I came across during this week of development; one of which was mainly as a result of my inexperience with the program.

More specifically, when a player hits another car, the original intention was for the other car to spin out of control and have the ability to hit other cars; causing chain reactions and pileups. However, I struggled with the physics system. I managed to make the cars spin-out, but there were too many issues with cars interacting with each other after they had spun out. So now, cars lose control, but do not cause other cars to crash after they have been hit. This may break some immersion during gameplay, but this is just a prototype; hence, it is only a minor issue.

GDevelop Learnings

During the course of development this week, I have come to learn more and more about how to utilize GDevelop’s many systems.

Firstly, I learnt quite a substantial amount about the “Effects” system and how it only applies to certain layers. I used this knowledge to create “Speed Lines”, as seen above, only to the grass layer (as to not obstruct the player’s vision).

Secondly, I learnt that there are multiple event types within GDevelop’s event-based scripting interface. Some include the repeat and “for each” loops, which came in very handy with moving around the car objects to suitable locations.

Lastly, I attained further knowledge about the sound effects system; using the pitch variable to add the illusion of the car’s RPM increasing with the player’s speed.

Applications and Inspirations from Readings

As well as applying Fullerton’s (2018) theory surrounding the different types of decisions (i.e. Informed and Uninformed), I also got some inspiration from Lazzaro’s (2004) 4 keys to fun. This involved investigating how to mix Hard Fun and Easy Fun (i.e. Fun through difficulty and fun through curiosity). I incorporated hard fun through a very basic balancing feedback system; this being, as the player accelerates and gains speed, obstacles travel at them faster. On the other hand, I also incorporated curiosity based fun through the player’s ability to experiment with the powerup synergies. The mix of these two types of fun has produced an interesting and possibly more engaging experience.

On a side note, the inclusion of the car crash physics also adds a small amount of curiosity based fun; as smashing cars off the road is surprisingly satisfying.

[rileym-igb220]

Get Gone - Elevator Pitch

Get Gone is going to be an action-racing game where the player controls a getaway driver, driving an experimental racing car, as they evade the police after a heist.

The main mechanic will center around random the power-ups the car generates during their escape.The player must use them tactically (as they only have two slots to store them in) and in a synergistic manner to last longer in their escape, For example, one power-up may give the car invulnerability when it goes over a certain speed, and another may be a basic speed boost. Used separately, they are handy; but used together, the player will be invulnerable for a much longer period of time.

The main PX goal is for the player to feel as if their decisions matter immensely; risking waiting for a better power-up may be game-ending... or incredibly rewarding. The game will take on a pixelated/retro style in both its sound design and art; and will mainly be targeted for lovers of classic arcade games and lovers of racing games.

[rileym-igb220]

Recharge - Postmortem

Effects of Readings on Design Process

Throughout the design process, I drew much inspiration from readings and the general array of topics discussed in lectures.

As mentioned before, the conceptual basis for the weapon pickup system was formed around the “Roles of Players” idea outlined by Fullerton (2018). I wanted to harness the theory that altering a player’s role, in this case their weapon, could change their experience in the game; and use it to keep the player’s experience differing constantly (to keep gameplay fresh). However, this idea did require some tweaking (due to various issues discovered in playtesting); and luckily, I was able to formulate solutions.

One issue, in particular, was the lack of consequences player choice had. The design of the weapon pickup system made it virtually impossible to choose what weapons you wanted to use. This was good for constantly changing the player’s “role” as planned; but players found the constant changing of weapons irritating to deal with. This is where Fullerton’s description and identification of Hollow Decisions proved very useful; as I was yet to recognize that players become more engaged when their decisions actually affect the game world. In the end, this lead to me introducing the ammunition system and making weapon pickups disappear after a short amount of time; hence, giving player choice actual consequences. I would have very much enjoyed finding a more innovative way to respond to this issue; but the majority of my solutions were too large to incorporate with the small amount of time I had left.

One solution, which I came up with after incorporating the ammunition system, was to create a system similar to that of Tetris‘s block feed. Conceptually, once a player ran out of ammunition, they would automatically be given a random weapon (instead of a new block).

Thoughts about the Development Process

Compared to the last prototype, I underwent a more iterative approach to the development process. I ran some small, naive and shallow playtesting sessions early on in development of the prototype; which lead to me recognizing some minor issues more earlier on than I would have. I also organized the overall workload more effectively; using Trello to keep track of what I had to get done by the date of the scheduled playtesting session in-workshop.

The one thing I would change about the development process would be the amount of time I spent conceptualizing. I felt that certain minor aspects of the game could have been paid more attention to; such as the movement, and weapon design. These elements were relatively rushed, and little to no thought was put into making them support the PX goal. In the end, I believe I managed my time effectively; but there is still some room for improvement.

Changes to the final Prototype

As mentioned above, I did not spend much time thinking about making interesting and fun-to-use weaponry for the game... and this is something I regret. As the prototype stands right now, it mainly aims to make players feel a sensation of fiero (as in a thrill in overcoming adverse conditions) rather than more gimmicky/curiosity based fun. I would have liked to include more of the latter via goofy weaponry; as I think it would have made for a more diverse gameplay experience. In the end, however, I am content with the final prototype. It does lack replay-ability due to its repetitive gameplay loop and, in my opinion, bland selection of weapons; but it fulfilled the goals I set out to achieve.

Another issue, as mentioned in an earlier post, was related to gameplay stagnation as a result of the shield recharge mechanic. I never incorporated a solution to this issue, with the gameplay loop (as mentioned above) still playing very monotonously. If I were to fix this issue, I would, as Fullerton suggested, introduce random events to occur during gameplay; hence, diversifying the gameplay loop.

[rileym-igb220]

Recharge - Finalisation

Finalisation of Prototype

To finish up the prototype, I added some sound effects to supply more feedback to the player; and tackled some of the issues I discovered related to the core design.

These issues being:

1. The presence of Hollow Decisions (occasions where player choices have no consequences (Fullerton, 2018)).

2. Unwanted weapon pickups creating emergent challenges was found to be more irritating than enjoyable.

3. Gameplay was found to be repetitive and not engaging (potentially due to a lack of release (downtime) to go with the games ever increasing intensity).

Weapon Pickup Changes

Weapon pickups now disappear after a short amount of time. This, in turn, removes opportunities for Hollow Decisions to form; allowing the player to choose whether or not they actually want the weapon being offered. If they do want the weapon, they can run into it. If they do not, they can avoid it until it disappears. This also eliminates the second issue, as now, unwanted pickups only form emergent challenges for a short period of time.

However, I did discover another potential issue when I was playtesting this version of the game; I tended to stick with the same weapon for the duration of the playthrough, as I was not forced to cycle through them. This lead to a much more monotonous experience than I wanted for players.

I considered balancing the weapons to be at an equal level of enticement to each-other, but instead decided to add an ammunition system.

Weapon Ammunition System

This new system limits the number of shots a player can take with a specific weapon pickup before they lose it and gain back the default starting weapon; this forces them to use the majority of pickups offered to them by the game. This, in turn, keeps the Player-Roles changing; encouraging a constantly differing gameplay experience (Fullerton, 2018) as planned in the elevator pitch.

Difficulties with Repetitive Gameplay

In the end, when it came to improving the monotonous and repetitive gameplay; I struggled. I implemented a difficulty system which gives the player sections of rest after a climax of action (based on the idea of tension and release discussed in the Week 3 Lecture); but this only partially fixed the issue. Gameplay now supplied a slight feeling of fiero, but due to the repetitive nature of the gameplay loop itself, this could only improve so much.

On the topic of the “Tension and Release” inspired difficulty system, I implemented it by adding a hidden “difficulty index” which works in the background of the game. This index determines the maximum number and top speed of asteroids, and incrementally increases by one every 20 seconds. Once the index reaches a certain value, it drops back by a factor of four and begins incrementing again. Every time the index drops back, this certain value increases by two. This formed a difficulty curve which reaches a high point in intensity, followed by it dropping slightly back to allow time for the player to recover. It can be seen visualized below.

Overall, I managed to alter and add to the game’s systems to solve two of the main issues; but the gameplay is still very repetitive.

Sound Design

On a more positive note, I created some sounds for all weapons, for when the player picks up a new weapon and for when the player destroys an asteroid. I was going to add a few sounds in regard to the shield’s status, but their inclusion proved rather irritating during gameplay. I also made the weapon sounds increase in pitch when the player is running low on ammunition, to assist in their awareness.

[rileym-igb220]

Recharge Development & Reflection on Learnings and Playtesting

So far I have successfully incorporated, in a bare bones way, all aspects of the concept. The shield diminishes every second and the player must destroy the asteroids to recharge it. I experimented slightly with a maximum value the shield could have, but in the end decided against it (as it made the game hard beyond accessibility); hence, I made the shield’s maximum value increase to fit whatever number the player has ‘recharged’ it to.

Development of Recharge Prototype & Playtesting’s Effect

As stated above, the prototype is in its final stages of development. All that remains are additional weapon types and sound effects. However, recently I asked some people to playtest the game (in line with a more iterative design approach outlined by Fullerton (2018)) and found some design flaws which I had not considered.

Firstly, when a weapon pickup appears that the player does not want, some players saw it as more of a nuisance to avoid than an engaging challenge; which is not in line with what I aimed for.

Secondly, the gameplay, although varied with the variety of weapons, still appeared stale and repetitive; I theorized this was most likely as a result of too much tension, and no release.

Lastly, the game also gives the player a large amount of Hollow Decisions (meaning the player has no real affect on the consequences, no matter their choices (Fullerton, 2018)); as they, whether they decide they want a new weapon or not, are forced to pick up all new weapons eventually (as all pickups follow the player).

Applying Unit Learnings to Design Issues

Firstly, in regards to the irritating weapon pickup system, I decided that the player should not be forced to switch weapons whenever a new pickup appears. This will be implemented via the weapon pickups disappearing after a short amount of time; allowing players to avoid them until they are not an option/obstacle anymore.

This may cause players to fall into a more monotonous loop of using their same favorite weapon time and time again; but that can be counteracted via balancing. This solution will also solve the issues regarding hollow decisions throughout gameplay, as the player can now actually choose whether to take or leave the weapon; the consequences actually changing depending on their choice.

Secondly, in regards to the stale and repetitive gameplay, I decided that I would aim to embrace the idea of tension and release (discussed in the week 3 lecture). I will do this by giving the player high moments of intensity, followed by low moments for them to recover. This will, hopefully, encourage a feeling of fiero within players; as they overcome difficult moments.

Issue of Stagnation

One extra issue with the design, which I discerned from the playtesting, is in relation to the recharging shield mechanic.The constant reinforcing loop when the player is achieving well can leave them in a type of stagnation of repetitive and boring gameplay (as outlined by Fullerton (2018)). To alter this, Fullerton (2018) suggests creating random events to take gameplay in different directions; hence removing the repetitiveness of the situation.

GDevelop Learnings

In regards to GDevelop, I had no struggles with the program this time around. All the scripting for the mechanics was relatively simple compared to the procedural generation and AI I tried to achieve when developing Reciprocate. Overall, I think the biggest change here is that I have learnt to scope down my projects.

[rileym-igb220]

Recharge - Elevator Pitch

Recharge is an asteroids-like game, where the player will need to destroy  meteors to recharge their constantly diminishing shield. Hence, forcing them to feel a sense of haste an aggression within the game-play; as once their shield runs out, they are vulnerable to death by 1-hit.

The main objective for the player in recharge is to last for as long as possible, with their total time survived being their score. There will only be one level, with a variety of weapons to keep game-play varied. New weapons pickups will follow the player, and will be picked up by running over them to maintain a simplistic control scheme, and to keep the player on their toes if they have a preference for their current weapon. This will also force the player to differ their play style occasionally, allowing for some more emergent challenges.

Aesthetic and Control Scheme

The game will take on a neon-pixelated style, with 8-bit sound effects. The main controls will be the W, A, S and D keys for movement; and the mouse to aim and fire.

3 Main Selling Points

-  Fast Paced and Aggressive Gameplay

-  Plenty of Room for Players to be Tactical in their Gameplay Choices

-  The Variety of Weapons Allows for a Variety of Emergent Challenges

Inspiration From Readings and Doom 2016

The main inspirations for the ideation of this concept were the “Glory Kill” system in Doom 2016 and a section of theory outlined by Fullerton (2018).

In the Doom 2016 “Glory Kill” mechanic, players are rewarded with health pickups when killing enemies in a specific way; creating aggressive, yet tactical, game-play scenarios. I thought of this idea when forming the “kill enemies to recharge shield” mechanic.

The section of theory, discussed by Fullerton (2018), contributed to the weapon pickup system. The theory suggested that the Roles of Players (e.g. classes in an MMO) have a massive effect on players’ experiences in game; as each role spawns a varied gameplay. This was essential in the inclusion of the weapon pickup system; as, in theory, whenever a player picks up a different weapon, they are given a “different role” in a way. This will potentially spawn varied gameplay experiences within the same playthrough; possibly counteracting the repetitive nature of the generic Asteroids gameplay loop.

[rileym-igb220]

Reciprocate - Postmortem

Inspirations during Design Process

One inspiration was the concept of balancing feedback loops; as outlined by Fullerton (2018). Balancing feedback loops involve a incentivizing the player when they fail (or punishing them when they succeed), allowing them to either recover and overcome the obstacles they are facing (or begin to struggle and enjoy a more challenging experience). This concept is often utilized in multiplayer games, such as Left 4 Dead 2 or Mario Kart to create a more engaging and balanced experience. However, I wanted to try and input this concept into a single player game.

This was central to the creation of the main mechanic; where on taking damage, the player was rewarded with a new weapon. This may have backfired slightly; as when players are hit by an enemy, who’s weapon they do not want, they receive, conceptually, negative feedback. Overall, excluding that note, I think I harnessed the concept pretty well. More skilled players, whom take less damage, are stuck with the same weapon for a large duration of time; which, if the prototype was fully developed, would lead to more intense game-play as the difficulty increases. As for the less skilled players, they are supported when they take damage; allowing them to potentially last longer.

What would I change about the development process?

A large change/alteration to my design process I wish I implemented earlier is also outlined by Fullerton (2018); the concept of Iterative Design. This means incorporating outside feedback (such as play-testing results) very early on in the design/development process; allowing any oversights, such as clunky controls or poorly thought out mechanics, to be addressed early. Incorporating this would have allowed for a more refined prototype, as it had some issues when it came to the central mechanic (see the above section). In the end, I will be doing more minor play-testing with my future prototypes to ensure a more refined final product.

Potential Design Changes for Prototype

One area I would definitely like to alter in the prototype is the enemies. I would have preferred to have a larger deviation between the weapons they give the player, as this would almost cause a change in roles for the player whenever they take damage; which Fullerton (2018) suggested keeps gameplay experiences differed.

On a more aesthetic note, I would have enjoyed doing more engaging artwork and sound design for the game; but time seriously did not permit.

[rileym-igb220]

Final Iteration of Prototype

After some tweaking and polishing, the final prototype of Reciprocate was done. I managed to refine the AI as best I could (with the very minimal knowledge of GDevelop I had) to be in a state where the enemies could follow the player at most occasions, or search for them if they were too far away.

I also added in a turret which allowed the player to acquire a turret arm when hit by one of its bullets, and gave the enemies a sword to give to the player when attacking. I also implemented a basic game loop and added a scoring system (based on enemies killed) instead of a timer.

Overall, the game, if fully developed, would be changed to have a timer scoring system instead (in a similar way to Risk of Rain 2) as well as a wider array of enemies and weapons. I would have also implemented heart pickups, which would appear on rare occasions; allowing the player to regain a heart. In the end, this was out of scope due to my lack of knowledge with GDevelop taking up quite a lot of time.

Reciprocate Playtesting Results

Rhys L - Playtester 1

“It’s something I would wanna spend my time getting really good at...”

Really enjoyed the main mechanic (which was awesome to hear), suggested that maybe giving the player a weapon to start off with might allow them to get a head start/conserve their hearts more. Stated that they would be interested in playing a fully developed version of the game.

Dong D (Michael) - Playtester 2

“I love the core mechanic of Reciprocate!”

Enjoyed the mechanic of trading off hit-points to improve their chances of scoring higher. Was reminded of “hit-trading”, a concept found commonly in fighting games (a similar trade-off).

Mentioned the idea of implementing heart pickups that appear after enemies are killed, creating a Reinforcing Feedback Loop (as discussed in the lectures) based around the player’s proficiency in killing enemies. Which is what I initially planned to include, so that is good to hear.

[rileym-igb220]

Reflections on Learnings & Game Progress

The screenshots above are some examples of what the arenas in Reciprocate are starting to look like. The engine I’m using, GDevelop, is pretty unfamiliar to me; however, I am slowly getting used to it.

Development on Reciprocate Prototype

The prototype is pretty much done. The arenas seen above are randomly generated at runtime; allowing for a unique arena every game. Also, not featured above in the images, I managed to get a basic enemy AI implemented. It can chase the player relatively well, jumping from platform to platform with decent success. Overall, I’m pretty proud of this prototype, it is still very basic in its game play, but I think it successfully captures the player experience I set out to achieve.

Unit Learning Applications

With the unit as a whole, I am really finding the concept of balancing and reinforcing feedback loops very interesting; so much that I utilised balancing loops to inspire the main mechanic. This is seen in when the player is attacked, they acquire a new weapon, yet lose health; which is conceptually a balancing loop, as they are losing something, yet gaining something to assist them.

I applied this theory in an effort to subtly increase the difficulty for the player as they perform well; and give them a benefit when they begin to perform badly. Therefore adapting the games difficulty, in a way, based on the player’s performance.

GDevelop Learnings

In regards to GDevelop, I‘m slowly getting used to the not-so-object-oriented coding style (something I’m not to familiar with). I have had some struggles when it comes to referencing the correct object in the game world; but besides that, I have it pretty much under control at this point. I did struggle when it came to setting up the procedural generation feature of the game, as sometimes the engine would not complete the code I set up (for reasons still unknown).

GDevelop Experimentation

As mentioned above, I managed to integrate a semi-competent AI enemy into the game as well as procedural-generation. This required quite a lot of experimenting, with many different approaches to these ideas failing very quickly.

In regards to the randomly-generated arenas, I struggled quite a lot when it came to forcing program to create playable levels. The main issue was platforms being too far apart, or too clumped together. In the end, I managed to set up an algorithm which randomly places platforms of random sizes, randomly decides if they are “jump-thru” platforms or not, deletes any platforms that are too close together and moves the remaining platforms closer if they are too far apart. This took up quite an abundance of the development time.

When it came to the AI, I tried to make it so the enemies could detect when a platform is above them; but this only ended in them bunny-hopping around the arena. In the end, I added invisible arrows, as seen above, which cause the enemies to jump and move towards the tip of the arrow (if the player is above them). These were then added as a step to the procedural generation; with each platform spawning two on either side of them. This ended up working well enough, but sometimes the player was up too many platforms for the enemy to effectively give chase (as they only ended up running beneath them); so added a “hunting” mode. This involved the AI detecting that the player was to high up for them to effectively give chase, followed by them strafing from left to right jumping to try and climb as high as they could. Its a very strange method, but it ended up working well enough for a prototype.

[rileym-igb220]

Reciprocate - Elevator Pitch

Reciprocate will be a procedurally-generated, rogue-like action platformer. The player will start the game in a randomly generated arena with the goal to survive as long as they can.

The main feature of the game will be that the player, when hit by an enemy, will acquire the abilities of said enemy. For example, if the player is shot, they will lose health and acquire a turret arm to attack the enemy that just damaged them (inspired by the Balancing Loops outlined by Fullerton (2018) and discussed in our Week 2 Lecture).

The main gameplay loop will centre around the player trying to survive for as long as possible, whilst managing their health and random weapons they acquire from being damaged.

The main player experience goal will be to make the player tactically take damage to benefit them in the long run (i.e risk vs.reward); as they will only regain health through rare heart pickups.

The game will be in a pixelated style, with the player controlling a robot-like character; who’s appearance changes when acquiring a new weapon. The main demographic/audience will be individuals whom enjoy classic action-platformer games; as well as individuals who enjoy puzzles and tactical game-play.

Re-posted from a blog I accidentally created when starting the unit >>https://rmigb220.tumblr.com