intel-core-i0

[intel-core-i0]

Postmortem Ω, Bloodrush

Last one.

Working on Bloodrush has been uniquely insightful to me as a developer and as a member of a team. I was surprised how closely our team dynamic matched the structure that Fullerton describes in chapter 12 of "Game Design Workshop," where a natural leader emerged among us, despite us making the decision not to designate one. I think the teamwork really is the takeaway from this project for me, the insights gained into how team dynamics form have, I feel, equipped me well to join, work within, and potentially lead teams for other tasks.

If there was to be something that we could work on in that regard it would be task allocation. Tasks often fell to whoever thought of an idea first, which while reducing miscommunications about concepts also delayed development where people would be working on tasks which they were, myself included, less suited for. Despite that, having the structure we did for tasking was immensely helpful. While every part of the design was absolutely collaborative, the tasking allowed us to focus at least somewhat on our areas of interest/expertise, and group moral was significantly impacted because of this - I believe this also increased our effectiveness, and I think these are the kinds of things that IGB120 aims to teach us. Speaking of IGB120, this is it.

The subject has, to me, been immensely helpful in understanding exactly what an actual gamedev environment looks like, and it has reinforced my belief that this is what I want to do.

I'd like to thank Chris K and David C for their engaging and helpful teaching, as well as Riley, Jia, and Tommy for an awesome time making Bloodrush.

I want to continue this blog, but if my Duolingo streaks are anything to go off that may be a false hope.

Regardless of whether I return to this: So long, and thanks for all the fish.

[intel-core-i0]

The Playtester's Gauntlet, Demographics, and Teamwork

We made a "complete" prototype for Bloodrush, and all it took was my sanity.

Then playtesting ripped it to shreds...

...in a good way!

Something this week taught me is that you can't imagine what playtesters will find in your game. Something I thought I could assumed about game development is that in the early stages, the most skilled player will be the developers, but through this phase that has become evidently untrue. From speed boosts to attack patterns that made enemies unable to land a hit, I was shown time and time again the error of that thought. I think there is a real lesson to be learned in that: Don't try to balance your game without playtesters.

Partially this may be due to the demographics of our playtesters. Every single one of them stated that they enjoyed platformers, which is precisely what Bloodrush is. That's the second lesson to be learned: the playtesters you chose really matter. I saw a glimpse of this while making Rubberburn ’98, but it came into full force during this round of playtesting. After finishing our main playtesting trials we have been left with somewhat of a dilemma - we don't know how easy our game is for someone with little experience with platformers. If I could change one thing about our playtesting methodology, it would be don't just recruit frequent players of your genre.

Many bugs were found, but most were also easily fixed. Crucially, some of the movement tech players found allowed them to escape the map! This was quickly patched, but earlier playtesting could potentially have helped solve that problem before the big day, so the more formal playtesters could play the game in its entirety.

One. More. Post.

[intel-core-i0]

Vampires, Collaboration, and the Big One

Assignment 3 = Impending Doom

We're back, and it's a bit different this time... I have good news and bad news.

Good news first: the design has largely been taken out of my hands, which I love, because I can finally focus on making an actually complex game based on a solid brief, since we're working in a team!

Bad news next: GDevelop is being difficult...

For this game, Bloodrush, I have been placed in charge of working on AI - I knew the experience from the Astro Annihilation would come in handy! Unfortunately, instancing has become a larger issue this time.

I have come up with a relatively simple, yet in-depth behaviour for the NPCs, which builds off the ideas about emergent behaviours discussed during Astro Annihilation:

Wander

The NPC walks in a random direction, for a random number of seconds or until it nears a wall. Upon this, it enters the "Searching" phase.

Searching

The NPC turns around, stands still for a random amount of time, then activates the "Wander" phase in that direction.

Fight or Flight

NPCs are constantly raycasting in the direction they are looking. If the player is spotted, they enter this third, non-exit-able state, where they will either run away from the player or attempt to attack them depending on their ability to fight.

