Introduction: 

For this project I was tasked with designing a level, level mechanics, as well as player mechanics with virtually no creative constraints save for the playable area had to fit within the bounds of 7000 x 7000 x 50 (geometry shape brush settings). I chose to make a game involving dragons, and make the primary gameplay to be a mix of flying and gliding. Concerning the latter bit, I had drawn inspiration from the 1996 game ‘Pilot Wings 64’, specifically the hang-gliding challenges.

 

Video: “Floating Isle of Etherea” Level : Gameplay Demo

 

What Went Right:

Basic Controls - The general functionality of the third person character was straightforward enough to implement. For one thing, I used the third person character as a template so basic movement was already in place. The rest was simply toggling to ‘flying’ in terms of movement mode, and adding some additional input actions (such as ‘flap upwards’ & ‘breathing fire’) which were all fairly straightforward in how to implement. The primary gameplay hinged around a ‘gliding’ state of flying (in terms of movement mode it’s technically ‘walking’, as gravity affects the player pawn), and admittedly I did some research to find how others would implement it. I combined two (already very similar) approaches, and tweaked it until it was decently refined.

Animation Blueprint - The animation blueprint was fairly painless. Setting up blend spaces, the state machine, pulling the necessary data (velocity, conditions, etc.) from the player controller / character, etc. etc. was all rather straightforward.

Art Assets - I wanted to do a game that involved flying (narratively speaking) and more specifically about dragons. I luckily already had a few dragon models from two separate asset packs I owned, though I’ve had a more expensive dragon related asset pack on my marketplace wishlist for a few months now. Not only did I not remember having some basic dragon models already, but that each came complete with quite a few animations that would be more than enough to cover any possible player control/ability/mechanic etc. that I had in mind for my gameplay. As I mentioned above, from there it was setting them all up in the anim_bp, and mapping the input actions to trigger each (in addition to toggling movement modes and related data). In terms of “breathing fire”, I did have to add a separate particle & sound effect for the flame and the sound it makes respectively, but again I had more than enough assets already owned that worked out perfectly for my needs.

Level Mechanics (Thermal Column & Teleporter) - Similarly to implementing the basic player controls (and animation states), conceiving of and programming the level mechanics was rather straightforward and went smoothly. The primary level mechanic (thermal column) was simple enough in functionality that I didn’t feel the need to research other implementation approaches (as was the case with the ‘gliding’ mechanic). The teleporter as well, in terms of the approach.

Use of Interfaces - Prior to this assignment I had yet to utilize interfaces, yet for this project I almost couldn’t imagine not using them. Particularly with both my ‘interact’ and ‘burn’ mechanics, there were so many variations of functionality for each that not using interfaces would’ve been a messy nightmare. Dialogue (triggered by the ‘interact’ input action) amongst NPCs would have been enough of a reason to warrant interfaces, but then interacting with a teleporter, consumable items, etc. made it best to have all individual class functionality exist within those specific classes vs. digging into references from the player’s overlap event. And again, with the fire breathing collision, which affected different things in different ways, I had certainly made good use of interfaces for that as well.

 

What Went Wrong:

Over Scoping - In planning out the level for the level design document, though I knew of the dimensional constraints, I still managed to plan out a level far bigger than what was possible for that space. Remedying it was luckily pretty straightforward. I simply condensed the gameplay to the original “end point/area” of the level design, which as it stood, was itself large enough to contain a playable area with a level start and end (and 3 pathways) within its bound.

