tisdag 27 april 2010

A-star Scala implementation...

Working on my game I decided to do a generic version of the A* graph search algorithm. Below are the results. Basically pass in your start- and goal node, a neighbor funciton, a heuristic funciton (which needs to be not only admissable but also consistent) i.e. straight line distance, cost function between two nodes (the A* implementation will only pass in neighboring nodes as argument to the cost function).



Not sure if the internal use of a mutable set to keep track of the fringe and closed nodes is optimal...


Cheers,
Emil H

lördag 10 april 2010

I made a floor (more Scala and JMonkeyEngine)!

I've played around with Scala and JMonkeyEngine some more. It is always a supprise when you've been working on something and then you get an epiphany "Oh, I shouldn't do it like this...", then you change the way you go about the problem and you're basically done in five minutes. Well, ideally that is... This time that is what coding my Floor/Game Board implementation felt like.

I got the tip to use SharedMesh on the JME forum. This felt like a good fit for my floor since each Tile would be exactly the same. Initially I had created each tile with its own vertices, colors, indices and normals array. With the SharedMesh all Tiles share the data in these arrays. Niffty :)


So here I use the singleton object Tile as the TriMesh for the Tile class. I think this is a nice fit. There will only ever be a single instance of the TriMesh used to create the floor and if I later need to change some property of the floor I can just change the values in the Tile object. So when creating a new Tile I just use the apply method of the Tile object, pass in a name and the x an z offset. This is done in the Floor object below. The Floor class is basically just a Node at the moment, but I expect will grow when I start building the actual game :) The magic happens yet again in the companion object.

I have to say I realy like foldLeft and I have missed it since I stopped coding in Erlang. Everything becomes nice and clean with it. You pass in some state to a Itterable along with a function (that returns a new state) to apply for each element. No mutables that change and cause strange bugs. Sweet. Oh, and another nice feature in Scala is pattern matching. I use it in the calculatePos method. This case is a very basic example of pattern matching (I could have used a simple if-elseif-else instead) and it can be much more powerful.

And here is the result:















Next step will be to create a figure to move about my new floor, some pathfinding in a hexgrid (I think JME has an A* implementation, so I'll have a look at that). Later I'll add some basic controlls to the game.

Cheers,
Emil H

torsdag 8 april 2010

Scala and JMonkeEngine 2

I've started a small game development project for funsies. Getting JME2 to work properly on my linux box was a bit of a hassel initally since I wanted to have it work with maven. After a bit of tinkering and following the slightly dated tutorial (most of it is still correct as of March 2010) I got everything running smothly with a Hello3D sample in Java. However, since I wanted to use Scala 2.8, I realized I had to update Netbeans to 6.8 and get the new Scala plugin for it. So to get going a little faster I skipped the maven part for now. Setup is always easier the second time around I have noticed.

With my environment setup I created a Scala project. Included the lwjgl-, jinput- and the jme-2.0 jar and added the native bindings to the VM options. And I was ready to go!

So I quickly ran into a problem that is due to (I believe) the scala-netbeans plugin, a import error "jme is not a member of com". It seems that the issue is that the plugin had not realized that I had included the libraries. When I restarted Netbeans the following generated no errors:



A few nice features in Scala can be seen here. First, importing using a wildcard i.e. "somepackage._". In the case above I imported "com.jme._" because of that I dont have to write the entire package name for all the things I import from a subpackage of jme. Instead I can write, for instance, "app.SimpleGame" to import that class from "com.jme.app.SimpleGame". Not the greatest thing in the world, but a good thing to know when looking at Scala code, and it does clean the import statements up.

The object keyword in Scala defines a "singleton object". What this means is that there will only ever be a single instance of that object. It's kind of like a Java class with only static methods. So why is this useful? Well, for starters Scala doesn't allow static methods so it's needed to create the entry point for the program. But, there is also something called companion objects (I'll talk about them another time) and that is when objects shine :)

The rest of the code is very similar to Java code. However, we can notice that the val "box" has no declared type. "box" still has a type of course, which is inferred by the scala compiler from the assignment to it. This cuts down on a bunch of boiler-plate. Oh, and "val" is a variable which can only be assigned to once (like a variable marked with the final keyword in Java). There is also "var" which is mutable.

I expect to see more Scala power once I get things rolling, for instance a DSL for the core game rules would be nice. I'll have to come back to that...

Cheers,
- Emil H