The Problem

The issue was instancing. When multiple of the same functioning NPC were placed in a scene together, all of them would stop working. It was quickly found that variables were clashing between instances, with them being aware of the state of the others without being meant to. Unfortunately, every technique we attempted to fix the bug failed.

The Lesson

The solution was to duplicate the behaviours for each individual instance. This was messy, but taught us a valuable lesson. Had we done this earlier, much more progress could have been made on the game, and we would be ahead of where we are now. The lesson to be learned is that sometimes an imperfect solution could be better than no solution. Not sure where this is from, but:

Don't let perfect be the enemy of good.

That's something I may need to learn.

Until next time, from a facepalming gamedev.

[intel-core-i0]

Postmortem III, Rubberburn ’98

Second last ultra-dry post, it's postmortem time!

The development focus for Rubberburn ’98 was somewhat different due to the time constraints involved - I found myself thinking about it less as a game that I wanted to be exactly the way I pictured it, and more as a teaching tool for the iterative design process. In the words of Brenda Laurel (MIT Press, 2004):

What is the process of iterative design? Test, analyze, refine. And repeat.

I think I took this to heart for Rubberburn, and I think it paid off. Who knew that listening to the advice of experts could... help you!?

I do think if there was one thing I would however change it would be the lack of experienced playtesting. Each round of playtesting (3 in the end) was conducted with naïve playtesters, and while this assisted me in getting new opinions and perspectives each time, not all the playtesters were really within my target audience. In "Game Design Workshop," Fullerton expresses the importance of using such players during the final stages of design. I think that a lesson to be learned is that using non-ideal playtesters may have delayed production of the game by having me focus on things that a player used to a genre wouldn't see as important, such as the visual effects of invulnerability. While all playtesting data is useful, sometimes it may be good to remember that not every single piece of feedback needs to be worked on individually.

For now though, that's kind of it! If i could change one thing about Rubberburn '98 it would be how rigidly the road moves from side to side, but the window for improvement there has somewhat passed.

For those in the know, Assignment 3 is now in full swing, so you can expect next week's post to be a devpost about that!

Hasta la vista!

[intel-core-i0]

Playtesting, Iterations, and So Many Explosions

Welcome back! I'm most of the way through creating Rubberburn ’98, which isn't usually when I make these posts, but this time I wanted to focus on something that these post often neglect to mention: Playtesting! Each game I make is both formally and informally playtested by a number of people, though I haven't spoken much about the results before now. Considering the relative simplicity of Rubberburn, I think this is a decent time to do so since there isn't exactly anything revolutionary in the code.

A (mostly) complete sample video of Rubberburn ’98, just missing a menu, some textures, and some tweaking.

The game is fairly simple. Players aim to survive while quickly moving down a highway that twists and turns to throw them off into the trees, but a lot of fine tuning needed to happen to make it fun, so here are just the 2 biggest things:

Trees

Originally, running off the road would instantly kill the player. Playtesters found that the game was extremely difficult, and that one in particular felt that some kind of grace period was necessary. Because of this feedback, the instant-kill was removed, and the frequency of trees were increased. Now, running completely off the road is still a death sentence, but players are given a little bit of leeway to stick part of the car off the road while surviving.

Respawning

The player, after death, respawns in the middle of the road. They used to be given 3 seconds of immunity from damage, and would be kept to the center of the road to avoid spawning in the trees if the road was turning quickly, but playtests found that this resulted in some players being trapped in unwinnable situations, losing invincibility moments before striking a vehicle that they could have avoided. Instead of being kept in place, the new versions allow movement during the invincibility phase, and also won't remove that invincibility until past the next car. This completely eliminated negative feedback in the area.

Playtesting has been a major part of my growing understanding during IGB120, and I am happy to now be able to confidently implement fixes based on user feedback throughout the iterative design process, which here I based on page 18 of Fullerton's book, "Game Design Workshop."

