《Drifting : Weight of Feathers》 Releasing Tomorrow (Dec. 15th, 2021 PST)!

Characters in《Drifting》

Brushing Her Hair

(noticed the shoulder-long hair do not clip through her upper body; also she briefly brushes her hair at 00:17)

One of the main features that come with Nvidia Hairworks API is the ability to pre-assign collision meshes for each hairpiece in its exporting pipeline. Since the protagonist has an over the shoulder hairstyle it is crucial to have a proper collision between her hair and her upper torso and limbs.

[ATTACH=JSON]{“alt”:“Brushing Her Hair”,“data-align”:“none”,“data-size”:“custom”,“data-tempid”:“temp_184840_1582961689860_535”,“height”:“576”,“title”:“Brushing Her Hair”,“width”:“1024”}[/ATTACH]

To make sure each hairpiece does not clip through her body while performing extreme acrobatic moves, I’ve spent some time adding the necessary collisions to her upper body. Additionally, I’ve also added several small collision spheres on her fingertips, which makes her hair respond to her hand brushing from her forehead through shoulder while in idle state - a small yet delicate I’ve been planning to add for a long time, now I’m just glad that my yearning is fulfilled.

I hope you enjoy the small clip of her idle animation, wish you have a wonderful weekend! :3

A glimpse of combat in 《Drifting》

Tutorial Ghost

https://media.indiedb.com/cache/images/games/1/70/69632/thumb_620x2000/tutorial_ghost_500x257.gif

Not until I attended the first play-test session last year did I realize, that a steep learning curve to my game might prevent gamer from fully enjoying it. Since then, I spent a considerable amount of time restructure and improve the tutorial section of 《Drifting》 according to a worklist composed, filtered and prioritized from feedbacks I received from each play-test session (see part 1 and part 2 of my previous articles for more detail).

The tuning process is long and cumbersome, in the past 6 months, I’ve added UI component specifically for the tutorial; embed extra tutorial logic into my already-over-complex animation and gameplay system; the level streaming method and respawn system also has to cater to the quirky nature of the tutorial section. Adding these specific, one-time features brought a lot of struggle and self-doubt to myself as a programmer, knowing nearly 90% of the work I’ve done cannot be re-used in some way past the first 15 or 20 minutes of the game.

[ATTACH=JSON]{“alt”:“Tutorial Ghost”,“data-align”:“none”,“data-size”:“full”,“data-tempid”:“temp_185348_1583562037949_567”,“title”:“Tutorial Ghost”}[/ATTACH]

Making a tutorial ghost is a suggestion I received from a play-testers a few months ago. I’ve added the suggestion into my working list, nevertheless, I was tired of doing those one-time tasks and decided I could achieve a similar result by using video clips instead. I cut myself some slack and done just that. A week later, I noticed the size of my packaged game gains an extra 400mb because of the amount of tutorial videos referenced in the map. Not only is the sheer size of video clips is an issue, but as I adjust existing animations, lightings and tutorial sections, all the previously made videos need to be re-recorded - the last straw that made me resort to the tutorial ghost method.

In the past week, I’ve spent some time to make a new actor class and animation blueprint to mimic the behavior of the player character. The idea is to enable the ghost to perform all the moves the players are able to do within a pre-determined path. Although the tutorial ghost system is still under development, I am pleased to see this newly added makes the tutorial section much more lively and interactive.

I hope you enjoy this week’s update, feel free to share your thought and post a comment on this matter, have a wonderful weekend! (・∀・)/

looks so beautiful! You have done such a great work. There was some talk of there not being a story yet. Is this still the case? My mid is full of questions like «who is this woman?» «why does she do what she does?» «what has happened?» «will something happen?» etc etc… you surely get the idea. Regardless of the visuals being stunning, I feel I’d need a reason, a motivation, a goal of somekind, to keep playing more and return again and again.

Hi @anonymous_user_64646855,

Thank you for your interest and good words. =)

Currently, the game only has a “theme” but does not have a story yet. Although I’ve done some basic profile for the protagonist, it may take quite some time to develop a full story for the game, since most of my time is occupied by level building and debugging and producing weekly update content - there really isn’t much time left after all these tasks.

Besides developing the backstory for the characters in the game, one of the difficult challenges I’ve been struggling with is how to tell a coherent story in a way that wouldn’t interfere with the pacing and momentum of the gameplay. I’ve done some thought experiments on this issue and came up with some possible approaches, besides audio log or audio narration, I’m considering the possibility to tell a story by level design - it is a much more advanced approach and I’m still testing and researching on the feasibility of this method.

Hopefully, by the time I came up with a good storytelling method, I’ll have a great story to tell!

Thank you again for your interest and an extra thank you for posting a reply, even a short comment lends a lone developer a helping hand to urge him to go forward and stay strong.

