Bleach:Zanpakutou Senshi is a totally free Total Conversion of Half-Life 1. It´s based on the japanese hit Anime Bleach.

  • View media
  • View media
  • View media
  • View media
  • View media
  • View media
Report RSS Cero Beam (WIP) (view original)
Cero Beam (WIP)
embed
share
view previous next
Share Image
Share on Facebook Post Email a friend
Embed Image
Post comment Comments
Darth_Cameroth
Darth_Cameroth - - 782 comments

I mean hopefully players won't be spamming Ceros, In the Manga and Anime they weren't being thrown around all that rapidly, its the balas you gotta worry about, but they also smaller too.

Reply Good karma Bad karma+2 votes
DarthKiller
DarthKiller - - 551 comments

how about you make them rectangular rather than circle-like to begin with so they sort-of connect to each other

Reply Good karma Bad karma+1 vote
eliasr Author
eliasr - - 515 comments

The issue with rectangular is the same as it was with Getsuga: Moddb.com

Due to the collision system being locked to the world axis, a diagonal attack would have an additional 25 units in collision box size - so 12 or 13 units on each side, depending on what the engine feels like doing.

with 32 units it is 6 or 8 units on each side.

We would still have to fill in the empty gap with a sprite.
Additionally the positive part of using a sprite is that we can shorten it or extend it depending on the distance between the last fired element and the player's GunPosition() - So for those times where the framerate might drop to 59/s instead of 60/s, it will not appear as if there was a gap between the first element and second element, despite the position might not be separated consistently all the time.

I haven't looked into stretching a model, it might be possible as scaling is. But sprites are easier to work with when it comes to manipulating it.

Reply Good karma+1 vote
Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account:

Description

15.75 -> 16 shots per second.
The gaps between the spheres appears to be around the player size and the worst case scenario of 32 players shooting at the same time keeps the amount of entities down at 512 - (1200 is max, 1000 prefered max).

Based on the velocity being normalized to 1000 and the players maximum speed being 1/4 or 250 - then per frame(60 fps) a collision box would travel 16 units and the player would travel 4.
This means that we can have a gap between 32 units (player size) and 44 units (32 + 16 - 4) and a collision is ensured to be within frame 1(16ms) or 2(32ms). The player's acceleration and de acceleration won't be high enough to play an important role - the player will only be able to evade it if that was the initial intention and 1 frame is an acceptable loss, also considering the extremely narrow possibility of fitting between 32 and 44 dead ray for 16 ms.

The goal is to make this look like the 60fps example by replacing the sprite (just like ESF who use the tail sprite for their beams) and have it cover the collision box and the gap till the next element.

Ah... all that engineering and math there is in game development :)

Static1.squarespace.com