Where do your bullets live?

[mystran]

This might be a weird question, but it's something I've thought about recently. Basically, in a shmup one can place bullets in either screen space (or "play space" if player can side-scroll a vert-shmup a bit, etc), or in world-space (ie relative to the map). There are some curious implications to each one, especially when scrolling a map is not completely linear (but for example follows a fancier path, or changes speed, or whatever).

Now empirically (from playing games, looking at what's going on; I do admit some bias towards bullet-hell types though), I'd guess that the "screen space" approach is far more common, but surely there are examples of map-space bullets too? Or maybe something even more weird?

So which one do you use (or something else?) and was it a gameplay decision or driven by some other reasoning (such as easier implementation, engine default, whatever)?

edit: actually upon second thought, I guess world-space bullets would generally make sense in a game with walls and such that actually block them, so maybe they are more common in those?

[Cagar]

I didn't know that there were other options than screen-space. I guess that map hazards count as world-space?

[mystran]

I didn't know that there were other options than screen-space. I guess that map hazards count as world-space?

Well, map hazards that scroll with a map (say closing doors, etc) would be world-space, yes. But that's sort of a different thing, I'm wondering how common it is to actually make bullets (specifically "enemy bullets" in case it's not obvious) scroll as well, and what the reasoning for that was.

[ciox]

I have a typical 3d shmup where the camera flies through the scenery, however I don't drag all the enemies and bullets along with the camera through the world since that would be just annoying, not to mention that the player ship and enemies would clip through the world unless you're very careful (you can see this clipping in Ikaruga and R-Type Final).

Instead I just have an area far away from the scenery where there's the main camera recording my "play space" with a giant screen behind it showing what the scenery camera is seeing as it flies through the world, no more 3d clipping or need for updating the position of hundreds of bullets every single frame.

[eebrozgi]

In Final Boss, I use the Game Maker's room editor pretty traditionally to make the enemy formations with spawner objects and to easily form levels with solid walls. The camera thus slowly scrolls up the room and shifts the bullets, enemies and such things up with itself, creating an illusion of an independent screen space.

I think screen space -bullets usually work better, especially when player-aimed bullets are involved. Though in the walled stages, some enemies'/bullets' speeds are adjusted to appear to be moving with the map space when it fits.

Does this count as a mix 'n' match, then?

edit: I somehow had an impression you're asking technical-wise but I was misguided. So yeah, the bullets are about 95% in the screen space here.

[mystran]

I think screen space -bullets usually work better, especially when player-aimed bullets are involved. Though in the walled stages, some enemies'/bullets' speeds are adjusted to appear to be moving with the map space when it fits.

Does this count as a mix 'n' match, then?

Yeah, that's actually very interesting. I think it counts as mix'n'match.

So you basically take the current scrolling velocity and add it to the bullet's movement?

edit: I somehow had an impression you're asking technical-wise but I was misguided. So yeah, the bullets are about 95% in the screen space here.

Well, I'm mostly interested in the game design aspects, but really this was very helpful post in general.

[eebrozgi]

So you basically take the current scrolling velocity and add it to the bullet's movement?

Yup.

Also, glad if I helped.

[n0rtygames]

Code: Select all

/* how2camera */

Vector2 mvCamPos; // This is your camera position in world space

////////////////////////////////////
// Some random entity
////////////////////////////////////
Vector2 mvWorldPos;    // <- you ALWAYS work with this. This changes.
Vector2 mvScreenPos;  // <- you CHECK this, it does not change through you.

void Update(float afTimeStep)
{
   //////////////////////////////////////
   // Convert world to screen
   mvScreenPos = mvWorldPos - Your.Games.Camera.mvCamPos;
}

There's literally no difference here whether you target your bullets using screen space or world space. If you want to get an angle then TargetVector-SourceVector returns the same so long as you are doing the math using EITHER world positions for both target/source OR screen pos for target/source. You never use both because that's stupid.

If you were to write an optimized collision system, you would then be able to work in screen space and easier pick out which objects on screen should be checked against since you always have 0,0 topleft (or wherever depending on what you're working in)

So you basically take the current scrolling velocity and add it to the bullet's movement?

You have to, otherwise bullets appear to travel downward incredibly fast. Shmups are full of illusions like this. All bullets actually move at incorrect speeds (as in, the scroll speed of the camera is subtracted from the bullets velocity each frame) as this leads to good gameplay



Note: Under some very very special and interesting cases you might do stuff with screenpos. But very rarely. Usually you might get screen pos, adjust and then set worldpos if you need to be screwing with bullets in this fashion. But manipulating world positions is best.

[n0rtygames]

There are other ways you can do cameras using Matrix math and such - Skyravens (old build) does this and allows for zooming in and out but honestly why the fuck I ever wanted to do that in a shmup is beyond me. :p

Looks cool, utterly impractical for gameplay though. Adds a bit more juice to effects here and there I suppose?

[BrooksBishop]

Yeah, it definitely has to be screen space.

I built my engine for Aeternum originally under the assumption that the camera would actually be set in place the entire time and the illusion of movement would be accomplished with repeated scrolling backgrounds.
Because of that, all my bullets were in "world space" which was in this case, the same as "screen" space.

When I finished that and moved on to a different project that involved scrolling pre-drawn maps, I could not at first figure out why any of my aimed bullet patterns simply never hit the player target, even just standing still.

In my case, the problem was that the player is always moving in world space, so bullets actually curve in screen space relative to the motion. I found this just feels incredibly bad, because I expected intuitively that if a bullet is fired at me, and I stand still, the bullet will hit me.

My solution was to move the player, enemies and camera in world space, then convert fired bullet positions to screen space and do all calculations there, including referencing the player's position in converted screen space as well. My situation was a little more complex because I was doing a vertical game with a horizontal pan (like Raiden) so I had to take horizontal camera position into account as well. But the idea is the same whether you do that or not.

[nasty_wolverine]

bullet coordinates are in world space, movement is in screenspace, collision system works in screen space (anything offscreen doesnt need collision).
watch a run of DFK, you will notice that with all the freaky scrolling in all directions, bullets only move in screen space. but to keep the collision system and physics simple, i would recommend to always keep one single coordinate system, and the best is world coordinates. and for the collision system use a grid, hash things into the cells of the grid, only collide stuff in the same cell (beware of things in two or more cells).

just let bullets have a world coordinate, when doing movement, convert that to screenspace, move to new position then convert that back to world space. if you have your vectors set up right, thats just:

Code: Select all

vector2 temp = world.camera - bullet.position;
temp.move(direction, speed, other);
bullet.position = world.camera + temp;

[mice]

But for verts with (manual) horizontal movement of the camera you just make screenspace adjustments on the vertical movement of the bullets.

See how hard to understand that sentence is?
That's why in Twin Tiger Shark, the bullets will most of the times miss you and no player will notice this because they're too busy trying to avoid the bullet that's about to miss the player...

[Lord Satori]

My bullets live with me. They're my friends, and I would never abandon them. My bullets have nowhere else to go so I keep them safe.

[mystran]

and for the collision system use a grid, hash things into the cells of the grid, only collide stuff in the same cell (beware of things in two or more cells).

In my experience this is much slower than just doing it brute force (for bullets, that is). The problem is, using a fast-path bounding circle/sphere check (assuming you even need anything else) is so freaking fast that if your objects move every frame, you spend FAR more time managing the grid that you actually save on collision testing. Bounding circle/sphere test is just a vector difference, inner product for squared magnitude, and comparison which can be done on squared magnitude directly (and on modern CPUs, it'll predict perfectly as 99.9% of crap never hits anything, so scales fine to at least 100s of thousands check per frame); this is literally less than 10 cycles (less if you get it pipelined) if done when the bullets are already in cache, say right after moving them; so any optimization has to have REALLY low amortized cost to be worth-while.

If you have a lot of map-geometry that you need to test against, then build an acceleration structure (grid, kd-tree, bsh, whatever) for those to quickly cull lots of that. Here the structure itself is hopefully going to be mostly static, so hopefully no per-frame update cost... but for a situation where you just test bullets against a few objects (say player + options + screen edges), it's really hard to beat the "naive" (well, with rough fast-path checks, obviously) approach if you need to touch them every frame anyway.

[n0rtygames]

In my experience this is much slower than just doing it brute force (for bullets, that is).

(and on modern CPUs)

http://www.youtube.com/watch?v=-X2FEf1nAZ0
https://www.youtube.com/watch?v=Tnk2lBwrXMo (The slight jitters you see here are not related to logic, but instead rendering - something which has since been eliminated in my current codebase)

If you have a lot of map-geometry that you need to test against

https://www.youtube.com/watch?v=tsu4Z7d5bGo

Both on xbox360 (which is a 10 year old steaming pile of crap) - none of this has been possible without grids. Every object you see with the exception of the player is stored in a grid - which is refreshed every frame. I once did as you did, brute forced everything and then when I ran it on a console... well, let's not talk about what happened there

This is considerably faster than doing hundreds upon hundreds of distance checks (even with squared magnitude) and allows me to use a blend of rect/rect and circular checks without any major concern.

[BrooksBishop]

I once did as you did, brute forced everything and then when I ran it on a console... well, let's not talk about what happened there

Interesting. I just brute forced on Aeternum and even on the xbox it was never a problem. After I fixed all the errant boxing, all my problems involved being GPU bound.

In fact the released version is still brute force, and isn't just simple circle-circle checks, it's all circle-extruded circle (aka pill) checks to prevent tunneling.
Makes me wonder what sorts of differences we had in approach that could cause that.

[nasty_wolverine]

But for verts with (manual) horizontal movement of the camera you just make screenspace adjustments on the vertical movement of the bullets.
See how hard to understand that sentence is?

Actually, very interesting topic to bring up.

what i did was, the main camera doesnot slide, i have a seperate matrix for the sliding. so the playfield is 4 by 4 grids, the view field is 3 by 4 offset by the sliding matrix clamped at 0 to 1 grid size. bullets always move in the 4 by 4 grid playfield, the player ship controls the sliding matrix. so that way, i have the manual side to side slide, with out messing with bullet velocites, all they have to do is move in respect to the playfeild.

In fact the released version is still brute force, and isn't just simple circle-circle checks, it's all circle-extruded circle (aka pill) checks to prevent tunneling.
Makes me wonder what sorts of differences we had in approach that could cause that.

you should let bullets tunnel, inaccurate but forgiving collision is better than accurate and unforgiving. http://shmups.system11.org/viewtopic.ph ... 93#p673393 << thats how cave does it, basically bullets have collision turned off for half the frames. watch some crazy katsuey dodging for why its fun.

[n0rtygames]

Makes me wonder what sorts of differences we had in approach that could cause that.

Out of curiosity : How many bullets have you actually run collision checks on at a single time?

[BrooksBishop]

Up to 2000. That really clogs the screen though and I thought it was too much for the style of game I wanted, so the most bullet intensive pattern on the hardest difficulty + player bullets only hits about 1600.

[mystran]

what i did was, the main camera doesnot slide, i have a seperate matrix for the sliding. so the playfield is 4 by 4 grids, the view field is 3 by 4 offset by the sliding matrix clamped at 0 to 1 grid size. bullets always move in the 4 by 4 grid playfield, the player ship controls the sliding matrix. so that way, i have the manual side to side slide, with out messing with bullet velocites, all they have to do is move in respect to the playfeild.

Yeah, I do something like this too and it's what I was referring to as "playspace" in the original post... but I thought it wasn't worth while to add another poll-option, since .. essentially it behaves more or less like screen-spaced stuff. In my code typically, the only thing (other than drawing) that actually cares for the actual visible region in my code is the "is this enemy on screen" check that is done when considering whether the enemy is allowed to shoot (since I found it makes stage design easier).

[n0rtygames]

Up to 2000. That really clogs the screen though and I thought it was too much for the style of game I wanted, so the most bullet intensive pattern on the hardest difficulty + player bullets only hits about 1600.

1600 bullets on screen is still far too many

I'll settle for being stupid then. I think the most I hit (with actual gameplay going) is around 1200 or so before thing start to get a little hairy. It's not really a huge concern though since I'm aiming to keep the bullet count below 200 - however I cannot use that as an excuse for being dumb. Half tempted to hook up the xbox for dev again to see exactly how far I can push it. Unlikely though.

[BPzeBanshee]

I try to keep my current object count below 300 at all times: during my initial stress testing on my legacy PC it was around this point that GMOSSE failed to run 60FPS on my legacy machine, and I think that's plenty for a manic. Bullet hells I can understand going a bit over but I see no need for more than 500 bullets on the screen anyway.

As to where my bullets live, it's pretty much all screen space except for enemies, walls etc. Any room that's larger than the view I drag the bullets with me as well within the 320x320 zone that the player can travel through, but NOT when the screen adjusts to players position within this size (ie bullets do not wobble with the wobble scrolling, no Raiden IV/Tyrian bullshit here).

[DrInfy]

World space!

While it creates a lot of problems, like forcing the background to move rather slow and bullets sometimes coming down too fast, it also allows to do some interesting things. Like enemies firing upwards on screen and the bullets still coming down on the player like in Saviors Stage 6:
https://www.youtube.com/watch?feature=p ... ng44#t=790

Also the bullets hit other enemies and world space obstacles in Saviors. It would also look really strange if the bullets weren't in world space when the camera rotates.

[n0rtygames]

World space!

While it creates a lot of problems, like forcing the background to move rather slow and bullets sometimes coming down too fast, it also allows to do some interesting things. Like enemies firing upwards on screen and the bullets still coming down on the player like in Saviors Stage 6:
https://www.youtube.com/watch?feature=p ... ng44#t=790

Also the bullets hit other enemies and world space obstacles in Saviors. It would also look really strange if the bullets weren't in world space when the camera rotates.

World space is good. The way to deal with the issues you've described:

Slow moving background?
1. Track your camera position with a 2d vector or something
2. Increment it at a specified speed
3. Render everything on screen based on WorldPos - CamPos

This will mean the speed of your camera dictates everything, including background scrolling speed... you shouldn't have to do anything fancy with that other than offset the positions of parallax layers differently depending on current campos.

As for bullets coming down the screen 'quicker' - you just need to look at what is happening.

If your camera is scrolling up (say (0,-1)) and you spawn a bullet with zero velocity in the middle of the screen it should appear to move down at the same speed as the camera. One way to counteract this, if you want the feeling of bullets moving on their own but still have a sense of being in world space - is to do :

BulletPos.y -= CamSpeedThisFrame;

Then your bullet will remain in the center of the screen independent from your vertical scrolling

[nasty_wolverine]

...

...

TL;DR
- Bullets live in world space (better for collision)
- Bullets move in screenspace minus camera left/right wiggle (so background speedups/movements dont effect bullet trajectory)

[S20-TBL]

I use world space for bullets since most of my levels are designed like a 2D platformer's, instead of using tile scrolling.

The screen space movement dictated by the camera actually uses global Cartesian displacement values which effect enemy speeds and placement, but not bullet speeds (since the screen wobbles at times, I consciously avoided making the bullets wobble with it). Quite similar to what n0rtygames described. Ergo the bullets have vectors separate from the camera movement.

[n0rtygames]

TL;DR
- Bullets live in world space (better for collision)
- Bullets move in screenspace minus camera left/right wiggle (so background speedups/movements dont effect bullet trajectory)

NO!



They move in world space, they are just rendered to screenspace and collisions are calculated on a screenspace level. World space is not easier for collisions. You have more of an area to take in to account. They obey a common rule to move unnaturally each frame to offset the effect of camera movement.

How you do it is up to you.. if you were tl;dr'ing what I said though - you totally reversed it

[nasty_wolverine]

TL;DR
- Bullets live in world space (better for collision)
- Bullets move in screenspace minus camera left/right wiggle (so background speedups/movements dont effect bullet trajectory)

NO!



They move in world space, they are just rendered to screenspace and collisions are calculated on a screenspace level. World space is not easier for collisions. You have more of an area to take in to account. They obey a common rule to move unnaturally each frame to offset the effect of camera movement.

How you do it is up to you.. if you were tl;dr'ing what I said though - you totally reversed it

my collision system is a grid hash thats always in screenspace, but takes its input as world space coordinates and the current camera position minus the screen wiggle.

[trap15]

You're all making this unnecessarily complex

Bullets should live in the world space, along with all the other things in the game. When the camera pans, the bullets should move naturally, not stick. Using screen space for nearly anything (HUD elements obviously not included) is silly, dumb, and bad.

"Sticking" bullets are a sign of a kusoge.

[n0rtygames]

You're all making this unnecessarily complex

^ Serious.

If I have a camera that moves around and I spawn a bullet with zero velocity.. what way does the bullet move? IT DOESNT!

However the upward motion of the camera each frame gives it the appearance that it is moving downward. There is nothing complicated about this at all.

Now - if you do NOT apply this subtraction on the bullets Y axis and the bullet travels at a fixed velocity - what happens to targetted bullets at the players location?

They end up going behind the player! Because the trajectory of the bullet is for arguments sake (1,1) - it's travelling down and right each frame in world space. The position you were previously at in world space has since gone several 10s or possibly hundreds of pixels down the bloody screen so the bullet will never hit you.

Does this happen in shmups if you stay still? Only in some cases - 99% of the time, targetted bullets are hitting you (with the exception of tanks that fire at fixed angles but fuck that for this conversation)

Subtracting on the Y axis is the only calculation you need to do. Panning left and right should just happen naturally and the bullets will appear in natural places as you would expect them to do. They do not stick to the screen.

The reason I mentioned fucking around with other axis is if you're doing rotating cameras... in which case it's valid.

:- )


BTW - How you calculate your collisions is not really where they live... To get screen space you just do worldpos-campos, to get worldpos you do screenpos+campos

however screen space collision checks are fine because you are working with a fixed area in which collisions can happen instead of your entire game world... and trap is a steaming buffoon if he believes otherwise.