As planned, last time I worked on implementing the turret and associated AI. First up, modeling it! Overall, I used the Phalanx CWIS as the initial inspiration.

So here's a simple shot of the model. Being more mechanical and less aerodynamic than the plane model, it's definitely got a touch of sharp edges to it. As before, I also implemented a super simple initial texture just to give it some visual interest.

I've already been asked why there is a robotic chicken on the top.

In any case, this model is predictably separated into parts. The octagonal base, swivel structure, center gun body (plus chicken), and gun barrel are all separate objects as part of the model, and are parented appropriately. This means that when I point the turret at something, I can separate out the rotational axes and apply them to each part separately.

Additionally, it'll be super simple to make a rocket/missile turret later on with only minor modifications to the model.

I also applied a maximum and minimum angle for it to point up and down, to avoid clipping and aiming issues related to going upside down or too far down. Overall I'm pretty happy with how it turned out, other than needing a final texture.

The Prediction Problem

As it turns out, the AI needs to know where to shoot in order to hit a target. Since the bullets I made were not hitscan, but actual projectiles, there's fancy math involved. Thankfully, I was able to steal and convert some C code from this Game Developer post for my purposes. The math involved is basically a quadratic equation that answers the question of "What is the intercept time, if possible to intercept this moving target?". Technically, the answers can be negative which means "You should have fired this far in the past if you wanted to hit it." Happily, we can use the positive value instead to predict how much further to lead the target if it does not change direction.

In the screenshot above, you can see ahead of the airplane are two green debug spheres. It's one for each turret in this case, since each one needs to shoot at a different place to hit the same target. Above includes some maneuvering that resulting in bullets all around the airplane rather than on-target, but it appeared to be working - initially anyway. Testing soon proved that the turrets could only hit targets that were stationary!

You can see that I ran into an issue where the bullets would always lag behind a moving target. It took a bit of time to eliminate all the variables as to what could be causing this issue. I spent a lot of time checking, re-checking, and refactoring the prediction math specifically because I assumed that was the issue. I figured that I must have implemented the formula incorrectly, or was applying the results incorrectly.

As it turned out, despite having all external forces disabled on the bullets there was still some weird physics effect that was slowing them down unexpectedly. Turning off the internal physics integration for the bullets solved the issue immediately.

The turrets are now perfectly accurate whenever their targets are relatively predictable (e.g. not changing direction and/or speed). Obviously, this makes them significantly more dangerous, but the plan isn't to make them perfect aimbots. Now that I can be certain that they can hit their target, I can manage AI behaviors in a way to make it more interesting for the player. For example, a great way to telegraph to the player that they are being targeted is to fire some initial volley directly across their field of view. It's also possible to easily add some degree of spread into the bullet's trajectory.

Design Developments

It was simple enough to add the bullets as a weapon to the airplane as well, so that's already done. Nothing has health yet, so that's something that will need to be implemented. That said, I don't want to add it yet because that will just make testing difficult (or I have to add cheats in too). Anyway, I've taken a step back from active development for a week or so (blame SGDQ, I suppose) to think about where to go next with this project. As such, much of the recent development since the turret hasn't been in terms of code or assets, but design work.

First, as you can see in the images above, the project has an official name. Steel Coast is what I'm going to go with once I get to the point that it matters.

Second, I put together a simple "overworld map" of the different mission zones. Each zone will have a particular theme, and the player will revisit each zone multiple times for different missions. That will reduce the number of unique maps I have to create and give the player some familiarity with the zones as they do missions in each of them.

If all of the above zones make it into the game, that will be 13 planned (plus a possible bonus zone I'm considering) maps to be created. I'd like to target about 5 missions per zone, giving me 65 potential missions in the game. That's quite a hefty campaign. If each mission took only 10 minutes, that's still almost 11 hours of gameplay. So, it'd be pretty important to make it actually enjoyable time to be spent in the game!

Third, I worked on some lore, and enemy ideas that tie into that. One thing that I had to decide on, related to this, is what the actual gameplay needs to be focused on. Up to this point, I had been envisioning a game somewhere between Rogue Squadron and Starfox. I decided that I definitely did not want this to be a rail-shooter like Starfox - but the "all range mode" of that game and of Rogue Squadron was more of what I wanted to design towards. That said, I really want this to be more "arcade" and less "simulation", so aspects of Starfox, like the big boss battles, are really something to draw inspiration from. More on that in the future.

Fourth, I decided that I definitely want to support cooperative multiplayer. I'm not sure if that's something I can pull off, but deciding in advance that I would like to means that I can hopefully plan out development to easily plug that in later. Given how I'm creating the various vehicles to be easily controlled by players or AI alike, there's no reason there can't be a third "remote player" controller type as well.

Next On The Agenda

With the above design considerations in place, the next stage of development is going to move towards adding more of the necessary content for those elements.

• Basic mission-selection overworld menu
• Initial version of at least two of the mission zones, Islands and Plains
  • This does require some final decision on map size/terrain scale and the vehicles' speed that I need to nail down first
• One more vehicle type; the Gunboat
• Some AI that is capable of doing more than just turret-aiming, and actually piloting vehicles instead.