dmurrqut - Tumblr blog

[dmurrqut]

Assessment 3/Transform Rescue Postmortem

We've finished up our report for assessment 3, and development on the prototype is done alongside it.

One aspect of the readings that helped inspire inspire our design process for Transform Rescue was the textbook section on Agile development methodology in chapter 13 (Fullerton, 2018).

We didn't make use of a proper Agile development process or properly set out a sprint or release plan, but we did define specific goals and tried to prioritize the development of specific features within short, specific timeframes. Given our limited time and resources, this allowed us to produce something useful (for the purposes of IGB220) quickly, and it also allowed us to rapidly pivot on some design specifics as our understanding of the prototype developed.

On reflection, it would've been nice to double down on this process from the beginning, but it may have ended up being an overwrought process for the type of task we have. However, it's something that I'd like to explore in more detail in future game design projects.

One thing I'd change about how we developed the prototype would be having a more thorough mechanical prototyping stage at the start. Our first stretch of work on the prototype resulted in a bit of a slapdash scene that wasn't built in a way that made it easily reusable (through global objects and events, for example) and it wasn't set up to test the forms and abilities available to the player. In other words, some of our early prototyping work wasn't done in a way that made future development easy, and it wasn't as helpful as it could have been for exploring mechanics.

One thing I'd change about the design of the prototype itself is the lack of an ability for the basic human form. This was a point of disagreement in the team, but when we first started working on the prototype, I felt that the "Human" form should have a unique ability like every other form.

Playtesting seemed to confirm that having a form without any abilities was indeed confusing, and it felt like a bit of a waste to me. Discussion of this kind of change made it into our report, but the short version is that I would've liked to add a simple projectile attack to the Human form, to make it useful for longer and less confusing to the player.

Above: He jumps, but little else.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Assessment 3/Transform Rescue Development

Our progress on our Transform Rescue demo leading up to playtesting was pretty solid. In this post, I'll explain what we did in a bit more detail.

First, a reminder about what the game actually is. Transform Rescue is a level-based platformer where the player can pick two forms to bring into a level, and they can change between these forms at particular points in a level (denoted by a floating ? bubble). Different forms have unique abilities, and may allow the player to tackle challenges in slightly different ways. The player beats levels by rescuing a citizen at the end of each one, functionally acting as a goal the player must touch.

As mentioned in the playtesting post, the demo at present contains a tutorial, 2 regular levels, and 1 boss level. The game boots to a title screen, proceeds to the tutorial level immediately, and drops the player onto a map screen after the tutorial and between levels. It's a fairly traditional way of navigating between levels in platformers, inspired by mainstays like Mario and Kirby games. The map is also where the player "equips" forms, by clicking a backpack icon to open their inventory.

Notably, the map screen is fairly anemic by design. The main focus of developing our demo further has been working on core mechanics as used within levels, and building the levels themselves. Our vision for the map & backpack per our pitch is much more elaborate, but for now it mostly just exists as a way of getting between levels and equipping forms.

As for the levels, we've built them to offer an increasing scale of difficulty; level 1 is pretty easy, level 2 is harder, and the boss level is the hardest. This is reflective of the intended design of the game, to build a sense of "flow" for the player where their skill aligns neatly with the challenge offered by the game even as they get better at it. It also helps to have a difficult curve present for playtesting, to help us judge whether we're under or overshooting the difficulty.

This relates to chapter 10 of our readings, specifically the section on balancing for skill (Fullterton, 2018). With our current approach, we're loosely trying to balance for the median skill level, and we don't have any difficulty settings. Further in development, it might make sense to implement difficulty levels that adjust a few parameters; for example, we could probably add a difficulty setting that determines how much damage the player takes from enemies, and how much damage the player deals to them. Balancing the actual layout of levels is also possible but a bit more tricky, as we'd either need to populate levels using events or create multiple scenes per level to accommodate each difficulty level.

We've also set up a camera boundary system so that levels are broken up into sections with a static camera. This was accomplished by adding a border object and fixing the camera to one based on player collision. In my opinion, it has made the game look much better, and helps level design by allowing us to focus on one distinct fixed-size chunk at a time.

