Potential Games

It seems that I’ve overlooked August. Actually, August was comprised of summer travel, summer activity, summer cold, and summer game design. Despite other activities, I’m really and truly making a push for complete and final beta-worthy game design. The game systems are now (on paper) simpler and more cohesive. The bulk of the design integration will be tweaks to existing Alpha code, but some new development will be involved. Consider the prior (current) Alpha release to be a palette cleanser. It’s now finally nearly time to implement Beta gameplay.

Potential RPG Alpha Playtesters (PRAPs) will find the Alpha v0.7 client and server have been deployed. Upon entering the world, enjoy the new terrain edging. You’ll soon notice the lack of much else in the world. I’ve disabled several components for pending gameplay improvements. Read the rest of this entry »

I’ve been so busy improving the game world that I haven’t even taken time to write about it lately. There are several significant improvements that are almost ready for Alpha testing. For the moment, here is a glimpse at a new rendering capability: Terrain Edging.

The world surface is composed of hexagonal terrain tiles, which, despite the elevation in complexity they incur, I’m quite pleased with in general. In practice, they do tend to create rather pointy, unattractive edges. The purpose of terrain edging is to provide visually appealing (see artistic disclaimer below) transitions between terrain.

Inspired by the article Handling Terrain Transitions, the world now automatically computes where to place edge tiles where terrain types meet. The system can support general-purpose edging for each terrain type, as well as special-purpose transitions from one terrain type to another. For example, grass edging may include general-purpose crinkly edges, but provide an embankment when next to a lake.

To make this work, each terrain type must include a set of edge tiles. More to the point, all the terrain and edge tiles must be drawn, preferably by someone with more artistic capability than myself. The screenshot shows the potential for terrain edging, but Alpha testers will have to tolerate my graphics until I can procure better art. (Note: Trees not drawn by me.)

As mentioned previously, my current focus is to prepare the game to support improved graphics. At this stage, I’ve adjusted the way graphics are managed by the game, making it easier for me to add new terrain and scenery (and soon, creatures, items, etc.).

Alpha Playtesters should read this forum topic regarding broken maps. Other than that, today’s Alpha testing release (v0.6.3.5) includes a few tweaks. There are likely some new glitches due to the new tileset system, so, as usual, have at it intrepid Playtesters.

Technical tasks have momentarily waylaid gameplay integration. I’ve restructured the graphic rendering routines to make the entire painting pipeline more stable and efficient. Instead of independent timers and redundant repaints, world rendering is now driven on a single timed thread, which carefully coalesces all collected dirty regions to repaint as little as possible on each rendering cycle. Most of the rendering cycle is no longer performed on the Swing/AWT event dispatch thread (only the painting portion), making the client more responsive in general.

The immediate benefit is a reduction in (complete removal of?) some avatar blips and jumps I was seeing during world navigation. Any remaining graphic issues will be easier to debug in the cleaner pipeline. The improved design will allow for future performance testing and tuning, as more sprites and effects are added. In fact, aside from general improvement, the motive for these updates is to begin a graphics enhancement process, which will finalize the handling of sprites and effects in the rendering system, allowing integration of better graphics, with the goal of providing a richer world environment.

I was just perusing the Java source code (because I don’t read the morning newspaper), when I discovered that java.util.LinkedList.clear() is implemented to operate in linear time. The documentation does not specify its order of growth, and I intuitively assumed that a linked list clear implementation would be a constant time operation.

Could this be an artifact of early Java development, leaving a legacy of poor performance? The remainder of this article explores the potential to significantly improve application performance when using the LinkedList.clear() operation. Read the rest of this entry »

Gameplay integration continues. Alpha testers will see a timed task queue pop up upon certain actions (such as drinking potions and changing equipment during combat). This functionality provides the game engine with the capability to coordinate character actions based on situation (such as combat) and game rules (such as attack speed). Actions that result in lingering effects (such as potions, spells, and afflictions) show how long they will last.

Under the hood, character navigation and combat attacks are also integrated with this timing queue. As more rules are integrated, this will allow the player better control over the combat situation. The goal is to ultimately provide a more strategic combat experience. Until then, Alpha testers can have fun attempting to break the new feature.

I’ve been taking some time to solidify the game design. Alpha Playtesters will start to see incremental updates, as I integrate the latest gameplay decisions. Some simple adjustments have rather fundamental impact, such as altering character ability computations. In addition to these enhancements, there are a number of new gameplay features in the pipeline. The goal of this next wave of updates is to bring Alpha a significant step closer to a feature-complete Beta.

First: Unless you’re a Java developer who enjoys weekend threading and locking studies, don’t read this, unless you want your brain to melt. I’m primarily writing this for my own sake (because I am a Java concurrency junkie).

Second: There is nothing wrong with LinkedBlockingDeque. It follows all the proper behavior of a concurrent collections class (of which I’m a big fan). The situation documented here boils down to a classic concurrency scenario I simply didn’t take into account.

The Exploit: The impact to my MMORPG was that a player could force his/her character to translocate over stretches of non-navigable terrain, such as bodies of water. This would constitute a major exploit. To add to the mystery, it only happened on my development platform, not on the alpha testing network (even over the same LAN). Read the rest of this entry »

Working on my own requires me to run the gauntlet of software development. The process exposes personal and professional strengths and weaknesses, which I believe are difficult to discover in a corporate environment. An employee’s job title tends to become a shell, which can be difficult to break out of. Being responsible for every aspect of this software project (not to mention starting a potential business) reveals where I thrive and where I am lacking in experience.

Since nautical analogy is always the best way to describe a complex situation, consider the software enterprise as an 18th century ship-of-the-line. Read the rest of this entry »