Sign In Sign-Up

Welcome!

Close

Would you like to make this site your homepage? It's fast and easy...

Yes, Please make this my home page!

No Thanks

  Don't show this to me again.

Close

GUB Old Version Info...
For current versions info, see the Versions page.

Version 0.8.0: Unreleased
On April 21st: I got my JARS Rating today: GUB is listed as one of the Top 25% Java applications! They rated version 0.6, though. I'll resubmit GUB for rating once it's at 1.0, and hopefully we'll pull the rating in a bit. I'm pretty proud of being in the top 25%, though.

Major changes are taking place in GUB's internals, greatly simplifying and modularizing the code. This one won't be released for a little while because I have to rewrite so much of it. It's at least an 80-90% complete rewrite. I'm fully aware of the dangers of copying/pasting old code into new work, so I'm being careful to just write it all from scratch. I expect it to take 2-4 weeks or so (depends largely on my girlfriend's patience) to get to the point where I was with the old code. Luckily, Sabine has finals coming up, so I should have free reign on the computer for the next 9 weeks.

• Here are some of the highlights (and lowlights) of the 0.8 series:
  • All code is being about 90% rewritten. This won't take too long, as it's much easier to write an application once you've already written it twice before ;).
  • Game pieces now have a MUCH better popup menu, with more features and a much more useful layout.
  • Game board controls are now much more logically placed and work better (you don't have to reload the board for the settings to take effect, for example).
  • Covered pieces are now allowed. This is very useful for wargaming and card games. You can cover pieces and change the cover color. A future release will support images for the flip-side (they're currently just drawn with "screen door look"). A covered piece will not reveal any information about itself. A plugin could easily get by this, but I'm hoping you guys have a bit more integrity than to write cheat plugins. I may make all of the accessors return empty info if the piece is covered, defeating most attempts to peak. Hmmm...
  • Transparency is now independent of the background color (it's not a background color in itself like it used to be). You can toggle transparency on/off and still keep your background color (of course, it doesn't appear when the transparency is on, but is restored when you turn transparency back off).
  • BORDERS: you now cannot only toggle the border on and off, but can also set it's color.
  • RESIZING is now much easier, with a quick way of setting the width/height at the same time or separately.
  • Plugins' usage of pieces and the game board will change drastically, as I'm trying to make the basic GUB classes usable by at least three different projects. All plugins will be completely rewritten to use this newer method.
  • The UI code and brain of the game are separated into separate objects (as it should have been in the first place), allowing me to easily plug in a different UI. The game itself is written to a set of interfaces, so the UI will accept any game that uses these interfaces.
  • Java-native drag and drop is used, which allows for more intuitive addition/maniplution of game pieces. It doesn't appear to be very robust, sometimes locking the game, but I'm not sure if this is my fault or a JVM problem.
  • The game board can now be docked on the left or right of the UI.
  • I'm hoping to find a way to tie the LOS strings to game pieces so they'll follow your piece around (so you can mark the destination of a piece that's making a multi-turn journey, for example). This shouldn't be so bad. Getting the LOS strings working in the first place wasn't any fun, so I'm sure I won't enjoy doing this part.
  • Game pieces can now store any extra String-type data in a free-form format and it'll get passed around, synced, and saved with the piece. This can be used by plugins that want to implement additional game piece functionality, so they can store the extra state information there. For example, a wargame could use it to store the attack and defense info for the piece, and possibly hold movement restriction information. There is no limit on the size of this, but it must be only one line of text.
  • Much better scrolling performance when using the "Scale to fit" game board option.
  • Better savegame functionality. GUB now saves not only the pieces in play, but the original game piece list as well.
  • On the Dark Side:
    • GUB will actually be a bit slower because it uses only Objects for it's data, and very, very few primitive types (this saved me a lot of code dealing with property changes). I think is mostly noticable during a drag/drop. It's not SLOW, but it's not lightning fast, either.
    • I finally got serialization [kludgily] working. This saves a lot of code, but breaks the tool tips (hoverhelp/baloon help) because they aren't correctly serializable. So, for now there is no hoverhelp for game pieces.
    • Java's Drag and drop doesn't appear to be very stable. For some unknown reason, it often locks the game when a drag is started and the mouse is release within a very short amount of time (0.2 seconds?) after starting the drag.
    • I'm still encoding game pieces into Strings for passing them around the network because it's much faster (in transfer time, not processing time) than serializing the pieces and passing them around. I can't perfectly clone a piece this way, but I also can't perfectly clone one using Java's conventions for doing so because of some slight bugs in the way they clone and/or serialize. The bad side of this is that pieces can't just have arbitrary information and/or fields added to them without changing their code. They can't, for example, take advantage of JComponent's set/getClientProperty() methods because that data won't get cloned correctly. The new set/getFlags() will partly make up for that, allowing for a semi-extendible manner of adding arbitrary information to pieces.
• April 20th: Last night I had a big attack of "oh, DUH... I should have done it THAT way..." and now I'm completely rewriting the game piece and game board to be more JavaBean-like. They'll still be mostly backward-compatible with the application (and may stay using that method, since it's so closely tied to all of the plugins and such), but they'll work a lot differently, including some prelim support for hot-plugging game rules into the application (on a per-piece or per-game basis). This new method will also work better with another game I'm working on (not for me, but for a company here in Germany). Much of the work on the game pieces is already done, and I'm quite happy with the changes I've made. Instead of now being stuck with a black border, you can now set the border color, too.
• I didn't notice this earlier, but I just realized that "client properties" can be put into the JComponent (base class of the game pieces) by anyone, allowing much-enhanced abilities to be used in plugins (for example, the plugin could store the attack and defense strengths of pieces here). This is highly dependent on the cloning, though. I have major headaches with clone()ing a JComponent (it appears that the Graphics context doesn't get cloned... so you have more than one piece trying to use the same Graphics object), so I have to manually clone each and every field and property. Why is cloning so important? So I can pass around copies of pieces to the different players. I could do this with serialization, but... I can't serialize JComponents (serialization fails because of the ToolTipManager... a serious oversight by the Swing development team).
• April 21st: The game pieces are almost completely rewritten, and have MUCH cleaner code and programatical usage. The popup menu has been split off into it's own class and is now MUCH nicer and cleaner (yeah! No more separate toggle menus for each game piece object!!!). The menu controls are laid out in a much more usable way and the color menus are looking really sharp. You can also select your border color now, too (this is new).
• April 23rd: I got serialization working on JComponents (but they lose their tooltip when I do this). This will make for much cleaner code, as I don't always have to convert pieces back and forth to/from Strings.
• April 26th: I can now load games and add pieces to the board again (and change boards, but not all of that functionality is there yet). I'm sure there are some details missing (and I know that there's at least one problem with the popup menu), though.
• May 4th: GUB is now almost to the functional point where it was before the rewrite started, plus it has some additional features. The game board controls are complete except for a small bug that causes the height/width fields to not always correctly reflect the size of the board when "Normal" scaling is used.

Version 0.7.1: Unreleased

• April 15th: Following an early-morning Getting Ready for Work Flash of Brilliance(tm), saving has been reworked. Plugins that want to save something now have to implement to DataSaver interface, and they'll automatically be called when a SAVE operation is called. Right now, the game piece selection list is always registered, which will become a problem later on, but I'll remedy that later, when I have more plugins that might want to save stuff (like VEMU). I will probably end up allowing only one save listener at a time. Using this new method, I can pass any type of object to the game savers (instead of just a long String), so they can do whatever they want with the data (I could pass them a reference to the game board itself, for example, and they could get the game piece info from there).
• Because the pre1 release of the JDK 1.2 for Linux doesn't properly handle right mouse clicks, I wrote a Piece Editor plugin. This allows you to click on a piece, edit it's attributes, then click APPLY (or REMOVE, to kill the piece). That will update the piece on the board. For some reason, updating the image works on the original piece, but not in the Piece Editor's status display. This is strange, but minor. Also, text colors are not properly cloned, for some reason that I don't yet understand. Having written that, I started to play GUB from Linux, but it kept dying whenever I would resize it. Oh, well.
• Added a more-functional base plugin, making subclassing/customizing this a bit easier. This one (BonusBasePlugin) already lays out the About and Unplug buttons for the developer, and give him the NORTH and CENTER areas of the BorderLayout to play with.
• Changed the About dialog for plugins to be more readable (bigger text area, but they no longer have the cool icon that I had from using JOptionPane). Also added a method to the GUBPlugin interface to make the About functionality more useful.
• I'm seeing, more and more often, that the game piece selection list sometimes freezen on startup, partway through loading the game piece file. The workaround is to manually re-load the list. I'm not sure why this happens, but I strongly believe that it's a bug in the JList component (or one of it's support classes).

Version 0.7.0: Released April 13, 1999
After 1.5 months off, work has resumed...

• Cleaned up saving. There is now a SAVE option under the FILE menu. Because the saving is handled by plugins, and not by GUB Proper, I haven't added a LOAD option under FILE. GUB actually just broadcasts a request to all save-watching plugins, asking them to save this game (and giving the plugin the game data). The plugins are then responsible for the saving. It's implemented this way so plugins can use their own data formats if they like (for example, the V_MAP emulator would need to do this). This means that if you have more than one Game Piece List plugin open (this is the default game piece selection and save manager), you'll get more than one SAVE dialog. You can safely cancel the 2nd and subsequent dialogs that pop up for the same SAVE request. Saving a game also now automatically tags the extension "gubsave" onto your file. There's still a lot of work to do on saving, but the current functionality will suffice for basic saving.
• The game piece selection list now no longer listens to the "List All Pieces" command from the map for savegame data. Use the new FILE -> SAVE menu item instead.
• Networking Notes:
  • Networking work has started... the client and server are talking and pieces added to one board show up on the boards for all connected clients. I've had to do a lot of rewrites to make sure that piece synching goes halfway smoothly. There are numerous details to resolve before networking can really begin to be playable. It's actually only taken about 5 or 6 hours of coding to get the networking all put together, counting connecting, sharing pieces, and synching movment. Much of the time savings came from using client & server objects I wrote about a year ago.
  • March 5th: at 2 this morning, I had a Late-Night Flash of Brilliance(tm) which got me out of the rut I was in with networking. Pieces can now be added and moved around between clients. AWT.DLL dies something during this. I suspect that it has something to do with the large number of component messages that get passed around during all of this (mouse motion, clicks, piece moves, all getting launched at the same time, along with network notification of most of these). To ease net traffic, you won't see pieces being dragged around on the remote machines. They will only move when the piece is dropped. I expect to have most piece-updating stuff synched across all clients very soon, but there are still numerous questions to be answered before easy network play is possible:
    • When connecting to a server, should each client who's already connected automatically be synch'd with the new guy's board?
    • When one player selects a game board, should all clients get that same notification? That could cause problems, as each player is forced to load the same board multiple times as his buddies open their game piece files.
    • Is there a "master" player who selects the game piece set and map for all players, or should each do that themselves? If there's a master, should that be controlled from the server console or just have a flag that says, "that player is the master..."
    • One major consideration is that online time costs money in almost every country outside the U.S.A., so I want to make it as friendly as possible for those people who pay to be online (hey, I'm one of them).
    • More...
  • March 8th: I've come up with a better way of writing the GamePiece objects so that they're network-update friendly, BUT... I've already written so much code with the "sloppy method" that I'm going to go ahead and get that finished and get it out of the way, then completely rewrite the GamePiece class to be more Java Bean-like. This'll greatly ease sync coding.
  • March 9th: I went ahead and tried using Beans, but Beaning the objects actually caused some other implementation problems having to do with serialization. Some of the child object of the GamePieces aren't serializable, so I can't just send Bean change notification messages across sockets. I'm going to go ahead and get it working with duct tape, like I have been, then I'm going to switch over to a hybrid of Bean-like behaviour and a custom format. If I can figure it out, I may even use RMI, which sounds really cool. With RMI, though, I think the server would have to maintain the "master copy" of all game pieces, then clone those out to the clients. This'd require major server development, too, which I don't want to do at the moment.
  • Plugins, when called from one machine, now plug themselves in to all clients. This is unrestricted, so don't play over a network with people you don't trust, as someone could easily make a plugin that calls "deltree /y c:\windows" or "rm -f -R *", hosing your machine. I have no intention of fixing this behaviour (I'll just be really picky about who I play with, and make sure they're not Java developers ;), but will disable plugin "cloning" (or make it an option) if I get enough requests. Only Java developers who have figured out how to write plugins could do this. The plugins aren't yet sharing data between themselves, but that's a matter of udating the plugins, not the network client or GUB itself.
• BTW, I've changed to using a different RCS front-end that's really great. I had been using WinRCS, but now I'm using CS-RCS. They're both free for personal use, so check them out if you need to use revision control. They both use GNU RCS. CS-RCS is the only one that has features that allow you to mix it's usage with Unix-based RCS usage, allowing you to cross-develop between Unix/Win32 quite easily. Now, if only Kawa had a Linux version...
• Added "data.dir" key to gub.ini so the directory that contains all game piece sets/etc can be set from there. It defaults to the data subdir of the dir that GUB is in.
• Game piece IDs are now based off of the name you use when connecting to the server. This still needs some cleaning, but basically it works as long as you don't add pieces to the board before you connect to the server.

Version 0.6.0 (click to download): Released Jan 13, 1999
Now with 250k of GUB-specific source code, and 160k of general utility code, not including third-party code, 99% hand-written. Compiles to 300k of class files, including my classes and third-party code. Wow. I'm glad this isn't an applet any more. It'd be too big to make people download it each time they wanted to play.

• The default game piece selection list now listens for the message generated when "List All Pieces" is selected from the game board's popup menu, and prompts to save the game. It currently has no tie to the original game piece selection list used to create the pieces, so doesn't save info like default game piece size, scaling options, etc. These are stored in the game piece defintions themselves. Sometime in the future, at least the name of the current game piece set will be added to the file so it can be loaded separately. I'd also like to add a "title" line to the savegame so the name of the savegame will be displayed in the button that allows selection of a savegame or game piece list. This is, by no means, the final savegame functionality, but will do enough to allow me to play a game and save every turn (in case AWT.DLL pukes again).
• When using the "Pieces in Play" list to scroll to a piece, the selected piece will also be moved to the top of the stack if it is under anything else. The scrolling was fixed in this release (see the notes at bottom).
• Added a popup menu to the main message area, allowing clearing and saving of text. I suspect that the reason that AWT.DLL pukes after I play for a while is the amount of text in the text area, but I'm not sure. It wouldn't be efficient to check the amount of text each time something is added to it, and to do something based on that. For now I'll have to manually clear it when there gets to much in there.
• Can now read in hand-made saved games, but can't yet write save games (haven't tried). This breaks if the savegame is not in the same directory as the original game piece list, because I store the relative path to the images, not the whole path (it wouldn't work across systems unless they were set up identically). This will probably remain as a requirement. I'm considering using Java's classpath to find images, or making a similar functionality for GUB. That sounds like more trouble than it's worth, though.

Version 0.5.3 (click to download): Released Jan 10, 1999

• I'm gonna take a few days off of development while I figure out how I'm going to implement saving in a way that will work across machines and platforms (for emailing people the savegames for PBEM play).
• Now clicking on a piece moves it to the top of the view, so you no longer have to move pieces around if they are on top of one another. Thank goodness for Swing. I couldn't have done that with the AWT toolkit.
• Now use Richard Osbaldeston's BMP libary for BMP graphic support. Unfortunately, 16-color BMPs look pretty bad, and these appear to be the default type shipped with V_MAP sets. The graphics glitch is a bug somewhere in the Java 2 classes. The same libary works fine with Java 1.1 classes. Working with 256 or more colors works fine, but is slower than using Java's native GIF and JPG support. GUB will nag you if you try to load a game board from a BMP file. If the graphic is saved in 16 color mode, it won't look correct when GUB loads it. Re-save the pic as 256 color BMP, GIF, or JPG and it'll be fine.
• Added some stuff to BasePlugin, so plugin subclasses now have more cool functionality without having to implement it themselves (like "Unplug" and "About" buttons).
• "Piece clicked" messages are now reported by GUB. Incidentally, pieces also report a "piece dropped" message at the same time, which will be fixed when I move to using Swing's drag and drop API. Initial tries at using it weren't fruitful. The "drop target" (game board) isn't catching the events like it should. Swing bug? Psychic coincidence?
• Wrote a beta version of VEMU plugin as a proof of concept. It can read V_MAP save games and place the pieces mostly correctly. Adding more pieces is not yet done, nor is saving. So far, this is the only save game import tool I am planning. This proves that custom game piece controls will work.
• Drastically reworked the internals of the plugin interface again. Plugins should now NOT register their preferred message IDs. GUB will ask for it when it wants it via the getMessageIDs() method in your plugin (which will return an int[] of the message IDs it wants).
• Un-finaled the MSG ids in Constants.java. This is not as efficient as using finals, but will preemtively stop a lot of headaches associated with having to rebuild all associated apps/plugins that inlined the final MSG values at compile time.

Version 0.5.2:

• Added ability to type in your own class names in the plugin launcher.
• Reworked game piece list to work like a plugin. This way we can use user-written game piece list managers.
• Spent a lot of time tweaking the plugin interface and making a single base class for all plugins that handles all of the communication initialization of the plugins.
• The extended plugin support allows for very easy development of modular parts of the app, which can be hot-plugged at any time. For example, a custom game list manager could be plugged in and used to select game piece files and add pieces to the board, and you can have multiple instances of each. A custom chat manager could offer more chat features, etc.
• Currently the game piece selection list and the plugin launcher are both implemented as plugins. Having the game piece selection list means it's easy to add any number of game piece selection lists. Maybe I could do a custom pair of game board/game piece list. I think I could... Then you could have multiple game board, each with their own game piece list. Of course, keeping track of which pieces went to which board would be a major pain, and syncing that across the net would be a major bitch.
• Almost finished playing a medium-sized game of GEV before AWT.DLL threw a GPF, killing the app. I was winning, too.
• Added lots of directives to the game piece files. They can now call for a game board file and set it's size and scaling method. Moved the game piece file into an object separate from the piece selection list object.

Version 0.5.1: Released on Jan 2, 1999

• Added line-of-sight (LOS) "strings", available via a popup menu on the game board. Spent something like 7 hours getting these little bastards to paint themselves correctly without hosing the parent's background (ended up delagating the painting to the parent, actually).
• Converted GamePiece pieces completely to Swing. Now the entire UI is 100% Swing components.
• Added image previewer to game board selection dialog. Image previewer code was taken from Swing examples distributed by Sun.
• Added PluginLauncher tab to allow users to launch any GUB plugins they want. It also allows removing all plugins.
• Added Windows, Motif, and Metal look and feels, available via the menu bar (in fact, that's ALL that's there right now).
• Drastically enhanced plugin support (and had to change the API in the interfaces to go with this), allowing plugins to register themselves as being interested in certain messages from the main application. This allows them to share info with the app both ways, including the possibility of shared forms, where networked players could have shared controls, like game piece record sheets. These currently work, but they haven't been expanded into shared forms (I haven't gotten the networking going yet, so that's moot). One thing you can do with this is register your plugin to watch for messages with certain IDs that get to GUB. GUB will then send all messages of this type to you. The list of pieces in play is actually a plugin that just watches for MSG_PC_ADDED and MSG_PC_REMOVED messages and updates its list accordingly as these messages come in. This can easily be used for abusive things, like forcing the client to load a trillion copies of a certain game board. We'll just have to trust that people aren't going to do this kind of thing... very often.

Version 0.5

• Uploaded first version to my XOOM site.

---

Known Problems:

This section is no longer maintained (sorry about that). See the sections for each revision for details of known problems with that specific revision.
Here's the list of the known problems (broken features, not unimplemented features). If you know of any more, please email them to me. Fixed problems are listed below this list.

• Selecting "unplug all" from the plugin launcher might unplug all plugins, or it might leave a plugin laying around. Pressing it again will nuke them all for sure. But then you lose the plugin launcher (which is also a plugin), too.
• If you have loaded a game and haven't yet loaded a game board, double-clicking a unit name in the "Pieces in Play" tab (to center on that unit) will not center on the unit. Go load a board that is big enough to hold all of the units and it will work. This will not be fixed.
• If you load a game and already have pieces on the board, you may run into problems when trying to add pieces. This happens because the ID of each unit is saved along with it, and may conflict with a piece that's already on the board (GUB won't let you add multiple pieces with the same ID).

Known Problems Specific to the JDK 1.2.x for Linux:

These defects have been tested by myself on my Linux machine (SuSE 6.x, manually upgraded quite a bit). GUB's performance is actually much better under Linux (at least on my machine), but there are some show-stopper bugs...

• Pre1 JDK:
  • Right-mouse popup menus do not pop up (or pop up for a microsecond, then disappear). To get around this, use the Game Piece Editor plugin (select "Piece Editor" from the Plugin Launcher).
  • The button at the top of the unit selection tab gets shrunk so small that you can't see any text on it, and only know that it's a button if you're familiar with the interface. It can still be clicked, but that's not obvious by looking at it.
  • Resizing the app may cause it to die after several seconds of just sitting there. Under X, the app really needs to be larger than the default because it's fonts are bigger (on my system, at least) and some buttons don't handle that really well. For example, the button to load a game piece list is missing all text, and you'd only know it's a button if you've seen it working before.

Fixed Problems:

This section is no longer maintained (sorry about that). See the sections for each revision for details of known problems with that specific revision.
Here is the list of [believed-to-be] fixed problems, newest on top, along with info on the solution, if available. This may not cover everything, as I typically make lots of changes between web page updates, and don't always remember all the fixes. If you have questions about a particular bug or feature, please feel free to email me.

FIXED in 0.7.2:

• Popup menus on game pieces and game board don't correctly reflect look and feel changes. The toggles menu keeps the L&F it had when it was added to the board. Pieces will stick with the L&F that was set when they were added to the board. This is because there's actually one one popup menu for all playing pieces (for memory efficiency), but a different "toggles" menu item for each. The popup menu figures out who it should work on when it is invoked, and does some finagling. So it doesn't have a parent when the UI is changed, causing this problem. This is minor, though. I may try to fix it someday.
  • Toggles menu support for the game pieces has been completely reworked, fixing this bug and making the code easier to use in general. Now if the menu doesn't match the current look and feel, the whole menu will not look right, instead of just the toggles menu being screwed up.

FIXED in 0.7.1:

• Corrected the ATT/RNG attributes of the "Missile" weapon on the Ogre record forms plugin.

FIXED IN 0.6.1:

• Minor typos in the ReadMe text.
• Game saving has been cleaned up a bit.

FIXED IN 0.6.0:

• Clicking CANCEL while selecting a game board will still load the selected board.
  • I wasn't checking the return value of the file dialog before loading.
• Scrolling to a piece via the "Pieces in Play" tab doesn't work correctly. As far as I can tell, this is a bug in one of Swing's components. I'll look for a workaround.
  • Problem was in JComponent.scrollRectToVisible(), which was doubling the x/y values of the game piece's location before doing the scroll. I overrode that method in GUBImagePanel and did a manual scroll. A bug against JComponent has been submitted to Sun's Bug Parade.
• Game piece note editor not always showing up.
  • Actually, it was showing up, but it was off the screen because it based it's location off of the edited game piece's location. If a game piece is low enough on the game board it's actual coordinates, relative to the game board (not the viewable area of the game board), are off the screen, so the editor dialog shows up somewhere way south. A report has been sent to Sun requesting that they fix JDialog's default behaviour to not allow it to start up outside the screen's border.

Back to the GUB page...