Above: A slightly more difficult section from the second level, adding damaging obstacles and enemies together and giving them less freedom to jump high and sail over things.

We've also updated the visuals a bit for the player character. Our original pitch used some mismatched styles, but we've changed the sprites for the "Ninja" and "Alien" forms to be more consistent with the overall style of the game. Importantly, they've also been sized so that player forms consistently look like they're the same size. This is helpful for collision, as it is both more consistent and clearer to the player. The "ball" sprite is still a bespoke creation that's not really consistent with the others, but this would change with more time & resources to fully develop the game.

Above: An update to a familiar graphic from our one-page, showing off the new sprites.

A large part of what we've been trying to achieve in Gdevelop is getting these forms working properly and consistently. In particular, the Ninja's ability to throw a kunai and teleport to it is something that involved a fair bit of iteration to get right. We have to be able to spawn the kunai, gets its position, move the player, and delete the kunai to make the ability function as intended.

While that's simple on paper, it means we run into a lot of quirks and edge cases about how our events are set up. For example, we had a bug where the ninja would seemingly disappear after teleporting, but only sometimes. Eventually, we worked out that it was because the teleport would happen after the kunai was deleted, which ended up teleporting the player to 0,0, which would get them stuck due to how the levels are built. but only sometimes. Some tweaking to the order of events and using some different conditions helped to fix this, and it was a good lesson in how a complicated mechanic can get fiddly and how we can go about troubleshooting it.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Assessment 3/Transform Rescue Playtesting

Our team conducted some of our playtesting at the week 13 halloween playtesting party, in order to gather findings for our report & work out what kind of changes we'd make for hypothetical continued development.

Leading up to this, we got all of our playtesting materials ready. We adjusted the IGB220 templates for the playtesting questionnaire, script & survey in order to make them appropriate for our use. For example, we completed the question about genres the player might be familiar with to be about platformers, Metroidvania games and puzzle-adventure games. Given that our demo had no sound effects implemented, we also nixed sound questions in the survey.

Above: An example question from the questionnaire.

At this stage, our demo contained a brief tutorial level, 2 proper levels, and one boss level. Because the core mechanic of Transform Rescue is changing forms, we made a point of ensuring that these levels were dissimilar. Level 1 was a traditional horizontal level with very open spaces, level 2 was a vertical level with more cramped spaces (in addition to generally being more difficult) and the boss level was a standalone encounter against one strong enemy. The playtest would start with a brief ingame tutorial (that the player is brought to upon starting the game), and would end after the player had beaten the boss level.

The actual playtesting went pretty well. We managed to get 3 playtesters during the party, and all of them stuck through the whole process, including the post-playtest survey. I took notes while observing all 3 playtests.

The full findings will be covered properly in our report, but there were definitely some standout trends that could immediately inform us about changes we should make. The most obvious one is the balance between player forms.

The player can bring 2 forms into a level and there are 4 forms in the demo total, but one form - the "Ninja" form - was used for most of the demo by all participants. It was clear in our observations that it was far stronger than the other forms, and all playtesters explicitly stated that they thought it was far stronger than the alternatives. As an extension of this, the other 2 forms with abilities - the "Alien" and "Ball" forms - got relatively little use, aside from one playtester making a point of trying out the "Alien" form some more.

This relates strongly to chapter 10 of our readings, specifically the section on dominant objects and dominant strategies. A dominant object is an object or unit stronger than the rest that the player will gravitate towards using, and a dominant strategy is a strategy that dominates others, thus reducing viable choices for the player. (Fullerton, 2018). Using the ninja form is very obviously a dominant strategy - being much more successful than any other choice - so this seems to be a dominant strategy revolving around a dominant object, and that's something we should change.

Another significant finding about forms is about the game's basic form, the "Human" form. The way the game is currently designed, this is the first form the player has access to, and doesn't have any abilities. However, this confused all of the playtesters a bit; because they could still choose this form after getting access to another one, they weren't sure if it was meant to have an ability that made it useful or not. They spent time pressing buttons to see if it would do anything, and seemed a bit disappointed when it didn't.

