The Chosen

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.

I knew that clickable units would brighten the spirits of my anxious audience, so I made that my next goal. However, as a programmer, I knew that implementing the unit selection system could be much easier if I had a visual representation of which unit(s) were selected. To represent this status I would need a graphic user interface (GUI), which meant that before I could add units, I needed to design and implement a GUI. The actual GUI layout was one of the many details that me and my designer argues over for quite some time. To settle this debate I decided that I would write the GUI using a my scripting engine, which would allow any user to customize the GUI any way that the user would see fit, the better way of course would then just be the default version. During initial talks, this process sounded pretty strait forward, and it it seemed like just a matter of time before it was done. Once I started work on this feature, I soon ran into several issues. (more…)

Despite many initial bugs, and almost a month of procrastination, I finally sat down and devoted myself to fixing numerous mouse related bugs, and writing the majority of the mouse scrolling system. After several bugs were identified and corrected, the rest of the scroll engine went rather smoothly. While I was able to somewhat lock the cursor within the window, the execution was done in such a was that left me (and other testers) dissatisfied. To improve this environment I decided to try a slightly different approach. (more…)

To achieve this screen I had to write an ImageStore class to handle all of the pictures. This class efficiently pre-loads and pre-renders each image before it is actually painted by the graphics engine.