Potential Blog

This article describes an interesting design pattern that I utilized in my Potential RPG code. The following describes the pattern in general and how I’ve used it in my code. Has anyone seen this pattern in the wild? Does it have any other common forms or names? Read the rest of this entry »

All the tasking for Alpha4 is complete (… or brushed under the rug of a later release). Alpha Playtesters are invited to read the details, then try it out.

For Alpha playtesters, I’ve posted an incremental release (on the roadmap to Alpha4) with some important enhancements to island building. See this playtesting forum topic for details.

I’ve been coding furiously since … well, since 2005. Over the past week, I’ve implemented the steepest spike in the project’s SLOC History.

Posted this morning, Alpha3 v0.3.1 is an incremental release on the roadmap to Alpha4, introducing Player-Created Islands. There are some known issues and limitations, but basic functionality is testable. (This is the secret alpha bonus feature mentioned earlier.)

Disclaimer: I’m not promising how this feature will manifest itself in the final game design, but I’m very excited about the potential.

Alpha playtesters should see this forum topic for details on testing the new feature.

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.