Nine Day Game, Day 6 - The Numbers Game

Role-playing Games (RPGs) are all about the numbers. Quantifying attributes, calculating armor values, computing damage after mitigation; It's a thing of beauty for data geeks. Up until Day 6, we had enough on our plate to worry about just getting the world to work without thinking about the calculations and equations that are integral to it. But, finally, it's time to bust out the Excel spreadsheets, power up the calculators and do some math. The goals:

• Select a stat system and implement it
• Build a scheduler to handle attack speed (i.e. calculate who attacks first)
• Develop an API to help optimize our world's rendering
• Create an OpenGL menu system for inventory management
• Begin work on the options screen

The stat system we ended up selecting was one I designed a few months ago to allow for heavy character customization. Each character has eight attributes: strength, constitution, magic, wisdom, dexterity, discipline, intelligence, and speed.

Credit where credit is due: Ryan came up with the mechanic of having strength and magic increase the damage taken by their respective damage type, which seems like a cool mechanic.

With this system, it's easy to create many of the classic RPG classes. For example, the mage/wizard in our system would pick up magic, wisdom to counter the increased damage from magic, discipline, and intelligence for critical hits. A mage from the Fire Emblem series could be represented by taking more speed than intelligence to increase dodge chances.

But this system also allows for some character styles that are harder to model with a classic D&D system, like the Templar from Dragon Age, who in our system would have strength, constitution and dexterity, like a warrior, with extra wisdom to defend against magic users. Or consider the spellsword, a prestige class from D&D. In our system, the hero would want high strength, magic, and dexterity, modelling a character who fights at melee range with a mixture of swordplay and wizardry.

Ryan began work on a scheduler to handle attack timing. The scheduling system takes inspiration from the way an operating system scheduler works, with processes (or in this case, characters) delaying themselves based on an 'action cost', before transitioning to a ready queue and executing the ability. All actions in the game world, from moving to resurrecting dark gods, get scheduled by this system. The result is that our game isn't exactly turn-based like a traditional roguelike. Instead, action unfolds more like it does in Final Fantasy, and very fast characters could potentially get multiple actions in a row, especially if those actions have a very low action cost.

The screenshot above shows some of the new UI elements I created on Day 6: a health meter (top left) and list of available abilities (bottom right). Overall, the 3D system is progressing slowly. While attempting to implement menus, I realized that some of the design decisions I had made earlier in the project were going to hurt the development of our UI. Early on, I was rushing development by throwing a lot of game logic into the 3d game engine itself. This came to be a problem when designing the menuing system because menus have a foot in both worlds - they're rendered by the engine, but the only sane way to try and control them is to have a handle to them outside the engine.

The upshot is that I spent a lot of time refactoring code yesterday to fix those design errors. The downside is that the time spent fixing those problems is time that could have been better spent creating art assets, learning how to use OpenGL's stencil buffer, or writing a particle engine. Day 7 will be busy!