Encouraged by the interest generated by my last post, I decided to do some more hacking on the real-time strategy game, which I’ve named **Armada**. I’ve now posted it on hackage; it can be found here.

The version on hackage adds quite a bit:

- Refinery units can now mine ore and transfer it to builder units.
- Builder units can now actually build units, if they have enough ore to do so.
- The scene is rendered using OpenGL/GLUT. Units are color-coded by player, with text describing their health and how much ore they have (except for fighters, which don’t carry ore).

I hope to keep adding to the project this week, though I haven’t decided what step to take next (don’t tell Joel!)

### Like this:

Like Loading...

*Related*

*Posted by intoverflow on 6 January, 2009*

https://intoverflow.wordpress.com/2009/01/06/armada-on-hackage/

## Adam

/ 7 January, 2009Part of the reason I was so interested in your last post on this is I’m working on a game, and have been debating switching to Haskell to force myself to learn it.

I’ve done that, although other than a re-implementation of some basic vector-based movement and some half-baked game unit code there isn’t really anything to show for it.

Trying to figure out how to handle targeting has been interesting, and led me to an interim solution of existential types with a map keyed by unit id, and a giant pile of material to research. Anyways, point is I’m interested in what you’re working on, keep up the updates!

## intoverflow

/ 7 January, 2009Adam,

I’ll definitely keep the updates rolling, though things might slow down a bit when the semester starts. Haskell is a beautiful language; I love the idea of writing games in it, partially because games rebel against the idea that Haskell is “bad” at IO-heavy, real-time-ish applications.

Indeed, game writing really forces one to quickly come to terms with some of these weird aspects of the language. Let me know how it goes!

## ararererer

/ 5 January, 2012Greetings

Armada doesn’t build with current OpenGL:

Armada.hs:410:37:

Couldn’t match expected type `Double’ with actual type `G.GLdouble’

In the third argument of `G.Vector3′, namely `zDepth’

In the second argument of `($)’, namely `G.Vector3 x y zDepth’

In a stmt of a ‘do’ expression: G.translate $ G.Vector3 x y zDepth

Armada.hs:430:9:

No instance for (G.MatrixComponent Double)

arising from a use of `G.translate’

Possible fix:

add an instance declaration for (G.MatrixComponent Double)

In the expression: G.translate

In a stmt of a ‘do’ expression: G.translate $ G.Vector3 x y zDepth

In the expression:

do { G.loadIdentity;

G.color $ (G.Color4 0.2 0.2 0.2 1.0 :: G.Color4 G.GLdouble);

let x :+ y = at om;

G.translate $ G.Vector3 x y zDepth;

…. }

Armada.hs:430:37:

Couldn’t match expected type `Double’ with actual type `G.GLdouble’

In the third argument of `G.Vector3′, namely `zDepth’

In the second argument of `($)’, namely `G.Vector3 x y zDepth’

In a stmt of a ‘do’ expression: G.translate $ G.Vector3 x y zDepth

Could you please update the code to work on GLdouble?