igb220-n10063013-blog

[igb220-n10063013-blog]

Wahoo

So that's it, final piece of assessment completed for the semester, now for a nap.

I got my first taste of proper game design during this unit and it was pretty good. I do have some gripes with the presentation of the unit which I will submit as official feedback, but I'll go over it lightly here.

Firstly I think this unit relied too heavily on textbook readings and these constant journal posts, it's just really not my learning style and I would have preferred more tailored tutorials which showcase a couple concepts at a time and then ask you to develop an instance of the concept on your own. Having design challenges would have also been very fun where everyone receives a half made game and can only add additional things to it to create something new. I thrive under set targets and learning goals in the initial phase and then spread my wings and experiment from there so this very hands-off approach made me much more subject to checking out for periods of time unfortunately.

What I will say though is that GDevelop is super cool. It is of course very basic and ...unique, but I found it very fun being able to rapidly test ideas and concepts for a game (I'm unsure if other more in depth engines are like this since I have basically no experience with them).

I will also say that the teaching team is super cool, I said the same thing last semester and I'll say it again. Entertaining lectures, entertaining tutorials (minus the aforementioned critiques), big plus from me. Thanks for the semester and I hope whoever marks this monstrosity has a rest of some kind afterwards or over the break.

Also play Spiritfarer, is comfy and got me through the semester :)

[igb220-n10063013-blog]

Assignment 3 - Kurogawa's Plight Post-Mortem

Oh boy, this is the end of it since I decided to do the post-mortem after I completed Assignment 3 (makes a lot more sense to me since its post playtesting analysis and all that). Unfortunately I do have quite a few negative things to say, but those are typically more valuable than positives so lets get right into it I guess.

Group Cohesion

I don't want to say reflect upon this stuff for the sake of putting down my group members, I think a lot of it isn't anything specific to them personally but sometimes you just don't mesh. Our communication and coordination as a whole was quite lackluster for the entire duration of the assignment, which was quite a whiplash from my other two group projects this semester which were a dream, but Im also absolutely not free from criticism in this aspect.

One group member is not a native english speaker so that made communication difficult at times due to my poor hearing. This is not at all their fault or something to look down upon, but simply a fact. I do actually think they had some very good insights and inputs, as well as a good work ethic but with something as communication heavy as game design (particularly in GDevelop since you cannot merge projects or anything of the like), quality is likely to dip without additional effort from both parties (this is where I lie at fault which I will discuss shortly)

The other group member was quite sick throughout the duration of the project, I don't know if this is a permanent thing or because of the illness but they seemed relatively checked out or shy when discussing things. I typically favour highly active group members because I thrive off the energy of those around me so I found it especially difficult to feel engaged. Again, I could and should have done more to ease communication and enthusiasm.

For my side, I will admit I did not do nearly as much as I should have in terms liasing and coordinating (I usually fit into this role well), but felt very burnt out during semester due to personal reasons, which is also why I received an extension. I haven't stated any of this to place blame on anyone or ask for special consideration, I just believe that when reflecting upon a project (individual or group) it is important to critique creative processes where possible.

Rigid Thinking

I think this stems from the general lack of communication but after some distance from it Kurogawa's Plight definitely suffered as a result of our rigid thinking. What I mean by that is that we we're all quite reluctant to pivot away from our original idea of climbing a tower to remove the occupying force.

This concept did not mesh with the game mechanics at all and really prevented the level design from complimenting and showcasing mechanics, which in the case of a platformer is basically its job (see almost any main Nintendo title which utilise the world and level to showcase a mechanic one at a time, before merging them all at once). I did attempt to showcase each mechanic one at a time, but the claustrophobic spaces inhibited an effective execution of this and popped up as a major issue in each playtesting session. Identifying this issue sooner and pivoting the concept to something more complimentary of the game mechanics (i.e. open spaces which allow player expression, multiple approaches, and clear visual communication (literally player-centric design)), would have likely had a profound effect on the finished product.

We also basically abandoned the idea of developing puzzles as a result of this rigid thinking, which would have added a lot more depth to the design of the game and create interesting outcomes.

The Good

Despite the issues stated above, I do think the core game has a lot of potential and interesting game mechanics. The formal elements of the game were interesting, with novel relationships between them and some interesting system dynamics as a result (Chaper 1, Fullerton, 2018). I do still really like the spear platform idea and will likely experiment with it while I learn Unity over the summer break, the Ninja's spear stealing is also very interesting in my opinion and could be taken a lot further with better physics and tailored level design.

Additionally I was generally happy with the level of polish I achieved through bug fixing and iterations, which I never quite attempted with the smaller development cycles in the rest of Assignment 1. This is where I really got to apply the whole completeness and functionality concepts in Chapter 9 (Fullterton, 2018), as well as small feedback recommendations by David in his discussions of fighting games in the lecture content (the concepts of hit and hurt boxes, and wind-up and wind-down frames really do go a long way in the overall feel and responsiveness).

That's it from me, onto the final post

[igb220-n10063013-blog]

Assignment 3 - Kurogawa's Plight Playtesting

Kurogawa's Plight V1 - Week 11

Due to time constraints within the workshop (Tom was unfortunately sick and unable to attend, plus here were issues merging the version of the game we invidiually developed), as well as the fact that there simply was not much to test in V1, we only had one playtesting session. Tom's unfortunate absence also made it much more difficult to effectively conduct and observe a playtesting session which would conform with Fullerton's recommendation in Chapter 9 (Fullerton, 2018).

Regardless, they provided some good insight into the core issues of the game. The main of which were the rampant bugs featured in the core mechanics, many of which we did not discover in our testing. The main bugs/issues were:

Bug - unable to move after attacking in the air

Bug - player permanently stuck after throwing two spears onto a wall and phasing between them

Bug - thrown spear stuck in a wall behind the player when the player attempts to throw a spear away from a wall while standing too close to it (this was a known bug but I was unable to find a fix for it during development)

Issue - player was initially unsure that they could stand on a spear or create new platforms with thrown spears for quite some time (mostly they resorted to double jumping as in this basic level you could complete the challenges without spear platforms, quite a design oversight)

Issue - player and enemy attacks feel unresponsive and have no telegraphing