There's much more we discovered, but these two stick out as solid trends across all playtesters, with relatively obvious causes and solutions. We should probably adjust the balance between forms by making the "Ninja" form less powerful, and we should also consider either making the "Human" form more useful or limiting its use to the tutorial stage.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Assessment 3 Project - Initial Summary

Our assessment 3 project is based on another group member's platformer pitch, altered for the purposes of this assessment:

"Transform Rescue is a puzzle-platformer game that tasks the player with rescuing the citizens of the city, who were stolen by monsters. The player must reach the end of each level and rescue a trapped citizen, using 3 different forms that they can transform between at checkpoints. By rescuing citizens, the city can be rebuilt, giving the player more power along the way. Beat the monsters and rescue the citizens!"

We went through all of our one-sheets and one-pages to work out what would be most appropriate. In the end, we decided on Transform Rescue because it seemed the most appropriate for the playtesting-centric nature of assessment 3.

The most important deviation from the original design provided by the group member and our assessment 3 version is that transformation can only be done at checkpoints in levels. Originally, transformation could be done any time with consumable items. By changing the transformation mechanic into something that can only be done at fixed points, we have greater ability to design stretches of levels around the assumption that they'll be completed in a single player-chosen form.

Because several different forms are going to be available to the player, we have the opportunity to see how players handle choosing between them and using them, which should yield some valuable information about what works well and what doesn't.

In particular, the information about "lizard-frog-mouse" balancing from Lecture 7 served as an inspiration. The idea is that the levels in this platformer will be designed in such a way that they can be completed with any form (at least most of the time) through challenges that any form can complete, or multiple paths that play to each form's strengths. With this in mind, we can hopefully produce some interesting decision-making moments for players where they make their own judgment about what tool is best for the job overall (as opposed to, say, only 1 form being able to complete a level), which feeds into some well-defined goals and observations for playtesting.

[dmurrqut]

Racing game/Destrally Postmortem

After working on my Destrally prototype, I've got more thoughts to share based on my experiences.

As per the elevator pitch, I ended up leaning into colliding into (most) vehicles instead of avoiding them. I set up a scoring to support this; smashing into regular vehicles awards some points, smashing into an ambulance awards points and restores health, and smashing into trucks and police cars damages the player. The objective is to reach a target score in each level, after which the player moves to the next level with an increased level of challenge and higher target score.

The most interesting part of this exercise on the technical side was giving global variables a proper spin. I decided to use multipliers to determine the difficult of each level. Target score, vehicle spawn rate and vehicle speeds are determined by the value of their respective global variables. These values are multiplied by a fixed value in the transition between levels. It also means I can refer to to a variable instead of an arbitrary number in events that spawn or manipulated the properties of vehicles, which also means it's much easier to quickly change values and have it apply to all vehicles without having to trawl through a bunch of different events. I have some examples of my approach below.

Our textbook readings helped to give me the idea for this approach. Chapter 10 has a section on balancing variables, relating to how variables can be used to control the balance of a game, using the grid size of Connect 4 as a prime example (Fullerton, 2018). With control over both the base values and multipliers, I can adjust both to moderate the prototype's balance.

I believe these kinds of practices will be helpful to carry forward into assessment 3, where a more elaborate and refined design would be appropriate, and where rapid changes would be helpful as a part of the playtesting process.

On that note, this design also proved to be a helpful lesson in playtesting. It quickly became obvious that all of these values could use tweaking; the starting speed of some vehicles was too fast or slow, some of the target scores were too high or low, and the rate at which the difficulty of levels increased didn't always seem right. I did myself a bit of a favour by setting this up in a way where I could rapidly alter values and test repeatedly, trying to find a balance that felt right. When things were tuned too low, the game felt boring and sluggish, and when things were tuned too high, the game was just boring.

Another playtesting-related note is that differentiation between "good" cars that you're meant to hit and "bad" cars that you're meant to avoid wasn't as strong as it should be. If I were to continue developing the prototype, I think I would change either the targets or the obstacles to something that isn't another vehicle to provide clarity to the player.

