Blogs - rit2040

Hello everyone!

I've submitted a DEV live stream event during Steam Next Fest at 12:30 pm June 17th (GMT +8) playing my game 《Drifting : Weight of Feathers》 demo!

Feel free to tune in and watch me playing my game! :)

《Drifting : Weight of Feathers》

Time To Move On

Steam Page

IndieDB

Itch.IO

Hello, fellow indie developers!

As you might have noticed in my recent weekly updates, in terms of gameplay content 《Drifting : Weight of Feathers》 is nearly finished. The demo released last week is the first milestone before the full game release.

Regarding the remaining 6 months, I like to devote my time to create content for gamers - something less technical and easier to swallow for casual audiences. I am still contemplating on the form and the frequency of my future updates, in the meantime, I also need to get prepared for the upcoming TpGS (2021/01/28) event. Both of these tasks require some time to think through thoroughly and get prepared accordingly, which means I won't be able to provide weekly updates for the coming months.

I will definitely update this thread after the new content is ready to go public - while you are waiting for the next update, please give the demo a try and share your honest opinion with me! =)

Thank you all for reading and sharing your thoughts on my weekly posts for the past 2 years, it's been a wonderful journey to talk with so many fellow indie developers!

Wish we all have an awesome 2021 and a wonderful weekend! ヽ(´∀`｡)ﾉ

《Drifting : Weight of Feathers》

Steam - Steam Page
Itch.IO - Texture Size
IndieDB - Texture Size
UE4 Forum - Texture Size

Texture Size

I found a useful tip on how to reduce texture size (in-engine) this week and would like to share it with the community, here is the source video

A prerequisite for using this method is the texture resolution needs to be a power of 2. Simply import the texture as you usually would, and select the desired resolution in the box (as depicted in the image). Noticed, not only the resolution is reduced but also the resource size of the asset is reduced - it is a fast and easy way to check oversized texture if you constantly get the texture streaming pool over maximum memory warning (like I did).

Before discovering this useful tool, I needed to save out multiple resolutions of the same texture in third party software and import them all into UE4 in case I needed a different resolution for the same mesh with a different scale, now I could do it entirely in-engine without external software!

I hope this small tip can also help make your project development a little bit smoother!

Have a great and relaxing weekend peko~( ﾟ▽ﾟ)/

《Drifting : Weight of Feathers》

Steam - Steam Page
Itch.IO - Jittering
IndieDB - Jittering
UE4 Forum - Jittering

Jittering

Konpeko~

Character jittering is a common issue I've been dealing with since the beginning of my game development journey. If the jittering occurs persistently, it is usually easy to pinpoint the cause of the jitter and resolves it, however, there are times when the jittering occurs randomly and there is no stable way to reproduce it. The only way I can think of to deal with the latter issue is to place logs in every line of suspicious code that may cause the problem and hope the log will show up and give me further insight into the issue the next time it happens.

Besides the aforementioned brute force approach, as I encounter (and solved) lots of jittering issues in the past 2 years, over time, I noticed there are only 2 types of jittering in my game: tick sensitive and logic sensitive. Although knowing this could not help me solve the issue, or reproduce the issue, it often hinted at the right direction for me to continue the search, narrowing my bug targeting list to a manageable scale.

Tick sensitive jittering is a common issue in my project. The game provides an additional dimension for players to traverse (in multiple ways), meaning additional movement states and its transition in and out of other states need to be handled properly - jittering will likely occur if any 2 transition conditions happen to be true at the same time. From my past experience, if the 2 conditions are established due to geometry layout and not faulty game logic ex: jumping off a ledge could be rightfully interpreted as either falling down or wall sliding down, the jittering could be solved by delaying the check of one of the conditions - ie: delay the wall sliding condition check and let the player fall down for a short period then try to wall slide down.

Although I use the word "faulty" in my previous statement, to be more specific, game-logic-induced jitterings are introduced by codes that do not respond very well with edge cases - it could produce the correct result 99% of the time and failed to do so in the 1% extreme case (that 1% usually occurs when you let other people try out your game for the first time).

I wrote a wall running logic where the yaw rotation of the player is determined by the dot product of the camera forward vector and the wall actor's right vector - the algorithm performs as expected until a test-player found out my character is jittering while wall running vertically. I cannot find a stable way to reproduce the issue no matter how hard I tried, then it occurred to me - what if the player's camera is looking directly at the wall with near-perfect alignment? A near-zero number might fluctuate between positive and negative signs which might be the cause of the jittering. I proceed to add a buffer in the logic before determining the yaw rotation of the character - the jittering never happen again since then.

Character jittering like many other bugs is an issue that developers need to deal with continuously, there are no (as far as I know) general programming guidelines for us to prevent that from occurring, however, by solving each jittering issue, hopefully, we gain more knowledge on how logic work in our game and honed our skills for solving these type of issues in the future.

I hope you enjoy this short article, feel free to share your thoughts or story on this matter, have a superb weekend! (ﾟ∀ﾟ〃)

《Drifting : Weight of Feathers》

Steam - Store.steampowered.com
Itch.IO - Rit2040.itch.io
IndieDB - Indiedb.com
UE4 Forum - Forums.unrealengine.com

Localization

I haven't had a proper (relaxing) weekend for almost a month! I've attended 2 events and met the person in charge of a localization studio, lots of online discussion and demo building (for QA purpose) occupied nearly half of my regular schedule. I'm starting to feel more than just a game developer - someone who is in charge of a tiny business - and I never thought it has this much preparation work to do for just one product! XD

Though I've begun developing the game with multi-language support in mind, I didn't expect the length difference of each language could break my UI layout. Here is a sample excerpt from my text table, each expressing the same meaning in a different language:

English - to hook onto walls
Chinese - 勾住牆面
Russian - для зацепа крюком за вертикальные препятствия
Japan - で壁に引っ掛ける
French - pour s'accrocher aux murs
German - um dich an Wänden einzuhaken

Depending on the language used, the length difference could amount to 1.5 ~ 2 times longer than the default (English) length.

Granted, I've saved extra space for each text box in case the length of the text becomes a problem under a multi-language environment - the reserved space is simply not enough for this amount of difference. I discussed this issue with the localization studio and they are kind enough to propose a revision of the translated language. After a brief moment of contemplation, I decided to refactor my tutorial system instead, the reasoning is that I expected the game to support more than 6 languages upon release, it is probably difficult, yet, the correct way to make the UI adapt to the language and not the other way around.

I spent another 2 days refactoring the UI component of the tutorial system, testing out each language by playing through the demo 5 times, build the localized version of my game, and sent out to the studio for more QA testing.

It is truly a busy month for me, yet, there's still a long way ahead before the game is qualified to get a public release. I wish we, as game developers, all have the strength and will power to endure the challenge in front of us and go through that bittersweet path.

Hope you enjoy this week's update, feel free to share your localization experience, it will be interesting to know how other devs deal with the language difference!

Have a relaxing weekend peko! (;´▽`)y-~~