Big old wall of text, sorry about that, but I think it's super interesting neat how I am starting to understand not just how to make a game but how to make a fun game. Postmortem will be soon since i've left this post so late.

[intel-core-i0]

The Last Pitch, a Racer, and The Worst Name

It's that time again. Through the last two games I think the biggest lessons learnt were definitely in scope, so this time my biggest focus for an elevator pitch is going to be not over or under selling. In this case, the game will ideally actually be slightly simpler than Astro Annihilation, since looking ahead I will have less time to work on it. I also wanted to improve the actual engagement of my pitches, since my previous one read somewhat like a boring newspaper ad. With engagement and scope in mind, here goes:

Rubberburn ’98 is a top-down racing game, where players dodge obstacles in order to speed as fast as possible on a crowded highway! Designed for all ages, prospective racers may bite off more than they can chew as traffic conditions and winding roads make getting to your destination more difficult then just going fast - racing isn't for those with slow reaction times!

Experience a high sense of speed...

Survive nail-biting near-misses...

...and dodge the slow cars standing in your way, but stay on the road! You won't beat a tree.

Rubberburn ’98 is simple to control, with only the left and right arrow keys required.

A shorter post, for the aforementioned time constraints on this one, but I think that's a significantly better pitch then the previous ones!

[intel-core-i0]

Postmortem II, Astro Annihilation

The Astro Annihilation prototype is complete, so here's a dry post to "celebrate."

This game was truly born from a wish to experiment with enemy AI behaviour, something which has been as interesting as I suspected it may be. The big inspiration for the more complex enemy behavior stems from the concept of "emergent behaviour" coined from Conway's Game of Life, where clever design can lead to complex behavior emerging from simple rules. Fullerton outlines multiple other examples of emergent behaviour in "Game Design Workshop," including enemies in Halo and characters in The Sims, but the level of simplicity present in the Game of Life was the most adjacent to this project considering the minimal amount of time allotted.

Unlike ChronoKnight's too-large scope, Astro Annihilation suffered from the opposite problem - the brief was too simple to allow for a great deal of content to be added without introducing entire new systems for the player... There are only so many enemy types to add within the context of the game that would actually be interesting to play against. To combat this, an upgrade system was added quickly and dirtily, simply by adding multipliers to most hard-coded statistics about the player, however due to it not existing in the original scope of the project it was difficult to balance and implement well. In the future, it would be better to create a more specific elevator pitch that allows for more expansion, without falling into the same trap as ChronoKnight.

If one thing could be changed about the prototype, it would be adding more random chance to the actions of the enemies. As it is, multiple playtesters explicitly identified the actions of the enemy ships and turned it against them, predicting when they would attack or run away. While it is a good thing that players felt that there was something to "get" about the game, the realization came too quickly and trivialized the experience.

While the game is certainly more complete - and therefore fun - than ChronoKnight, it was also very insightful into how scope may further be managed in the future, and also provided me with significantly more information about GDevelop's systems can be used to produce complex interaction using simple behaviours.

[intel-core-i0]

Asteroids, AI, and Instancing

Hey there! Working on Astro Annihilation has been a lot of fun for me, so much so that I may have stayed up just a little late very much so too late to mess around with it!

It's become very clear to me that the BIG focus of this game will be the AI enemies. Reading Fullerton's works, specifically chapter 5, I gained a lot of insight into how enemy AI works in simple-ish shooters and arcade games, and I've decided to mess around with different behaviours for the enemies. Specifically, the enemy ships that mirror your own and hunt you down across the screen are designed with 2 main behaviours. Such a system allows seemingly very simple rules to produce complex and interesting interactions with the player:

Behaviour 1:

Move towards the player, and fire a projectile when close, then switch to behaviour 2.

Behaviour 2:

Move towards a random location on screen until out of range of the player, then switch to behaviour 1.

Gameplay of Astro Annihilation, including enemy ships (the more angular, fast moving spaceships)

