Groovy Invaders II


Yesterday I began a trail on my development of the classic Space Invaders using Groovy. So far I only shared my Maven “pom.xml” which I will use to build my final project. I’d eventually like to execute the project with Maven if possible/practical but since I’m still a newbie I’ll stay content with a basic Maven build. Let’s move onto the code for the game. I explained yesterday that if you wanted to follow along you should create a folder named groovy-invaders somewhere on your hard drive to hold all of our hard work. It doesn’t need to be called groovy-invaders at all; you can call it whatever you wish. (Name the folder “crap-that-occupies-my-time-when-i-should-be-working” if your operating system supports really long folder names.) The code in my little series is all based on code found in a tutorial here.

The Game Logic
The majority of my trail will be a shameless copy from the original tutorial with some minor modifications here and there as I attempt to put my personal touch on it. If you are familiar with Groovy and see a better way of writing a particular line of code, drop a line and I’ll incorporate it in the tutorial. I’ll start with the core “Game” object which is defined in “Game.groovy”, and explain what it is and how it works as I understand it. (Hint: Now would be a really nice time to right click inside of your folder you created earlier and click the “add new text file” feature of your file system browser. Or do the same with your IDE if you’re using one. Name the file “Game.groovy”) I’ll explain things at a high level then supply code to illustrate what I’m doing. I encourage you to vary your logic from mine because I’m varying mine from the tutorial as I follow it. As I follow the tutorial I try to code from the explanation rather than reading and copying the example and using the explanation to decipher afterwards.

Game.Groovy
The Game object extends java.awt.Canvas. Why java.awt? Well from what I’ve learned in various Open GL writings and Java Gaming articles, java.awt plays much better with accelerated graphics than Swing. Probably because it’s all heavyweight, close to the native and stuff. The idea is the accelerated drawing can happen in a java.awt component which you can mix in with your Swing application. (There are some issues with mixing AWT and Swing you should be aware of.) Our main Program Entry Point (or PEP as some call it) will merely instantiate Game and throw it into a game loop. You can include the PEP logic right in Game or create a separate file. Whatever you see fit. The game is responsible for creating a window or a frame and embedding itself into it. The game loop will be defined in Game and is responsible for all of the high level logic running the game.

Are you following along? If so then you may have guessed or imagined the following in Game.groovy:


   public Game()
   { //Here we create a frame and draw ourselves to the screen   }

   public Game gameLoop() { //core logic goes here }

   public static void main(String[] args)
   {
       def g = new Game()
       g.gameLoop()
   }



Drawing the Game
The most important piece of our project concerns creating the frame and drawing to the screen. I’ll explain a little about the technology we’re using. Because we want accelerated graphics we take advantage of the Java 2D API. Eventually our trail will take us to a refactoring where we’ll pull Java 2D out and do the rendering with the JOGL API over Open GL. (I’m not sure if that last sentence makes sense, I’m just throwing tech terms at you so you’ll think I’m smart.) In our Game constructor we’ll create a frame and get a reference to it’s content panel, set the panel to 800×600 dimension, and set the panel layout to null. Then we’ll disable window resizing (cause this is a game and we don’t want to have to truncate the action or deal with resizing graphics on the screen), add ourselves to the content panel, pack the frame and set visibility to true. There’s two things in our Canvas sub-class to pay attention to at this time. We have to tell AWT not to repaint the screen because we’re doing low level accelerated drawing. We also need to define our buffering strategy and get a reference to it. My code looks like this:
    public Game()
    {
        def container = swing.frame(title:"Groovy Space Invaders",
        defaultCloseOperation:javax.swing.WindowConstants.EXIT_ON_CLOSE)
        def panel = container.getContentPane()
        panel.setPreferredSize new Dimension(800, 600)
        panel.setLayout null
        setBounds 0, 0, 800, 600
        panel.add(this)

        setIgnoreRepaint true
        container.pack()
        container.setResizable false
        container.setVisible true

        createBufferStrategy 2
        strategy = getBufferStrategy()
   }

(Yours can look better or worse. The idea is to get a feel for the API by using it rather than watch how I use it and copy text.) Note how the strategy variable is not defined in the constructor. I am caching it in an instance member for later use.

Game Loop Logic
Here is where the bulk of my innovation begins. As I read the tutorial it explains the loop works as follows:

# Work out how long its been since we last looped
# Process any input from the user/player
# Move everything based on the time since last loop
# Draw everything on screen
# Swap the buffers over to make the new image visible
# Wait for a set period

To me, that evaluates to this here Groovy code:
       while(gameRunning)
       {
           elapsedTime = calculateElapsedTime()
           processInput()
           display(draw(elapsedTime))
           delay()
       }

I initially used something similar to the above code with an additional method call to a moveSprites() method but as I followed the tutorial certain things didn’t line up correctly, forcing me to tuck the movement logic into the draw method. Pay close attention to that code because it may refactor some more as we move along. I’m calling it quits for now. (“Hey, we only wrote two or three methods? C’mon! Let’s keep it movin’!”) I have work to do so you can dream about the remaining programming or you can read ahead on the other tutorial and get ideas. Show me some love in the comment section and I’ll hit’cha back…

(Showing love is a brotherly way of expressing ones ideas and innermost thoughts. In no way does it referr to an intimate relationship of any sort. As the author promises to “hit’cha back” the only desire is to respond to any “love” or comments included in the trailer of the post. Punches are not implied and violence is not tolerated.)

Previous Part Next Part

4 thoughts on “Groovy Invaders II

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