On the whole, I think my Destrally prototype has provided some valuable insight that I can carry forward.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Racing Game Elevator Pitch - Destrally

My elevator pitch for my racing game is as follows:

"Destrally is an action-racing game where the player drives along an endless highway, smashing into & destroying vehicles as they go. Smashing small cars gives points, but more dangerous vehicles like police cars and trucks will damage the player. By earning points, the player can advance to ever-more-difficult levels with more & faster vehicles & obstacles. Destrally's target audience is those who enjoy endless arcade experiences, and the visual style focuses on vivid colours and exaggerated car designs."

Image retrieved from: https://www.pngfind.com/download/iobhoom_car-3d-automobile-vehicle-3d-car-flame-fire/

This pitch is the basis for my assessment 2 submission (the one-page and one-sheet), and so development has also gone a bit further than the others to support that. I'll follow up with a post-mortem that goes into more detail on what I actually did.

[dmurrqut]

Racing Game Development 2

Another interesting I had developing my racing game prototype was the use of instant vs permanent forces. Originally, I had an event with no condition applying a permanent force. This had unexpected results; the car having a force applied to it travelled many times faster than expected and accelerated out of control.

It appears that the force was cumulative and being constantly applied. By changing it to an instant force instead of a permanent one, the car started behaving as expected. This is yet another function of GDevelop that I'll have to keep in mind.

I've also been wondering if I would've benefited from using a physical prototyping method for this project. Chapter 7 of our readings describes physical prototypes, with a prominent example being using slips of paper to represent elements of the game. Interacting with those can be done to conduct some quick and dirty prototyping and revision, seeing what works or doesn't and quickly changing it (Fullerton, 2018).

If I had used a physical prototype, I might've been able to get a sense of how I want the player and obstacle vehicles to move during gameplay. For example, I could use a piece of paper as the game area, and run some toy cars across it by hand to work out movement patterns and speed. It would've been a good way to get an early sense of how I want the game to feel.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Racing Game Development 1

Following the practical for racing game development, I ran into an interesting situation where obstacle cars that I was spawning in with an event would appear then almost immediately disappear. At this stage, I hadn't added in any extra behaviours or events for the cars, so it wasn't immediately clear to me what was going on.

After some troubleshooting, I worked out that there were actually two problems. The first of the two was a simple typo; I was spawning the cars at a position off the top of the screen (with a negative Y axis value) which resulted in them being in an invisible area.

The more interesting issue, however, was the second; if the cars were being spawned offscreen, why were they briefly appearing? After fiddling with it, I think the root cause was that the timer-based event spawning cars in wasn't set to go off only once. I don't know whether this meant the event was triggering a bunch of times or something else to that effect, but the result was that the car would briefly appear at the correct X but incorrect Y position before quickly vanishing. Once I changed the event to only go off once, cars appeared as expected.

This represents an interesting quirk of GDevelop that I should keep in mind. If I want an event to only occur once at a time, I should make sure that I add the "only once while true" condition to enforce that and avoid unexpected behaviour, even if it doesn't seem like the kind of event that would have problems operating in sequence.

[dmurrqut]

Splitterfield/Asteroids Postmortem

After working on my Asteroids-based Splitterfield prototype, I have some postmortem thoughts that I'll now share.

An aspect of the readings and lecture materials that inspired my design process were discussions of "fiero", as the player's positive response to triumph over adversity. Speaking personally, I generally enjoy the feeling of fiero in games, and so it's something that I'd like to capture in some form across my prototypes. In the case of Splitterfield, the intent was to create an increasingly hectic environment for the player to navigate based on the player's input, allowing them to ratchet up the challenge and assume risk as appropriate via the use of splitting asteroids.

One thing I'd change about how I developed the prototype would be the control method for the ship. I think the ship slowly following the cursor isn't ideal, so I should've caught this earlier in the development process and worked on other options then. Importantly, this speaks to the order of what I did, not just what my actual design was; earlier testing and iteration might've revealed better solutions.