The simplicity of these systems seems like it would produce little results, but when combined it makes the enemies feel very lifelike in their movements, so long as there is enough visual complexity onscreen to prevent the player from analyzing their movement. This method of producing "AI" was arguably inspired by Conway's Game of Life, a simulation more than a game, which is well known for its complex interactions between objects based on very simple rules.

Instancing...

... is its whole own can of worms. Objects in GDevelop can be repeated many times, where each iteration is designated as an instance. This is how all enemies in Astro Annihilation work, by creating an instance of the original object which inherits its behaviours. The problem that can potentially emerge from this is information meant for one instance effecting others. GDevelop enacts actions on instances based on the conditions for the behaviour - if an instance triggers a condition, it will be acted upon. This caused few problems during the development of Astro Annihilation, since GDevelop contains a handy tool to seperate instances in code, a "For Instance" container, but this information is something that is likely to come in handy later.

I am suitably tired at this point, so I'll end this post here, but the game is going smoothly.

[intel-core-i0]

Mistakes, Comprehension and a New Direction™

Time to actually produce the second GDevelop game. I've learned a few lessons after the last attempt that I want to apply to this one:

1) Reduce scope

The biggest problem that plagued my attempt at creating a platformer was the large scope, trying to incorporate environmental storytelling into a hand-built word. This was not an achievable level of quality in the time allocated for the task, and deviated away from the seeds of gameplay I identified in my first post on ChronoKnight. For this reason, Astro Annihilation will focus on moment to moment gameplay instead of complex level design, and will use things such as enemy spawn tables and duplicated assets to reduce the development time. This relates to the IGB120 Week 5 Lecture on understanding the possibilities and limitations of GDevelop, especially the advice of finding a simple scope that is easy to iterate on.

2) Playtest earlier and more

It will be important for Astro Annihilation to be playtested more than ChronoKnight, especially in the early phases. The reduced scope of the game will aid with this, as having a smaller amount of work for each gameplay moment will allow more to be produced before a reasonable timeframe for playtesting arrives.

3) Take on a more iterative approach

Further on this point, Astro Annihilation would benefit from a more iterative approach - things such as enemies and movement are easier to tweak and adjust than a hard-coded level design, meaning more action can be taken on player feedback.

Hopefully, following this new design strategy, it will be more feasible to complete an appropriate quality game within the timespan allocated. Sorry though, this was another dry post, but I think do it's an important one.

[intel-core-i0]

Asteroids, Another Pitch, and a Worse Name

Since I've completed the first prototype for ChronoKnight, it's time to work on another concept. For its pitch, I wanted to focus on identifying the player, more than the specific design of the game. This allows for more flexibility while creating the game than feeling hamstrung into creating a past vision for a game, and lets me alter parts of the game while focusing more on the player than arbitrary goals. An early IGB120 lecture discussed a possible framework for identifying a target player, which is elaborated more on in chapter 3 in Tracy Fullerton's "Game Design Workshop". The framework includes pacing, structure, complexity, and technological thresholds. In this case:

The pacing will be fast - easier to achieve entertainingly with the scale of the project.

The structure will be aimed at short bursts of play, meaning users will be less likely captivated by long play sessions

The complexity will be relatively simple, primarily comprised of identifying different enemy types and reacting accordingly

The technological thresholds will be that the game runs on a PC using a mouse and keyboard input method

With this in mind, I came up with the following concept for a game:

Astro Annihilation is a space survival arcade game in the style of the retro game Asteroids. Players will pilot a spaceship around a 2D field filled with various dangers such as asteroids, enemy ships, and dangerous alien drones. It will be targeted towards players of all age, but especially towards players familiar with traditional asteroids gameplay who are looking for a new twist on a classic.

Is it great? No, but it leaves significantly more room to be flexible in development, which I'll talk about more in the next post! For now, adieu from a very busy university student.

[intel-core-i0]

Postmortem I, ChronoKnight