Monthly Test-Play Session 2020-10-31

《Drifting : Weight of Feathers》

Steam - Steam Page
Itch.IO - Monthly Test-Play Session 2020-10-31
IndieDB - Monthly Test-Play Session 2020-10-31
UE4 Forum - Monthly Test-Play Session 2020-10-31

Konpeko!

In this week's update, I'd like to share some of the results I've gathered throughout the play-test session held yesterday (2020/10/30), please take a back seat (and a cup of coffee?) and enjoy my latest findings!

There are 3 major additions in the latest build of the tutorial level - a hollowed platform, a long corridor with a visual directional hint, a new feature that forces the player to perform the required action before progressing to the next section. Each of these new additions has been thoroughly tested yesterday and reveal some interesting observation on human behavior.

I've added a hollowed platform right after teaching players how to wall dash, the idea is to encourage players to utilize their newly learned skill and experience how it could make traversing on walls a lot more enjoyable and convenient. I deliberately made the gap between platforms deep enough and hope that players will intentionally want to avoid it - the resulting outcome is 50 - 50: some people make the effort to dash between platforms in order to proceed faster; some simply took the longer route and go through the bottom of the platform and up again, they seem to acknowledge the fact that they are doing it "wrong" but it did not bother them (maybe the penalty is not large enough? or the distance between gaps is too short for them to respond with the proper move?) so much to the point that they want to actively avoid it.

The directional hint I've added last week is probably the greatest achievement I made so far - people actually (finally!) learn how to throw sideward instead of throwing forward all the time! I've made a long corridor with a sphere spawned in the middle, two statues placed on either side of the wall - I was aiming for a visual setup where players will want to subconsciously throw the sphere without aiming their target. By carefully predicting the player's viewpoint, I place the two statues so that players could barely see their target, this in turns, causing the angle between forward throw and sphere traveling direction become so wide (near orthogonal) that throwing sideward (with a near parallel angle) seems to be the logical way of throwing it. To my surprise, this simple setup achieves a 100% success rate yesterday, all of the playtesters successfully perform one left throw and one right throw without my verbal assistance!