I wish you have a productive weekday! :3

Must be tough doing everything on your own. I know some writers, none native English though, but writers none the less. If you’d like some help there, I could ask around if someone has time and interest in a sci-fi/fantasy story :slight_smile: if nothing else, maybe they could help you with asking the right questions. Make noise if that is of interest!

Hey @anonymous_user_64646855~

Thank you for providing the info and advice!

I’ll see what I can do about the story - if things didn’t work out for me, I’ll make sure to contact you and call for help! XD

Have a great day!

Scenery in《Drifting》

HISM Distance Culling

(As the camera moves away from HISM actors, spherical opacity mask kicks in and draw call rises, however, HISM actors that are further away from the camera will be disabled by distance culling and decrease the draw call. The combination of distance fade shader and distance culling allows the game to have a large number of opacity actors in a scene while maintaining a reasonable draw call)

In a previous post, I talked about how the distance fade shader causes the draw call for my scene increases dramatically and I need to find a way to disable actors - or more specifically HISM actors - when it’s far away from the player camera. (see this video: to learn more about HISM in UE4)

[ATTACH=JSON]{“alt”:“HISM Cull Distance”,“data-align”:“none”,“data-size”:“custom”,“data-tempid”:“temp_185980_1584154877889_284”,“height”:“598”,“title”:“HISM Cull Distance”,“width”:“1024”}[/ATTACH]
(Although both StartCullDistance and EndCullDistance are exposed to the default property of HISM component, setting the value directly in its default tab window will cause the HISM to disappear in editor viewport - disregard of the viewport camera position in the world. That is why I move the distance cull logic to event begin play instead)

I’ve tried cull distance volume, however, after some research and testing I found out it’s not applicable to moveable actors (including HISM). I dived into the UE4 source code and discovered there are already variables for HISM distance culling - StartCullDistance and EndCullDistance. The variables did what its name suggested and after some modification for my HISM actor class, I am able to reduce an average of 2 ms to the draw call for my scene which is a pretty huge performance improvement.

As I keep developing the project, optimization issue will always be on the top of my worklist. It is a process that requires the developer’s constant attention and awareness of the potential performance cost of new features that are about to add to the game.

I hope you enjoy this week’s update, have a relaxing weekend. (●′∀‵)ノ♡

A glimpse of combat in 《Drifting》

Throw Physic

(most of the enemies possess armor/shield to block incoming attacks, once the armor/shield break down, players are able to grab and throw them around)

Grab, throw and shoot are the three moves players need to learn early on in order to advance through each level of 《Drifting》. Among the three, throwing is the hardest move to master due to its physical nature - unlike shooting and grabbing which only requires players’ aiming accuracy - the throw mechanics take physical collision and velocity into account. The difference between the two is essentially line trace and projectile simulation in UE4’s term.

[ATTACH=JSON]{“alt”:“Assassin Bone Hierarchy”,“data-align”:“none”,“data-size”:“full”,“data-tempid”:“temp_186468_1584769283324_300”,“title”:“Assassin Bone Hierarchy”}[/ATTACH]
(noticed the root bone is located near the hip of the character. If the root bone is set to (0,0,0) instead, the travel path of the mesh component during projectile simulation will appear to be lower than the desired travel path which makes the throwing appear to be “less accurate” - a lesson I learned the hard way)

Projectile simulation for a skeletal mesh instead of a static mesh (ex: bullet or arrow) poses several interesting challenges. One of the obvious challenges is AI behavior, after the projectile travel to its destination, unlike bullet or arrow which could be destroyed or despawn for later use, the skeletal mesh need to stop the physic simulation and resume back to its behavior tree and act accordingly - this transition phase is particularly important in order to maintain a realistic gameplay experience for players; another unexpected challenge is the skeletal mesh bone structure, I use SetWorldLocation to move the mesh component during projectile simulation and found out the component location is bind to the root bone of the mesh, which means the root bone cannot be placed at (0,0,0) but need to place near the hip bone of the character for visual consistency.

I hope you enjoy this week’s update, have a happy and healthy weekend! :3

IndieDB
Itch.IO

Scenery in《Drifting》

Nearing the End of the Arsenal Level

A few months ago, I made a post to introduce the design and backstory of the “arsenal” level of my game. The process of building the arsenal level has a bit of twist and turns - as I kept working on the level, newly added tasks with higher priority (ex: bug fixes, performance optimization) kept appearing and stacking on top of each other slowing down the level building process considerably. After several weeks of work, I’m gradually approaching the end of building the arsenal level.

(the hight of this building is around 13,700 unreal units, making it one of the tallest buildings in the world of 《Drifting》 so far)

