PROJECT: TFP SDCOM – 1

First update, so I have that going for me!

This week was primarily spent in Godot. As I posted previously, some of the initial assets have been created. So I integrated those into Godot, made the project, and worked through some of the GDScript.

If you didn’t already know, GDScript is great. It is, practically, Python. I use that language a bit for work and data science stuff. Godot is a great fit.

Update: as you’ll see in the quick video below, I got the missile silo firing at coordinates and reloading. The reloading is via timer, 30 seconds. Thinking about it now, I may switch out the silo for an air defense launcher of some sort. Like the U.S. Patriot system (U.S. MIM-104 Patriot, wikipedia). That might be a down-the-road change since it is (really) cosmetic. At any rate, I’ll have to make that sprite anyway. The missiles are interacting with each other and the enemy missiles (or bombs, in this case) interact with the cities.

Learned (or remembered) a couple of things. First, I initially had the player’s missiles on the same collision layer as the enemy missiles. This was a mistake since, at a low trajectory, the player’s missile would interact with the cities on the way through, thus blowing them up with their exhaust. Or something. So I placed it on a different layer and reworked the layer interactions, easy enough.

Second, and this is a good to remember, so I’m writing it down. Godot’s assumed rotation for a sprite is left-to-right. When I drew the sprite for the player’s missile, I made it up-down, as shown. But, when I would click to designate target coordinates the missile would turn about 90 degrees too far. After 30 minutes or so, I realized the issue. I rotated the sprite by 90 degrees and then the Kinematic 2D node that is its parent by -90 degrees (canceling it out and making it point up again). By doing that, the missile would then rotate toward the target coordinates., without going over Presumably, if I just make (rotate) the missile sprites left-to-right, this won’t be an issue. I’ll probably explore that with the hostile missiles.

As you can see in the video, at the moment, the missiles must turn to face their coordinates before boosting. I’ll probably keep that mechanic, but, good grief, the game is hard.

But that’s also kind of the point. We are talking about hitting objects hurtling toward cities with crazy destructive potential (more on that later). It shouldn’t be (too) easy.

I also doubled the size of the screen space from the SNES-benchmark (256×224). That is really small on modern monitors. However, I didn’t remake the assets to fit the larger resolution, so they look a bit more pixelated as Godot doubled the original 32×32 resolution.

Next Steps:

  • Hostile weapon spawn point and timer
  • GUI – to show “score” (maybe), enemy weapons left (maybe), and player reloads
  • Missile explosions, i.e. when your weapon reaches the coordinates it has the opportunity to incinerate enemy missiles… or cities…
  • City destruction animation (somewhat cosmetic)

Objective: With the completion of those four items, I think I’ll have completed 90% of the original game’s gameplay that I’m using as inspiration. Still need to sort sound though.

And, if you’d like to learn more about why nuclear weapons are terrible, I encourage you to read/check out this website: https://www.icanw.org/. This group is part of the reason I would like to make this game, well, difficult and to avoid using a “score”. If there’s a nuclear conflict, as depicted in this game, there’s really no “winning.” I guess 10 points for intercepting a gravity bomb and negative however many points for the population of the city that was just wiped out…

Published by dcgrapher

I like writing, drawing, Geography, gaming, programming, running, and cats. My family is awesome.

Leave a comment