Octane Mech, OpenGL Haskell based mech game; early code and some haskell notes


I am in the initial design and some development of OctaneMech; as the title implies is a OpenGL Haskell based Mech (bot, tank mobile) game.

An early goal is to recreate/port glAnts (mech game) to haskell
http://glants.sourceforge.net/

On Haskell

 Haskell is a pure functional programming language where your primary view of your software is through the use of functions. In java or other objected oriented/imperative languages, you are looking at the lowest level components; in Haskell, you are able to concentrate on the operation a particular function is used for without focusing on the low-level details (step-by-step sequences) of the function.

I won't now or probably in the future detail the power you are given with Haskell and I leave that up to you the reader. I will focus on how I am using Haskell to build my project. And this first entry will contain some simple Haskell snippets.

Main

 Like other applications, a Haskell application begins with entry point definition main function. For example, the following snippet below is all that is included in my Main module (included in a text file called OctaneMech.hs)

module Main where

import MechGLScreen
main = do
putStrLn "running OctaneMech"
mechLaunchGLWindow

It almost resembles a Hello World application. We import the needed library "MechGLScreen" and then write our main definition. putStrLn was used to print the startup message. mechLaunchGLWindow, is going to get a little bit more complicated. It includes the OpenGL initializations and sets the display callback.

Launch OpenGL

This function also may resemble more the sequential, call by call nature of an imperative program. If you are used to OpenGL development, most of the calls are window and GL initialization. It may get a little bit more interesting with the "SimplePlayer" data type which is composed of a x and y position.

mechLaunchGLWindow = do
getArgsAndInitialize
initialDisplayMode $= [DoubleBuffered]
initialWindowSize $= Size mechScreenWidth mechScreenHeight
createWindow mechWindowTitle

curMech <- newIORef (SimplePlayer {
shape = MechBoxShape,
posX = 0,
posY = terrainYSize-ssize,
angle = 0})
-- Get the current and rotation matrices
curMatrix <- get ((matrix $ Just $ Modelview 0)::StateVar(GLmatrix GLdouble))
rotationMatrix <- newIORef curMatrix
-- Keep track of camera movement
cameraRotPosition <- newIORef (0::GLint, 0)

-- Set the OpenGL callbacks
displayCallback $= displayGameLoop curMech rotationMatrix

-- Set the keyboard callback for handling actions
keyboardMouseCallback $= Just (mechKeyboardHandler curMech)

idleCallback $= Just idle
mainLoop

This particular function initializes the GL window and other game initializations. Now, open the MechDisplay.hs source. This function contains operations for swapping the GL double buffer and rendering the plain (Quad) object and player character (a simple cube).

displayGameLoop mechObjRef rotationMatrix = do
clear [ColorBuffer]
curMech <- get mechObjRef
prevMatrix <- get rotationMatrix
loadIdentity
multMatrix prevMatrix
curMatrix <- get ((matrix $ Just $ Modelview 0)::StateVar(GLmatrix GLdouble))
loadIdentity
scale 0.06 0.06 (0.06::GLfloat)
multMatrix curMatrix
-- Render the terrain, including the flat plain
renderTerrain
-- Render the Mechs
renderBasicMech curMech
-- OpenGL, swap buffers
swapBuffers

And I know it is short entry but I will actually continue in my next couple of posts on this topic. See all of the source code for this simple example below. Once you have it compiled, you should only see a 640 by 480 window open up and then you are able to use the keyboard (arrow keys) to move the "box" character around.

Source for Example

Download Haskell Example

Follow the Project at Googlecode:

http://code.google.com/p/octanemech/















Note: google code is horrible about the code formatting, so you will have to browse the included source to view the correct indentation

Comments

Post a Comment

Popular posts from this blog

On Unit Testing, Java TDD for developers to write

It has been a while, let's kick off 2017 with a blog entry. I have read and I am reading about four or five posts a day about unit testing. It really has been a long time obsession for me. I have moved past the technical and practical considerations on unit testing frameworks and done with the debates with "should you use Junit or Mockito or Karma?" I am more interested in the psychology of unit testing, who does it, likes it, hates it? It really is one of those easy to learn, hard to master concepts. For example, many many may play chess when they are young and can end up being horribly chess players most of their life, I am part of that majority. Unfortunately, I have never played chess and sat down for hours and tried to master it. I never see the common patterns or have a developed end game. I mostly just play with a knowledge of the basic rules. Following good unit testing practices within your software development shop is a lot like playing chess. It is easy to le...
Read more

Is Java the new COBOL? Yes. What does that mean, exactly? (Part 1)

Image
"If you want to know the past, look at your present. If you want to know the future, look at your present." -- Gautama Buddha Java is the new COBOL, whaaaat?     If you are software developer that mainly writes applications for the web; even if you aren't a Java/J2EE developer, you have probably heard the new meme circulating the web and blogosphere. "Java is the new COBOL" . Most blogs and technical writers regurgitate that statement and follow-up by saying that EJBs suck, and some companies are considering Ruby on Rails. I didn't really think much of these posts. I get the impression that a lot of these "managers" don't write any Java or COBOL code. They are really not highlighting the seriousness of the problem. COBOL development has remained stagnant for decades. Java may see the same problem in the future. The Pentagon/DOD has a trillion dollar COBOL problem because it is so difficult to change their ancient infrastructure. Anyon...
Read more

JVM Notebook: Basic Clojure, Java and JVM Language performance

Image
"Measure, don't guess. The primary goal of all performance tuning exercises should be maximize the end user experience given the resource constraints." [1] "It isn't so much a "farewell to the J" as an expansion of the platform opportunities Java provides. Sun's investment to power ongoing development of JRuby and Jython broadens the range and reach of Java, as a whole." -- Rick Ross Overview and JVM Languages    One of the exciting trends to recently emerge from the Java community is the concept of the JVM language. These technologies are all that you would expect them to be. They are implementations of languages that run on the Java Virtual Machine. Some are newly created and some are based on existing, more mature languages. JRuby, Jython are two JVM languages based on CRuby and CPython. Groovy, Scala, Clojure are three completely new JVM languages that were created to add new language features that weren't supported by the core Ja...
Read more