somegamedesigner

[somegamedesigner]

Assignment 2 Progress

As this relates to a previous prototype and may lead to the next project, I should probably mention this:

As part of my university studies, I’m making a one page / one sheet based on one of my previous prototypes, in this case, Nightlight at the bottom of the sea, and trying to flesh out many of the concepts to do so. The main purpose of this is for us to get into groups and spend a few weeks working on fleshing out one of these ideas even further, and so these documents also serve as a pitch to our cohort.

And so, let me give you a more refined and focused pitch for nightlight at the bottom of the sea, having made a prototype already.

Focus Game: Nightlight at the bottom of the sea

X Statement (razor and slogan):

Razor: Roguelike asteroids in the deep sea.

Slogan: Become the bigger fish else you lose yourself in the darkness.

No. of players: 1          Genre: Roguelike?     Platform: PC

3 Unique selling points:

Fight for survival against highly aggressive and intelligent foes

Roguelike gameplay with permanent upgrades

Search for light as the light from the surface fades from view

Additionally, I want to potentially add an upgrade system, similar to the one I developed for Cosmoscrap Racing, but with two ‘categories’

Upgrade Types:

Base Increases (Damage, Movement Speed, Max Health, Attack Speed)

Abilities (Forwards Dash, Grapple (shoots towards target then pulls towards), Brake (Plus shrapnel on upgrades))

Upgrades are given in sets of three, one determined by boss killed, two random. Abilities replace upgrades on this screen if given to the player.

With some conceptualising done, I got to work on the one sheet first, because I wanted to do some game art to add to this one.

Nightlight at the bottom of the sea sell sheet

A one sheet, alternatively known as a sell sheet is meant to advertise to potential customers and to get funding for a game to be developed. As you can likely already tell, I chose to let the game art take main focus in this one trying to allude to movie posters such as jaws with the threat of the shark looming shark taking centre stage.

Feeling comfortable about this, I started work on the one page:

Comparatively, this one took a lot more work and revisions, as my first attempt at it was majorly lacking in the image department, and overusing descriptions, which would make the document less useful to potential developers, so I ended up remaking it from the ground up with this in mind.

Nevertheless, A one page is meant to act as a guide for developing the game for potential game developers, with descriptions of all the core mechanics and a significant amount of blank space for further ideas and notes.

Anyways, I might not end up working on this thing anyways, so I think I’ll leave it there for now.

[somegamedesigner]

Racing Posmortem

Alright then, now that that’s done I guess its time to review.

Game for anyone who is so inclined to play: https://some-game-designer.itch.io/cosmoscrap-racing-prototype

#postmortem

Once again, Fullerton’s Game Design Workshop textbook defined by process, although likely not as much as previous prototypes as this one was more driven by my experience with both racing games and in making the previous prototypes. That being said, a large amount of the broad strokes were defined by the discussion of formal and dramatic elements described in chapter 3 & 4, and Chapter 9, on conducting playtesting was especially useful for this game in particular. Additionally, I have read chapter 6, on conceptualisation at this point, but I then realised that most of the points mentioned I had already been incorporating into my work.

In terms of the development process, I took a similar approach to the asteroids game, with a main focus on mechanical integrity, alongside an emphasis on visuals to make the game’s objective as clear as possible to players. This worked very well, resulting in a more complete and structurally sound prototype with all of the mechanics fundamentally working. That being said, I wish I had done earlier and more thorough playtesting, before I had tuned in many of the mechanics, yet again, as suggested by Fullerton. Additionally, I wish I had developed this prototype in a different and more capable game engine, as my biggest problems with this game resulted from the limitations of GDevelop.

Finally, the prototype itself, as mentioned previously, was limited by the engine it was built on, which meant that the wall collisions and opponent pathfinding were lacklustre at best, with the wall collisions only vaguely following the tracks and the opponent travelling in straight lines unable to be moved out of their path. On top of this, I wish I had implemented music and sound into the game as the game feels a little less impactful without it. That being said, the track design, player movement, opponent balance, and UI were all pretty sound during my playtesting, and the core gameplay loop of the game is clear as day within the gameplay.

Well then, I guess that’s all of these prototypes done; on to the next thing then.

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

[somegamedesigner]

Racing Development Post 3

#development-post

Alright, guess I’d best get on with it.

