Developing Asteroids: a series.

I’ve been developing a little homage to the 1979 arcade game, Asteroids, in Codea. I’m doing a series of articles, up to #17 right now and not done, describing how I build up a program like this. I’ve intentionally started in a procedural way, as one often does, and only now is the program beginning to move to a more object-oriented style.

Unlike many “how to” articles, my articles show the trials I make, the mistakes, the recoveries, all the things that happen to real programmers when we build real programs. I hope that folks interested in Codea will find this series useful.

Comments and questions are welcome.

https://ronjeffries.com/categories/asteroids/

@RonJeffries - been following your development of Asteroids with interest, like to see how real coders approach projects. I never seem to be able to finish mine, hit a snag, shelve and start a new project. Trying to get round that now.

I have made a few mods to your project on my pad - deleted the testAsteroids tab. Moved and modified the score display (just personal preferences).


function drawScore()
    local s= "000000"..tostring(Score)
    s = string.sub(s,-5)
    fill(255, 253, 0)
    fontSize(32)
    text(s, WIDTH/2, HEIGHT-60)
end

Slightly modified the drawAsteroid() function to partially hide the circle showing the asteroid size by making it more transparent (still retained it for development).


function drawAsteroid(asteroid)
    pushMatrix()
        pushStyle()
            translate(asteroid.pos.x, asteroid.pos.y)
            stroke(253, 41)
            ellipse(0,0,2*killDist(asteroid))
            scale(asteroid.scale)
            stroke(255)
            strokeWidth(1/asteroid.scale)
            for i,l in ipairs(asteroid.shape) do
                line(l.x, l.y, l.z, l.w)
            end
        popStyle()
    popMatrix()
end

Also, I increased the stroke and changed the colour on the ship to make it more prominent - just my preference.

I know these deviate from the original, but I think they do lift it a bit. Are you intending explosion of the ship on collision with asteroids?

Will continue to follow this, very neat and very professional. Thanks.

p.s. made me go back to my own thread with space invaders, which I hoped would suck in ideas, suggestions and code ideas. Must finish that!!!

p.p.s - not your code, but I have an issue with buttons near the iPad screen edge, dragging in other windows - distracts the concentration of us space pioneers dealing with the asteroid storm!!! I have raised this with @Simeon to see if we can switch out some iOS features to avoid this.

i’m glad you’re finding value. i plan to build in most of the function of the original, so, yes, the ship will explode when hit by an asteroid. i removed the circle entirely this afternoon, as it had served its purpose.

the ship is not drawn properly so will be changed to better match the original. making it a bit more visible is probably a good idea.

one challenging bit may be the sounds, either emulating them or ideally getting the originals somehow.

questions and comments are welcome!

@RonJeffries very interesting blog - only just come across it now so have a backlog to work through. Though you say its aimed at those new to Codea - I’ve been using it for years and have taken a lot from it already.

Here’s a zip of a step by step tutorial I put together 6 or so years ago for asteroids. It’s been interesting going back over it (and seeing a bunch of stuff which has been deprecated and I’m not sure that the step by step one from the github works anymore). One thing that jumped out at me was that when putting it together I focussed on getting the player’s ship up and moving then firing bullets before adding the asteroids. I note that you’re going for a depth first approach on the asteroids - getting them faithful to the original before moving on. Not a criticism, just an observation.

The second zip is the game fleshed out a bit. Different asteroid types (custom graphics), different power ups, levels named after actual asteroids. Still very rough (and from a few years back). Like @Bri_G I don’t tend to finish things, but this was one of my more complete efforts.

Anyway, just thought some of it might spark some food for thought.

Looking forward to the rest of the series

Thanks for the look and feedback. I did the asteroid shapes mostly because I was studying the 6502 code for the original and decided to try to draw the asteroids to check my understanding, so I went at it when my mind was (relatively) fresh. In any reasonable sense, round ones would have been a good place to move on, coming back to refine the shapes later.

Naturally, at some point, I plan to replace them with more attractive sprites, but shhh that’s a secret, and I want to get close to the original first anyway.

I’ll have a look at your work but am trying not to contaminate my mind, so that the mistakes I make (and always document) are not made less likely by seeing something sensible. :smile:

Thanks!

@West - nice package, very good finish. Sure I saw your tutorials before but working through them slowly now. Thanks.

The tab trick is interesting but deep in the guts.

@RonJeffries the tab trick was something another forum member passed on way back - it was trying to convey the slow build up of a program in a self contained package, however I do think blog posts allow for much more depth

Thanks @Bri_G ther should be lander and snake somewhere, but not sure if they still work

Yes, I saw that you had borrowed the tab trick. I must try to figure out how it works one of these first days. :smile:

@RonJeffries - think kill the ship killed the score.

In the drawScore function, change self.score to Score.

@dave1707 - thank ‘ee your a gent!! Now when the ship goes blammo I get a 20 point lift in my score. Now checking for collisions to see where the score increase comes from.

Edit: looks like it comes from the asteroid score, so when you go blammo the asteroid takes damage but the ship is splatted.

ah. prob should be fixed the other way, i’ll treat it as a bug report for next time. thanks! i wonder how to prevent these glitches.

@RonJeffries You can’t prevent glitches, you can only do a lot of testing to find and fix them. Question: If you have a bug in your code and nobody finds it, is it still a bug.

@dave1707 - remeniscent of the ‘if a tree fell…’ or more lately, from Terry Pratchett - “If an acorn fell …” which is more relevant to us!!!

@RonJeffries - the answer to your question is play, play play!! Or, more sensibly, hand over the bug testing to a lot of willing hands/digits/minds - US !!! Thanks.

better microtests would help a lot, and i’ve not been doing a good job of that. it’s tricky with games.

@RonJeffries - microtests? Is this testing small routines in isolation?

not precisely. but small test, taking short time to write first, short time to make run next, then nailing that bit down thereafter

@RonJeffries - aha, so correct me if I’m wrong. You are building a skeleton of small routines then concentrating on one to develop required features within it. Then moving onto next routine and ensuring overall compatibility.

not quite. too tricky to fully explain here. Basically “Test-Driven Development” is the root discipline but in the case in hand, I’ve not been doing full TDD, for reasons, but using it sometimes. It can be used to test-drive anything, just that the tests are small steps as are the implementations. If you read my articles on Asteroids, you’ll see that everything I do is in very small chunks which I make work before doing another chunk. With decent micro tests, each chunk would also have a tiny test to show / confirm that it works. Normally I always do that, but with a graphical game I don’t see quite how to do it effectively yet.