Groovy Invaders – Timing is everything


This is not a follup post on Groovy invaders, rather an update. I found a bug! (Again!) For those of you that don’t follow my site regularly, my series on GroovyInvaders has been stalled. The last entry revealed a nasty bug that had the spaceship jumping and flickering about the screen. Well just this past weekend I took some time to work on the project and I found out what the problem was. I believe my timing algorithm is flawed. Adjusting the move speed and game tick clock to different values started to make the ship move smoothly across the bottom of the screen. I also discovered some flaky issues in, dare I say… Groovy? Why must I dare before saying? I’ll tell you why. Groovy is the best thing since Hip-hop music! It is the spread that I want to butter my bread with! It is the one technology I am not ashamed to obsess over! (…I’ve been know to obsess over XML related stuff and for that I am ashamed…) If I approached the pearly gates and the Lord said they only run WinXP and did not use Groovy in Heaven I would do an about face and take a brimstone bath just so that I could write more Groovy! (Though I’d have to question why Groovy Compilers would be allowed in Hell and not in Heaven. It would probably be a Gates issue at which point I’d also question if the gates were really representing the entrance to heaven in the first place.) So yes, I must dare before admitting to any possible flaw in such a prestine technology. Flaw? Who said anything about a Groovy flaw? Oh yeah, I was saying there was some flakiness there. As it turns out there is some confusion on scoping and using typed declarations mixed with typeless declarations. (The confusion is most certainly on my side because the Groovy team most certainly got it right, I’m sure.) I don’t remember exactly but I think that using typed ints and longs in some places causes weird errors. (Or maybe its the use of “def” as method params and storing them in typed variables.) Whatever the issue it comes up occasionally and causes me some refactoring. I also am not happy with the removal of the @Property keyword. I think I read somewhere on the Groovy wiki that “def” could/should be used as a replacement for @Property but in my experience it doesn’t work that way. I found myself inserting @Property declarations in my GroovyInvaders codebase as a quick fix to some scoping errors.

That the short story. Stay tuned for the long version when I resume the series and fix a whole load of issues. I’m also thinking of introducing some refactorings suggested by Kev, the author of the original Java based Groovy invaders that I’m copying. I have to take his word because I’ve never written a game before and I don’t know what I’m doing. Most of my work on GroovyInvaders is a direct copy of his Java code with the suffix “.groovy” applied. All of his original code is dated and it uses workarounds for problems that no longer exist in recent JVMs. Anyway, shots out to Tiago for waking me up and reminding me that I haven’t done anythinig on the series in a while. I plan to have a working playable version finished soon. Drop the “blahsay blah” in the box below…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s