[BGMC 31] Destroyer

You thought shooters had to be first person shooters? This game will place you in command of the entire suite of weapons that a battleship has to offer. You’ll have gattling guns, railguns and swarms of missiles at your disposal.

Of course, a game like that needs plenty of dakka, so the first thing to do is to … make some gattling guns:

(change the video to 60FPS)

Each of the 9 guns puts out 2000 rounds per minute (compensated correctly for barrel spin-up time, and shots that fire not at logic-sync-time) and the bullets travel at 853m/s. Yeah, it’s raycasts for bullet collision rather than moving the physics bodies.

I did want to get up to 6000rounds per minute, but then a single gun can have several hundred bullets in the air at any given time (bullets despawn after 2km travel), and I need to have spare processing power left over for the swarms of missiles…

Github repository at:

All assets/scripts are either developed during this gamejam or come from previous projects I’ve published open source. Currently taken from my other open source projects include:


Looks like a fun concept. Keen to see how it turns out :slight_smile:

1 Like

No water? No problem. It’s a hovering destroyer. Currently armed with six gattling guns that you can target by clicking on things. The front/rear decks will gain triple-barrel railguns…

Yes, I keep clicking on the terrain tile so it targets that. It seems the resolution of the click detection is a bit coarse. The whole targetting/piloting interface needs to be designed, so this shouldn’t be an issue in the final version. (I don’t want sniper-clicking to be a game mechanic here).

The destroyer totally needs some sort of effect on it’s thrusters for when it moves.


not for now, but bullet has a batched raycasting command - you may want to wrap it.

Huh, I didn’t know that bullet did batched raycasting. I just threw a profiler into the current game…

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    24792    0.141    0.000    0.141    0.000 {method 'rayCast' of 'KX_GameObject' objects}
     4368    0.035    0.000    0.122    0.000 minigun.py:60(_aim_at)
     7105    0.016    0.000    0.032    0.000 ship.py:48(update)
     1421    0.016    0.000    0.024    0.000 camera.py:38(update)
     1421    0.015    0.000    0.379    0.000 scheduler.py:56(_do_update)
    10712    0.012    0.000    0.046    0.000 minigun.py:165(update)

Yup, the rayCast calls are the most expensive by ~4 times over the next most expensive function. This is in a couple seconds of gameplay, the guns have shot 1600 bullets and there have been 24000 calls to rayCast! Hopefully I won’t need to patch blender during the BGMC, but I’ll bear that in mind if the performance drops too far.

I think it should be OK because:

  • The projectiles aren’t physics objects. This means that even though there may be thousands of projectiles in the air, the physics engine doesn’t check collisions between them, and the raycasts “automatically” ignore the other bullets.
  • The terrain is split into chunks of about 1000 polygons, so each bullet doesn’t stress the narrow-phase of the physics engine. as it has to check worst-case 4 terrain segments.

This means that the calls should be pretty fast. The most expensive raycast will be the one that detects what the mouse is over, which spans the entire camera view range, and as a result will hit narrow-phase on up to 8 terrain tiles per frame (plus the other in-game entities)

1 Like

What is game-play even going to look like (?)

Looks like Star Wars. Nice job btw :slight_smile: :+1:

1 Like

What is game-play even going to look like (?)

Uhh, shooting?

Yeah. So in the above video I was assigning targets manually by clicking on them, and piloting the ship using the arrow keys. This is going to change completely.

Piloting the ship will be done by setting waypoints by clicking on the terrain.
Shooting weapons will be done primarily through:

  • Assigning priorities (eg gattling guns should attempt to shoot down missiles, then engage small craft, but should not engage big enemies)
  • Direct assignment (using hotkeys or possibly via clicking). This allows you to say “these guns target this thing”

Thus the gameplay is similar to an RTS, but you have a single large vehicle that can do many things at the same time rather than a bunch of small simple units.

1 Like

I’m going delusion_of_granger-mode here & guessing you mean like 100 guns each assigned individually to 1 key (?) Maybe not . . . :wink:

Ok, that sounds sensible :slight_smile:
Seems to be that your trying to make a battle-ship like game.

looks so good


Add support for fast batch raycasting on SPU / BulletMultiThreaded

“teresting, I didn’t know about this. Look in the Benchmark and ConcaveRaycast demos for #ifdef BATCH_RAYCASTER”

The ship gains a name (the Omega Fourteen), two twin-railgun turrets, and a decorative helipad


Introducing functioning railguns:

Unfortunately I’m hitting lag-spikes. Something is (unsurprisingly) straining the python garbage collector. Probably time to refactor the bullets to be leaner.

I was hoping to add in missile swarms, but I think I’ll do other things first (the UI, enemies, sounds)


Do your bullets have per-object physics (?) Are they set to static or rigid-body (?)

Most things are no collision - including the bullets.

The bullets are a python object containing a position and direction, and each frame they do a raycast and move their position. It then moves/stretches an object to have the right position for it to be visible on-screen.

I found the cause of the lag-spikes and, well, it was my fault.
The guns fire their bullets not on frame boundaries. If you have frames at 60FPS and a gun that shoots bullets 33 times per second, you need to compensate for the time that a bullet is launched in order for the bullets to be equally spaced. Unfortunately the timer that kept track of it was still being incremented when the gun couldn’t get a direct line of sight on a target. So if the target was hidden, the gun would “store” all the bullets it wanted to fire, and when the target became visible, it would fire a whole stack of bullets at once.

I made a quick patch, but I need to reconsider how this is done because the patched method means that a gun may not fire the instant a target is acquired, but may wait a bullet reload cycle.


why don’t you make it 30 bullets per second, then simply use an always with 2 tics. just an idea.

I love the RTS strategy look, also got a tower difence gameplay

Using An Actual Projectile Is Somethin’ Really Neat Like How This Gonna Turn Out… Sometimes Fps Just Use Mouse Over For Fps… I Wonder How You Gonna Approach The Collisions Effects… It’s Gonna Be Neat When You Add That Later :wink:

there will be no collision for the bullet. it’s all done with a ray cast.
a ray will be cast in front of the bullet to see where he should be next frame, if in that next frame he would hit an object, then we can use that objects data to add a bullet hole for example.


That’s Neat… :wink: But If Use Actual Projectile And Set The Designated Target Having A Rigid Body Box Which Disrupt The Bone Of The Target It’s Not Gonna Stay In Static Motion Means The Projectile Can Effect The Course Of The Target… If Your Going For That Approach… :wink: If Not Is Already Fine :wink: Yeah Maybe Add Some Fire Effects Yeah… :slight_smile: If The Damage Is Too Much :wink:

You mean hit left arm and arm moves reacting to that? you won’t need actual collision for that, once the ray hit, you got the hit_obj, hit_normal, etc so at that point you can do anything you like really.

for example if you have a cube, bullet hit that cube then we can simply add some (impulse)force on that hit position and the cube would react to that.

1 Like