I've finished working on the prototype for ChronoKnight. This post is going to be a bit drier than my others, as I'm going to be analysing the production process I underwent while making the game.

To begin the game, I mainly focused on the "seeds of gameplay" we learned about in one of our lectures. I believe this was a solid foundation in terms of starting development, as it gave me a clear direction moving forward. The "seed" I decided to focus on was the mechanic of time travel, and that greatly influenced the direction I took the game in moving forward. I believe this helped avoid feature bloat.

In terms of development, one major mistake I made was overshooting the scope of the game. Considering the short amount of time we had to create our games and how relatively slow development in GDevelop is, attempting to fit a real story to the game wasn't a practical endeavour. Scope is something that has been discussed in lectures and that I need to focus on more as time goes on.

If I could change one thing about the design of the prototype, it would be the amount of text in the game. This relates back to the scope of the game, but the text attempted to provide a rudimentary story, but by the time playtesters reached the prompt to activate time travel, many had already begun to skip parts of text, and were then confused when presented with a seemingly impossible obstacle which required reading the previous text to understand. In future, it would definitely be beneficial to take on a "show, don't tell" attitude, especially considering how little time is practical to show any kind of real story.

For my first real game development project, ChronoKnight has taught me some very valuable lessons as to the amount of time it takes to create different parts of a game, and I feel better equipped now to control the scope of future projects.

[intel-core-i0]

Birds, Boids, and Bugs

Eagle-eyed people watching the video attached to my last post may have noticed something flying along the top of the screen at various points... Birds! One of the first things I noticed about the visuals of my game was how flat it looked. It took me a little while to figure it out, but I realised that the problem was that, other than the character, nothing in the scene moved.

At this point, I recalled a video by Sebastian Lague on "boids", a type of flock simulation with many instances of an object, such as with birds or fish. Sebastian refers to a research paper on the topic, which outlines 3 guidelines for creating boids (Reynolds, 1987):

Instances should move away from each other when too close

Instances should face in the same average direction as those nearby

Instances should move towards the center of the flock

These 3 rules, while of little use on their own, together provide a fairly convincing set of rules for flocking animals on a 2D plane. Thankfully, GDevelop includes a framework for boids, which also supports an additional 4th guideline, which is to move towards a target object. When instructed in code to perform this action about a moving object, the result is a surprisingly effective approximation of flock behaviour.

If you have a listen to the video above, you may find that the explanation of the real life bird's behaviour somewhat mimics the guidelines we outlined for the boids!

When given a simple sprite and set to follow an invisible object, an easily implemented thing like this is effective at bringing some life to an otherwise still scene.

[intel-core-i0]

Core Mechanics, Basic Visual Design, and First Gameplay Sample

Today I began the actual development of a first prototype! The first thing to do, as I decided, was to see if the concept I had in mind would actually work.

Objects and Behaviours - The Basis of the Game

In GDevelop, objects can be given behaviours that affect what they do within a scene. An example of this are platforms that a player should walk on. Such objects should be given the "Platform" behaviour.

The reason this is useful is that behaviours can be turned on and off at will in code. When the platform behaviour is deactivated on an object, characters will fall through it as though nothing is there. Further, objects can be made invisible also through code. If these things are combined, you have a quick and dirty way of making objects disappear and reappear at will.

To create a very simple "world switching" mechanic, all that needed to be done from there was have multiple objects that alternate their visibility, either on a timer or by the press of a button:

This system forms the primary mechanic of ChronoKnight, where players need to switch between two layouts of the world to progress.

Visual Design - Taking the Level Switching a Step Further

At this stage, the time travel mechanic works, but it is uninteresting. To improve this, I focused on the most immediate thing most players notice about a game - the visual design. Using a creative commons asset pack from Itch.io, I transitioned the game from an object-based system, where surfaces are hand-placed, to a tilemap system, where tiles can be easily placed on a grid. This allowed for both significantly faster level design, but also for two complete tilemaps to be swapped out for each other. The advantage of this is that it's significantly easier to alter not just the locations of obstacles during a time-swap, but also the aesthetic design of the level, with different tilemaps for different time periods.