There is one issue that kept bothering me since day 1 of the test-play session - no one ever bothered to read the short (no more than 7 words) hint shown in the middle of the screen. An apparent side effect of this issue is that people tend to use the moves they've already learned before trying new moves, no matter what the hint told them to do. I've attempted to turn the text hint into a gameplay hint by only allowing the player to proceed if they perform the requested move - no other moves could pass the lesson except the one they are asked to perform. To my surprise, for some incomprehensible reason, despite the game paused and explicitly told them to do a specific move, despite they've tried their old move and failed, again and again, they kept trying until I told them to look at the hint and try to do what the hint told them to do. This new feature I've added is an utter failure, it has absolutely no effect on altering players' behavior, I guess it's time for me to look for another alternative to solve this bothersome issue. :(

Just like developing a game, there are always ups and downs in playtesting, sometimes the new feature works; sometimes it doesn't. In retrospect, if I regard the whole process of me building the tutorial level for the first time in a meta sense, I am also "playing" a tutorial level - the goal of that tutorial level is to build a tutorial level that works for people who play my game for the first time - and clearly, I've been continually failing and failing for more than 6 months. Thinking back, I really shouldn't complain too much about people who are generous enough to help playtest my game. XD

That's all for this week!

Thank you for reading my weekly article, wish we all have a great and relaxing weekend! ヽ(ﾟ∀ﾟ)ﾉ

《Drifting : Weight of Feathers》

Steam - Steam Page
Itch.IO - Monthly Play-Test Session 2020-09-25
IndieDB - Monthly Play-Test Session 2020-09-25
UE4 Forum - UE4 Forum

Monthly Play-Test Session 2020-09-25

Hello Everyone!

Since yesterday is the last Friday of September, I attended the monthly play-test session as usual and would like to share the latest feedback I received from other indie-developers.

I've written a post not long ago about how I change the tutorial UI to make it stand out from the screen; make the game pause before every tutorial section; the idea is to ensure players will at least take a quick glance of the moves they need to learn before proceeding further. From the first-hand experience I gathered that night, this idea didn't work out as effectively as I thought due to my own mistake.

Among the 6 play-testers, only 1 or 2 players have a habit of clicking off the tutorial menu immediately after it pops up, granted, I've made a 1.25 second delay before players can click it off, I doubt they took that short period to read the text since they exemplify a tendency to blaze through the tutorial level in their own way without external help. This behavior actually isn't an issue for my tutorial level, watching these 2 players play through the later sections seems to suggest that, players who wanted to play the game in their own way exhibit a certain resilience in their play style - they don't stick to one familiar move set and abuse it; more often then not, I watch them mix and match the moves they found out by themselves and "accidentally" get a right combination to solve the puzzle (albeit, not the intended way) and proceed further.

The real issue here is the ones who really took their time to read the description and trying to do what they were told to do. For these people, the gaming experience was mixed. The overly menacing tutorial UI presentation (full-screen width UI with the game pausing) seems to give them the impression that it is the "only way" to pass the level; if they successfully perform the required move, they get pass each section of the level fairly quickly (even smoothly in some occasions, which is a rare sight for me); on the other hand, if they died once in the tutorial level, since the tutorial trigger will not spawn again (the reason is I don't want the game to pause the second time players trigger it) there are no longer hints on the screen, suddenly, they just don't know what to do and kept running around helplessly - not even trying to mix and match what they've learned previously.

Developing tutorial level is like taking care of a child, it is easy to push my approach to either side of the extreme: gave them the necessary supplies and let them figure out all by themselves or be overly protective and holding their hands 24 hours. In the latter case, I could argue that if I made the tutorial hints spawn every time players trigger it, then it "solve" the issue of players lost their guidance and don't know what to do, however, I couldn't help but think further: what will happen if these players get to play the real level? are they capable of solving the puzzle by themselves? are they capable of utilizing the moves they've learned appropriately?

Frankly, I was a bit disappointed (of my tutorial level) after attending the session, it seems after 6 months of iteration, I was running around in a circle and now I'm back to the start - maybe it is not a bad idea to push the tutorial hints to the side of the screen and let players experiment the moves on their own?

Feel free to share your thoughts on this matter and wish we all have a relaxing weekend. (＞﹏＜)

《Drifting : Weight of Feathers》

Steam - Steam Page
Itch.IO - Non-Axis-Aligned Box
IndieDB - Non-Axis-Aligned Box
UE4 Forum - UE4 Forum

Non-Axis-Aligned Box

I encountered a seemingly simple mathematic problem yesterday, and trying to figure out an appropriate solution for an entire morning:

Calling UPrimitiveComponent::IsOverlappingActor() was my first attempt, however, after some thought experiments I abandon the idea for 2 reasons: first, the point is not represented as an actor (creating a collidable dummy actor will increase calculation overhead and further complicate my colliding channel); second, it will be much better performance-wise to avoid using per tick collision event if I could figure out a way to use mathematic to solve the problem.

Calling UKismetMathLibrary::IsPointInBox() was also a failed attempt since the box is non-axis-aligned, the function assumed the box is perfectly aligned with the world coordination (simply comparing the max/min x,y,z values will return incorrect results if the box is rotated). Another version of the function - UKismetMathLibrary::IsPointInBoxWithTransform() seems to do what I wanted - calling the IsPointInBox() after transforming the point from world coordinate system to component coordinate system - however, for some unknown reason (perhaps incorrect value for the input component transform?), the function still gave me the incorrect result after calling it.

I googled and found various ways to solve the problem on StackOverflow - alas, due to my poor math grade in high school, I cannot comprehend the logic behind all these clean and clever solutions! I was hesitant to add these methods to my project before gaining an understanding of how it works. After some more failed attempts to try and understand the online solutions, one of the solution gave me an idea of how to (partially) solve the problem:

The obvious downside of this method is it only works if the box is rotated in the z-axis, a rotation in x, y axis will give incorrect results - not a general solution to the problem but good enough for the particular problem I encountered in my project. I proceed to implement the method into my code and it works like a charm, then I happily close my project and went out and grab something to eat for lunch. XD

I hope you enjoy this week's update, feel free to provide an even easier solution for people that are not good at math (such as me) to give them a better time to develop their games!

Have a relaxing weekend! d(ﾟ∀ﾟ*)

A glimpse of combat in 《Drifting : Weight of Feathers》

Steam - Steam Page
Itch.IO - Dipping The Water
IndieDB - Dipping The Water
UE4 Forum - UE4 Forum

Dipping The Water

In this week's update content, I like to introduce you to a small feature I've added by accident - the water dipping technique.

While I was testing out the new level, it occurred to me that the collision of my water volume was not properly set - I discovered it by accidentally hook onto the water surface. I kept a mental note in mind to fix the issue afterward, however, as I keep playing around the level, I noticed the dash mechanic actually respect the water surface type, therefore - with precise timing and sufficient altitude - allowing players to dash on water.

Instead of fixing the issue, I added additional condition checks to make sure players are indeed dashing on water, and proceed to add additional effects and audio cue to give players proper feedback while performing this technique.

Turning a bug into a playable feature is a practice I seldomly use in game development; more often then not, this practice encourages developers to compromise their initial vision (and avoid the effort of bug fixing) then create quality, spontaneous game designs. For this particular feature, I think it actually provides an experience that aligns pretty well with the core gameplay of 《Drifting : Weight of Feathers》, hence, I think I could make an exception for once.

Feel free to share your thoughts on this issue and please do not hesitate to post your comment if you have a different perspective then mine on this matter. =)

Have a great weekend! ヾ(･∀･)ﾉ

A glimpse of combat in 《Drifting : Weight of Feathers》

Steam - Store.steampowered.com
Itch.IO - Rit2040.itch.io
IndieDB - Indiedb.com
UE4 Forum - Forums.unrealengine.com

Tutorial UI Overhaul

The last Friday of every month is a special day to me since that is the day I build the latest version of my project and bring it to a small play-test session for feedbacks.

The last session (namely, Fri. 07/31 ) was a particularly fruitful day; the number of participants reaches a new record high, which gave me plenty of opportunities to collect feedback and see how affective was my tutorial level for people who played my game for the first time. Admittedly, the average consensus is the tutorial level is way too hard for newcomers, however, all of the testers managed to complete the tutorial level by themselves, albeit spending 2 ~ 3 times longer than I've expected.

One of the annoying things I've noticed that day is no one ever bothered to read the tutorial instructions before trying out moves - it's as if all the testers subconsciously ignore the instructions. I have to explicitly tell them to read the instructions or after they've stuck at a particular section for a while and they realized there are instructions labeled on the left side of the screen.

Since the exact instance happened multiple times that night, I've concluded that my tutorial UI didn't get the attention it needed due to its overly translucent background, located way too far from the tester's visual center and an extremely small font size.

I've re-design the tutorial UI layout with an "in your face" approach - make the UI fullscreen wide; use color contrast to separate game scene and UI scene; animate the UI when it popup on the screen (along with audio cue) and last but not least, pause the game the first time player triggers a tutorial!

With all these efforts put into redesigning the tutorial UI, I hope testers will be able to finally noticed the instructions and come to appreciate its guidance during the tutorial level.

I hope you enjoy this week's update, feel free to leave a comment, and share your thoughts!

Have a great weekend! (ﾟ∀ﾟ人)