Monday, April 4, 2011

Forge Gui - Harder Than It Looks

I'm still working furiously on a new graphic user interface (gui) for Forge but progress has been very, very slow.  I'm using someone else's videogame library so I don't have to write anything from scratch.

Last week I started with three game libraries and picked the smallest one, named Fly, to use.  Fly seemed easy to use and had some documentation but I couldn't get it to load images.  Fly tries to make it "easy" but it ends up not working.  I think it tries to uses reflection or some advance Java stuff.  (Fly didn't come with the source code so I couldn't try to fix it.  I thought about decompiling it but I just tried the next videogame library.)

Ucigame was my next choice.  (And no, I don't know what it stands for.)  It had more documentation than Fly as well as 12 short demos programs which showed how various stuff works.  So step 1 is loading an image and showing it on the screen.  Check, thankfully Ucigame had no problems there. 

So I went on and coded a few more things before I found Ucigame's game breaking problem.  You can't use "for" loops, or any other kind of loops, in the draw() method.  At first I thought I could "code around it" and ignore the problem but I couldn't.  The more I coded the more I thought that this was a serious bug.  I presume it had something to do with a threading problem, where a computer runs two programs at the same time, but I have no idea.  Coding threads is always a problem and that is why I was using someone else's code in the first place.

OK, I was down to my last Java videogame library GTGE, which stands for "Golden T Game Engine".  The slightly odd name stems from the fact that English is not the author's first language.  The good news is that GTGE can load images and use "for" loops in the draw() method.  The bad news is that nothing else is done.  I felt like I didn't do any "real" programming this week because I had to spend a few hours sorting through the various game libraries.  Thankfully GTGE seems pretty good and I'll deal with any problems that it has. 

A good game library (API) tries to help you out but doesn't restrict you either, which is a hard line to walk. 

Tanks for reading,
mtgrares

p.s.
--Yes, "tanks" is an intentionally misspelled. 

--"API" stands for "application programming interface" and is programming talk for a code library that someone else wrote.  The library tends to have a specific goal like "get web pages over the Internet" or "make writing videogames easier".

--I didn't have any humor in this column so feel free to think of a joke about exploding chickens.  :=)

2 comments:

dismal_denizen said...

Is there any reason why you didn't try Slick? After a bit of searching that was the library I decided on for my little projects (admittedly, this was a while back when I still primarily used Java).

PS Thanks for Forge and this blog. The program brought me into MTG and the blog helped me code my very own MTG program!

Forge said...

Slick looks pretty good and it is currently updated. I didn't exclude Slick, I just randomly tried a few libraries that I found.

I might try using Slick if is isn't too complicated but it is hard to get up-to-speed when using a new library because you have to learn "their way" of doing things like resizing a sprite or using a font.

Slick features:
* Provide a simple 2D API
* Make transition from Java2D to OpenGL easier
* Enable distribution via WebStart without the complexity
* Provide the tools required for most simple games out of the box