One major gameplay element of the arsenal level is to challenge players to perform several precise throws consecutively. In order to raise the stake of a failed throw higher, almost 80% of the arsenal areas are sunk below the ocean plane, meaning a failed throw (thrown object fall under ocean plane) results in players starting over again; a miss-step from players (due to overreaching the hook distance and fall under the ocean) also results in instant death. As players progress through the level, the challenge becomes harder and harder, yet, after players completing the level, I hope they would found out the throw mechanics in the game has far more potential than meets the eye.

Thank you for reading this short post, feel free to comment and share your thought on this subject. Be vigilant and stay healthy! =)

IndieDB
Itch.IO

Scenery in《Drifting》

Itch.IO -Moving Tripwire
IndieDB -Moving Tripwire

Moving Tripwire

(depending on the actor’s property setting, tripwire can be moved either by players actively triggering it or automatically moving by itself)

Besides narrative purpose, part of the reasons I’ve decided to make the game world covered with a large ocean plane is to rationalize the usage of grappling hook and wall running. Although the game is designed around these two mechanics from the very beginning, I wanted players to feel these mechanics are there not just for convenience but essential tools for their traversing ability - an instant death ocean plane greatly facilitate that purpose.

Unfortunately, the same trick cannot apply to levels that are too high for the ocean plane to pose an immediate threat to players. To solve this problem, I’ve created a moving tripwire actor to fulfill the same role as the ocean plane at high altitude levels. Compare to the instant death ocean plane, the moving tripwire is not as lethal - only deals damage if players or NPCs touched its wire, however, the moving direction of the tripwire could be either horizontal or vertical or something in between, which created a more challenging task for players to get around with it.

I wish you enjoy this week’s update, have a great weekend and stay healthy! =)

The Making of Maze

Itch.IO -The Making of Maze
IndieDB -The Making of Maze

Hello everyone!

In this week’s update, I wrote an article about how I made a maze-like level, I hope you enjoy reading it!

Feel free to share your thought on this subject and have a wonderful weekend! 。٩(ˊᗜˋ)و ✧*。

Scenery in《Drifting》

Water Dungeon

Itch.IO - Water Dungeon
IndieDB - Water Dungeon

An article I posted last week talked about the process of building a maze-like level, the challenges I encountered and the solutions I came up with. As the construction of the maze level approaching its end, I figured the last section - the water prison section - might be a good place to test all the tips and tricks players acquired in the previous level and put them to good use.

The design theme of the water prison level is as its name suggested: an instant death water plane lies just above the ocean surface, posing a constant death threat throughout the entire level. To balance the difficulty of the water prison section, I made the puzzles a lot straightforward to solve, however, players need to carefully plan out his/her every move and execute it with extra precision compare to other levels - a miss-step or an impetuous move will likely cost his/her life and starting over.

Hi @rit ,

You are an inspiration. I stop by your post from time to time to see your latest update. You get my hyped up. I’ve been itching to develop a Ninja Game with sword & gunplay and acrobatics for months. I made a decision tonight, to move forward with converting my current work The Rianth into a Ninja Game, code name: SPAGHETTI.

Keep up the awesome work!

Hello @TechLord,

I’m glad you are interested in the weekly updates and share your thoughts on game development. =)

Experimenting and testing gameplay mechanics is part of the development cycle, it’s always better to conduct drastic changes early on than later.

I remember back in 2017 I was working on a fixed-camera, point-and-click, puzzle-solving game. After several months of iterations and prototyping, the game gradually changes from a pure puzzle-solving game to an action-oriented game - a change in development route I couldn’t have imagined back then.

Thank you again for your input. I wish you a lovely weekend and all the best for your project! :3

A glimpse of combat in 《Drifting》

Throw Behind Fence

Itch.IO - Throw Behind Fence
IndieDB - Throw Behind Fence

(click the image for higher resolution)

As players progress through each level by throwing objects around to unlock the next challenge, at one point, they will face a peculiar challenge - throw an object to where they can see through but cannot aim directly - throw object behind a barbed fence.

It is intuitive to throw an object forward to where the player could aim at, however, the game provides another way of throwing: sidewards and backward throws. These two types of throws although appear similar has different underlying mechanics. Compare to forward throw, sidewards and backward throws are target-oriented throws. As the player throw sidewards or backward, the game will perform a large area box trace and filter out the “appropriate” target to throw the object onto - a complex process involves distance check, angel check, target’s tag (type) check, collision check…etc, to ensure the object is thrown to the intended target.

Throw behind fence fully utilize the idea of target-oriented throw, since players cannot aim directly through fences, throwing sidewards or backward seem to be the more appropriate choice here. As I explore this idea, it opens up a wide range of gameplay possibilities - one of them is a puzzle where players need to throw an object onto an elevator; turn on the elevator so it reaches the second floor; from the first floor, throw the object from the elevator to another elevator at the far side; bring that far side elevator down to get to the object - an example that reflects the intricate dynamics between players and the game mechanics.

