Archive for the tag: software

Java 6 Update 10: No Longer Just for Developers

Developer's Cave, Island Forge Comments Off
Sun has released Java 6 Update 10, with the primary goal of improving end-user experience. Java is a wonderful programming language and runtime platform for developing many types of applications. Unfortunately, running a Java application can be a stumbling block for end users, which, in my opinion, has been holding Java back from reaching its full potential. This update promises many welcome improvements to the platform.
Attention Alpha Playtesters: I'll be testing the new Java version soon, with the goal of officially updating the game's base Java requirements to this version. Playtesters are encouraged to try the new update and report any issues/improvements.
In the rest of this article, I give my two cents on Sun's approach to Java thus far, and examine a couple improvements I've been eagerly anticipating. Read the rest of this entry »

Software Versioning

Developer's Cave, Island Forge 2 Comments »
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.

Developer Question: External Content in Software Repository?

Developer's Cave, Island Forge 4 Comments »
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?

Read the rest of this entry »

World Rendering: Graphics Engine

Developer's Cave, Island Forge Comments Off
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.

Design Process

Developer's Cave, Island Forge 4 Comments »
I don't yet have as defined a game design process as my software process, but I've evolved a simple methodology for recording and refining my game design ideas. The technology needed is a pen, a journal, and a wiki. The process involves three activities: For one, I write down (with the pen, in the journal) every random gameplay thought, with little regard for feasibility or conformity to the rest of the design. From my technical background, I tend to auto-cull things that would be impossible to implement. From my board game background, I tend to prefer strategic mechanics, rather than fuzzy "wouldn't it be cool if" concepts. The second activity also involves a pen and a journal (I use the same one from above). The goal is to refine the random thoughts into coherent game mechanics. Terminology like "attributes" and "weapons" and their interactions must be defined. The goal is to draft and refine the game systems. The final activity, which I had underestimated, is concisely documenting the final game design. This phase forces decisions, exposing gaps and conflicts. If you can't play the game in your head from these designs, and design the software, then there is something missing. I've found that a wiki provides the best balance between formality and flexibility. All of these activities happen more or less at the same time. This is not a sophisticated requirements tracking system, and document versioning would be needed to coordinate design and software teams, but this works for my team of one. Overall, this methodology seems rather obvious, but it's important to be aware of the process, and write it down. Unless something is well documented, it cannot be well understood.

Design Progress

Island Forge 6 Comments »
After making some progress implementing new game features, I found myself leafing through my design journals to extrapolate the final design decisions. To solidify the ideas, I've spent a few days codifying the design in a wiki (DokuWiki with Dokubook template). Now I have a more rigorously defined design. There are still gaps (the 20% of the unfinished design mentioned earlier), but they are more clearly exposed, so I can code around them. The most fundamental design change is to the character attributes. From a gameplay standpoint, the character system should feel more "classic." Simply put, raise your attributes to become better at things. Strategic decision involves which attributes to raise, and what equipment best compliments them. From a technical standpoint, this affects many of the core content objects (characters, creatures, and items). The new attributes have been implemented, but not integrated with any logic that uses them. As soon as I can, I will release a new client, so Alpha playtesters can at least see the character changes.

Java Web Start: Antithesis of Usability

Developer's Cave Comments Off
Java Web Start should be a major benefit for Java application developers and, more importantly, end users. The JWS concept is simple: A configuration file (JNLP) sitting on a Web server defines how to install, update, and launch a Java application. At each launch, application resources are fetched, installed, and updated for the user as automatically as possible. Great concept, but the reality of Sun's JWS implementation is abysmal. End users are forced though a gauntlet of obstacles, in which any error tends to be catastrophic. Assume JWS is installed and browser integration is configured correctly for all browsers (a MIME type must be set up to launch JWS when a JNLP file is clicked). When a JNLP is first launched, shortcuts are installed on the user's desktop and in menus, as directed by the JNLP (barring some bugs). These shortcuts conveniently launch the application. However, there are several bugs against JWS in which these shortcuts become corrupted. The result is a cryptic error that implies the application is broken, which is enough to prevent most end users from using your application. The situation is not easily repaired (as discussed below). One such case prompted this article (rant): Upgrading from Java 5 to Java 6 caused all JWS application shortcuts to become broken. To correct the situation, users must find the JWS Viewer application. I couldn't find the shortcut in Windows, so had to run "javaws -viewer" on the command line. This could be a friendly viewer of installed Java applications, but is actually considered a sub-dialog of the hideous Java Control Panel, showing the JWS "application cache." The applications had to be removed, then the original JNLP link clicked to initiate a new installation. If the user cannot perform these steps, and does not know the JNLP URL, the error is unrecoverable. The same problem can occur in several other ways, such as renaming shortcuts, or making several JNLP changes. The end result is an error shown to the user, implying the application is broken. In all cases, JWS should be smart enough to detect the corrupted shortcut and reinstall the application. Instead, an exception and stack trace are shown to the user. This is a completely unacceptable scenario for the end user. Another problem occurs if the user saves the actual JNLP file locally, then launches from that file. Even though the JNLP has the full URL information of the application resources, JWS does not go to the source when the JNLP is clicked locally. Thus, no updates are ever discovered, which breaks the basic contract of a so-called "online" JWS application: the user will always have the latest version.Overall, Java Web Start should be redesigned to provide a robust user experience. Otherwise, I don't anticipate moving MMORPG out of alpha with JWS. An alternative is to simply create a launcher script (or Windows executable) that checks resources before launching the application. However, Java developers shouldn't have to reinvent this wheel. Resources: This bug should never have been closed: Sun Bug 6446676 This bug appears to replace the previous: Sun Bug 6563938 Similar broken shortcut bug: Sun Bug 6549428