Just a bunch of stuff I cobbled together to investigate/play with the C-API.
It definitely still needs some finesse, and maybe a few licks of panache.
I was inspired by an old old game I played once, where the player could fire ample bullets. I loved the way they "snake" across the screen in a beautiful sinusoidal wave.
This looks pretty damn cool! I'd advise using vectors for the alien movement if you want to make them move randomly, it'll stop that jitter.
Thanks for the suggestion.
I've just started looking at the alien movement now. I'm working on having them follow a vector trail of dx/dy's - that should allow me to create different and interesting movement for each type of alien. I'm also toying with the idea of making some super-tiny aliens, and have them flock around the bigger aliens using the "boids" algorithm... but maybe that's a bit much for a simple shooter.
I also want want the aliens to "hyperspace in" somehow at the beginning of the level.
Another update.
I added some rudimentary sound effects. I've never played much with sound, this was fun. I made all the effects (so far) by just making mouth-noises and tweaking them Audacity.
As discussed, I made the aliens move in particular patterns rather than just randomly-jittering. This is implemented with lists of direction vectors, so the alien moves along the line described by the vector for some milliseconds, before switching to the next direction. This works well for both simple movements - the lowest-level alien simply moves around the "corners" of a square, where others walk (fly?) in circles, lemniscates, etc. These were a bit tricky to calculate, but then I worked out that simply subtracting the N+1 point from the N point gives me an approximate direction. Good enough for an alien flight-path anyway.
I also made the aliens less-dumb. Now they drop bombs in the direction of the player, rather than anywhere. Higher-level aliens can impulse the bomb with a higher velocity so it reaches further, faster. I'm wondering if the top-level alien should be smart enough to aim a bomb directly at the turret. This might be too difficult for the player though. It is a wonder how the aliens can achieve interstellar travel, but not drop a bomb accurately whatsoever.
Today (chores permitting), I want to get the aliens flying in some sort of phalanx. I think this may look better, but probably more importantly, this is what people expect from this sort of game.
TODO:
I was cogitating on adding some "accounting", so that missed shots somehow count against the player. Maybe it reduces the bonus, or perhaps just adds -1 to the score. What do you think?
Another Update:
Yesterday I added Alien Phalanxes, and as part of this, I had to define a grid-like set of alien starting positions. I'm not 100% happy with this, and in some cases I don't use it. For example I start the "flyer" aliens off the side of the screen so they immediately turn around, heading in a known direction. So I might yet add a further starting-grid, or tweak the existing one.
Now that there's a starting grid, the patterns the aliens move in became an issue. The problem is that even if you start the alien in the exact centre coordinate, the movement pattern has to follow an equidistant path about this point, otherwise it no longer "looks" centred. One of the higher level aliens moves in a circular path - but the starting point for the path is on the eventual "west side" of the circle, so the alien moves to screen-right. It doesn't look good.
I've been thinking of ways to mitigate this issue. One simple way, is to simply create the path such that it travels around the centre point. So now the lowest-level alien that previously moved in a square, now moves in an "hourglass" pattern centred on the origin. It works, but doesn't look as nice as the original simple square. My next-best idea is to simply make the first step of each path a one-time-only movement that corrects for any future offset. So the circle-moving aliens - their first movement would be a radius left. Maybe this even happens off-screen. Possibly I could pre-calculate the middle (centroid) of all the x,y path changes as an automatic offset. But there is a time factor involved, so this would have to be re-calculated each level change (if the aliens speed up, or whatever).
It's not all bad though. The flyer aliens now move in a sinusoidal wave - I'm really happy with this. I think it looks great - especially the way they slow as they cross the middle of the path. They're also nicely challenging to shoot down.
TODO:
(Hmmm, the TODO list never seems to get shorter. Oh bother.)
EDIT: I don't expect to have any time for further changes today, my apologies.
Today I added the "hit points" of the player's tank as a health-bar... and I don't really like it. I'm starting to think I need the "queue" of reserve tanks as a little icon list. I will have to cogitate further on this overnight. Just reserve tanks? Reserve tanks and health? Something else?
I burned a lot of time not really making progress on getting the aliens to orbit their starting position. There was a couple of stupid bugs - not taking into account the fixed FPS rate into the distance calculation for one (that was a clanger!). The next bug was that the algorithm to calculate the polygon centroid didn't work at all on the concave polygons. /me sighs. Then I noticed that there's some subtle weirdness going on with the patterns too. Even the sine-wave following "flyer" aliens creep down the screen, but I decided that despite it being unintentional, it's good. It makes the game-wave progressively harder for the player, as the bomb-drops get closer and closer overhead. Only the noob-level aliens stay put. So the upshot of all of that is to just get on with things, since everything is going to be all right.
Since now I need to pre-make level/wave layouts, I made some more. So far there's 10... but how many do I need? At the end, they will restart but with more difficult settings.
TODO:
Complete sound effects
Turret Artwork
End-of-level bonus screen
Pretty Banner of Game Name
I moved the health-bar around, and added an icon.
I think I like it now. I still might change it to the typical "3 lives" model, but I'll play-test it for a while and see how it goes. I'm not wed to it, and neither code-change is involved, so it can easily go.
New code to implement various power-ups.
So far I've only implemented a "shield" type power-up, and now the player starts with three uses of them. I also plan bullet-modifiers, like 3-way bullet streams, and big-bullets.
It took longer to code the status-bar of power-ups than the actual player-shield. I expect the bullet modifiers to quicker to code though. Fingers-crossed!
I'm still waiting on some proper player-turret bitmaps from our pixel artist.
I had a lot of anti-progress this week. Most of it revolved around my lack of understanding of the way realloc() works. In my, uh, years of programming C I've only ever used realloc() to change the size of a block of memory, never to "de-allocate" the memory. I'd only ever used free() for that. I strongly urge the maintainers of the C-API to add a system->free() for this purpose. Just for The Record: calling realloc() on NULL results in an allocation - even if the size parameter is zero. Most of my calls to moveWithCollisions() returned a NULL list, so I was burning memory like there was no tomorrow.
Then I stupidly got the idea in my head that off-screen sprites might still have had their update functions called, and went to great lengths trying to NULL-out the update function pointer when the sprite was back in the pool. I keep all the bullets and bombs in a sprite pool so they're ready to "fire". So what I was trying to prevent was all these pool-sprites being updated too. Calling setUpdateFunction( sprite, NULL ) on a sprite while it's in the update loop causes a segfault. Of course I didn't know this at the time. So I spent countless ages wondering where I had broken it. Anyway, once I figured out the segfaulting problem, then a simple log message showed the updates are not called on off-screen sprites. So a total waste of time. /me sighs.
Anyway, enough glooming...
It did force some code clean-up & rationalisation upon me though. So now my bullet-recycling functions are much nicer.
I did also manage to two more power-ups: "Super Bullets", which are bigger and fly faster. And "Bullet Spray", which fires out 3x as many bullets. The latter really gunns those alien scoundrels back to their home planet. Maybe it's a bit too powerful. I guess I'll make the use-timer shorter. Maybe.
I still haven't decided how the power-ups will be delivered. Should they randomly drop from an alien? Should a Space Marines' drop-ship deliver them? Something else? ... And what happens if you shoot one mid-delivery??!
Thoughts on the End of Wave.
Since my aliens don't "advance" to cover the screen, I'm concerned about the game-play during the time near the end of the wave of aliens. I don't want the situation where the payer can rest to the side with impunity, while a handful of aliens drop bombs impotently in the other corner.
Other games of this genre (ah... "alien shooting"), typically have a "Hurry Up" alien, like the small saucer in Asteroids or the "Baiter" in Defender, and even that stupid little bouncy smiley face[1] in Berzerk... Anyway the purpose of all these entities was to produce a fear in the player that they better get rid of the "easy" aliens quickly, before the much-more-deadly aliens came along.
So I'm toying with the idea of having the aliens do "bombing runs" when there's less than 10 remaining. Maybe there's a random 10% change of a bombing run per remaining alien. I wanted an interesting pattern for the flight-path, and have been playing with logarithmic spirals, just because they're pretty. So far I've hacked-up a demo in python which shows the movement points.
I'm hoping this will look good, but also provide a flight-path for the alien that makes it a little more difficult for the player. Also the player must react, as the alien is on a collision-course.
One problem with this path, is that it's not feasible to pre-generate points for every alien position per player position, so they'll have to be generated on the fly. The maths is reasonably hefty with calls to pow() and trig' sin() & cos() functions. But I think so as long as it's not called too much, performance will be OK.
What do you think - is the spiral stupid? I really like its curves though.
--
[1] Honestly, who's idea was the smiley-face-of-doom??! It really doesn't fit the game world-theme at all. I'd wager it was hacked-in (or badly tweaked) at the last minute to ensure a better rate-of-return per hour with no concern for the gameplay. And it looks crap.
It's really fast, can walk through walls, and you can't shoot it. 
Looking really good one of my favorite genre online leader boards always adds a lot for this style game for me.
Ok, so the looping turned out to be really hard. There were a couple of problems.
Firstly to make the aliens fly through a path that includes the player position (at the time of departure) I simply made the radius of the logarithmic spiral the distance between the alien and the player. But this path may sweep off-screen! In the most extreme case - alien top-corner Vs player bottom other-corner, the top of the path was mostly off-screen. It looked rubbish.
So I decided to scale the height of the spiral, squashing it up to fit. This is not ideal, but it's far better than the aliens being off-screen. They still sometimes go off-screen to the sides, but it's very occasional, and minor.
The second problem was a star-crossing of graph point-density the movement speed. To follow the path, I taught the aliens to follow a series of coordinates. At each new point, they turn to move towards the next point. At each update they move about {speed} pixels towards the destination.
However the spiral has lots of points bunched-up near the origin. When the aliens moved between these closely clustered points, they often over-shot the destination. This made their first movements erratic, and they tittered from side-to-side, up-and-down before finally taking off. To correct this, at first I tried simply leaving the first N coordinates out of the graph. But for smaller loops (when the player is horizontally close to the alien), nearly all of the points are close together, so there was no good N to use.
In the end, I had to calculate the distance between successive points in the spiral. I didn't want to do it this way, since it requires the 2-point (euclidean) distance formula. This needs the square-root function, which is relatively expensive to calculate. So now during the loop generation, we only keep points that are more than 8 pixels distance from the previous point. That gives nice sweeping loop, and I'm happy with them. I just hope the real Playdate hardware can keep up.
I also had some nasty bugs, borne out of my own carelessness... let's just say: don't forget to take a break in your case/switch statements .
I finally got some time to work on this. I'm still stuck on text entry in the C-API.
I've come up with a D-Pad letter-picker concept, which doesn't suck too much.
I'm not sure the buttons are OK, but they'll do for the moment. If the PD API ever supports text entry under C-API, then I'll probably just switch to that. In the meantime, it's d-pad key entry.
What do you think? Is it ugly? A little ugly?
It would be better with a nicer font, just that's more time that isn't strictly game development. And while it may be easy~ish"donkey work", it is far less interesting than actual game-play logic.
I would have liked to have had the text say "A ↓ F" and "G → M", but the utf-8 arrows aren't in the font.
Anyway, now I need to work this into the high-score table. A lot of work for fetching the players initials... 