With all of these additions and added mechanics, I felt that game only having the one track would get stale quickly, and the lack of straights on the track doesn’t mesh well with the nitrous, so I designed and created a second track.

Track 2: the ‘Warehouse’

A main design point of this track was to make it feel visually and mechanically distinct from the first track, which was now dubbed the ‘Circuit’. In comparison, the warehouse starts with a series of 90° corners, which quickly leads into the actual warehouse of the track, a large relatively open area populated by a few darker spots containing black holes. The warehouse also has two entry points, the ‘shortcut’ which has a narrow entryway and leads into a series of walls difficult to traverse and the normal path, which is longer, but has a long straightaway and transitions smoothly into the next corner. The track is not without its flowy corners however, as the rest of the race consists of such corners, as the player movement had largely been balanced around such corners at this point.

This led to a problem however, as the game had no method of choosing tracks, so I needed a track select screen, and so, I made one:

Start screen (left), Track select screen (middle), Controls screen (right)

As can be seen, I also created a proper start screen for the game, as I felt this was a suitable location for some visual flair, additionally, I added a controls screen to this menu, as it was a clear location for such a menu and to inform players about how the nitrous works.

Additionally, I realized that the second track’s layout would be a bit maze-like to newer players, and that the location of the opponent would be entirely unknown to the player when not on screen, so I added a ‘minimap’ to both tracks

Track 2 Minimap

To tie this all of this back into my readings of Fullerton’s Game Design Workshop textbook, I had been reading Chapter 9, on playtesting, and realized the game was most definitely at a point to do some playtesting, so as it suggested as a viable possibility for some low-effort playtesting I sent the game off to a few friends to gather their thoughts about the game at this point.

Firstly, one suggested that the opacity of the tire smoke could change depending on the angle of the player, and also the rate at which you gain nitrous. The nitrous changes suggested had already been part of the game, but I did tune up how much angle boost nitrous generation a little but the tire smoke could certainly be changed as such, and so:

New tire smoke effects on track 2

Secondly, the opponent racer felt slow, which I recognized as intended behavior at this point, but also felt there was an opportunity to add a mechanic from other racing games to make the racing more exciting.

In most racing games, opponent drivers are sped up when behind the player and slow down when in front of the player, to force the opponent drivers to approach the player, leading to more fun racing, and is a known and common mechanic. However, often when this is not balanced properly it can become very obvious to players and cause what is known as ‘Rubberbanding’, where the player gets substantially ahead of the player and causes the opponent to get slingshot forwards at ludicrous speeds, where the player is then unable to catch them.

And so, I introduced a similar mechanic to my game, where the opponent’s speed increases / decreases proportional to the difference in checkpoints and laps reached by each car and the amount of time it has been that way. With some tuning, this means that the opponent reliably stays within a range of the player and that the player can throw the race and still end up winning by the end.

With the game feeling more complete than it probably should be, I did a second round of playtesting in a workshop similar to that of my previous two games. As is becoming a pattern of these playtesting sessions, players suggested adding temporary powerups to the game, with potential to be in line with Mario kart’s item system. This idea was dismissed due to it conflicting with the already refined feel of the game and due to the playtesting being a little too late to implement such an idea. Additionally, players were annoyed by the janky opponent movement and wall collisions, but fixing these problems was beyond the scope of this project. All I really got from this playtesting was to tune in the opponent’s starting speed and confirmation of my design decisions.

So, all in all, I’m pretty confidant this is enough for now.

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

[somegamedesigner]

Racing Development Post 2

Alright then, getting back into it then;

The first thing I did after creating the tire smoke was change the aesthetics of the track, after all, my game is set in space, and I could make the track be floating above a field of stars, making the black holes make a little more sense (not that black holes this large this close to a track while not ripping it into bits can make sense).

Track 1 with background

At the end of the day this was a pretty small change, but it had a significant impact on how the game played and felt as well as the game’s visual identity.

Alongside this visual improvement, I also added collision to the track, to actually require players to drive around it, although engine limitations led to the walls being a series of blocks around the track vaguely where the sprite says the walls are located, and hitting a wall in the wrong spot may cause the car to stop entirely.

Following this, I sought to fix the issue of the race having no end, or any ending that would be made having little purpose, so I decided to implement some upgrades, as to match my pitch, although with a bit less complexity due to the limited scope of this project. In order to do so, I created the following series of race and UI elements:

Top to Bottom: Race countdown timer, Lap counter, Race position UI element

The countdown timer acts as an indicator to the player of context, with a start line in front of you and another car beside you allowing players to fill in the gaps that this is a race. Additionally, as nothing moves for the three seconds before it counts to “GO!”, it gives the player a moment to observe their surroundings at the start of the scene.

Meanwhile, the lap counter and race position give the player an indicator of the status of the race, while making the objective clear, complete eight laps of the circuit before the blue car does. These required a series of hidden checkpoints around the map in order to function, both to require the player to complete a lap before going to the next lap and as a check for which car is ahead of the other.

With these, I was now able to create the upgrade system, where at the end of a race (given you’ve won the race), you can choose between two permanent upgrades to your vehicle, or three if you managed to lap your opponent. Taking an upgrade also increases the speed of the blue car in the following race however, although this information is not given to the player.

Victory screen (left), Upgrade Screen (right) {Outstanding Victory}

The upgrades available after completing the race include:

Higher speed (Boosts player speed)

Better Cornering (Increases turning speed)

Increase / Decrease Gravitational Force (Changes the force applied by black holes)

Stronger Nitrous (Makes nitrous stronger)

Higher Max Nitrous (increases the maximum nitrous the player can have)

You may notice the “Stronger Nitrous” upgrade seen above, which brings me onto what I added next, a nitrous meter to the player UI and a temporary boost. You gain nitrous by drifting and creating tire smoke, filling up a bar on the top left of the screen which can be released by holding ‘Space’, boosting you forward while nitrous lasts. It exists to add more strategy to the racing other than just taking sharper lines, as well as encouraging sharper cornering, as it fills nitrous faster.

Nitrous meter increasing and decreasing in a race.

Nitrous Visual effects

Anyways I think I’ll pick up from here later, I've done more but problems are arising from the post being too long.

[somegamedesigner]

Racing Development Post

#development-post

Alright, like the previous prototype, I started work on this during one of my workshops, although unlike the previous prototype, I sought to create a rather different game than was provided, a top-down racer rather than a score-based lane switching game, so I simply am using some of the assets as a starting point to build off of.

To do this, I am expanding upon the movement in my asteroids game, using GDevelop’s experiment physics behaviors to keep the player’s momentum. Additionally, as opposed to the asteroids game movement, I am including left and right input and rotating the player sprite as opposed to forcing the player to always be facing towards the mouse. The rotation speed is also boosted while at low speeds for greater maneuverability and the force applied to the player while pressing W scales with the player’s current speed to give an acceleration effect. Additionally, also unlike the asteroids game, the camera is centered on the player as the playing field of a racetrack is larger than the available screen space.

From here, I needed somewhere for the car to drive, so I created the following racetrack as somewhere to test and tune the car’s speed and handling capabilities.

Refined Racetrack layout

As can be seen, in the design of the racetrack, I went a little heavy on the hairpins, as I found that the methods I was using for player movement forced the player to drift around corners in an entertaining manner. That being said, this layout was surprisingly effective, with a number of low-speed and high-speed corners and a few straights, with a short track length allowing for quick laps.

With a track laid out, I felt it was time to add some of the sci-fi elements, so I added a few black holes off of the edge of the track, which pull the player towards them, forcing the player to either counter steer or for one I placed in a corner, possibly use this effect to gain more speed and encourage aggressive cornering.

This unfortunately causes the blue car to travel in perfectly straight lines between points and be nearly impossible to move out of its defined path, making it very difficult to overtake. Additionally, it initially would not slow down for corners, exasperating this challenge. In the end, the opposition moves entirely differently from the player, with sharp cornering and very limited top speed.

Blue Car movement in comparison to player

Finally, with the blue car’s movement, I felt that the drifting of the player car could use some greater player feedback, so I added a tire smoke effect when the player is at a certain angle to the direction they are travelling.

Tire Smoke

Anyways I think I’ll leave it there for now, I’ve got other things to do.

[somegamedesigner]

Racing Elevator Pitch

So, the rule for this one was that it had to be a racing game, in whatever sense we see fit, but I’m keeping it simple with a top-down racer, taking some points from the asteroids game I made previously.

Just like before, I’m following Fullerton’s Game Design Workshop textbook, and I’ve finally read the chapter on Conceptualisation, and I realize most of the points I had already been incorporating into my work before. That being said, I did take some more time to dial in my concept this time, and so without further ado:

