⚠️GOBLINS ONLY⚠️

Michael Keel (he / him) | n10876669 | This blog is dedicated to my game dev journey during IGB220 at QUT

[devgoblin]

Week 13 | A3 Post Mortem

What aspects of the readings helped inspire your design process?

The development of TimeKnight was the first time this semester I was able to have the time to develop a game to the point of prototyping it. I was very much made aware to the point made in chapter 9 of Tracy Fullerton’s ‘Game design workshop: A playcentric approach to creating innovative games’.: playtesting is key to a game’s development as it makes you aware to how the perception and play of the game is, not what you wish it to be (p. 310). Developing a game is hard, so it’s easy to try and cut corners or justify things that don’t go the way you want them to, and playtesting makes you face those shortcomings head on. Additionally, it can also help to inspire and motivate you to work on your game - it was incredible seeing how much people enjoyed their time with TimeKnight’s early prototypes. In future I think I’ll be more willing and prepared to prototype my games, regardless of what stage of development they’re in.

What’s one thing you’d change about how you developed the prototype?

I believe we were too ambitious with TimeKnight’s scope for the duration of this project. I believe we were too focused on trying to thing of unique and interesting mechanics for TimeKnight that we neglected spending enough time defining what we wanted our Player Experience Goals to be. Our plan for TimeKnight was so ambitious that we spent a lot of time just developing a few versions of an early prototype. Player experience goals are used to consider what sort of experience you want the player to have and help understand what ways are best to make them achievable (Fullerton, 2018, p. 12). We received a lot of feedback on our prototype indicating that what we had was enjoyable, but lacking in interesting gameplay - it was a good early prototype, but did not offer any rewarding experiences at this stage. If we had spent more time thinking about what sort of experience we wanted our players to have, and what sort of experience would be achievable within our time frame, then we may have finished with a prototype that explore the mechanics we implemented in more interesting ways.

What’s one thing you’d change about the design of the prototype?

If I were to change anything about TimeKnight, it would likely be the implementation of the Dash mechanic. Though interesting, I believe it was too ambitious for the scope of our project. Additionally, most of our negative remarks in the playtesting was tied to this mechanic. If we were to continue development, I believe we should think about ditching the dash mechanic all together and working on creating some unique and interesting gameplay for the parry mechanic (i.e. thinking about those Player Experience Goasl!!)

[devgoblin]

Week 13 | TimeKnight Development based on Player Feedback

During our initial playtest of TimeKnight, we got a lot of feedback about players not realizing they had been hurt. Players indicated that this was due to a lack of feedback. As such, I got straight to work on making some hurt frames for the player character to help address this.

We would also add some audio cues to accompany this, but that was handled by another team member.

Additionally, we found that the Dash mechanic needed a good cooldown with a clear indication of when it is and isn't available to use. Taking inspiration from one of the team's favourite games, The Legend of Zelda: Breath of the Wild - we evaluated that something as fundamentally important as movement should central to the player.

We would place the above animation right above the player character (which is where we notice players were looking most of the time during our playtest). Finally, players found the immediate teleport to the next level to be a little jarring, so I created a "teleport" animation to help convey the process.

[devgoblin]

Week 12 | TimeKnight Playtesting

To be a good game designer, you need to not only be an advocate to the player, but also work collaboratively with players through playtesting (Fullerton, 2018, p. 278). In Playtesting, you are able to listen to and champion player feedback in an effort to produce a better, more enjoyable game. This week, we began our Playtesting with TimeKnight.

*sniff* our little's baby's first playtest - they grow up progress in development so fast!

Overall, our Playtesters responded very positively to TimeKnight! There were a few bugs with our game that we knew would need to be squashed going in to the Playtest, but it was great hearing an actual player give us feedback on our game. The thing most players seemed to like was the art for the game - which I found very flattery as this semester has been my first experience with pixel art. That being said, I do personally adore the design of the player character, TimeKnight itself, so I'm glad that it's not just creator-bias speaking there!!