Level Design - Though of course I enjoy creative aspects and decisions to be made in all design assignments, I still struggle with the more rigid and calculated aspects of level design. At least I find it to be more tedious and less enjoyable than even seemingly mundane aspects of the overall game design, such as abstracting the programming for example. Making narrative choices and beats, events, environmental story-telling, etc. is all really enjoyable - especially given my background in the creative arts. However, the next most enjoyable aspect of game design for me is the programming and all the creativity (and problem solving) that arises in the blueprints / coding the mechanics, functionality, event triggers, and gameplay. Planning action blocks, balancing IPM, and placing shapes (geometry or mesh) to construct a level / playable environment feels difficult at worst, tedium at best, by comparison. For this project, knowing my primary gameplay would take place in the open air, I found myself neglecting designing and constructing an interesting tangible environment that houses the gameplay (at least at the ground ‘level’). I worked towards remedying this after it was most necessary in terms of the scheduled design process, but I’m happy to have realized the mistake and produced a viable remedy. However, it still is admittedly more sparse in comparison to previous level design assignments of which involved gameplay that took place “on the ground”. But again, that’s mostly due to the nature of the game involving flying/gliding as its primary form of gameplay.

 

Feedback (screeching SFX) - I added a lot of feedback, and was quite happy how it turned out. Especially the SFX, which I finally utilized anim_notifies in the animation blueprint to implement most of that feedback. However, it was the feedback (and the SFX specifically) that led to one of my biggest issues I had with the first graded submission. The issue specifically was the animation I used to transition between flying and falling as well as gliding and falling (technically both “falling” but separate states in my design). The animation smoothed out the transition (flying to instant nose-dive breaks immersion a bit), but it was accompanied by one of the loudest dragon “screeching” sounds that I had in my bank of SFX. Given that this transition occurs so often during gameplay, the sound soon became extremely annoying and jarring. In my presentation in fact it would often drown out my own narration. I remedied that by designating that transition to be solely for the condition of transitioning from flying to falling after losing stamina. If it’s done so manually the transition does not occur. A stretch goal is to duplicate the transition but without the sound effect, and then reroute the animation (and feedback) states to seek out that transition between their respective state changes.

Fickle Burning Functionality w/ ‘Shrubbery’ Class - The overlap event from the “flame” collision (which I made an interface call from in the dragon’s BP) affected my ‘shrubbery’ class by activating feedback particle fx (fire, smoke, smoldering, etc.) and then executing additional functionality such as sending data to my objectives BP for counting (and eventually changing the value of a designated bool by a certain point), and then of course destroying itself as an instance. Yet for some reason some of the placed instances were more fickle than others. It appeared as if some of the “shrubs” simply didn’t burn. I remedied this by simply making less instances, but a stretch goal would be to determine the cause of this fickleness and devise another solution.

Player Mechanic Bugs - I programmed the controls (which of course directly inform the animation states) in a rather haphazard manner, adding things and making connections as notions came to me. Had I planned it out ahead of time I could have better modularized a lot of the functionality and subsequent conditions (value of certain bools) therein. The result was that spamming the input actions (even reasonably so) often resulted a few bugs arose, such as:

• Sometimes between my ‘gliding’ and ‘falling’ states, the player character could end up in a gliding state as far as the physics was concerned, but in a falling state as far as the animations were concerned. This would appear as a slow drifting dragon gliding downward but positioned in a nose-dive.

• Sometimes between breathing fire on the ground and ceasing to breathe fire, the dragon would suddenly switch to a flying state (both in terms of animation as well as the engine-based ‘flying’ movement mode - of which the two are tied).

• Occasionally being able to move forward while still in the “crash landing” animation. This appears as if the dragon is sliding flat against the ground with no muscular articulations that would indicate slithering forward. It looked ridiculous.

 

I remedied these by refactoring the code where I thought it could help, and I was able to remedy two of the most obnoxious for sure (nose-dive-gliding & fire-to-flight), but admittedly some similar bugs do remain and a stretch goal is to clean up the code to better validate the states (functionality and animations) and prevent against bugs of this nature.

Conclusion: I really enjoyed this project and plan to continue working on it to sharpen my programming and design skills. I want to extend the level to dimensions that align with my overscoped notions I had for this project earlier, as well as add additional gameplay and game modality. Also I want to really polish and refine the existing code - as modular and comprehensive as possible - and really make an effort to push my implementation practices in terms of organization and abstraction.