I hope you enjoy this week’s update, have a wonderful weekend! (づ′▽`)づ

Scenery in《Drifting》

Itch.IO - Spline Component Distance LOD
IndieDB - Spline Component Distance LOD

Spline Component Distance LOD

(the LOD distance in the image is reduced to 5000uu to better visualize the LOD effect)

If an empty scene causing an RTX 2080 SUPER to run on 45 fps, then you know something isn’t right about the game - that unfortunately, is what I’ve encountered during the development of the project.

As I kept searching for clues that might cause the GPU’s bottleneck, I stumbled across a helpful post explaining the proper way to setup spline actor distance LOD. It turns out the way I’ve setup spline distance LOD has no effect at all - since I was using dynamically constructed spline components, each component need to set up its own max draw distance individually - simply set the max draw distance of the spline actor itself will not affect each spline components (neither will set visibility).

I adjust all the spline actor blueprints accordingly and packaged the game, run the game with 1920x1080, borderless mode, v-sync off - what I saw is an fps boost from 45 fps to 145 fps - a huge performance gain signify how leveraging distance LOD collectively could have a big impact on the final performance result.

I hope you enjoy this week’s update and won’t make the same mistake I made!

Have a nice weekend and stay healthy! (/>///<)/

Hi @rit

One of the most coolest visuals is the Hair. How did you do that Hair?

Hi @TechLord,

I’m glad you like the hair rendering. =)

The UE4 version I’m using is the one integrated by Nvidia (a GitHub account is required to view the page, or it might show 404 if you haven’t logged in already). I followed the tutorials posted on Nvidia’s official website to learn how the export pipeline works from third-party software (Maya or 3dsMax) to UE4.

The tutorials are quite comprehensive and straight forward, watching one of them and you should know all the necessary steps to bring your grooming results to UE4.

After exporting to UE4 and assign Hairworks asset to Hairworks component, the rest of the works involves a lot of tweaking and adjusting back and forth between third-party software and UE4 to achieve the looks and style you are aiming for - which is not very difficult but time-consuming and tedious - since, for every adjustment, you can’t visualize the final result right away in UE4.

That being said, while I have no experience with the latest version of UE,** instead of using the Nvidia’s GitHub branch, I will recommend trying out the hair grooming systems introduced since UE4.24, which is a fully integrated solution that allow developers to perform the grooming process in-engine and visualize the final results accordingly.**

Although from what I see in the tutorial video so far, the current UE4’s hair grooming system lacks a lot of artistic controls compare to the Nvidia’s branch, I believe the new hair grooming system is the officially supported one and Epic will probably improve the system in the future in terms of ease of use, hair simulation, and artistic controls.

I hope this information could help you decide which route to take and get started with hair grooming.

Have a wonderful weekend! :3

P.S. If you decided to use Nvidia’s branch, here is a short article I wrote about the tips and tricks I’ve learned using Nvidia’s Hairworks tools.

Hi @rit

I truly appreciate the thorough response. Sounds like ill have to dig into C++. My plate is full at the moment. I look deeper into integration when i get to the ‘polish’ stage. Going to put hair on everything including robots:)

A glimpse of combat in 《Drifting》

Itch.IO - The Magic of 0.215
IndieDB - The Magic of 0.215

The Magic of 0.215

Actions games are typically renown for challenging players’ reaction time, whether the challenge comes in the form of last-second dodge, counter parry or perfect reload, a well-designed time interval is crucial to make players addicted to the mechanic instead of feeling frustrated because of it.

As I was developing the attack behavior of my assassin character, I became aware of its sniper attack seems extremely hard to dodge. The sniper laser turned red 0.5s before she fires the shot - a signal that came too early and for multiple trials, I ended up dodging it too soon and got shot mid-air; I lowered the interval to 0.1s, expecting a closer timed signal and shot will result in a more accurate input from players, however, the situation isn’t anywhere better - since the shot came almost immediately after the signal, I couldn’t react to it and got shot before I could input anything.

(for people who are curious about my reaction time, the test result for me is 0.257s 5 out of 5 trials - slightly below average)

The problem persists for some time until I found out a site where you could test your own reaction time. Besides measuring my own reaction (to confirm whether the aforementioned problem is solely due to my incompetence to play my own game), more importantly, the site collects all the user data and provide statistics for the average users’ reaction time. According to the statistics, the average users’ reaction time is 0.215 seconds. Out of pure curiosity, I replace the value into my code and to my surprise, the assassin’s shot becomes much easier to dodge - my perfect dodge rate increases from 30%~40% to near 70%~80% without actively concentrated on the signal.

Besides solving the problem, I learned an important lesson that day - for NPC’s attack time interval, player’s input tolerance - if I couldn’t find a suitable number, try the magic number 0.215! XD

I hope you enjoy this week’s update, have a great weekend! :3