Reference: Fullerton, T. (2018). Game design workshop: A playcentric approach to creating innovative games, fourth edition. CRC Press LLC.

[devgoblin]

Pls don't fail me I have an extension

"You've just activated my trap card, Swords of Revealing Light! Automatically Approved 48hr Extension"

[devgoblin]

Week 11 | Time Knight Sell Sheet

Look at this! Group 27's Time Knight is looking like a real game!

[devgoblin]

Week 10 | A3 Development

This week I formed a group and got developing a new game: Time Knight. I've been assigned the role of artist, so I spent a lot of my time working on some game assets for the team. Our playable character is a knight of time, so I thought an hour-glass based player model would be best suited for the game!

Player character - top left Level progression bar - top middle Health UI - top right Time Clock Fragments (main collectable) - middle Debris - bottom left Projectiles - bottom left, to the right of Debris Enemy Sprites - bottom middle

[devgoblin]

Week 9 | Racing Game Post Mortem

What’s one thing you’d change about how you developed the prototype?

If I were to undertake the development process of Fish Whizzard again, I'd probably spend less time in the assets phase and more time actually working on the Prototype (a trend I'm seeing very much repeated in my development cycles). This time around, I was very aware that asset generation would be necessary for me to properly convey the information and feel of Fish Whizzard in Assessment 2 (the previously posted Sell-Sheet and One-Page document), so I ended up spending a lot of time on things like the background and enemy and fish designs. Whilst I feel this was beneficial for my second assessment, I do feel as though I could've kept the ball rolling better with the actual prototype and potentially had a more robust version to playtest.

What’s one thing you’d change about the design of the prototype?

I ultimately think that the mechanics don't quite control the way I'd like. Initially, I thought having a bit of slide to the player's movement would result in more interesting gameplay, but ultimately it seems like all players (myself included) far prefer a tight control scheme.

In future I want to try and spend more time hammering down the mechanics and playtesting multiple versions before moving on to other aspects of the game.

[devgoblin]

Week 9 | A2 Fish Whizzard One Page

The completed One-Page for Fish Whizzard. It's a little overcrowded, but I felt like there was a lot to explain. In future I guess I don't need to go into quite as much detail - but I figured it was better to be safe than sorry with my first one-page document.

[devgoblin]

Week 9 | Racing Game Dev Post

Finally got the hook to work!!! Progress!!! Wooooo!!!!

[devgoblin]

Week 8 | A2 Development: Sell Sheet

With development going steady on Fish Whizzard, I got to work creating the single page sell-sheet for the game!

What do you think? Are you sold on Fish Whizzard yet? (Because you should be, look at this little dude!)

[devgoblin]

Week 8 | Racing Game Development Post

