Potential Blog

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.

There have been no posts for a while, as I have retreated to my cave of solitude to contemplate game design.

I’ve found game design to be more mentally exhausting than software development. When building software, my mental process is all about separation and isolation of responsibility and functionality. The computer science terminology is high cohesion with the pieces loosely coupled.

Since my mind is wired this way, I naturally apply the same process to game design. That is, I try to break down the overall gameplay into small, independent components. However, I’m starting to wonder if this is not entirely appropriate.

A game can be divided into sub-systems (characters, items, combat, etc.). Certainly they all play off one another, but I’m finding that I cannot design these systems with any degree of isolation. For example, weapons cannot be designed without considering the direct impact on both characters and combat.

Consequently, delving into game design requires a great deal of focus. The entire game system must be continually reviewed from top-to-bottom, while refining each sub-system. This explains why game design is so mentally exhausting.

From my software design background, I’ve become adept at breaking down large problems (this project, for example). With more experience, I expect to discover more mentally efficient game design techniques.

For now, I am left with these questions to ponder:

• Is game design a fully artistic process; something that cannot be engineered?
• What type of process do other game designers follow?
• In larger game studios, how is game design managed as part of the overall development process?
• When will my game actually be fun to play?

This article is mostly of interest to RPG Alpha Playtesters. Characters, creatures, some surface features (trees), and sprites are being painted as on-the-fly effects, atop the underlying terrain. The underlying terrain was still being background rendered to an off-screen image, rather than on-the-fly.

As a performance test, I’ve added an (internal) switch to paint the underlying terrain with the new effects system, short circuiting the (soon-to-be legacy?) background rendering altogether. The latest test release (labeled 2008-05-02-1442) renders the terrain in this fashion.

The concern is that the effects-based on-the-fly painting system will not be fast enough to handle painting all 256+ on-screen terrain tiles, plus surface features, characters, creatures, as well as other special effects sprites. Nonetheless, it seems to be working for me, on my non-graphics-accelerated Linux development machine.

There are some known issues and glitches. Items, towns, corpses, and other surface elements will not be drawn during this test (they’re still bound to the legacy rendering system).

The recent significant graphic performance improvement inspired me to tinker with a few new rendering tricks. Surface features (such as trees) now stand atop the underlying terrain. Characters and creatures
can walk behind these features. The goal is to provide a more dimensional perspective to the world.

For alpha playtesters: There are some known issues with the new feature rendering, but I’ve released a new alpha version anyway.

I’m often amazed how much processing can be performed in a few milliseconds, even in the face of sloppy algorithms. Graphic processing, on the other hand, seems to be another story. Any excess painting can be significantly detrimental.

For the record, I’m developing this game in Linux (Debian) with no accelerated graphics drivers, and I am determined for it to run well on my platform of preference. Sun promises a vastly improved graphic pipeline with its upcoming Java update release, but this only helps with DirectX in Windows.

It’s easy to unjustly blame sluggish graphics on Java or Linux. So far in my burgeoning graphics experience, I’ve found that performance problems invariably indicate that I’ve done something horribly wrong. Reading an article on Swing animation last week inspired me to vastly improve my graphic processing.

Without getting into the technical details (unless there’s an interest), the conclusion is that Java on Linux can certainly drive graphic content, as long as you’re meticulous in your implementation. While Java’s general software performance is exceptional, only so much graphic excess can be swept under the rug.

I’ve cleared out excess pages and swept some things under the rug. PotentialGames.com looks exactly the same, but information about the game is now found under Potential RPG (until the new name is revealed… read “decided upon“). Other resources (forums, wiki, task tracking) have been moved.

Alpha playtester(s) should contact their (his) nearest regional branch playtesting center supervisor (me).

Hear Ye, Hear Ye. By High Decree, the game shall be renamed! Huzzah! (No, that’s not the new name; that’s just an olde expression of exclamation.)

Until then, I’ll use a generic placeholder to refer to the Potential Games MMORPG. Portions of the site will be offline until relaunched. Alpha (Beta Beta) testing is paused briefly until relabeled.

For MMORPG Alpha (also known as Beta Beta) Playtesters, I’ve put out a minor upgrade featuring some combat tweaks. This does not yet represent the full MMORPG combat system, but some strides have been made in that direction. Particularly (for the curious), creature population processing logic, character navigation, and combat computations have been adjusted and improved.

What does this mean to you? If you’re a playtester, you’ll find you have an assortment of minor weapons to play with. Until towns are reinstated, there is no way to create any more. There is a population of weak Spiders to the South of Firsttown, which your default character is wildly overpowered to fight.

There are some gameplay limitations to be aware of for playtesting. As mentioned, combat computations are way out-of-balance (in your favor). Compounding the mass slaughtering this enables, corpses do not seem to decay properly. Consequently, the Spider Forest is littered with the crushed exoskeletons of vanquished arachnids. If you do find your hit points dwindling, the best way to replenish them is to die.

That’s all for the moment.

The plight of your character, and staple of RPGs, is to be ambushed by creatures bent on your demise. In MMORPG, the world’s proliferation of evil creatures is determined by population logic. New and improved population management is now in place.

From a gameplay standpoint, the new logic includes (the beginnings of) population dynamics. If you hunt down an area of creatures, the population will dwindle. In time, a population will restock its numbers. In addition, frequently traveled routes (such as along roads) will remain more clear of enemies. Population logic also controls potential combat rewards (items, resources).

From a scheduling standpoint, population dynamics will be further enhanced later. My immediate goal is to continue integrating Beta Beta core gameplay features. Combat improvements are scheduled next, followed by items, shops, and towns. These systems already exist from Alpha, and are being tweaked, per the latest game designs. After this, new components (such as magic, quests, and skills) can be integrated.