Potential Blog

Just a couple notes for Potential Playtesters… Read the rest of this entry »

I’m trying to settle on a sensible software versioning scheme for Potential RPG. The most familiar structure is X.Y.Z, which I’m calling Generation.Feature.Incremental.

The generation is the major version of the software. A feature release indicates the completion of a set of available features. Incremental releases may include bug fixes and enhancements, as well as new features that might not be fully integrated or ready for a feature release.

Incremental version numbers are treated as steps toward the next feature release. The test environment (including Alpha testing) should see all incremental releases. However, the production environment (when there is one) may skip some incremental releases, but should see all feature releases.

In practice, this versioning plan may be too linear. For example, a bug that affects the production environment may need to be fixed before any next release is ready. What is more, the latest incremental release may include features not ready for the production environment. Branching is the revision control mechanism that deals with this, which must be accounted for in the software development process and release management scheme. For Potential RPG, I will probably resort to a fourth patch level version, indicating something was fixed outside the mainline of development.

In addition to the software version number, I also include an edition (”Alpha3″), which is a marketing version name, the repository revision whence the product was built, and the build date/time.

Here’s a handy article on retrieving the Subversion revision from within your Ant build script. Anyone with further advice/insight into the exciting world of version management is encouraged to comment.

I am proud to announce the Potential RPG Alpha3 edition! The focus of Alpha editions is to introduce gameplay features, bringing us closer to a feature-complete Beta edition. Alpha releases are for approved playtesters only, but steady progress is being made toward a more open Beta edition.

Some of the outward improvements in this edition include:

• Walk-behind surface features
• Terrain edging
• Zoom in/out world view
• New Town & Shop design
• Enhanced Weaponsmithing
• New Skills system
• Sprite animation
• Resizable client

This edition theoretically fixes several bugs and performance issues, but Alpha playtesting is greatly needed (and appreciated). If you’re an Alpha playtester, have a look at the new gameplay (and have a look at the outstanding tasks).

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 »