Let the Games Begin

In this post I'm going to go over some my early fumblings in Groovy. First, I've been reading a book on the language. I know some people don't have trouble learning languages just by looking at docs on the web sites, with a few tutorial articles thrown in. Personally, I prefer to deal with book. All the info in one spot, told (hopefully) in a coherent fashion.

The book I picked is "Groovy in Action." I'm not sure if it is available at book stores yet. I'm working with the eBook/PDF edition so I don't know. I'm not going to try and review the book - I'm still working through it. So far, though, I've been pretty happy with it.

Reading a book, though, isn't the way I learn a language "for real." Usually I don't get a language until I use it in a real project. Given limited time, I can't really use Groovy in a big project. Since this blog is about playful exploration, I decided that a little gaming project would be a good place to start.

And I don't mean video games. I have the utmost respect for game programmers, and know that there isn't really such a thing as a simple video game project. I mean little programs based on board games and such.

Which leads to the first little project - a dice roller. A lot of games require the use of dice as a randomizing element, and its hard to imagine anything simpler to start with. I'm going to try and make this interesting by seeing how far I can push this, of course.

Anyway, a few preliminaries. Die rolling is a bit interesting in the sense that there are many different types of dice. In addition to standard 6-sided die, there are many other types with a different number of sides such as d20. These are used a lot in Role Playing Games (RPGs), which I used to play a lot. Also, depending on what you're doing you will likely roll more than one die at a time. So we'll start with a function that will roll an arbitrary number of die, all of which have the same (arbitrary) number of sides. Since RPGs often modify the roll with a constant (e.g., add 2 to the roll), we add the concept of a modifier. This leads to a Groovy function that looks like:

def diceRoller(number, sides, modifier) {
 dieRoll = 0
 number.times {
   dieRoll += (int)(sides*Math.random() + 1)
 }

 dieRoll + modifier
}

Before I dig into the code, I suppose I should say why I choose to write a function like this, rather than define a bunch of classes like Die and such. First, I'm not really ready to go into classes just yet. And second, I suspect that would be overkill. I'm a big proponent of Object-Oriented Analysis and Design (OOA&D), but I like to start simple. Besides, it should be trivial to go down that road if it seems like we need to later. And since I'm just playing around, writing little scripts like this is just faster.

Anyway, the function itself is pretty trivial. From a Java point of view, the oddest thing would probably be the lack of type information. The function doesn't declare a return type, and none of the method parameters have any type information either.

This is Groovy showing us one way in which it is a dynamic language. However, I should point out that Groovy does allow you to specify the types. This is a little different from most languages, in that you can choose on the fly whether to type things or not. I still find this disconcerting - under what circumstances should I choose one option or the other? I really haven't figured this out at all. For now, I'm trying to be dynamic as possible, but sometimes I feel the urge to give an explicit type and will do so. I welcome any thoughts on how to choose this...

But this code is a bit weirder (from a Java perspective) than just dynamic typing. In particular, I'm using a closure, and taking advantage of the times method that groovy has added to the integer type. It felt strange, I must admit, to write a loop like this without falling back on the for loop. I did this because:

1. I think this notation is more expresive of what I'm doing than a for loop
2. The for loop in Groovy is actually not the for loop I've come to expect from years of C/C++/Java coding.
3. I want to play with closures.

One thing the "Groovy in Action" book emphasizes is the importance of closures in Groovy. The simple way to think about closures as little bits of code that you can pass around and execute. They're actually quite a bit more involved then that ... but I'll leave that for another time. Closures are used a lot in Groovy for dealing with collections. Here's an article that covers closures and collections (mostly focused on Ruby, but Groovy seems to borrow pretty heavily from Ruby in this area). And here's another recent article on closures.

The last thing to notice is that the function doesn't explicitly return a value. Like a lot of dynamic languages, Groovy makes the return statement optional. If no return is specified, then the value of the expression evaluation is returned. If the last statement doesn't have a value then a null is returned (I think).

This is a pretty long post, already, so I'm going to call it quits here. Next time I'll try to get through things faster. I'll talk some about testing in groovy, and dig a bit into collections.