This is also a good topic for talking about what I would've done differently on the design side. I think it would've been nice to move to a twin-stick model, where the movement of the ship and aiming/shooting are handled by different inputs. By decoupling movement from shooting, I'd be able to focus more on the player engaging in evasive manoeuvres alongside shooting, instead of compromising one to do the other.

The process of developing this prototype has, in my opinion, helped me to gain some more insight into the "feel" of games from a development perspective, and exactly how I can make challenges manifest without leading to a negative gameplay experience.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Splitterfield Development & GDevelop Thoughts

As part of my prototype development for Splitterfield, I've started adding mechanics that I believe will enhance the game. In particular, I'm focusing on two mechanics; asteroids splitting apart when struck by the player's bullets, and a scoring system.

My first task was to make sure that I could actually spawn two asteroids when one other asteroid was deleted. It looks like there wasn't a ready-made trigger for when an object is deleted, so I had to find a way to spawn new asteroids at the right time and place.

To do this, I added events to record the X and Y position of an asteroid before it is destroyed, then after the action that destroys the bullet, I added events to spawn in two asteroids of a smaller size, and apply a random force to each.

This worked quite well, so I replicated the process to make a medium asteroid split into small asteroids in the same way.

I conducted some playtesting to see how these changes felt and worked. While the base functionality of the split was fine, the asteroid split wasn't particularly exciting and didn't add much challenge to the player. To iterate on this, I decided to speed up the force applied to asteroids to make the splits more dangerous to the player. Regular asteroids move at 40 pixels per second, so I decided to increase this to 80 for medium asteroids that split from large asteroids, and 160 for smalls that split from mediums.

After playtesting with these changes, I was very happy with the results. The faster medium and small asteroids ended up making the task of dodging much more reactive and fun. There's definitely a lot of balancing work to be done - at face value, the speed of the ship is too slow and the asteroids might feel fairer if they only ever spawn in at an offscreen position - but I'm happy with the results as a core mechanic to build off and twist up the Asteroids formula.

One concern I have about where I'm at so far, however, is that I don't seem to have a compelling objective for the player. According to the objectives section of chapter 3 in our readings, objectives give the player something to strike towards and can help set the tone (Fullerton, 2018). I'm not convinced that I really have an objective that does either of these things in my prototype, which is something I can look into more of I have time.

Going into this exercise, I had some concerns about how GDevelop would handle multiple objects of the same type in one event. Fortunately, actions seemed to properly handle references to objects by the last instance of an object of that type, so by ordering actions correctly (ie, creating asteroid A, doing something to asteroid A, creating asteroid B, doing something to asteroid B), it seemed to go off without a hitch. Coming from a broader object-oriented programming background, it seems a bit simplistic, but for the purposes of these prototypes, it has worked well so far. It will be interesting to see if I run into some more nuanced object referencing limitations in the future.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Evelator Pitch - "Splitterfield"

As I did for my platformer, I'm going to describe my elevator pitch for my Asteroids-style game. The pitch is as follows;

"Splitterfield is an science-fiction arcade shooter where the player guides a spaceship to shoot incoming space junk to score points. However, every piece of debris hit splits into more debris, and the player must be move their ship to avoid getting struck by an ever-growing mess of their own creation and avoid biting off more than they can chew. Splitterfield is envisioned as an experience for those who enjoy arcade games and racking up high scores."

The style is envisioned as being relatively straightforward sci-fi fare, with a simplistic ship design and obvious elements that the player needs to judge. As a starting point, I used the Stable Diffusion model to generate a piece of concept art for "spaceship flying through space junk", which produced something I think is appropriate enough to demonstrate the style.

My next steps will be to continue working on my prototype and add the junk-splitting mechanics and a scoring system, which will be my next post.

Stable Diffusion source: https://github.com/CompVis/stable-diffusion

[dmurrqut]

Slimby Climby Postmortem

After creating a basic environment to test movement & mechanics for my platformer, I settled on a prototype that focuses on vertical traversal by using timed button presses and bounces on enemies. I have some thoughts to share as part of my postmortem.