Making Time Travel Impactful

I then added post-processing effects to both the old and new time periods to reflect the mood that I wanted to convey, with the old period feeling sunny and lively and the new period feeling abandoned and unwelcoming.

Lastly, I introduced audio elements. Each time period has its own soundtrack that transition into each-other when the player switches, along with a deep bass sound effect to cement the theme that the time travel is profoundly unnatural.

Finally, I was left with what informal playtesting has revealed to be a suitably impactful moment (turn on sound):

That's all for this week. I'm satisfied with how the game is progressing, although I am beginning to see scope problems that I will likely address in a post-mortem once I finish messing around with ChronoKnight.

[intel-core-i0]

A Platformer, a Pitch, and a Bad Name

Week 3 is later than I wanted to start this, but a lovely thing called Tropical Cyclone Alfred had other plans. This post is going to be a bit of a pitch for the first game prototype I'm planning to create as part of my IGB120 subject.

Before that, though, I first considered why a player would want to play my game. In a previous lecture we learnt about the 7 Motivations for Play, coined by Ethan Levy (2006). I thought those seemed like a good place to start, so I considered which of these could apply to a simple platformer, and came up with this:

✗ Immersion

✗ Fantasy Fulfillment

✗ Human Interaction

✓ Excitement

✗ Reward

✓ Challenge

✗ Addiction

The reason for most of these not applying is simply the project's scope - It is difficult to establish any sense of connection with the game during the likely very short length of its gameplay. The exception to this is addiction, which in player-centric design, is not considered desirable. With the goals of enticing players through excitement and challenge specifically, I wrote this loose pitch (name most certainly to be worked on):

ChronoKnight is a puzzle-platformer based around time-travel mechanics. It is heavily inspired by the time-travel mechanics presented in Titanfall II (2016), where players can switch at will between past and future versions of the level in order to progress further. The game will contain a mix of platforming and puzzle sections, using the time-travel mechanic heavily throughout both medieval and modern 2D pixel-art worlds while avoiding traps and roaming enemies. ChronoKnight will be aimed towards all ages.

(link to an example of Titanfall II's time-travel in the mission "Effect and Cause")

That's all from me for today, I definitely need to work on that name. I'll likely make a post either tomorrow or the day after about the first progress on the concept.

[intel-core-i0]

Welcome!

Hi there, I'm Ben! I'm making this blog for my university subject, Introduction to Game Design, but I hope to find the time to continue writing here afterwards. I'm completing this subject as part of my first year in my Bachelor of Games and Interactive Environments degree at the Queensland University of Technology (QUT).

In terms of game design, I'm very interested in creating alternate controls and actions mixed in with familiar mechanics. Think platformers with time travel, Asteroids with extra dimensions, and racing games with flight mechanics. Basically...

5D Chess with Multiverse Time Travel (Chess.com, 2020)

In my own play, I'm mostly into slightly slower-paced simulation games like Elite: Dangerous and DCS World, but I enjoy a good run of Helldivers II as much as the next person. I'm also super big on VR. You can absolutely expect to see influences of such things in the prototype games I'll be working on.

Initially, this blog will discuss my progress in understanding the fundamentals of designing games for the player and my understanding of GDevelop as an engine, but I will include anything interesting and relevant to my studies as I see fit.

Further on through my degree, I intend to major in animation; so my aim for this subject is to gain a solid understanding of the foundations of game design and production so that I can apply the concepts I learn to my further studies in order to work more effectively with all aspects of game development. I believe that a game can look beautiful (my department), but it's not a game without gameplay (what I would like to get a grasp on).

This was a far-longer-than-hopefully-usual post, but I do hope you enjoy reading through my blog and that there are some learning moments and takeaways from this for both you and me. (Unless you are here to mark this assignment, then I hope you find enough in here to give me the elusive 7 😉)