Despite the afformentioned issues, Playtester 1 indicated that they enjoyed the visual style and core mechanics of the game, but that it was simply too hard to understand or interact with.

Our insights to from this playtesting concluded that the main aspects to iterate upon were the level design (to better show the player should do at a given time through visual communication) and also by adding a health system to the game and telegraphing enemy and user attacks clearly. The second insight is a result of our visual observations during playtesting where the tester was hesitant to attempt anything due the game featuring a 1-hit-kill on the player, as well as both melee attacks being instantaneous.

Kurogawa's Plight V2 - Week 12

Unfortunately Tom was still sick this week so we were unable to conduct playtesting to the fullest capacity. We did however conduct two playtesting sessions with naive users who alligned with our core target audience (as noted in Part A) so it was particularly important that the information gained this week was valued and respected. The core findings between the two players were:

Issue - Uncertainty between physical walls and decorative walls

Issue - Wall jump was less polished than games in the same market space, playtesters cited the Ori series and Hollow Knight as good wall jump mechanics which allow a player to slowly slide down a wall while connected to it for more precise wall jumps

Bug - Both players encountered the long lasting bug where they could get a spear stuck in a wall behind them (I have an idea to fix this next week)

Issue - One player did not realise when they were taking damage (some sort of visual and auditory feedback would like solve this issue)

Issue - Players noted that the second floor was much more claustrophobic due to the aesthetic decoration.

Issue - One player complained that there was no real goal or progression with the game as a whole. This is something we were planning to address next week anyway as we construct the second level and ending, however it is still important to note that players are in fact able to critique a games completeness through their own satisfaction (Chapter 10, Fullerton (2018))

Once again, players have indicated that the experience and core mechanics were overall enjoyable and engaging, and that the main issues in the game lay with the level design, visual communication, and general polish.

I will refrain from discussing Week 13 playtesting as that is largely the topic of Assignment 3 and because the reflective journal requirements indicates that playtesting is only required for Week 11.

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.

[igb220-n10063013-blog]

Assignment 3 - Kurogawa's Plight Development

Initial Conceptualisation - Week 10 (Part A)

Assignment 3a proved to be relevant to my learnings during my racing game development process, in that it focussed on conteptualisation and creating an outline for development and design content. Unfortunately both of my group mates preferred that we did not create a mind map and instead tracked a brainstorming session via a dot pointed list which also contained certain visual/control requirements for each feature. Reflecting on my readings of Fullertons textbook, and since I believe an engaged and enthusiastic group is a good group, I employed Chapter 6 concepts such as "No criticism", "Shout it out", and "Put it on the wall" (Fullerton, 2018) to break the ice with my group and initiate a productive discussion. This worked quite well and we came up with a lot of interesting extensions and formal elements to enhance the current prototype, which was based off the platformer game I developed at the beginning of the semester, Kurogawa's Plight. From this point we employed the concepts of "Technical Feasibility" and "Aristic Considerations" (Fullerton, 2018), as well as realistic development timelines (learnt during IGB181 and our prior GDevelop experience) to refine the scope into a realistic development plan and feature list. Below it the final result of our brainstorming.

Kurogawa's Plight V1 - Week 11

For Version 1 we focussed on polishing the existing mechanics from my personal platformer development time into a more playable state (my initial concept was very buggy as throwing a Spear with a platform behaviour does weird things sometime), as well basic Attack mechanic for both the Player and the Samurai enemy. We additionally swapped the existing Frog enemy out for a more artistically relevant Ninja, and a basic level to convey these concepts to a naive tester to identify some of the core gameplay issues, and determine whether they were rooted in design or simply execution. My contributions are listed below since poor coordination and scheduling resulted in a disregard for the Gantt chart despite my efforts (RIP Mr Gantt):

Player sword attack (animation included)

Samurai sword attack animation polish

Level design (simply to showcase mechanics and provide an insight into the visual aesthetic developed by Brysen)

Refer to the Kurogawa's Plight Playtesting post (section V1) for playtesting discussion and insights.

Kurogawa's Plight V2 - Week 12

Week 12 saw quite a lot of changes and improvements to Kurogawa's Plight. A revised level was developed with the aim of it functioning as a soft-tutorial, which forces players to understand a each mechanic one by one before being able to proceed. A particular touch I liked was that players must stand on a spear as a platform to access a locked area, and then must create a spear platform to exit it (we replaced the double jump mechanic with a restrictive wall jump to prevent players from simply leaping over challenges).

Additionally I aimed to improve the game feel through wind-up and wind-down timers on the Samurai and Player melee attacks sespectively, to telegraph the danger of the Samurai attack, and add a weighted feel to the players (I also prevented either object from moving whilst attacking to encourage intentional inputs and entice players into thinking before acting). I utilised hit boxes to achieve the effect of the animation only applying damage whilst the sword was actually slashing in the animation as the importance of developing attacks this way was illustrated during the IGB220 lecture content.

