This article covers a handy bit of logic to stabilize Java/Swing components that otherwise have annoying grow/shrink behavior. The (perceived) problem occurs when a Java/Swing application uses layout managers that obey internal components’ desired sizes. The layout shifts to accommodate internal components as they grow/shrink, which can cause much distress to the end user (at least it does to me). Read the rest of this entry »
There is now a mini-SLOC (Source Lines Of Code) graph in the sidebar. I generate this nightly from my software repository, using custom scripts and tools.
If there’s anything I like more than writing code, it’s simplifying code. At the leading edge of the SLOC graph, you’ll notice a massive drop from yesterday. Those 6,436 lines of code are attributable to Task#235 - Update towns to new designs.
The new design for towns and shops is much more traditional, in exactly the right kind of way. From a software and content development standpoint, it’s easier to work with and much more extensible. For Alpha testers, I’m gearing up for another update, which will feature a few of the latest design changes, including towns, shops, resources, and weaponsmithing.
Java interfaces are a wonderful thing; don’t get me wrong. However, many interface contracts make assumptions about how the implementation will behave. What is more, Java offers no way to programmatically enforce such an interface contract.
This article discusses a particular example of interface behavioral assumption and how to (partially) enforce the behavior programmatically. Read the rest of this entry »
Java’s enum feature offers a powerful language capability: compile-time type checking of constants. In addition, enum constants make code much easier to read and debug. However, an enum represents hard-coded values, requiring application recompilation/redeployment to alter.
This conflicts with the mantra of code design taught to me: “Abstraction, abstraction, abstraction.” That is, a piece of software should be as general-purpose as possible.
Take, for example, the Potential RPG game engine. I’ve designed it to abstractly support MMORPGs, allowing game-specific content to be defined in external data files. This often precludes defining enum constants where they would otherwise make good programmatic sense.
For example, my game supports a variety of shop types (weaponsmith, alchemist, healer, etc.). Currently, these are loaded from a definition file, rather than being hard-coded in the software. Adding a new shop type can be done without modifying the code… almost (read on).
What I’ve discovered is that new content still requires logic and GUI code to be written against it. Therefore, the game must be recompiled/redeployed anyway, so why not just simplify things and hard-code enum constants?
Ideally, I’d love to make the game engine 100% abstracted from content. For example, all content-related code should be isolated into dynamically loaded classes, referenced by the content definitions. While it’s just me at the keyboard, simplification seems in order. (Unless someone is looking to invest in such a game engine…)
In summary, depending on the requirements of your project, just use enum constants unless the level of effort is worth the design/implementation/maintenance overhead. (Hmmm … now I’m talking like a software project manager.)
While in grad school, I learned to use gnuplot to create line/bar charts. It works well for command-line scripted data processing, so long as you’re good at discerning arcane commands.
Looking for Java-based charting, I found JFreeChart. I’ve only spent a couple hours with it, but it looks to be an impressive library. It’s not simple, but appears to be well designed.
I hope to become more adept at JFreeChart. So far, I’ve only redeveloped my Potential RPG Source Lines of Code (SLOC) chart (originally processed by gnuplot):
Can anyone offer other Java-based charting library suggestions? Any opinions of JFreeChart? Read the rest of this entry »
This article describes a Java-related assertion failure apparently due to a recent video driver update in Debian (and Ubuntu). The assertion dumps a backtrace to the console, but the Potential RPG Alpha client appears to be otherwise unaffected.
The remainder of this article describes the problem and how to work around it. Read the rest of this entry »
This article presents a simple programming technique for ensuring Java Swing tasks are executed on the proper thread, while avoiding unnecessary delayed invocation. Read the rest of this entry »
Here’s a question for software developers out there (independent game developers and otherwise):
Is it best to keep external content in the software repository?
The previous article describes features of my world rendering engine. This article describes graphics engine techniques used to render the world. I highlight two competing approaches with which I’ve experimented.
The goal is to paint a picture of the world. This includes layers of terrain, characters, creatures, and other surface features, as well as special effects graphics. See the previous article for a small sample of the rendered world.
Under the hood, I’ve employed two approaches: (a) Off-screen, background-thread, pre-rendering vs. (b) On-demand, in-line rendering. This represents a classic memory-versus-speed tradeoff. Allocating the world image in memory, to be rendered by a background thread, should improve the speed of screen painting and overall client responsiveness. This is a theoretically reasonable approach, which is actually rather common (often used for double-buffering). However, the devil is in the details.
Due to Java’s painting architecture, my background rendering thread must be synchronized with Java’s painting thread. Ultimately, my background rendering thread becomes a tripwire to Java’s painting. (Tripple-buffering might overcome this, but would be memory prohibitive and even more complicated.)
The second approach embraces Java’s painting architecture, rendering the world on demand. Since all the painting calculations are now performed in Java’s painting thread, more careful optimization is needed to avoid stalling the application. Optimization adds complexity, but in this case I consider in-line rendering to be more straight-forward than off-screen rendering.
In my usual manner of over-analyzing and over-engineering, I’ve experimented with a hybrid approach. Terrain is pre-rendered off-screen, while characters, surface features, and effects are drawn on-demand. In this case, the Java painting thread still synchronizes with my background rendering thread, but is only grabbing part of the terrain layer, which rarely changes once drawn, thus avoiding the tripwire effect described above. This approach may provide the best of both worlds.
During alpha testing, I’ve tried all three techniques. The first technique is too cumbersome. The second technique is performance sensitive, but seems promising. The hybrid approach provides the best and worst of both worlds, at the same time solving and creating more subtle issues. From a software standpoint, I’d love to perfect the hybrid engine. Someday I will, but the on-demand drawing system is the simplest to pursue for my immediate needs.
From a performance standpoint, I do not have any hard statistics yet, but on-demand rendering seems to perform well on 5-year-old hardware, in Linux, in windowed mode (not full screen exclusive mode), with no accelerated hardware drivers. With further rendering optimizations and improvements promised for Java, my graphics engine should support Potential RPG and future projects.
Having never built a graphics engine before, I’ve found this to be one of the most challenging and interesting components of this project.
A big part of my Potential RPG project is to write my own software. I’ve spent a large part of my time (more than anticipated) developing the world rendering graphics engine. My personal goal is to increase my experience with graphics processing. My development goal is to produce a simple, tile-based rendering system, supporting some basic features.
Note: The rest of this article describes the current state of the graphics engine, primarily out of my own interest. Other software developer-types might be interested, too.
At this point, world rendering includes terrain tiling, avatar navigation, surface features, and sprite effects.
The engine can render either a rectangular or hexagonal tiled world. In either geometry the tiles can have North-South overlap, providing some basic perspective.
In conjunction with tiled terrain rendering, the engine can layer player character avatars, creatures, surface features, and effects atop the world. These features and effects can be static graphics or animated by the sprite driver.
Avatar navigation occurs on a rectangular coordinate system at finer granularity than the terrain tiles. This allows avatars to walk in natural N-S-E-W-NE-SE-SW-NW directions, rather than being tied to each hexagonal space.
While walking around, if an avatar becomes obscured by a surface feature (such as a tall tree), the engine allows the figure to be seen, as if through the obstruction.
This (very preliminary) image shows a small sample of the world rendering, with a character hiding behind a tree. The inset shows the minimap, which renders a larger geographic region of the world at a smaller scale. The minimap is actually drawn by the same rendering system as the surface, just with a smaller (one-pixel-per-coordinate) terrain tileset.
