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.