(please excuse the gross yellow filtering on the demonstrative gif's, I used a bad mkv to gif converter but I dont know how else to do it hehe)

The final segment I worked on was inspired by my analysis of system relationships throughout the semester. This was the Ninja's grapple hook mechanic which allowed them to grab a thrown player spear out of mid and and return it to them, dropping any grabbed spears upon death.

Kurogawa's Plight V3 - Week 13

Ah the final week of development, at this point the game was feature complete and we focussed level design polish, game feel polish, as well as and intro screen, second level, and ending screen to make the experience much more cohesive.

I spent a lot of my energy this week on general polish by tweaking animation timings, input feedback and the like so there unfortunately isn't much to talk about on that front, I just strived for a balanced experience and tried to ensure that each mechanic (which was developed individually) merged well together and ran as smoothly as I could at my current skill level. Additionally I added an aiming reticle for the spear and grapple hook as two of the playtesters were observed to not intuitively understand that the projectiles were mouse aimed.

I did manage to fix that pesky bug where players could get a spear stuck in a wall behind them when throwing it away from the wall, it was achieved by just using a timer that prevented the spear from being stopped for a certain time after throwing (a simple fix but it works well)

I also added sound effects to almost every action/interaction in the game to drastically improve the perceived response of the game, as discussed in the Asteroids post-mortem this really ties a game together. As a quick sidenote I actually directed a friend of mine who made all the sounds himself. While what we were making is of course very basic it was a really enjoyable insight into creative direction and working with someone of a different discipline (which is the exact style of work I would like to do in the future, DXB205 also revealed how much I enjoy this process as I worked with artists and producers to develop a TTRPG book while I focussed on gameplay and the game world). I unfortunately can't seem to attach the sound files in a tumblr post but please feel free to view the gameplay preview in Assignment 3 if you wish.

Speaking of improved game feel. I also added much better feedback for when the player character takes damage. Similar to other games they now are pushed backwards in a brief stun period which clearly communicates the instance of damage to the player (combine this with sound effects and its hard to miss). Similarly Brysen implemented checkpoints along the level to reduce frustration amongst newer or more inexperienced players (who also fall under our target audience and who will likely playtest the final product).

A second level was also added which contains the win condition of cutting down the opposing armies flag to signal you have successfully cleansed the tower of enemies (Part A divulges much more of the story detail I didn't think it was necessary here). This cut to the second level is quite jarring as it only really exists for performance sake (the idea was a single tall tower as a level), as the laptop we are conducting playtesting on cannot run the game at its full size at an acceptable framerate (~15 fps as a whole level).

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.

[igb220-n10063013-blog]

Assignment 2 One Sheet/One Page

[igb220-n10063013-blog]

Racing Game Post-Mortem

So as excited as I was about successfully utilising a conceptualisation techniques through visualisation styles, I will admit that I somewhat tunnel visioned onto the process (which is reflected in my development post which barely mentions the game, I could edit it but I would prefer to be honest about my experience, reflect on it, and aim to improve in future projects).

Conceptualisation Process

I feel a bit like a broken record but I think further iteration upon my mind map could have gone along way, not only to potentially further develop the game by uncovering new and interesting interactions and then testing them. But also to improve legibility for other people if I ever utilise this process in a group project (which is currently looming on the horizon with assessment 3). I showed the mind map to a few of my peers and they seemed interested in the concept, but I had to explain how it worked to almost everyone which almost defeats the purpose (at least in a group setting, the mind map was very helpful for my own thought process).

The Actual Game

With many other pieces of assessment rolling in at the moment I admittedly developed this game rather hastily and almost disregarded a lot of my prior learnings in other projects. I believe the game was enjoyable to an extent, with the very brief amount of playtesting I did revealing that players particularly enjoyed the interaction between the players fuel dump and a police cars short dash (the police car fully spins out and explodes if timed correctly, spawning an additional fuel cannister), the remainder of the game was very linear and limited in player choice or novel situations. This could be written off as a simple limitation of the endless runner style genre but I think this could be alleviated in a much heavier developed game. Player progression could be added to increase the cars efficiency through simple stat upgrades or additional mechanics, or the opposite with opposing police cars would create a much more diverse game and allow for additional system dynamics as discussed in Chapter 5 (Fullerton, 2018). A proper review and analysis of similar games in the genre, such as the flash game The Heist could have provided an insight into design solutions to achieve completeness and reveal how similar problem spaces appeared in my own design (Chapter 10 Fullerton, 2018).

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.

[igb220-n10063013-blog]

Racing Game Development

As stated, my main aim for the development of Run from the Fuzz was to commence my design process in a much more product way to attempt to alleviate my main development issue, which is a lack of prior planning. To do this I needed to better visualise my game mechanics as interconnected systems, while I understand the concept of system relationships as discussed in prior posts, I've noticed that I personally struggle a lot more when I contain all this information inside my head. Doing so makes it much more likely that I get railroaded into a direct line of thinking, which ironically is exactly what I've been attempting to avoid in my previous games.

As eluded to in my elevator pitch in this post I will mostly be concentrating on Chapter 6 of Game Design Workshop: A Playcentric Approach to Creating Innovative Games (Fullerton, 2018), which discusses design methods related to conteptualisation such as brainstorming and converting a brainstorming session into a tangible concept. During this semester I've also been studying User Experience (CAB210) which heavily features visualisation techniques of qualitative data analysis through the use of card sorting and mind maps, which I have found extremely beneficial for my critical thinking skills. Fullerton also discusses these concepts through Idea Cards and Mind Maps, which when combined, allow a designer to quickly list core mechanics onto cards, and then lay out their interactions and relationships through a mind map (Fullerton, 2018).

Above is the mind map I created before my development sessions, and while to some it probably looks like a mess, I cannot understate how relieving it was to attempt something like this and it's positive effect on my development process.

When creating the game I was able to focus on a single chunk of the game at a time and polish it to a level I was happy with, then move onto each systemic function individually and repeat. It seems obvious to develop a game this way, as it is incremental and iterative design effectively the cornerstone of software development (and many other things I don't doubt), but I had never quite attempted to realise the process when it came to game development in such an intentional way.

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.

[igb220-n10063013-blog]

Racing Game Elevator Pitch

As discussed in my Asteroids Post-Mortem post, my main focus for the racing game project is on process and integrating theory and design methods from Chapter 6 of Game Design Workshop: A Playcentric Approach to Creating Innovative Games. As such the Elevator Pitch for this game (while still applying and taking into consideration Fullertons teachings) is much less centred around some key design theories.

Inspiration / Concept Art

The key inspiration for the design of my racing game draws from police chase scenes in movies such as Baby Driver (Wright, 2017), and Drive (Refn, 2011). In these two films the protagonist often uses intelligent decision making and skill to turn opponents own weapons against them, such as spinning a spike trips their adversaries in a direction which disables their chasers. Developing a game which replicates the tension and release (utilising Fiero, discussed in week 4 lecture content) of being pursuing and temporarily overcoming the pursuit is the core development motivation for this project.

https://youtu.be/IHzyI_v74_Q

Elevator Pitch

In Run From The Fuzz you play as a getaway driver stuck on a seemingly never ending highway. Police cars are chasing you, nipping at your heels, and using every tool they have at their disposal. To survive you must use your ingenuity to dismatle the police's technology or even turn it against them. Reversing spike traps, distracting enemies, and laying oil traps are the only tools at your disposal. Using these tools wisely, while attempting to avoid the bystanding traffic, is key in your attempt to outrun the Fuzz.

Breakdown

Gameplay

Run From The Fuzz comprises of the following challenges for the player:

Manoeuvre around traffic to avoid a collision, which heavily damages the player

Eliminate pursuing police before they capture the player, ending the game

Collect fuel pickups to increase driving time/distance

Accumulate high scores by overtaking cars and eliminating pursuers

Methods of Police Destruction

Avoid or hit spike traps into police cars

Dump fuel onto the road to cause pursuers to spin, draining your fuel meter in the process

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. Wright, E. (2017). Baby Driver [Film]. Refn, N. (2011). Drive [Film].

[igb220-n10063013-blog]

Asteroids Post-mortem

Design Process

For the design process of my asteroids game I mostly focussed on design theories such as system dynamics emergent gameplay, discussed in Chapter 5 of Game Design Workshop: A Playcentric Approach to Creating Innovative Games (Fullerton, 2018), to inform my design process and better assist myself in a critical thinking approach to development. I selected these core principles in response to my platformer project which, upon reflection, lacked depth or compelling design as I was too focussed on player agency a very rigid structure developing a prototype through whitebox testing and iteration (disussed in Chapter 1 and 7 (Fullerton, 2018)). While these teachings are of course valuable I believe I did not execute the design process of my platformer as well as I could have as I did not fully consider the techniques and thought processes required during iterative playtesting/development.

I believe my application of these new thought processes and concepts worked quite well, particularly in the later stages of development. A lot of the positive feedback I gained during playtesting were on aspects such as polish and gamefeel. I attribute this to my consideration of the aforementioned concepts from Chapter 5, but also Fullertons Chapter 10: Functionaliy, Completeness, and Balance which emphasised the importance of refinement, rulesets, and reward structures to improve the moment to moment gameplay (Fullerton, 2018). Additionally this stage of development coincided with the subjects week 6 lecture which discussed very helpful and applicable concepts such as tactical immersion, micro choices, tension and release, and feedback.

Design Process Improvement

To further improve my design process (or to iterate upon my process, hehe game design terminology) I believe I should concentrate my efforts towards early conceptualisation. In both my platformer and asteroids project my early mechanics and systems creation was very spuratic and nebulous (i.e. poorly defined ideas floating around my head). My platformer development process was based around this as I simply played around with my mechanic and developed whatever else came to me, while as discussed above the asteroids concept was a little better. Regardless, the core constructive feedback for this prototype may be linked to design aspects from very early on in development. I believe I simply accepted aspects, such as the semi-high skill floor of the movement and unintuative rules, as a core component of the design. As a result of my system dynamic/relationship design methodology (Fullerton, 2018), subsequent mechanics and systems inhereted these flaws as they lay within the foundation of the concept.

Too alleviate this, I will endeavour to focus more on Chapter 6 as in this segment Fullerton discusses the conceptualisation process as well as various technique suggestions. While I have already been using the list creation method for mechanics whilst creating my elevator pitch, focussing on the brainstorming methods of idea cards and mindmapping will likely prove more beneficial. (Fullerton, 2018) I ancitipate idea cards will allow me to better track mechanics/systems as unique aspects, while implementing these cards into a mindmap will facilitate a more profound visualisation of the design prototype as a whole, potentially revealing any flaws and improvements one could make.

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.

[igb220-n10063013-blog]

Asteroids Playesting

During this week tutorial I had two people playtest Berserk Beams and disussed gained some great feedback.

Positives

Both users indicated verbally and through the survey sheets that the game was very enjoyable as a whole and the kinetic feel of interacting with the mechanics felt great. One tester particularly enjoyed how I implemented a physics system into the player movement as it was something they had not previously seen, "Making the ship spin in fun circles because of the movement physics allowed for some fluid gameplay!".

The other playtester reported that "managing [their] fuel bar while manoeuvring around asteroids to destroy them was some engaging gameplay." and later expressed that they enjoyed the lifesteal style mechanic where you may regain thruster energy when destroying asteroids.

Both playtester also communicated that the sound design, score system, and enemy destruction animations added a lot to the concept and facilitated an immersive experience.

Not so Positives (Constructive Feedback)

While the objective of the game (destroying asteroids to attain score and replenish HP) was regarded as good, the way in which the HP regaining system was telegraphed was described as confusing. This is likely due to the mechanic being displayed during play and not in a pre-game screen of some sort like I saw in other's prototypes. Additionally displaying the final score on the deaths screen would amplify the importance of the objective as future players could keep track of their best scores and attempt to beat it.

Both users reported that while the movement mechanics and my system dynamics was very enjoyable, they initially found it hard to control as the momentum of the player could very rapidly snowball while shooting and moving at the same time. This is due to the forces applied while hitting a target and using thrusters combines while using both mechanics, personally I never encountered this issue as I would often use the laser and thrusters one at a time.

One playtesters was confused on the function of the laser initially and did required a few attempts to realise the intention of the laser was also to pull you towards enemies, this is partly due to the aforementioned issue. I have however discovered that this is likely due to a bug where simply holding down the laser for a long period of time (using a single burst to attack multiple asteroids) will only pull you towards the first asteroid you attack for an unknown reason.

[igb220-n10063013-blog]

Asteroids Development

For this game I wanted to focus my efforts towards system dynamics as opposed to my prior core design theory of player centric design, which I attempted by facilitating player agency through in depth mechanics which allowed for multiple outcomes. Unfortunately my game did not entirely achieve this as the main mechanic was quite static and rigid/clunky in feel such as a thrown spear would always travel perpendicular to the player which would require rather awkward positioning to use effectively. Two additional contributing factors to this shortcoming can be attributed to my level design which upon review two weeks post development, was much more linear than I initially believed and effectively had one correct approach, another issue that my game lacked completeness due absent audio and visual feedback, this will be further explored at the end of this segment.

In Chapter 5 of the units textbook by Tracy Fullerton, she examines this very concept which is more aptly referred to as system dynamics and the importance of relationships between the various systems. She also articulates the very issue I experienced with my first game by displaying the contrasting number of outcomes between chess or tic-tac-toe, and how this is largely attributed to the vast number of systems (how each chess piece operates) which result in a branching network of outcomes rather than a relatively linear flow. (Fullerton, 2018)

A diagram representing the aforementioned phenomena (Fullerton, 2018).

Initial Development

In my elevator pitch I briefly discussed my two mechanics which would serve as complimentary systems in an inherently interconnected way. Developing both the thruster mechanic was quite simple while the laser was a bit trickier achieve visually, but was solved by using a linear red line particle effect of unlimited length and very short duration to create a constant beam, while the actual hit detection was performed by 1 pixel sized objects travelling at a very high speed. Once a collision with an enemy asteroid was detected I would simply add a permanent force towards the asteroid while the collision was true.

I also created the discussed fuel/energy system which was a large bar displaying the fuel amount, which would prevent activation of the thrusters when empty and begin a gradual recharge after 1 second of being innactive. This was as far as my initial thoughts on the game had led me, and while the tight feedback loop I had envisioned (hurtling towards an asteroid doing as much damage as possible before performing a 180 and rocketing away to prevent a collision) was there...it wasn't very engaging and lacked any of the fluidity and potential I was aiming for. It was at this time in development that I realised I had not fully comprehended Fullterons examples.

I believe that the discussed importance of system dynamics may also be applied to the potential outcomes within each system. Simply implementing additional mechanics, even supplementary ones which are inherently linked in their design, did not dramatically alter the perception of potential outcomes, regardless of the objective actuality. In reality I was designing my game as an emergent system, which can be surmised as a large quantity of simple systems creating more complex and unpredictable results (Fullerton, 2018), also discussed in Chapter 5 of Game Design Workshop: A Playcentric Approach to Creating Innovative Games. My progress was still valuable and works well with what I was initially aiming for, to achieve my goal of developing a truly engaging and enjoyable play experience however I directly observed the relationship between my two systems to improve their dynamic through emergence (this thought procedure is similar to the feature design method in Chapter 6 (Fullerton, 2018)).

Momentum and Physics

Aftering pondering some potential solutions I concluded that adding a physics system to the players movement should remedy the linear game feel and facilitate an experience of metaphorically branching player inputs.

Below are two examples of the physics systems implementation.

Quite frankly this was an excellent decision and it vastly improved my concept. I believe the contrast between the former and latter versions of the movement showcase the importance of moment to moment gameplay (as discussed in the lectures), as tactile and enjoyable mechanics at the most basic level evidently have a very large impact on the overall feel of the game.

A very nice side effect of this improvement is that it allowed me to iterate upon other elements of my design, to keep things short these changes are:

Destroying an asteroid refills your fuel meter - allows the player very rapidly move from target to target in sprees

Hitting the border of the map will now bounce you towards the centre - preserves momentum and thus the games flow state as opposed to halting the player (i.e. avoiding stagnation, discussed Ch 10. Fullerton, T. (2018))

Similarly, hitting an asteroid will rebound the player away

Completeness

Chapter 10 of Game Design Workshop: A Playcentric Approach to Creating Innovative Games saw Tracy Fullerton detailing completeness in a game, and how aspects such as reaching and exceeding goals, collectables, and impactful construction/destruction can transform a games polish (Fullerton, 2018). While these steps aren't necessarily required for a simple prototype, I wanted to explore this space regardless. Some implementations which I found effective were:

Score counter

Audio queues when destroying an enemy or taking damage

Destroying an asteroid will cause them to explode into up to 20 particles which are thrown across the screen

A visual goal where players are rewarded with additional lives when reaching score milestones

Personally I think these extra effects and goals significantly improved my game and it feels a lot closer to a more complete product, up next is playtesting.

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.

[igb220-n10063013-blog]

Asteroids Elevator Pitch

For the next few weeks I have been tasked with developing a game in a similar genre to Asteroids. From reading Chapter 5: Working with System Dynamics I became particularly in the concept of simplistic systems which were related to one another, and when combined would result in a single and much more immersive system. To achieve this Fullerton disussed an importance of relationships and interweaving behaviours, this concept will be the main design principle for my prototype.

In an opposite direction to my last game, which focussed on dual-purpose design and simplifying multiple mechanics into a single diverse one, I instead will endeavour to develop two seperate and contrasting mechanics, which combine to create a singular system and intense moment to moment gameplay which requires impulse decisions.

Inspiration / Concept Art

My main inspiration for my mechanics derived from tractor beams seen in movies where smaller ships are pulled towards much larger ships to ensare them. Instead of the large ship controlling the beam however, it is instead the smaller ships (i.e. the player) who fire the beam at their enemies to damage them, while also ensuring they do not collide with the much large adversary)

Image sourced from https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.cnet.com%2Fnews%2Freal-star-trek-tractor-beam-nyu-nasa-david-grier%2F&psig=AOvVaw25Icjj3j6fWGJXbHwPfhQi&ust=1630046152547000&source=images&cd=vfe&ved=0CAsQjhxqFwoTCOCm9YyJzvICFQAAAAAdAAAAABAh

Elevator Pitch

In Berserk Beams you play as a small ship trapped inside an asteroid field very limited means survival you must use what you have to avoid or destroy the titanic asteroids which threaten to destroy your ship in the vastness of open space. Your engine was damaged when you discovered the existence of the asteroid and must now save your limited energy capacity to make emergency adjustments to postpone your demise. You may use your laser to navigate the field or destroy your obstacles, the laser however rapidly pulls you towards the enourmous geods so you must be on your guard. How long can you survive? Will you escape? You can only try.

Breakdown

Gameplay

Berserk Beams features only a few mechanics which combine to create an engaging experience, players may:

Avoid asteroids

Destroy asteroids to accumulate higher scores

Hurt asteroids with their tractor beam - which also has the side effect of pulling the player rapidly towards the enemy

Maneuver using their limited capasity thrusters

Modify their ship by attaining powerups such as stronger/wider tractor beams, unlimited energy, invulerability etc.

[igb220-n10063013-blog]

Platformer Post-Mortem

So my platformer development is officially finished, and I think I've learned a lot major techniques and little tid-bits that will help me in many projects to come. Fullertons book was a lot more helpful than I would have initially guess; I often found myself thinking of ways an actual player may interpret the level and trying to develop ways to facilitate that as that was my main takeaway from her writings (i.e. player agency and player centric design).

White-boxing/Playtesting is great

The most applicable thing I feel I've learnt in this project was really just how useful a white-box is and how firmly it supports the cycle of desining/testing/iterating. I remember in my small unity porject I kind of ignored this concept entirely and tried to develop a level then insert interesting mechanics into it (or rather I would repeatedly tweak the jump mechanic in a very tedious attempt to make sure all jumps were clearable). This new process was so much faster and more enjoyable, I would often find myself just playing around in the empty box basically limit-testing what a mechanic could achieve in it's current state. In doing so I found it quite easy to imagine additional features and methods in which I could further the concept (something I haven't had time to do but may continue this project on my own for fun). The double-jump is a very simple but greate example of this, I honestly really didn't want one when pondering upon my initial concept, this is why I listed a pogo mechanic as a suggestion for further mobility, but it ended providing a much better flow state and in-air freedom for the player (maybe the pogo would have been more unique but it seemed harder to develop and could simply replace the double jump in the future).

Visual communication/art is critical

While some of my feedback in user playtesting indicated a lack of polish and simple game mechanics, it was pretty clear that despite my attempts some stages of the level were simply not clear enough due to various reasons I've discussed in the playtesting post. Slowly iterating and polishing mechanics to remove the jank or improve complexity is something that takes time and isn't really expected of a basic prototype, but I feel like visual clarity is something that can be developed from the start so that is something I must keep in mind for the future (being able to create my own sprites would probably help a lot but again Im the furthest thing from an artist so I will endevour to put more effort into scouring forums for free assets.)

What was developed

Basic spear-throwing platform mechanic

Ammo counter and ammo pickups

Double jump mechanic

Two varying enemy types

Basic level to slowly introduce (testing inferred not slowly enough) the mechanics and explore potential ways to interact with it

A small easter egg ;)

Future development ideas

Due to my time constraints I unfortunately really didn't get the time of have the GDevelop skills to create some of the mechanics I suggested in my initial pitch. I also spent far too long getting sprite animations to work because I wanted the game to look nice, something that I really shouldn't have done as it has relatively very little affect on the initial playtesting/prototyping process (seriously it took like 8 hours for some reason). Here are some of the further imrovements/mechanics I believe would improve the experience.

General polish and bug removal

Addition/more robust levels to feature new ideas

Mouse aimed throwing spear (could really open up potential level designs)

Pogo spear mechanic discussed in game pitch

Spear pickup ability (make the game more forgiving, perhaps there could be certain block types that prevent pickups at times?? honey/slime?)

Improved visuals (both for communication purposes and simply because it would look awesome)

Jumping board spears (this coul possibly be an entire new spear type, I could then make a mechanic to swap which spear type you had selected)

Conclusion

I genuinely enjoyed this development process, though slightly disappointed at how little I managed to do with it in the time constraints, probably should have learnt it would take 3x longer than I planned since that was a repeated joke in IGB181. I learnt just how much a design process can influence the results of game development and will likely refine my technique/process in the future. As it currently is my game isn't super rewarding, technically the finish point doesn't even work correctly when uploaded to a playable link, but I think with more refinement the gameplay could be a reward in and of itself. Of course though adding quality of life improvements or tangible completion trinkets and unlocks would improve the experience, alas though I believe next week we're moving on to asteroid style game.

[igb220-n10063013-blog]

Platformer Playtesting

So this is the final week before checkpoint 1 and I've done another round of playtesting sessions with my friends (sadly I was unable to attend the workshop). Two of them had very little issue navigating the space and communicated after the playtest they found the level quite easy to read in what was expected of them. Being well versed in platform games however enabled the first two testers to give me some good feedback and suggestions for further developments. Here are some combined thoughts from the two of them.

The spear mechanic being a linear projectile did not feel natural and was at times clunky to allign - I believe this would be remedied by implementing physics to the object as well as mouse aim if possible

Both users liked I had used spears as breadcrumbs in the cloud section, they also seemed to enjoy having a limited number of spears and thus needed to think about their placements

One playtester reported the cloud's movement speed was far too slow, they also noted you did not need to use a single spear in the section (whoops).

I admitedly did my chapter readings on playtesting a little late this week, but after the playtesting sessions with my two friends I realised some content from the chapter was very applicable to me. Tracy Fullerton discusses the seperation between testing with confidants (i.e friends) and with people you are less familiar with, while both testers provide the benefit of new opinions and thought process a confidant is more likely to pull some of their punches in their feedback or look at the project with a positive bias. So to remedy this I asked a friend of a friend, who isn't very experienced with games in general, to test out my game and observe them.

Uninformed Playtester

This playtesting experience was wildly different to my previous testing, and I learned a lot just by watching them play before even discussing it. While my playtester-friends moved with ease throughout the level, this friend had a sense of hesitation in all of their moves and seemed a little unsure at times. I think some of this hesitation is due to their blanket lack of video game experience, but there are aspects of my visual communication which could be improve, below are my main to indicators of this.

The above segment I would consider the main source of information, and one that came at the expense of the player as they became visilbly frustrated in the 6 attempts. While this section was purposed designed to prompt players to think about here they throw their spear - the intended path is not to through a spear on the right wall but instead double jump and make a platform on the higher left wall - two factors I hadn't thought of became apparent:

Given that the amount of spear ammo given to you at this point is exactly how many you require on the optimal path, making a mistake (throwing the spear on the right wall) results in having to refresh the webpage and starting the game again.

The timing window required to throw your spear on the left log wall is slim, unfamiliar players find this timing much harder than I anticipated.

After discussing why this gauntlet was so troublesome for the player I have thought of a few potential solutions:

Change the log wall on the right to a grass wall to indicate a spear should not be thrown there (improved design communication through visual telegraphs)

Increase the length of the left log wall to reduce the timing window (easier challenge once the player realised the true path)

Increase the total spear count to allow the player to create both a platform on the right and left wall (more forgiving/less punishing)

Overall I think this section was so apparent because it was asking too much of the player at an early stage. At this point no jumping throws have been required, nor has the player been intentionally mislead and tasked with thinking about a less linear solution. I think this semi-puzzle is good on its own, but so early in the level prompts players with two many new concepts at once, instead gradually introducing them one by one would be optimal.

Another and more long term solution would be to implement the functionality of picking up a spear you have already thrown, this would allow players to reattempt sequences in a less punishing manner without having to restart.

Another interesting sequence can be seen above, the player stands on the cloud as it slowly moves to the left and must create a path over the vertical wall, they may also stand at the speech bubble with a grey cloud in it to recall the cloud to the starting platform. While I did suspect the speech bubbles visual design was not the greatest (I used a premade asset since my artistic skills are beyond anything another human should have to see), I did not anticipate something.

The moving platform being a cloud relys on inherited visual communication from past platformers which often used clouds as platforms, it required an informed audience to recognise it was a platform. This uninformed playtester made the realistically reasonable assumption that you can't stand on clouds and that it was simply an aesthetic choice, and instead attempted navigate to the platform with the frog on it by throwing spears (which is impossible), because that's what the previous challenges had required. I could remedy this by changing the sprite of the cloud to something else, or more interestingly the level could feature a platforming test earlier in the level which forces a player to stand on a stationary cloud platform.

Summary

This playtest was very helpful and provided me with a lot of insight into iterative design where, if this was a real game production, I would act on any issues that came to light in testing to improve the players experience. Despite some of the hiccups in playtesting, all testers seemed to enjoy the core mechanic as well as some of the example expanding mechanics I proposed to them.

[igb220-n10063013-blog]

Platformer Development

Ok wow so this week was...insightful. Learning the ins and outs of GDevelop took a lot longer than I was expecting, and I spent even more time just trying to get the platform-spear throw idea to work.

Thankfully the tutorial provided me with a pretty decent skeleton for a platformer, basic jumping and enemy "AI" so they can patrol around and be menacing, I basically just ripped this project for my own development as a good jumpstart (I even kept the name Bingus Platformer because the default model we were given looked like a good Bingus to me). In Chapter 7 of Game Design Workshop a Playcentric Approach to Creating Innovative Games (Fullerton, 2019), Fullerton discusses the loop/technique of visualising, building, playing, then refining or building upon a prototype, this method of design was much more helpful than I would have thought and I found it to be very fluid and engaging. She also emphasizes that a design should almost solely focus on "the fundamental mechanics, and if these mechanics can sustaint the interest of playtesters". Using this knowledge, as well as a bit of my learning from IGB181, I built a white-box style space with a single enemy in it to playtest my mechanics as I was designing and developing them. This would also force me to play the same pieces time and time again and eventually helped me polish and tweak little things here and there (such as the enemies model being slightly too high to jump over, so I added a double jump to make it easier and more expressive to move around, plus its cool ninja stuff).

Spear Mechanic Development

First things first was the core mechanic, throwing a spear. Immediately I realised I had absolutely no idea how to do anything more complex than a jump in GDevelop so consulting youtube was a must. I found a few tutorials recommending the use of bullets, which made a lot of sense to me I'm basically trying to create a projectile that sticks into walls. The bullets worked in that they shot out when I pressed the Q key and it was pretty straightforward to make it kill the enemy using collision/delete logic, I even gave it a spear model, but for the life of my I couldn't get it to stop when it hit a wall and turn into a platform.

Eventually after playing around for far too long, as well as realising that the the enemies "AI" was basically just a blank sprite with a force applied to it, I found my solution. Instead of creating bullets I could just create a platform object (I eventually made it a jumpthru platform) that looked like a spear and apply a force to it from wherever the player was standing and determining the direction using the same direction text variable assigned to the player, then if it hit a specific type of wall it would simply stop all momentum. Honestly this revelation alone felt amazing and it worked exactly how I wanted it to, at least at first glance.

Unfortunately because it was a platform the player would glitch in and out of it until the spear was safely far enough away, this required all kinds of weird fixes like fine tuning a spawn displacement over and over again.

Above is the basic whitebox I worked with to test features, at this point I added some simple instructions as well as an ammo mechanic, since I was planning on making ammo management part of the puzzles (EDIT: there were no puzzles created past me was far too ambitious, also the character is mid jump because screenshots require holding shift which is apparently a default jump button, fun).

I let two of my friends play this very basic concept as they were partly watching me develop the game on discord. One friend thought he was very cheeky finding an erant pixel outside the map to stand on.

and another found that a spear would get stuck in the wall if you were too close to it, the sacred benefits of testing have already become apparent (but also no, I didn't bother fixing this)

"Finished" Development

So its now been a week since I implemented the spear mechanic and here's what I've done .

I was far too ambitious in my pitch but this is the completed version for now so let's break it down with some quick thoughts.

Wanting to develop extra skills and abilties to unlock was beyond what I should have realistically expected given the time it took to develop what I have so far. (maybe slightly lazy but time was also a big factor)

A nice-ish backdrop was added as well as a decent level

While creating the level I realised it kinda bland to just have the same enemy over and over again, it was also pretty hard to think of new ways to throw a spear at a wall.

A jumping frog enemy was added, the samurai enemy could not be jumped on but would always drop a new spear, while the frog enemy was the opposite and forced you to risk goomba-stomping him or spend a spear

I added a little floating cloud (and a recall button to pull it to the starting point) the player would stand and have to keep up with while navigating a little challenge

Bonfire finishing point

Easter egg if you can finish the level with a spare spear and jump over the wall next to the bonfire (the easter egg has not been shown as while it adheres to player reward theories discussed by designers and academics, Im not so sure they would approve of my reward (no, its nothing vulgar just an inside joke for my friends who will playtest the game shortly))

A lot of this process was pretty straitforward thanks to me prior experimentation in my "white-box", I felt pretty comfortable coming up with new pieces of content and implementing/iterating upon them. One particularly interesting mechanic was in response to my friends very initial playtesting where they found it was cumbersome not being able to drop down from through your own spear (Terraria platform style).

I figured out how to make his suggestion work by disabling all spear objects platform behaviour upon pressing the down key, then re-enabling the behaviour once the player was falling fast enough (I tweaked this amount to be just enough to fall through and be caught by another spear just below it)

This logic for this mechanic is shown below, I've also thrown in the spear-platform logic as well because why not

So that's that, my level is finished in my eyes, time to move onto player testing and then the postmortem before checkpoint 1. Here's the link if you'd like to play it, not sure why the background doesn't work though: https://games.gdevelop-app.com/game-56eaf9d8-8391-4669-ab73-60f081963ef2/index.html

Fullerton, T. (2019). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.

Re-Logic. (2011). Terraria [PC].

[igb220-n10063013-blog]

Platformer Elevator Pitch

I have been tasked with developing a short prototype for a platforming game, utilising some concepts and design principles learned from Game Design Workshop by Tracy Fullerton.

From the very beginnings of chapter 1 Fullerton discusses the importance of the concept of a playcentric approach stating that "Being a superior game designer isn’t about controlling every aspect of the game design or dictating exactly how the game should function It’s about building a potential experience, setting all the pieces in place so that everything’s ready to unfold when the players begin to participate" (Fullerton, 2019) Taking this theology into account I immediately wanted to develop something which promotes player agency, such as a puzzle game or a player expression focussed combat system. Given the short time period (as well as skill defecit) I believe combining the two potential pathways into a single, dual purpose mechanic would achieve a sense of reward to players whilst navigating puzzle, as well as the sense of mastery from open ended combat.

Inspiration/Concept Art

The core mechanics of Kurogawa's Plight are inspired by Tai-Lungs prison escape scene in Kung Fu Panda, in which he manipulates his oppontents spear style weaponry in various ways, such as redirecting them into a wall to act as platforms.

Elevator Pitch

In Kurogawa's Plight you play as an unnamed martial artist on a quest to retake the stolen lands of his village. Throughout your journey you will traverse the various biomes of Japan which present natural challenges that demand your use of skill and ingenuinty with spears to navigate efficiently. The land of Kurogawa is also plagued with the very warriors who stole your life from you. Harness your prowess to defeat, incapacitate, or maneuver around these enemies on your way to take down their leader. For you, all you need is your spear, your skill, and your mind to accomplish your goal.

Breakdown

Gameplay

Kurogawa's Plight will feature a mixture of combat gauntlets and platforming puzzles utilising spear based mechanics such as:

Melee combat

Throwing your spear at enemies

Throwing your spear/spears into walls to create platforms

Using your spear as a pole-vault to leap over dangerous obstacles

Rewards

Hopefully the gameplay in itself is rewarding. Players will be presented a tight gameplay loop in which they gather one or more spears, attempt to use them in the most efficient ways possible, and then find some way to reattain more spears to deal with whichever challenge is presented to them. To support this goal more trational rewards such as collectibles or skill upgrades may be implemented, these may include:

A skill which allows players to swing or trampoline off their existing spear platforms

Increased spear capacity

Additional projectile unlocks (smoke bombs, stunning bombs, traps, boomerang spears etc.)

Collectibles which reveal certain pieces of lore or gameplay insights

Collectibles which unlock additional levels

Fullerton, T. (2019). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.

Kung Fu Panda. 2008. [film] Directed by M. Osborne and J. Stevenson. DreamWorks.

[igb220-n10063013-blog]

GDevelop About Page/Post

Hi

My name is Lachlan Taylor and I'm a BGIE (Game Design major) student at QUT. This semester I will be documenting my design process across a range of games, as well as my learnings from each project.

Game Development Interests

Games have always been my main passion in life, quite literally some of my first memories involve playing Halo: Combat Evolved, yet the process of their development has remained a mystery to me despite my avid engagement. I dabbled lightly in the topic by creating custom game modes and maps in subsequent Halo/Call of Duty and found immense enjoyment when my friends or cousins also enjoyed them. Creating shared experiences, I have since learned, was the part I enjoyed the most. Around 2015 I was offered the opportunity to study a Certificate 3 in Interactive Gaming and Programming Specialisation at local Brisbane studio Lightmare Studios. People around me however expressed their concern that I was not committing to my school studies enough, especially since game design was considered an unviable career choice to them, so I tried to give up on the idea. I think from the two or three weeks I was there though I knew the topic was something I was very interested in.

After highschool I tried a few degrees based off my strengths in schooling, confusing the feeling of enjoying success with the feeling of genuinely enjoying the topic regardless of my achievement in it, which never quite clicked with me. During this time I discovered the Youtube genre of game essays - essentially videos dedicated to discussing interesting points in game design/history - and once again that urge to explore the world of game development grew.

After this repeated interest, combined with a global pandemic and a lot of self reflection, I've realised that I have to try game development. If it works as a career and I am able to create games I'm passionate about with people I care about then that's excellent, if it doesn't work out at least I won't regret not trying, and at least I will have learnt some fascinating things about my passion.

Focusses in the Unit (What I aim to do and to learn)

My main interests in game development are focussed on gameplay, level, and narrative design. So this unit will really facilitate an early understanding, exploration of, and reflection of the first two topics so I am understandable quite excited to delve into the process. From my very brief knowledge of GDevelop it seems to be a fairly lightweight engine using code-blocks (i.e. more similar to creating the logic behind games rather than full fledged coding such as in unity), which specialises as a very fast way to develop and iterate upon design concepts. The assessment seems focussed on this very concept but also emphasises on the importance of reflection and mapping out your thoughts on how/why a project may have done well or maybe not so well.

I aim to attempt pieces of design that inspire me to develop them the the highest standard I can, which should improve my conceptualisation skills and the methods I take to transfer them to a tangible product. I will attempt to adhere to the prescribed textbook readings the best I can (something I admitedly ancitipate may be problematic) as the knowledged gained will not only inform my design process, but also supply me with the tools, terminology, and techniques to reflect on my creations in what will hopefully be an enlightening and interesting post-mortem.

Unforunately I know I'm not quite there yet in terms of skill to create piece of game design which evokes more profound experiences from a player (such as emotions more complex than enjoyment/not enjoyment), but hopefully this unit will provide me with the foundations of such skills and fascilitate a journey to mastery in latter courses or personal projects.