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.
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.
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.
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 »
I just stopped coding for a moment and realized we were a month into 2009. I thought I'd better let everyone know that I'm still hard at work developing the brand-new old-school (so-far, so-called) Potential RPG.
At the close of 2008, I evaluated and distilled my game design goals. My recent focus has been to solidify and enhance the core capabilities of my (so-far, so-called) Potential Platform, in support of these desired gameplay features. For example, a new map management capability allows maps to be either persistent (such as mainland continents) or instances (such as caves to clear).
I'm looking forward to (the rest of) 2009 and plan to have something fun to offer soon...
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?
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.
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
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.