Potential Games LLC

We've released a major gameplay update for Island Forge ( http://islandforge.com ) incorporating several improvements prompted by community feedback - many thanks to those who have participated so far. We're excited to welcome new players! Island Forge: Create islands and stories for others to explore!

Potential Games LLC is proud to present its premier title: Island Forge -- the brand-new old-school massively multiplayer online role playing game, where you can create your own islands and stories for others to explore. Have at it!

Play FREE during Beta!

Potential RPG Final Alpha edition is up and running. The focus of this release is playability, and just about everything has been updated and improved. The world layout has changed (each island is now a self-contained town, expedition, and story). The island builder is easier to use. Character life and experience have been unified (as originally envisioned), but in an interesting new way. Resource processing and equipment crafting has been improved. The catalog of spells, potions, enchanted items, and variety of weaponry has been enhanced. The user interface controls are overall more attractive and functional. There are even some sound effects to be heard. If you're an Alpha Playtester, please have a look. I eagerly await your input and anticipate a slew of new issues (I've already patched a few myself). Meanwhile, I am forging ahead with Beta tasking, much of which is not specifically software or gameplay related.

Over the past two months, I've kept a feverish schedule of rampant development, all with an eye to playability. Drawing on feedback from alpha playtesting, I've adjusted, tweaked, or at least polished almost all aspects of the gameplay, while maintaining the core tenets of the game design. A new version has not yet been released, but only a handful of high priority tasks remain.

So much to report... soon. Sleep now...

A week of not-yet-released gameplay-altering changes. Hold fast.

The Potential RPG (working title) v0.8.16 series (BetaAlpha edition) has been steady as she goes. Beneath the surface calm, a current of design builds into a swell of development, which will crest in the following weeks.

Running autonomous test clients against my game server, I kept generating a situation in which several client network connections (TCP) remained open. This resulted in those client sessions remaining active long after the client had disconnected. This had the potential to retain game state in the server, preventing memory from being reclaimed (effectively a memory leak). The player might not be able to log in later, because they still have an active (albeit bogus) session. No matter how many safety checks I put into the networking logic, I could not detect these broken, lingering connections. As it turns out, Java sockets cannot report they have closed when the socket was not shut down cleanly, without actively attempting to read/write data. My game server protocols are rather conservative, and do not chatter unnecessarily with clients. As a result, an abruptly disconnected client socket could idle indefinitely, so long as no data was destined to be sent its way. To alleviate this problem, the server networking logic now takes note of client communication times. After a configurable timeout with no activity, the server sends a ping, to which the client is to pong. This has one of three results. If the pong is not returned within another probationary timeout, the client is considered lost, and the session is forcibly closed. If the client is, in fact, alive and well, the pong refreshes its most recent activity. The third result is what I've most commonly found: the attempt to send the ping over a broken connection triggers a network error (IOException), which is caught and handled, more-or-less, cleanly. In a perfect world, client software would cleanly tear down all TCP connections. In the real world, several factors can prevent this ideal behavior (network failure, software crash, killed application). In any case, server systems cannot rely on clients to behave ideally. While I could spend the rest of my days improving network communication logic (resume available upon request), the above technique is simple enough and appears to be working well in ongoing tests.

Remember those client/gameplay updates I've been promising... I'm almost ready to get going on that. This week I've been hunting down excessive server memory allocations and deflating them. The goal is to have a predictable (and low) memory profile, so I can gauge the RAM required to support N players (as N approaches infinity, if all goes to plan). The particular improvements include content persistence, atlas activities, and server startup data indexing. These activities were each consuming large chunks of memory, which could spike and cause OutOfMemoryErrors. One technique I used to lower runtime RAM consumption was to stream content directly to the backing store during persistence, rather than constructing large intermediate data structures in memory. Atlas maps are served up directly from disk, when possible, rather than redundantly inflating/deflating in memory. Startup data indexing now builds its lookup structures on disk, rather than in memory. Overall, this should make for a smoother ride. Although I could spend the rest of my days improving system software design and implementation (resume available upon request), I'm eager to re-focus on the player experience with client and gameplay enhancements. Why can't there be N of me?

... as I was saying, behavioral testing of the server under heavier load has spilled into this week, and consumed it. Several key systems now exhibit better behavior and are overall more resilient and scalable. At the end of this week, I find myself implementing another performance/scalability/resilience improvement into the server. Namely, persistence can cause wicked memory spikes, which can slam into the memory limit of the server process, causing instability. I have a design for improving the persistence routines for both speed and memory efficiency, which I'll be implementing just as soon as I publish this post. (Saturday night, 8pm, time to code!) Then, client and gameplay improvements are (for real) just around the corner.