XERGS Xml Encoded Retro Gaming System
Rebuilding the wheel my way. This is my development journal of my java 2d sprite engine. Maybe someone will find this usefull, maybe not...
07/28/2006
Xergs, a History of
music: Indiana Jones III (movie)
mood: Rested (since I took today off from work)

Here is a briefy history of Xerg development so far.

Sometime in December of 2005 I found a site that used Java and USB controllers. I found this fascinating as I am pretty much a console gamer. It was over some time off that I had for the holidays and I couldn't sleep, so I thought, why not play around with the code (which was from Killer Game Programing in Java, see references). I had picked up a Usb Logitech Precision gamepad on a whimsy and decided to give thing a try at 3:00 am.



This is the start of Xergs and as you can see its pretty simple. The little dot in the left box tells which direction the control pad is pressed and the buttons turn yellow when the gamepad buttons are pressed. The controller is very similar to the old Super Nes controller, except with an extra R and L buttons (total of 4).



Once I had that working, I just had to add another controller (the code now supports upto three at a time) and create a playing field for the controllers to move around it. Note that this is as simple as it can get, the 'camera' or view does not follow the dots (so they can run off the edge).



After working on or off for a few weeks, I changed the dots to ovals, because the players have height, width, and depth attributes. I implemented a system that allowed the controllers to switch between the other dots, similar to Secret of Mana.



Finally, we reach the current state. The represents about 6 months intermittent work since the previous screen shot. I cleaned up the code and made one project, rather than periodically copying the code, so I don't have any other progress 'snapshots'. The code is in cvs on my iBook and has these features (some of which you can see from the screenshot):


  • Sprites are used to draw the tokens on screen. The code only gets the images it needs to draw.

  • A viewport system is used that follows the players and allows them to move around the dungeon (all rooms are dungeons for me, even the top level world, dungeon is just a container idea).

  • Input from controllers is turned into 'Events' such as move, attack, block, etc. I have concentrated on getting movement to work, but some are stubbed out.

  • Collision detection has been refined so that a token will move as far toward an object as possible. For a long time, if the object was less than 5 pixels away, it couldn't move 'upto' the blocking token, since it could only take 5 pixel steps.

  • The View code uses double-buffering and supports game updates independantly of screen updates.

  • Use of interfaces is allowing me to make the GameEngine and DrawEngine code generic so that I will only have to customize the tokens.

  • GameEngine is beginging to use 'phases' to run game. The phase is game specific and would include things like title screen, load/new screen, main game screen, etc. I'll expend on this later.



Currently I am working on getting the Overlay (or HUD) system up and running.


New Comment
Name:
E-Mail:
Homepage:
Smilies:
smile shocked sad
big grin razz *wink wink* hey baby
angry, grr blush confused
cool crazy cry
sleepy hehe LOL
plain jane rolls eyes satisfied
 
  Formatting hints: bold text, italics & underlining can be done easily by bracketing text with two **asterisks**, \\backslashes\\ or __underlines__ respectively. Also, limited html is allowed.