Strike-16 GOTM Jam Entry

Relatively recently, I was told about gotm.io, a site dedicated to playing Godot engine games in-browser.  

I had made a game for a previous jam which I couldn't get to work in-browser on itch, and lo and behold, it worked just fine on gotm.io!

So when I heard the gotm team were running a jam I was really keen to try it out again.

The Game Submission

It's a tribute to StarWing/StarFox trying to fulfill the theme by having some gameplay based around the boost/brake.  You can play it here (perhaps ironically, I haven't got round to putting it up on gotm.io yet)

At the time of writing, voting is still ongoing, so I don't want to criticise it too much.  ;p

However, having played some other submissions, my link to the theme is pretty weak.  Never mind - I enjoyed making it.

The Making Process

I learned a lot making this and if I was to make it again, I would approach it differently, but here's how I went about it.

I started by trying to get the look and feel of StarWing, along with the camera and ship motion.


One really important aspect I did NOT get right was the camera field-of-view, which had important consequences later on.

Oblivious to those future problems, I proceeded to make the bullets:

So far, so good.  Then tanks!

The tank was where I started to hit interesting complications with the import process.  I like to try and separate 'raw' assets from 'game' assets, and I couldn't decide which a .glb file was.  I tried making inherited scenes from them, but kept getting annoyed by forgetting to remove the extra Blender crap when exporting.

Then I discovered the 'Merge from Scene' option, so I could have treated the .glb file like a 'raw' asset, then extracted just the nodes I wanted into the 'game' asset scene.  That gave me much more control in the Godot IDE, but impacted the workflow because if I changed the model and re-exported, I then had to manually re-merge the meshes into the 'game' scene.

In hindsight, I think I just should have deleted the extra Blender crap (camera, light) in the Blender scene, but meh.  I wanted to see the pixellated meshes without having to export them first.  Anyway, that's something I'll experiment with next time I set up a 3D project.

Next, the player needed to be able to take damage!

 (I hope you also enjoy my initial comical failure at actually getting shot.  If I had been trying to dodge those bullets, I probably wouldn't have managed it.)

You might also be able to make out the wreck models I put in.  I wasn't confident I could make a convincing enough particle effect that could cover up an instant disappearance of the tank mesh.  The wreck models seemed like a nice solution - seeing it instantly turn dark is much less jarring.

Problems Arise

This was the point at which I realised I should have thought through the scene/project structure better.  I needed some kind of level data to hold when and where the enemies would be spawned.  That was seriously complicated by the way I had imitated the semi-fake 3D of StarWing:


The player does not actually move forward in the scene - everything else moves towards the camera.

...

It felt like a good idea at the time.

...

:(

I believe more understanding of how to work with sky boxes could have saved me here.  However, my decision meant that if I made a full level scene, you would see the objects emerge through the skyline, so I needed a spawn system that would make them appear at a closer point.  It needed to work on fake level distance or time.

(Writing this now, I realise I could have made the whole level as a scene in Blender, made everything invisible, then just made each object suddenly visible when it reached a pre-chosen z value.  Dangit!)

I dithered about making a Godot scene with nodes that I could place for the objects, and with writing a custom Blender exporter to produce a spawn list.  In the end though, I went with a tried and tested text file.  I had to make it as a text file resource so the exporter would pick it up, but I got there.

Spawn All the Things!

So then I went crazy spawning buildings, tanks, gunships and generally flapping around, hoping that I would stumble on something approaching a decent level design.

The building-dodging was actually by design, as was the line of tanks just after that you have to brake for to get them all.  Most of the rest was trial and error with a hefty pinch of luck.

Finally, with the deadline looming I realised I needed a boss, and it wasn't going to be straight-forward...

Da Boss!


I was working fairly late into the night before the deadline getting this thing to work.  I still haven't invested the time to work out how to make animations in Blender that will export into Godot, so everything is done in code.  It's such a mess.

Making the weapon covers line up properly over the weapons was a pain, as was having to re-duplicate the engine meshes every time I made a change.  Oh, and I had to re-make the 4-gun one because I had initially forgotten that I wanted them to disappear when shot.

Thinking about how much time I wasted with breakpoints and debug prints trying to find a collision detection problem makes me sad.  I had forgotten to set the layer/mask correctly. :(

I also ran out of time to polish it properly, so the missiles are really hard to dodge and the targets are really difficult to hit.  You remember me saying about the camera field of view?  This is really where it hit home.  The wider the field of view, the more quickly things get smaller as they move away from the camera.  With the boss so far away, the targets are tinytiny, as are the player bullets.  If I'd made the field of view smaller, they would be much larger and easier to see your bullets hitting/missing them.

And another thing: I wanted the spinny-core thing to shoot fireballs, not the same bullets as everything else.  But there's only so much time in the day.

Summing up

I really enjoyed this game jam, and I'm proud of how much I got done in the time.  I had so many more ideas that I had to ditch, but hopefully I'll be able to come back to this, implement it properly and include loads more.









Comments

Popular posts from this blog

Micro:Bit and SPI display

DCS World with TrackIR under Ubuntu

Cardboard Mock-up of USB Joystick