 Yes, it's summer again in the Northern hemisphere and the temptation exists to do things besides code. Perhaps it's time to take a break when you look at 4th of July fireworks and think "hmm, that gives me a good idea for my particle system..." :) But I have indeed been coding, I'm already at around 30,000 lines of not-exactly-liberally-commented code. :( That's a scary thought -- our product at the web company I worked for was ~120K lines for 5-6 developers. I should probably take time out and clean up the loose ends (there are many) before I get too far. It's ok if you know where your weak areas are and document them as such; but if you're not really sure about the fitness of a module, best to give it the once-over. OpenGLOUT This is my acronym for "OpenGL Ordinary User Toolkit". (I actually forgot what the 'O' stood for, which lends me to believe I need to document my code more). It's a GUI system I'm making for the game that runs under Java and OpenGL. Here's a screenshot:  Due to the prevelance of really bad programmer art, it's kind of hard to tell what's going on here. These are overlapping windows with a little bit of transparancy, the big white pillboxes are buttons, and the green frame is a combo box with the pulldown shown underneath. The little white line on the right is a scrollbar. Anyway, making the UI toolkit was easier than I thought. I use sort of an AWT-like metaphor, in that I have components and containers, and everything is done through events. However, I do not have LayoutManagers like in Java, instead I specialize individual containers. For example, I've found most layout tasks can be done with GLOTableContainer, a container which behaves somewhat like an HTML table. Layout of a container is explicitly done by calling a layout() method -- which is sort of a pain, but allows for less surprises. It's very handy to be able to render the entire UI every frame -- instead of having a complex notification system to update certain widgets when certain things change, I am free to change any parameter at any time. So if the data in a list box changes, the changes are reflected immediately on screen. Things that I still have to tackle are keyboard input and the problems of "focus". A UI is a lot easier if you don't consider keyboards, but I think it's essential to make everything keyboardable in a complex game. Why make a OpenGL UI? There are several obvious reasons -- portability, ability to run full-screen, and "skinnability". Another is the coolness factor -- I mean, you can't tell a Windows dialog box to "rotate 720 degrees, turn orange and explode", can you? Not that I would do such a tasteless thing :) Java Doesn't Suck I'm now using Sun's JDK 1.3 + HotSpot, and it's faaaaast. In fact, I doubt that you could tell that my game is a Java app except by looking at the little coffee-mug in the upper-left corner of the window. GC pauses are not even detectable, and my frame rate seems about 20-50 FPS, depending on how many windows are open in my UI :) I try to get everything into display lists as soon as possible -- this helps take some load off the Java VM, and as a bonus, cards with hardware T&L will benefit. In fact, I'm considering releasing the game in Java, not converting to C++. I think Java is ready to play games now -- I wouldn't write Quake IV (or Doom III) in Java, but I think many slower-paced games would do well. I think it hinges on the memory usage -- a Java program is going to suck up more memory than an optimized C++ program. Of course, having GC makes it less likely you'll have leaks, so there's a tradeoff. I wish I could post a screenshot of the game-in-progress, since it does look a lot better than the UI shots would indicicate -- but I have more business-planning to do before I announce it. First of all, I need to decide on a name. I was thinking "Woodchuck Hunter 3". Oops, darn, gave it away :) 
|