#elevator-pitch

Title of Game:  Cosmoscrap Racing

Elevator pitch:

In a interstellar scrapyard around a field of black holes, you’ve just worked your way up to a new ride, hopefully your ticket out of this dump, with the region’s tradition of scrapping each other’s car parts at the end of races. Race your way to the top of the food chain in this top-down racer where your hope lies on the end of annihilation.

Game Controls:

W for gas; A/D for left/right; Space for nitrous

3 Unique Selling Points:

Scrapping – Winning races awards you with parts of the opposition’s vehicles

Space Hazards – Watch out for nearby black holes, dodge them all you must or use them to your advantage

Top-down racing – Get a clear eye of the battlefield from an aerial perspective

Oh, and finally got around to uploading these prototypes to my itch.io, so if you are so inclined:

Platformer: https://some-game-designer.itch.io/water-hammer-prototype

Asteroids: https://some-game-designer.itch.io/nightlight-at-the-bottom-of-the-sea-prototype

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

[somegamedesigner]

Asteroids Postmortem

#postmortem

Well, it seems that project has come to its conclusion, so once more, I ask myself what I’ve learned from this experience.

Like the previous prototype, I’m trying to incorporate the Game Design Workshop textbook by Fullerton’s readings into my work, so in this prototype I took a lot from chapter 5, on System Dynamics, putting the majority of my effort into the combat system, adjusting various components to improve the player experience. In doing so, I also took a few points on Chapter 3, on formal elements, in order to create the fundamental structure of the game, and although in a simplistic manner, to give a level of meaning to the game. Additionally, the discussions on how to get significant benefit from playtesting in Chapter 10 was used in order to guide the brief amount of playtesting I did, as well as interpret the results I gathered.

In my development of the prototype, I focused largely on the core gameplay loop, similarly to the previous prototype with an extra emphasis on the look and feel of the gameplay experience as well as providing significant player feedback. This worked well, and resulted in more polished gameplay, but had its problems, as much of my time was spent perfecting the enemies and more specifically the bosses, with little to no development time spent on the player, or many of the concepts outlined in the pitch, which had some negative effects on the resulting prototype. That being said, when I was making the pitch, I went in with the understanding that many of its ideas may be altered or outright abandoned down the development pipeline, which Fullerton all too often notes, for various different reasons.

When it comes to the prototype itself, as briefly alluded to in the previous paragraph, the player abilities were very limited, and the player had similarly limited freedom apart from shooting things and trying to dodge attacks, with many of my ideas for player upgrades and player choice in combat left behind. This feeling was confirmed by my playtesting, where all of the playtesters felt that the player’s capabilities felt lacklustre compared to that of the enemies they were facing. Additionally, in the pitch I wanted to make the ocean feel dark and unknowable, but none of these ideas got implemented into the final prototype.

All of this being said, I leaned a lot making the enemies, and made up for a lot of the faults in my previous prototype, but either way, its on to the next thing now.

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

[somegamedesigner]

Asteroids Development Update 2

#development-post

So, since the last post I’ve made a significant number of changes and done some playtesting, so I guess I’ll go over it now.

To start with, I created a custom boss health bar for the shark boss, both to allow players to gauge their damage and to make the shark feel more significant.

Shark boss bar

After this, I figured there was significant reason to add a second boss, to compliment the combat loop of the shark and provide a different gameplay experience to players. To do this, I decided to create a “laserfish” which as the name suggests would shoot lasers at the player as opposed to charging at them outright, letting players shoot at a stationary target.

The laserfish fires in volleys of three, which then become five when below half health, forming a series of yellow crosshairs to telegraph where it will fire beforehand. I chose to use crosshairs due to various other games of differing genres using crosshairs to represent where an enemy or player will fire, letting player experience help teach players.

Laserfish weak attack (left); Laserfish in action (Right)

As can be seen above, I made some simple animations to go with the laserfish, hoping it would add to the atmosphere and better the player experience through more predictable attacks. Additionally, the laserfish travels quickly towards the player between volleys, in order to prevent players from running away from the boss.

Additionally, I made another boss bar to match the shark’s one.

Laserfish Boss Bar

I felt the game was missing a goal, so in line with various games within the medium, I added a simple score meter which would increment whenever the player killed an enemy, depending on the enemy, which would then be shown on a simple death screen upon the player’s death.

