Pixel artist & lowpoly modeler @DinPixelsVGen & Ko-Fi commissions are CLOSED.Works' status are listed on this kanban.Find me on: Cara | Instagram | NewgroundsPixel Joint | Lospec | LinktreeTips: Ko-Fi | PayPal.Me
Was listening to Nagato's theme and it gave me an inspiration to draw this piece in PC-98-ish style. I limited the palette to 16 colors and picked desaturated, dull colors.
In this update the ghosting during dash is more stable, there are basic tiles to visualize the environment, and animations are added to the character.
Dash/Ghost FX
Originally I intended on using CPUParticles to emulate the same dash/ghost effect as I previously did it before, but since I want the easy way I ditched the idea and decided to move the entire spawn function to the Dash state itself.
From this (within the Player, Tsuyomi)
To this (migrated to Dash State under the State Machine)
Since the function was moved and relies on physics process there's no need to use the Timer anymore and so it was removed.
In this approach every instance of the dynamic sprite were consistent in frames (60 FPS).
In terms of the ghost's modulate the smooth transition from magenta to indigo color was possible thanks to Tween--in an instance, once the tween of its properties are done, it frees itself from the memory.
With the aforementioned the number of instances in these frames barely affects the performance (so far).
Animation
I converted the Sprite to AnimatedSprite and added Idle and Dash animation to its SpriteFrames resource.
The dash may seem static at the moment as currently it only has 1 frame in it (I haven't exported the updated sheet with 3 frames for dash), still, I kept the same function for loading images and setting them as dynamic textures.
(will continue to write this later the heat is killing me)
Added a simple dash effect with the use of Tween, Timer, and a separate Sprite. The texture is dynamic as it loads from its parent's image data.
I have a better approach to this i.e. CPUParticles2D (since it's rendered in GLES2) which is more consistent and have more control in instancing the ghost sprite per frames.
Since this relies on a timer it's kinda hard to adjust at certain frames, especially when relying on very tiny durations.
So the way with the CPUParticles2D would work is just as the same as this one in terms of texture, that is:
Get the image data (Image) from Texture of the parent Node.
In ghost Sprite, create an ImageTexture and load the image data.
Set ImageTexture as Texture to the ghost Sprite.
Also this solution has issues in terms of Timer, going < 0.05s will cause inconsistencies depending on the refresh rate, unlike particles that's consistent in FPS.
Okay so if these are the cases, why then use this approach on the video then?
The reason is that CPUParticles can't be flipped in terms of scale directly--the image data within its texture is the one that must be flipped, and only via bool values.
This is feasible but it's very hassle (as I already did it). I want direct control over the scale as it inherits from a Node2D class--when I flip itself, i.e. a CPUParticles2D, i.e. inherits from a Node2D class, I want it to fricking flip directly just as a Sprite will do. I DON'T HAVE TO FLIP THE IMAGE DATA ITSELF.
That's all. Thank you for listening to my silly thoughts :>
A small study how State Machine works. I was playing a cool game with very juicy gameplay feel and so I was curious on how it works.
Given that it is a study and more like a hobby, I won't make any promises with this project.
So far I learned that:
Virtual functions and class boilerplates are convenient for being used with almost same applications. They're versatile and flexible.
States are isolated and so the changes are in immediate effect on objects. The inputs feel great and responsive.
State machines keep the code and states clean and organized.
There are many ways on solving a problem, and there is no absolute answer to everything. I can choose what is 'perfect' for me and use it to my liking and advantage.