A part of our readings that I found helpful was the section in chapter 4 about challenge. Specifically, the idea of managing the level of challenge against the player's ability to create a sense of flow seemed like something I'd like to pursue. The downslam & bouncing mechanics are intended to represent a skill-based activity (by requiring them to take a time and positon-sensitive action), and in a full version of the game, would ideally be paired with levels and even incrementally added mechanics that gradually increase the level of difficulty for the player to match their increasing level of familiarity and skill with the game.

Depending on the complexity of level design, it could even require a degree of planning from the player to correctly navigate their way through a series of bounces. If I end up continuing work on this prototype for future assessment or my portfolio, I think this angle gives me a clear avenue to explore and expand into.

One thing I'd change about how I developed my prototype would be to spend longer developing more and better core movement mechanics for the player. While I settled on one core mechanic, it would have been good to set up a very basic testing environment with a floor and an enemy, and spend a large chunk of time adding mechanics the player could use to interact with that enemy to move around. Doing this early would help cultivate a broader set of ideas that could be implemented into the prototype.

Interestingly, my process (and the process for this unit in general) seems to have skipped past the physical prototyping described in chapter 7 of Game Design Workshop, but the process of prototyping in GDevelop is "quick and dirty" enough for this kind of game that it seems like a suitable substitute. (Fullerton, 2018)

In terms of the actual design of the prototype, I think one change I'd like to make is to generally add more hazards for the player (that damage or kill them, removing progress through the level) and add checkpoints that they return to when defeated. Hazards would increase the amount of challenge offered to the player, but checkpoints would also reduce the consequences of failing and, importantly, allow them to retry challenges more quickly and become better at the game. Hopefully, adding these two things and tuning them appropriately would help to contribute to the player's sense of flow by giving them an appropriate challenge.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Slimy Climby Development & GDevelop Thoughts

To start with, I had to actually decide what I wanted to do with my platformer to make it different. I wasn't sure how to go about this, so I took a look at chapter 6 of our readings. The brainstorming section caught my eye, specifically the emphasis on team brainstorming to generate innovative ideas (Fullerton, 2018). I ended up having an impromptu brainstorming session with a friend about platforming mechanics, while we were chatting on Discord while playing another game. It wasn't exactly formal, but I think that actually helped to tease out ideas, and the textbook itself says that brainstorming in a playful, neutral environment can be helpful.

My first attempt at adding another mechanic to my platformer prototype was a "downslam". In short, the idea was that when the player pressed the down key, they would immediately begin falling at top speed, and if they landed on a slime, they would bounce higher.

To begin with, I needed to find out how to actually stop the player in midair and cause them to fall. After some playing around with events, I ended up doing this by checking for a keypress while the player is jumping, then aborting their jump and setting their falling speed to a high number. I also added a new "Downslam" variable to the player object, to track whether or not they are currently using (or able to use) this downslam.

After playtesting and troubleshooting to make sure this part was working as expected, I began to work on the custom behaviour for the downslam that differentiates it from "normal" falling. In the end, I decided to accomplish this by splitting off the existing slime bounce event into two subevents, based on whether or not the "downslam" variable for the player is true. If it was true and the player was downslamming, a new set of actions would take over and increase the player's jump speed for their bounce, and finish off by resetting downslam to "false".

I tested this again, and immediately found that there were some big problems with how this worked. Specifically, there was no delay on downslamming again after bouncing, meaning that the player was likely to jiggle on top of an enemy and move up and down rapidly as long as the down key was held. It also had problems setting and resetting values for the player's jumping speed, meaning that they weren't properly getting the jump speed bonus they were meant to.

To solve this, I did some quick research and ended up using timer to track how long it had been since a downslam bounce had happened. I moved all the actions that "reset" the downslam into an event that checks to see how long has passed since the timer started, so it always triggers a set amount of time after a downslam bounce happens.

After doing this, the downslam worked just about as intended; by pressing the down key in midair, the player immediately starts plummeting, and if they land on a slime, they bounce higher into the air than normal. Further changes could be tested to see how they feel (eg, restricting left/right movement midair to add more challenge), but I'm happy with the interim results for this feature.

A higher jump, courtesy of the slime peeking out from beneath.