Death Screen (left); Score Increasing and health bar (right)

With a clear goal created and many of the mechanics implemented, I felt it was finally time to do some playtesting to gauge any unforeseen problems and glitches. So, as suggested by Fullerton in Game Design Workshop, in one of my workshops, I managed to get a few of my peers to test my game, gaining some significant insights for the purposes of iteration. The general consensus of players was that the boss fights added greatly to the gameplay experience and was their favourite segments, and that they functioned great, although few beat the shark, and one was unable to identify its attack telegraphs. Additionally, players suggested that greater player abilities through powerups or additional movement controls would add to the gameplay.

With these learnings from the playtesting, I swapped the boss order, as most players felt that the shark was more of a threat than the laserfish, and I figured swapping their order could solve the problem of players missing the shark’s attack tells, which I would also increase the duration of for players. I am currently unsure about adding powerups or greater movement capabilities as the bosses are designed with limited player movement in mind and further combat options would upturn the boss battle system likely require some rebalancing to greater expected movement capabilities.

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

[somegamedesigner]

Asteroids Development Update

#development-post

Going into this prototype, I want to try and make up for some of the faults and failings in my previous prototype, in particular the visuals and level design, giving an emphasis to player feedback, as was mentioned in the lectures, rather than the core gameplay loop. That being said, I still intend on doing more playtesting as I progress through the prototype’s development.

To start with, in the workshop I built the beginnings of the core gameplay loop, far more in the style of asteroids and its gameplay, with a collection of simple asteroids and a ship, which I would immediately replace in favour of simple fish sprites. As part of this, a simple though problematic solution to spawning asteroids on top of the player was to check for collision when creating the asteroid and then rerolling for a different location. Instead, I chose to create a series of bubbling sprites, which would have no collision themselves but create the fishes after a short delay, acting as a far more effective solution as it would also prevent asteroids from spawning immediately in front of the player before they would have time to react, which would have the same problem.

Large Fish Variants

Medium Fish Variants

Small Fish Variants

Gameplay Image with all three sizes of fish and their respective summoning bubbles

On top of these bubbling animations to add to the fish appearances, I added red variations that spawn after a fish is killed as further visual aide.

Death splatter particles; Small (Left) Medium (Middle) Large (Right)

Having done the basics by this point, I felt it was about the right time to make something more characteristic of the pitch I previously made, and as such, I got to work on a shark. The shark is intended to fill the role of a boss enemy, which gets summoned after killing a number of fish in the area, drawn by the smell of their blood, and seeing you as its next meal.

Shark (I spent quite a lot of time on this sprite)

It attacks with a barrage of telegraphed charges, using smaller and differently coloured bubbles to tell you where its going to charge at before it does. The locations these bubbles are located are calculated as where you would be if you didn’t move for the second before it charges. This is to force the player to react to the shark’s telegraph and require them to stop targeting the shark for a brief moment while making the act of fighting the shark more entertaining and require greater player focus.

Shark combat

Well, I think that’s enough writing for now, I should get back to making this thing.

[somegamedesigner]

Asteroids Elevator Pitch

Well, for the next one, we’re making a variant, or prototype vaguely based upon, the old Atari game ‘Asteroids’, where you play as a spaceship flying through space destroying asteroids while trying not to crash into them.

Just like before, taking a player-centric approach to game design, as described in Fullerton’s Game Design Workshop textbook and using its teaching to define my process, though giving the processes and workings within my Uni workshops have first say; and as such:

#elevator-pitch

Title of Game:  Nightlight at the bottom of the sea

Elevator pitch:

You are in control of a deep-sea research robot sent to the depths of underwater cavern, and its inhabitants see you as worthy prey. Fight your way to the bottom using your mounted laser and whatever you can salvage from the ocean’s depths.

Game Controls:

W for forward and Left click on mouse to fire, direction of movement always towards mouse. More controls may be added as you gain access to new abilities (if I make them)

3 Unique Selling Points:

Aggressive Enemies, they’re aware of where you are and are actively hunting you down, in comparison to the asteroids in ‘Asteroid’

The screen will slowly zoom in, representing the light fading away as you fall deeper and deeper

Slight Friction, unlike the original Asteroids, you are underwater, and thus you slow down over time unlike the vacuum of space.

