As of this month, I have transitioned from adding gameplay features into improving usability, performance, and scalability.
Usability includes improving the game's user interface, as well as streamlining client behavior and server operation. For instance, the in-world shops and character inventory have been given a face lift. More technical issues include client network behavior and server configurability.
Performance testing measures CPU and RAM utilization on the client and server, client-server network requirements, server database/disk read/write, and graphic processing capability of the client. Performance tuning will allow the client to run smoother and reduce server-side bandwidth, CPU, and RAM requirements.
Scalability is related to performance, dealing specifically with the capability of the client, server, and network to handle increasing numbers of players (and therefore islands, creatures, battles, items, etc.).
It's old news that Java's Swing GUI toolkit follows a deficient Model-View-Controller (MVC) architecture. In most cases, Swing fuses together the notion of the View and Controller, but offers a separate Model. At least, that's what the naming convention implies. For example, JComboBox should be a View-Controller to a ComboBoxModel.
This particular case failed me today. Read the rest of this entry »
Today's SLOC count is 96,060 (4,237 less than my 100k analysis
and 3,501 less than yesterday). While adding several new gameplay features, I was able to streamline the implementation in several places. This SLOC drop results from isolating (and removing) a good chunk of legacy logic, rules, and display code, which was impeding the integration of new features. Most importantly, playtesters should notice more direction in the gameplay, just as soon as I can deploy the next incremental Alpha release.
I was just perusing the Java source code (because I don't read the morning newspaper), when I discovered that
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
operation. Read the rest of this entry »
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).
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 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 »