The most interesting part of this exercise was learning how to track an event over time in GDevelop, in order to manage the "cooldown" and general behaviour of the downslam ability. The downslam variable was useful for tracking and reacting to player input after the fact, and the timer was very useful for imposing a specific delay on an event. They add a great deal of flexibility to what I can make objects do, and I expect to be using both extensively.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Elevator Pitch - "Slimy Climby"

In this post, I'll be describing the elevator pitch for the platformer I'm prototyping. I'm going to split this into 2 parts; the pitch itself, and some elaboration on my thought process.

My pitch needed to contain my prototype's name and a brief description, including its genre, primary mechanics or modes of gameplay, its setting and/or style, and its target audience or demographics, all wrapped up within a few sentences that could be delivered within ~30 seconds. So, I came up with the following:

"Slimy Climby is a platformer-exploration game with a colourful pixel style, where the player must ascend a slime-infested tower and find their source. Starting with the ability to bounce on slimes for height and distance, the player must find new movement abilities within the tower to reach ever greater heights and, eventually, reach the top of the tower. Slimy Climby is envisioned as an experience with broad appeal for platformer-enjoyers of all ages."

The style is imagined as something similar to Shovel Knight, with pixel graphics and an emphasis on colour. The intent is not necessarily to directly emulate a particular hardware's style (like Shovel Knight did for the NES), but just to keep things proportionally appropriate for a platformer and simple enough for the player to look at and assess.

On the gameplay side, the pitch is largely built around the repeated slime bouncing mechanic discussed in the previous post. In developing this pitch & prototype further, the intention is to prototype extra abilities that the player could acquire over the course of the game, to allow them to traverse specific environments.

Sources:

Image retrieved from: https://www.indiegamewebsite.com/2019/11/13/shovel-knight-treasure-trove-is-finally-finished/

[dmurrqut]

Platformer - Initial Work

After going through the initial platformer design work in GDevelop (creating a basic character with a jump function, platforms, enemies that move left-right, and landing on enemies to jump again), I decided to briefly investigate how these components could be arranged in a more meaningful way.

To do this, I arranged them so that some simple gaps could only be crossed by landing on an enemy mid-air to perform another jump, with the enemies patrolling left and right in a way that requires the player to time their jump. It's simple, but adds some significance to the enemy bouncing mechanic by making it useful and necessary to progress.

After this, I decided I'd try to make use of playtesting to see what might need changing, following advice from our Game Design Workshop textbook. I had a core mechanic in place - bouncing on enemies as a form of traversal - so some simple playtesting might inform future iterations of my work. Ideally I'd have third parties perform playtesting, but for this stripped-down example I decided to play around with it myself and see what I could learn from the player's perspective.

Something I quickly found frustrating was that because I'd set up an event for enemies to be defeated after being bounced on, I could only travel these impassable gaps one way. That felt a bit claustrophobic and might be a problem for exploration in a full level, so I modified the event to no longer defeat the slimes.

After testing this new version, I found that it not only worked fairly well, but that repeatedly jumping on the same enemy felt fun, and that there was some entertaining challenge in staying in the air by repeatedly bouncing on a moving enemy. I think this enhanced the core mechanic, which seems to prove just how useful playtesting is (and how much more useful it could be with even more people involved).

This seems to be iteration as described by Game Design Workshop (Fullerton, 2018); the game was designed, tested and evaluated, and the evaluation resulted in a modified design that was tested and evaluated again. I'll use this experience to inform some details of my elevator pitch in a subsequent post.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dmurrqut]

Introduction

Hi! My name's Daniel, and I'm a third-year Bachelor of Information Technology student, doing IGB220 as part of my User Experience minor.

I like all sorts of games across a lot of genres; some things I've recently played are Total War: Warhammer III, Metroid Dread, Neon White, Elden Ring and AI: The Somnium Files - nirvanA Initiative.

I have a longstanding interest in games as a hobby, and I'm hoping to gain some insight into development techniques and processes in this unit. In particular, I'm keen to better understand how game development software tends to work, and how playtesting tends to go down.