Well then, guess it’s time to get started.

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

[somegamedesigner]

Platformer Postmortem

#postmortem

Having made their first proper game prototype, one looks back on what they’ve done. And so, without further ado: my thoughts for the process that got me here

My design process was built off of Fullerton’s Game Design Workshop Textbook, and so I tried to incorporate many of the Ideas into my work, notably chapter 8, focused on digital prototyping and as such, taking a quick and dirty approach to the visuals in favour of refining the gameplay through playtesting and iteration. As such, I focused my efforts on getting the core gameplay loop to a point where it could be playtested and iterated upon. Additionally, I took many points from other games in the medium, largely those noted in the book, allowing the new features to shine upon the standards of the genre.

What I would have changed about this process of prototyping is to increase the amount of playtesting, as what bits I did helped significantly but were still constrained to my cohort, rather than someone with no knowledge of our goals or ambitions or even experiences with the game genre. On top of that, I would have started with the enemy design, rather than homing in the finer details of the movement, as the goal was to create the core gameplay with none of the strings attached, to shorten development and make the prototype a prototype rather than the complete game. That being said, a main goal of this project was to get a feel for the engine and making games in general and I most certainly succeeded at that.

In terms of the prototype itself, I would have added more look and feel to the enemy interactions, as the combat felt repetitive and both your and their attacks felt insignificant, alongside being made inconsequential by the harpoon’s knockback outright preventing their approach. This problem area is made all the more glaring by the comparatively perfected movement, enhancing player control but also allowing a degree of skill in execution. Additionally, the level in the prototype feels mashed together with no clear goals and vision, which of course it was, making the game feel somewhat aimless.

All in all, I’m pretty happy with this prototype, and somewhat proud of the movement I didn’t really intend to perfect. So, with this done, on to the next thing I guess.

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

[somegamedesigner]

Platformer Development Update 2

#development

From the last post I’ve made some enemies, as I needed to make some enemies that could be moved, preventing the slime I made in the workshop from working, as moving it outside of its designated left and right junctions would force it to move indefinitely or cause similar problems. On top of this, I wanted some greater enemy variety, leading to the following two enemies

“Blob” (left), “Top” (right)

Starting with the red enemy on the left I titled “Blob” for developmental purposes, I found that using a combination of platformer character, tween and pathfinding behaviours created a simple and effective way of creating an enemy that follows you, and could be knocked back, even if when you stand above the blob it would bob up and down in place (see below). Additionally, removing the platformer character behaviour would cause it to float around, which would then be used for the “Top” character as a stronger enemy. So, with the addition of some simple health bars and having learned a few things in the process, I made the following:

Of course, following Fullerton’s Game Design Workshop once again, enemies have no stakes if there are no consequences for death, so I added a death screen, which would trigger if the player had less than or equal to zero health, or if the player fell of the map, restarting the game from the beginning.

Death Screen

With these enemies, I decided it was time to add the kick attack on right click, to allow another method of engaging in combat and another avenue for player expression in gameplay. Eventually, it changed from a kick to a short-range lightning pistol with the same effect, realising that I wasn’t going to change the player model, and I wanted something that matched a little better. Mechanically, it creates a hidden hitbox that collides with enemies to deal high damage, with knockback scaling with player speed in exchange for preventing all player movement while in use and likely damaging the player in the process.

Before I had properly figured out the enemy mechanics, I also did some playtesting in one of the workshops, as a player-centric approach to game design encourages early and frequent playtesting to gauge the efficacy of your approach. The results I found was that players had a hard time figuring out how to properly use the harpoon attack’s recoil as a movement option, and that the blob in its current state felt somewhat insignificant. It also found a few glitches in the game, notably that turning around against a wall would allow you to jump again, acting as a sort of wall jump, which I felt had more value as a difficult to use movement option than removing it, so I decided to leave the bug in.

Wall jump

Taking the considerations of my playtesters in mind, I added the aforementioned “Top”, a few test blocks past walls to teach players certain mechanics, as well as significantly increasing the threat the blob posed by increasing its health, all in order to fix the flaws I found in playtesting.

Anyways I think that should be all from the platformer then, just to make a postmortem.

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

[somegamedesigner]

Platformer Development Update

#Development

To start off with, yet again following Fullerton in ‘Game Design Workshop’ I went from that premise into prototyping on GDevelop, seeking to fine tune the core gameplay loop, discarding any aesthetic qualities or story in order to keep the scope small and allow for easier tinkering.

