The Chosen

Well, the bad news is, this project is not currently my top priority so it may be a while until I get back to working on it full time. The good news is, this project still has a special place in my heart and I still spend quite a bit of time thinking about it. Even though this is not my top priority, I still have found some time to do some minor coding on some of the smaller features.

I have added unit order queuing and some simple code to show those orders so now the units can be moved through multiple waypoints effortlessly. I’ve also added the distinction to separate your units from enemy units, and adjust the cursor icon as necessary. This also includes code to prevent you from moving or mass selecting enemy units. I haven’t incorporated actual teams yet, which will allow for allied units that are not yours to control, but not enemies to attack, but that will be the next addition. I’ve added some minimal code to link the GUI to the action by showing the currently selected units in the bottom left of the screen, giving a count for each unit type and listing every unit. I’ve added code to allow the game to be played at any resolution, and even full screen, but for now the game will remain at a constant windowed size. I’ve added a splash screen. Recently, I’ve added the text display part of the GUI that will inform you of unit completion or base attacks. This has all been added and tested but still needs a little tweaking and I will probably incorporate much of it into the current scripting system, but that’s a task for another day.

All in all, I am bummed out that I can t spend much more time on this, but it does give me something to look foreword to when I finish the other projects I’m currently vested in.

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 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.

Whenever I start a project like this, I also try and identify all of the possible problems, and troublesome issues first. Long before I start writing any code that will end up in the final game, during the first design meetings, I isolate each issue, either mentally or in actual test code environments, and make sure that the design concept is possible, and within grasp. This project was no exception, and I wanted to make sure I knew what I was doing.

(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…)

After finishing the first admin panel I was ready to start creating a database for my RTS. Using the picture table editor, I created a small picture listing and saved it out in text file form for lookup by the actual game. Next I simply copied the code from the admin panel to load the text and build the picture database in the RTS. After loading the database, the RTS now uses a name reference to look up any and all pictures in the database for painting. Once again, having all of the pictures in one database ahead of time allows me to pre-load and pre-render each image, which should hopefully help to reduce the initial stress of loading the game and its engine.