game-dev

Revisit Danmaku made by Haxe

Almost one year ago. I decide to implement a Danmaku System which follows Touhou Danmakufu(th_dnh for short)’s API and make many bullet patterns for our Early Access game 《Umbraseal》. Now th_dnh becomes open source software, I want to learn the design decision from original version for improving our work.

Before we diving this topic, I have to declare that I don’t mean to judge th_dnh’s design. Like we discussed in previous article, this software creates the most bullet pattern in the world and has a great creator community. We just want to learn some idea from it’s source code.

Choose an API set to study

After counting API usage from popular script of BulletForge, I found our game only need the following APIs :

Furthermore, only Shot Functions and Move Object Functions use multiple class. So these functions will be our study target.

Shot creation and moving pattern

At first, I thought the CreateShotX1 functions are just wrapping CreateShotX2 by transforming speed/angle to x/y-axis speed. But they actually have different behavior when setting max speed property. So th_dnh uses StgMovePattern class to present different moving strategy, including moving character.

The pattern class is clever, but th_dnh also makes StgMove class scheduling patterns. This structure make ObjMove_AddPatternXX function faster than user script. However, our system don’t use script. So adding pattern by task wont hurt performance, but reducing StgMove class’s responsibility. The ShotMoveSystem should be replaced by pattern class.

Delay and delete in shot’s lifetime

th_dnh uses delay and delete parameters to control the moving timing of shots. Moreover, these two parameters also affect fade-in/out effect, collision activity, auto deleting, laser width, … and so on. By diving into code, I found some ugly code like :

_Move();

_DeleteInAutoClip();
_DeleteInLife();
_DeleteInFadeDelete();
_DeleteInAutoDeleteFrame();

are actually filled with the knowledge about making playable bullet pattern. However these knowledge about timing and visibility are hidden by comprehensive class’s method.

In our ECS system, delete parameter was simply implement by existed Lifetime component. After knowing these knowledge, I decide shot delay and delete should deserve their own system. In addition, separating different concepts to systems can prevent ugly codes.

Pivot of shot and laser

Originally, I thought shot has a center pivot circular hitbox. The straight laser has a mid-bottom pivot rectangular hitbox. And the loose laser is a special straight laser that will changing it’s length from bottom to top. However, this design is very inconvenient for rotating bullet pattern.

Now I think th_dnh is right. The loose laser should have a center pivot hitbox like shot. But it has rectangular hitbox with changing length from top to bottom. That will make bullet pattern design become easier.

Wrap up

We are still building our game and adding more bullet pattern for Boss battle. Have a defined behavior can follow is very helpful. I guess these ideas are useful enough for now. Until we decide to add curve laser or something, we can focus on bullet pattern design and ECS’s own problem. BTW, we are almost finish two new Boss stage. The story mode will coming soon.

 

NOTE – Itch.io page is closed. Free play demo and community will move to Steam.

Official NekoSithSoft WordPress! We are indie game developer. Follow us:
Discord Wix Facebook Twitter Instagram Pinterest Tumblr YouTube

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s