The Chosen

I’ve had a lot going on lately and haven’t had much time to sit down and document my adventures, let alone sit down and actually write code for the RTS. Hopefully this will catch you up on what I have been working on for the past 2+ months. Progress on the RTS had slowed down mainly because I still had some legitimate doubts about the server-side code I was going to have to write to handle the enormous amount of data. I was sure that I could get something working, but instead of storing data in cryptic text files like I have done before, I wanted to try something entirely new. I had been looking into Java database clients (JDBCs) for a while but never had the real need to get one working, so this seemed like the perfect time to push my limits once again. In addition, the actual performance of my previous servers was severely limited because of the code structure I used, and it needs to be drastically re-designed.

Knowing that a major overhaul was gonna be necessary on my server’s design, I figured that now would be as good a time as any to design a new server structure that incorporated a complete database back end, as well as data protection and more sophisticated client management interface. Not entirely sure what would be necessary in the RTS database, I made the tough decision to put the RTS engine on hold while I dedicated my designing, coding and testing a completely new sever structure.

I started by once again trying to get a JDBC client to run, this time with the HSQLDB package. My past attempts at getting the JDBC working all failed miserably so this time I was absolutely determined to get it working. I sat down expecting a big fight to get it up and running and much to my surprise, this time it just worked. With very little fight at all I got a small test app setup and running just like I would like. After a very brief celebration, I began writing a new server.

While it would be nice to just be happy about the new server and start implementing it into the RTS, I would rather see the design tested in some working environment to ensure that this structure will, in fact, do what I need it to do. I eventually decided that I would use pieces of my old chess program to create a new stratego program to use the new server. The concept is an entire tabbed interface where users login, chat in the lobby, join as many games as they want, and play stratego with other players over the internet, with all the traffic running through my server of course. Most of the networking and database code is complete and working but there is still a lot that need to be fixed and/or improved in the client side code. As of right now, it is entirely playable but still has a few code bugs that need to get worked out, and some design issues that need to get fully implemented before I release it beta group. More news will be posted on FreshProgramming.com.

After returning to the RTS again, I decided that I would no longer live in fear of the major unit issues that I had run into before. When I last worked on the RTS I discovered that because I was using Java’s swing classes just for their mouse listeners, the class was running much more code then was necessary for my needs. For example, every time I would change the cursor, every swing child would automatically repaint, which was totally unnecessary because I am maintaining my own graphics engine. To correct this, and numerous other problems that were a result of using the swing classes, I changed the type of my base game object to no longer extend swing’s JComponent. I also went ahead and stripped out the old mouse engine which let windows control the mouse, and replaced it with my own. My new custom mouse engine allows me to much more control over what the mouse can, and cannot do. By handing all mouse movement from within the Java code, I can easily, and smoothly, lock the mouse inside the window making scrolling and other complex interactions much simpler.

With the new mouse engine I have added modifiers for numerous things that I could not have controlled before such as mouse sensitivity and also allows me to handle all mouse actions a new all in one procedure. Because the new mouse engine is running from within the Java I can directly what happens when the mouse is pressed and no longer have to worry about mouse listeners or which object is on focusable or anything else. With this great progress I hope do some more work with the units soon.

After adding Unit to the interface it became very obvious that something was wrong with the way the game objects network with game engine and all of the mouse and keyboard actions. When working to get the GUI interface to work, I struggled to find the correct setup that allowed mouse actions to pass into the frame but get caught before hitting the actual game engine. After finding a working scenario, I worked up a system to properly handle the actions caught by the GUI. Unfortunately, the current setup will not work at all with what I need to do with clickable elements that exist inside the game engine. Currently the units, which are extensions of the base game object, which is an extension of awt.Component, are attempting to maintain themselves in a variety of ways that are all causing issues with my current setup. For example, the source behind the moving lag is actually the result of the unit trying to repaint it’s self after being moved, which clashes with the existing graphics engine. In addition, because the scroll engine doesn’t actually move every element when scrolling the units move but the locations to click on them do not. Anyways, my first instinct was to create my own very stripped version of the Component, which would involve me writing all the back end code to handle mouse, and key actions. After some more thought I decided that I would first try creating a complete catch all object that would catch all the actions and just forward them to the main engine to be handed to by my code. Both of these solutions would remove the Component from the issue and leave me to handle all mouse actions, sending them to the appropriate units. On the positive side, once I optimize the entire engine I should much more control over which elements get tested for mouse actions, painting, and other general searches.

After conversing with my designer on Friday, and talking him into creating a GUI script file, I got got home, and before I could start I wanted to backup my current files onto my laptop just in case something happens.  When I plugged my portable hard drive into my laptop, very quickly it was brought to my attention that a few files were corrupt on the drive. Not too concerned because of the numerous backups I happened to have, I quickly tried to delete the corrupt files. After a simple delete failed, I then salvaged what I could from the drive, and reformatted it. Sadly the reformat only deleted my files and left me without a drive.  Because I had used the drive as a main work environment for use on multiple computers, I then found myself fighting with the corrupt drive all weekend and getting no real work done. By the time Monday had come around I had completely lost my train of thought on the GUI, and I decided to take a small break until a replacement hard drive could be delivered. In the mean time I will work on some more specific planning of how the several complex pieces of the puzzle will fit together.