The Chosen

The whole reason I had to design and implement a new mouse engine was because the addition of units before was seriously conflicting with the old mouse engine. With this new mouse engine working perfectly in the RTS I was then free to change my focus back to the units. Before this big haste, I had units, and they were clickable, and even movable. Of course all of this fancy movement was a direct location change and not a fancy, slow, speed based movement, and all of the selection and move orders only worked at the origin view location. Basically, interacting with units didn’t work after scrolling and the movement was actually more like a teleport. However, all of that has been changed now. (more…)

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 months of coding and design, the game is finally taking shape as I can now handle units on the screen. I put several finishing touches on the selection system and the scroll system to prep the RTS for another build. Also I have recently added numerous new script variables to a root script file that allows my other developers and I to very easily tweak the code before it runs. I added script variables for screen size, tile size, an array of GUI/mouse interaction variables, nearly all variables involved in the scroll system, and even variables to set preferred frame rates in the graphics engine. I am still amazed at just how helpful these script variables can be, and how they make the designing of the game much more simple and enjoyable.

(more…)

Finaly I’m done with the scripting portion of the GUI. Though I’m sure that I will need to modify a thing of two as I start witting other code to interact with the GUI, but still it feels like a big accomplishment. While finishing touches on my script code for the GUI, I was also working on the cursor animation engine which is also up and running beautifully. Sadly, because the cursors are automatically removed from the screen shot, my cool animated cursors don’t appear in the picture, but I assure you they are very cool. In almost no time at all, after minimal explanation, I was able to hand off the script files to my game designer and he was able to construct his own version of the GUI as seen above. He was also able to modify the new cursors file, and using a constant code base, work with multiple new cursors and see how they looked in the real engine. Before I knew it, he had completely redesigned by default test GUI (bellow) into something that looks much yet functions exactly the same.

(more…)

After completing the scroll engine, and implementing a working pause system, I found myself at a decent stopping point to take a break and collect my thoughts. However, I found that I was very pleased with the progress so far, and after a brief break, I jumped back in by working up a list of tasks, that still need to be done. I knew that there was still a lot to do, but apparently it may still be a while before official version 1 is released. I knew that eventually I would have to to do some serious optimizations to the graphics engine, but decided to put that off for a while longer to see how long I could live with the simple version. The actual task list proved to be more that even I remembered. (more…)