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 returning to work on the RTS I decided to start by fixing some the problems that were on my mind. I knew the major painting problems needed to be fixed soon, but I decided to first start by working on new cursors, and a completely new mouse management system. In previous versions, to achieve cool cursors I simply just changed the current windows cursor icon to one of my custom cursors. The new system I have put in place is completely new and different. In addition, to solve the issue of the cursor leaving the screen when I didn’t want it to, I decided I would lock the cursor in the center of my application, and let my graphics engine render the cursor. With the windows cursor locked in the center of the application, i simply measuring the distance traveled and on each move and adjusting the rendered cursor location accordingly. In addition, I replaced the windows cursor with a transparent image, so the windows cursor is completely unnoticeable and the user never even imagines that the change has been made.
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.
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.
A few modifications to the graphics engine to separate floor tiles from unit tiles, and also down-sizing the current units (the black circle placeholders). This running version also had some minimal graphic clipping around the edges of the screen but painted only the 250 or so visible tiles and not all 10,000 of them. Unfortunately, the modifications I made to achieve this smaller painting area were overly simple and will need to be rewritten before the graphics engine can be considered “done”. The keystroke engine on the other hand has been applied and is remarkably smooth. So far the graphics engine, mouse engine (scroll engine), and keystroke engine are all running very smoothly and still using very few CPU resources. I hope that remains true after the more complicated engines have been written, such as the pathfinding, A.I., or networking engines.