(Messy "code" right now, but I'm working on it!)

I have the fishing hook working (to a lesser extent)!!! When the space bar is pressed, a hook will spawn under the player and begin descending down to the ocean. When it is released, it will ascent towards the player until it collides with them, resulting in the hook's deletion.

Known Errors:

Currently, if the player releases and presses the hook again, it will spawn another hook. This can be fixed with some if statements and variable magic.

A new animation needs to be created for the Fish Whizzard for when they are fishing.

There is no continued fishing line. I'll look into creating one, but I don't see this being a priority for the prototype. Worst case scenario and I can't figure it out, I'll have the Fish Whizzard use telekinesis rather than a fishing line to cast and reel his hook.

[devgoblin]

Week 8 | Racing Development Post

Today I implemented a boundary into my game to ensure that the player wouldn't be able to move off-screen.

Besides implementing the boundaries I also slightly tweaked the rotation and movement speed of the player character. Next step is to figure out the hook mechanic!

[devgoblin]

Week 8 | Racing Development Post

This week I've been working on setting up the base controls and assets for Fish Whizzard. By utilizing the top-down movement behaviour that comes in-built with Gdevelop, things went pretty smoothly with the implementation of the controls.

The thing that took up most of my time this week was creating the assets - though I'm very happy with the Fish Whizzard Sprite! At the moment, I have a base idle sprite and a hurt sprite.

I also create a scrolling water sprite, to give the impression that the player is flying across the sea.

[devgoblin]

Week 7 | Racing Elevator Pitch

Title of Game:

WHIZZ-ARD FISHER

Racing Elevator Pitch:

A side-scrolling racing game meets a fishing game with a wonderous wizard-y skin! Race from left to right trying to sail the seven seas on your broomstick! Avoid seagulls and magical enemies while hooking up different fish for unique power-ups - but be careful, hooking up trash might hurt your wizard!

Image:

Control Diagram: W - fly up || S - fly down D - accelerate || A - decelerate Space Bar - drop / raise your hook

3 Unique Selling Points: 1️⃣ Racing game meets Fishing Game! 2️⃣ Sail the seas as a wizard / witch! 3️⃣ Fishing is now fast and sexy!!!!

[devgoblin]

Week 7 | Asteroids Post Mortem

What aspects of the readings helped inspire my design process?

As mentioned in a previous post, the notion that the first idea you come up with is scarcely one that makes it through to the final version of the game (mentioned in Chapter 1) really helped me with my design process. During my platformer development, I was too married to my first idea and struggled too much to implement it in time. This time around, I leaned into the fun things I was experimenting with and it produced a much more polished and playable product.

What’s one thing I'd change about how I developed the prototype?

I don’t know if there’s much I’d change about my design process for this one. Whilst I acknowledge that starting out with a range projectile maybe wasn’t the most helpful for my more melee-focused direction, however it did help me understand how collision works in Gdevelop. Ultimately, I think I would’ve benefitted from underscoping again. Tracy Fullerton raves on and on about how a game needs a unique selling point or twist to engage and hook players, and whilst I completely agree with that notion, I don’t believe I am skilled enough at game development to bring the ideas I’m having to life. Whilst I would love to innovate and make exciting fresh new games that put a bit of a spin on the classic genre, it takes me far too long to figure out how to implement the innovative features (if I ever figure them out at all!). My biggest challenge moving forward is going to be figuring out how I can add a innovative twist on a genre without over-scoping myself as a baby game dev.

What’s one thing I'd change about the design of the prototype?

If I could change anything about my prototype, it would probably be the polish. I would’ve loved to have more time to make custom sprites, and implement visual feedback and sounds. A lot of the player-testing feedback I got was confusion due to the bare-bones nature of Space Janitor at the moment, and I would’ve loved to see what feedback I got if I was able to counter-act that.

[devgoblin]

Week 7 | Asteroids Playtesting Feedback

After getting three of my peers to have a playthrough of Space Janitor, I came out with some great overall feedback. Whilst I have to say I expected to hear a lot of it, I can't say it doesn't sting slightly more when hearing it from somebody else. Nevertheless - I am greatly appreciative for the feedback as this will help me turn Space Janitor into a better game!!!

Playtesting Feedback:

The game feels unresponsive at times, look into adding sound, hit animations and general UI indicators.

It was easy for players to get a bit lost at first, but after a few tries things started to be more natural for them - look into refining visual clarity or adding instructions.

The LaserBroom has a bit of a distracting glitch when it reaches the mouse position and the player is still holding down the mouse button, which can result in player aggravation.

The same thing can be said about the PlayerShip.

The score isn't immediately obvious it is a score.

The game was "unexpectedly fun" (woohoo!)

[devgoblin]

Week 7 | Asteroids Development Post

What have you been trying to achieve in GDevelop?

This week I have been trying to get Space Janitor up to a playtesting level - and I think I achieved that!

I first messed around with the LaserBroom mechanic, fiddling with the control of it until it felt like it was in a good, responsive and yet still challenging place.

Speaking of challenge, I also added a condition / action so that the LaserBroom would hurt the player if they came into contact with it, adding some much needed depth to Space Janitor's gameplay.

I also finally implemented a score feature! Now players have an actual indicator of their progress / achievement! Yay Game dev! All in all, I think it's looking pretty good!