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.
I’ve had a lot going on lately and haven’t had much time to sit down and document my adventures, let alone sit down and actually write code for the RTS. Hopefully this will catch you up on what I have been working on for the past 2+ months. Progress on the RTS had slowed down mainly because I still had some legitimate doubts about the server-side code I was going to have to write to handle the enormous amount of data. I was sure that I could get something working, but instead of storing data in cryptic text files like I have done before, I wanted to try something entirely new. I had been looking into Java database clients (JDBCs) for a while but never had the real need to get one working, so this seemed like the perfect time to push my limits once again. In addition, the actual performance of my previous servers was severely limited because of the code structure I used, and it needs to be drastically re-designed.
Knowing that a major overhaul was gonna be necessary on my server’s design, I figured that now would be as good a time as any to design a new server structure that incorporated a complete database back end, as well as data protection and more sophisticated client management interface. Not entirely sure what would be necessary in the RTS database, I made the tough decision to put the RTS engine on hold while I dedicated my designing, coding and testing a completely new sever structure.
I started by once again trying to get a JDBC client to run, this time with the HSQLDB package. My past attempts at getting the JDBC working all failed miserably so this time I was absolutely determined to get it working. I sat down expecting a big fight to get it up and running and much to my surprise, this time it just worked. With very little fight at all I got a small test app setup and running just like I would like. After a very brief celebration, I began writing a new server.
While it would be nice to just be happy about the new server and start implementing it into the RTS, I would rather see the design tested in some working environment to ensure that this structure will, in fact, do what I need it to do. I eventually decided that I would use pieces of my old chess program to create a new stratego program to use the new server. The concept is an entire tabbed interface where users login, chat in the lobby, join as many games as they want, and play stratego with other players over the internet, with all the traffic running through my server of course. Most of the networking and database code is complete and working but there is still a lot that need to be fixed and/or improved in the client side code. As of right now, it is entirely playable but still has a few code bugs that need to get worked out, and some design issues that need to get fully implemented before I release it beta group. More news will be posted on FreshProgramming.com.
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. Read the rest of this entry »
While the new mouse engine did fix countless obvious bugs and prevent lots of future headaches, that’s not to say that it didn’t come with a few bugs of its own. To start, because the new system was repositioning the now invisible mouse cursor to the center of the screen, it had some issues that arose whenever I would try to move the window from its default loading location. I also have to convert all of the old mouse action code to flow through the new mouse system. In addition, because the new mouse engine locks the cursor inside the window, i added a procedure to unlock the cursor when pause to allow the user to exit the exit or perform other tasks when necessary.I also fixed a bug that popped up that was throwing the scroll engine into overdrive ever since I started painting the cursors with the graphics engine. After finishing all of that, and finalizing the new mouse engine I made one final change and fixed some of the liking for use hovering and mouse cursor sensors to show off some of the new cursors. At this point the new mouse engine and taken the full load and has completely replaced the stock old one, which leaves me with no other choice but to move on to bigger and better, and cooler tasks.
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.
When I came across the recent problems in my RTS, I knew they would delay work on the project as a whole, but I underestimated their full mental effect on the developers. My designer thought I should take this chance to further explore the complexity of how a game server will work. Even after re-writing almost my entire chat program to use dynamic socket connections, my designer still doubted the possibility of getting this whole project playable online. As he requested, I put the RTS on hold and shifted my attention to a new project, a small 2D TDS (Top Down Shooter) designed for 8+ players at one time across the internet.
