It’s interesting: I learned SDL game development a while back.   While learning it, I developed my own model for a graphics memory manager and draw-images queue.

Now I’m working on   a Java2d game engine with a lot of similar features.   I’m finding that more often than not, the features are best implemented in nearly the exact same way.   I’ve done a few changes to my graphics manager and the model of graphic storage for better image ordering and management.
With graphics, in my SDL graphics manager I stored graphics in the graphics manager, and when an entity needed to draw a graphic, it would pass in the x and y coordinates of that graphic, and a reference to that graphic, and ask the graphicsManager to draw it.   This works fine for drawing sprites, but what if I wanted to draw a more complex visual but use the same source image?   For example, animations, color shifted images, blurring, a combination of two images through a filter?
Now, each entity contains a “VisualRepresentation” class.   This class contains the reference to the immutable loaded image , and when I ask the VisualRepresentation to draw, it will allow the graphics manager access to this instance’s properties.     The VisualRepresentation contains only state information relevant to rendering and not information about the entity itself.

Portal looks so goddamned cool. It reminds me of a weapon in the killer quake(1) mod, one that let you make portals to walk through walls.

BlockGrab has been released. It can be found here. Basically, when a block enters the black part, you press a button to “capture” it. It’s a simple game and there is no way to lose. I used SDL to program it. It was written in C++

I just bought a new 300 gig hard drive.   Because of this, I reformatted my hard drive and put the latest ubuntu on it.   I had ubuntu on an earlier setup but to be quite honest, I experienced a lot of strange bugs / memory leaks.   That was before   the release of dapper.

I managed to get dual screens working too!   This is great news for me, as now I can use linux as my programming os.   I’m going to try   it out and see how it goes.

Java game development has been going ok, but honestly, the documentation for java game programming is really bad. I found out the book I was using is outdated and that I should be using the “BufferedStrategy”, but the docuementation for it is pretty sparse. Is the interest just not there compared to flash actionscript / emcascript programming?

A lot of the information I’m getting is off the sun java.net site. I don’t understand why the model of learning things on the internet is as it is. API docuementation is neccessary but not useable for a top-down approach. Tutorials and articles are outdated and too specific to problems. Forums which provide answers to problems over and over, but then do not organize them in a single source location for future understanding. A wiki done right is a good solution, but the problem is wikis just aren’t added too enough sometimes.   I wonder if wikibooks’ problem is that it’s too structured so it prevents teaching anything outside the realm of a book.   I propose we need an intermediary. A documentation style that is top down and bottom up. I’d call it a doctorial, but really it should just be called proper documentation. When people write documentation, the should simultaniously write how to use their API from both the bottom up, and the top down.

I like the whole information hiding in web2.0. To improve the bottom up experience, I could see a documentation system where API’s would have a hidden paragraph that is made visible by hitting a [TUTORIAL +] button, similar to digg’s buried comment show system.

For the top down, an ordered tree of these tutorials (ordered by generalness) with each one having a link to API’s of any referenced classes. Problems would have tags, so you could also find similar problems. This would be the ideal “Doctorial”.

My current project is basically a multiplayer board game.
I finally settled on using Java to write my game server, and the game client will be written in as a java applet, as well.

It uses sockets, and the client will be a Java applet using Java2d.   I think the client can be rewritten as any of several languages and interfaces.   I was considering flash, or a downloadable client in SDL, or even in JavaScript, using DHTML. Not really AJAX, but more like comet. There was talk of a ruby on rails technology, Armageddon, that looked interesting.
For now, since I’m a single programmer who doesn’t have a lot of time to maintain cross-language implementations, especially with the pace browser technologies are changing, I’m sticking with Java for the client and server.
The way I am writing the client, I think that it will be possible to reuse the same client for other games, the server will transmit enough information through the socket to draw a game.   Sorta like my own form of HyperText, but trasmitted through Object Streams.   This means that the client won’t have to be redirected to play different games, and that since the client isn’t updated often, I wouldn’t have to worry about the client caching old versions too often.

I’ve been working on multithreading, it seems a lot easier than I expected.   Java an excellent platform for writing synchronized and multithreaded servers.
For me to complete the server, I need to learn how to do Database to Java, probably MySQL.   It looks like JDBC will be what I need to learn.   That stuff is all abstracted away from the server and client so temporarily, I can just leave it volatile, and if the game server shuts down all data is lost until I implement it.   I also need to figure out how I am going to translate a web-session to a java authentication, I know it’s possible, I just haven’t researched it much.