Starting with a simple few platforms and a slime which dies upon jumping on it that I created in a workshop, I spent the last week adjusting the movement, prioritizing making control of the character feel natural rather than focusing on combat and level design. As such, the controls were set primarily as was described in the last post: WASD for up, left, down and right respectively, as well as Space for jump, following the conventions of most PC based platformers while allowing reasonable use of the mouse for other controls. As such, set left click to the harpoon ability, seeing it as the more reliable damage ability due to its range and swapping it with the hammer, keeping it on the mouse due to its aiming requirements making it the most reasonable requirement.

First off, I found the game’s movement felt a little sloppy and unresponsive and I wanted to move easily conserve momentum, so I added some code seen below to make turning around and stopping snappier while allowing players to maintain a lot more speed while airborne.

From there I started to figure out how the harpoon was going to function, as I thought getting the projectiles and knockback functioning early would be a worthwhile learning opportunity.

 Pretty quickly I had created some simple sprites for the harpoon and shockwaves, choosing to make the shockwaves a simple sprite animation rather than trying to scale up the object over time for simpler development.

From these, I used the projectile system and an object spawner behaviour to turn it into a functioning projectile, leaving just the recoil effect of shooting the harpoon. This was a surprisingly difficult task, as had some specific requirements from the recoil, that being:

 1 – Recoil would apply in both the X and Y axis

 2 – Recoil would scale with the angle with which the harpoon was thrown

 3 – Recoil amount would be independent of player distance from mouse

The third requirement was especially difficult, as it meant I couldn’t just use the mouse’s coordinates. In the end it required calculation of a unit vector, in order to meet criteria three, see below for the final code.

In the end, this code is limited by the engine, as the ‘Change the current falling speed’ command is overridden while the player is jumping, only working on the Y-axis when the player is falling, so the knockback from shooting the harpoon is unable to change how high the character can jump.

I’ve done some more stuff than this, but I’m still experimenting to try and make things work so I’ll leave this post at this for now.

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

[somegamedesigner]

Platformer Elevator Pitch

To start with, I figured a platformer would be simple to create and conceptualize, while also allowing for great gameplay.

I’ve been reading Game Design Workshop by Tracy Fullerton, intending on incorporating the ideas into the games I make. As such, I’m taking a player-centric approach to game design, which involves lots of prototyping frequent and early playtesting in order to root out any core issues before its too close to release to change. This all made clear sense to me although I disagree with starting with player experience goals and building the gameplay around that in comparison with starting with gameplay and then building an experience as I feel that giving primary focus to what you want players to feel may force repetitive structures and impede innovation in gameplay. The points made I don’t believe are entirely invalid, but rather I believe that more experimental design decisions would create more innovative experiences rather than building games to suit already saturated experiences, as such I have instead began the conceptualization with the following.

#elevator-pitch

Title:  Water Hammer

Genre: 2D Movement Platformer

Elevator pitch:

Water Hammer is a fast-paced movement-focused platformer set in an alien water world where in times of turmoil, a veteran warrior must fight one last time in order to keep his country from collapse, using every aspect of the terrain to his advantage.

Goal of damage dealt being dealt when an enemy gets knocked into terrain, proportional to how quickly an enemy decelerates, with the player’s momentum factored in.

Game controls:

WASD for movement, Left Shift to Dash, Left Click to swing your hammer, Right Click to Throw a Harpoon, creating a shockwave towards the mouse but also has recoil.

3 Notable Selling Points:

Level to level gameplay, allowing for pick-up and play.

The main way of dealing damage is to launch enemies into walls.

Faster Player Speed means more damage, encouraging faster play and potential speedrunning.

Audience: Ages 13+

References:

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

From here, I think I’m gonna start experimenting in GDevelop to make a prototype.

[somegamedesigner]

Introductions

So, I guess I'm just a game design student at QUT, Creating a devlog as part of my studies knowing full well it might not lead to anything, or I might come back to this years later after everything's been said and done.

But in terms of my interest in game development, I've got no real preference in terms of genre, though I'd like what I'd make to have a significant challenge to it, as that tends to be what I'm drawn to in terms of the games I play. eg. Elden Ring, Ultrakill, Modded Terraria

And so, let my however meager and faint mark on the world begin.