AI Scripting: Oogie (Lua)

Design Overview

Design Objectives:

The Robust Design supports various player classes and multiple enemy types, allowing new ones to be easily created and added.
Balanced Play ensures that the implemented class(es) interact with enemies to allow for a challenging experience without creating undue difficulty or making it too easy/hard.
A Good Gameplay Loop means refining mechanics and balance decisions to encourage player engagement and attentiveness.

Design Overview

Balance:

Initial stats were decided based on archetype, and lightly refined based on comparative DPS values. This spreadsheet

allowed me to see changes propogate and allow for detailed breakdown of where strengths/weaknesses of characters

manifest and how to influence them through base stats.

The exception noted here is because of damage modification debuffs, which affect Total DPS but does not contribute raw Spell DPS.

Robust Designs:

All characters derive from a base character with a simple set of stats (such as Health, Attack Power, and Spell Power). The majority of these stats derive from the base attributes Constitution, Might, and Will. Those stats which aren't derived in this way are specialized according to the overarching class of the character, such as Attack Range and Magic Affinity.

Good Gameplay:

Refining gameplay meant more than just iterating on numerical values, it meant looking at the core gameplay systems and improving the feedback methods available to the player. Particle effects, simple animations, floating numbers, selection circles and more.

Implementation Highlights

Implementation Highlights

The Map:

The Crypt is a simple map designed to introduce different enemy types rapidly and cleanly to players while providing a sense of progression and choice. As everything is identical and there are no non-combat actions to take, this is a facade—but as level designs weren't the priority on this project, the simple layout was serviceable.

At every point in the design, the intent was to provide a framework for building gameplay. In this case, exposed aggro radii allow me to place enemies and be certain of their behavior according to the simple protocols the AI follows.

Blueprints:

A lot of the heavy lifting occurs in the Character, in response to events from the Player or AI Controller. The characters (including enemies) share base behaviors, while custom features build on that groundwork in child classes such as the Skull Knight or Giant Commander.

Abilities need to do a lot of things, and keeping these visually sorted can be incredibly valuable for debugging and preserving the atomicity of the actions themselves.

However, the primary effects need to be the manipulation of stats. Appending some behaviors to this interaction keeps them connected in a way meaningful to players, ensuring that these feedback systems always match in-game actions.

Enemy characters use the same template as player characters, driven by external actions and preserving the behaviors within themselves as unified pieces.

Post-Mortem

Post-Mortem

What Went Well:

Strong Initial Design: Front-loading balance calculations allowed an early look at design issues and allowed for some intelligent refinements before completion of gameplay.
Excellent Exploration of Complexity: The large number of tasks needed, even for basic gameplay, allowed insight into the impact and relation of a number of typical gameplay systems.

What Went Wrong:

Incomplete Top-Down Analysis: While initial designs were of appropriate complexity and relatively robust, I neglected the effort of task planning as I would be the sole developer. A number of initial specifications (relating to character progression and multiple player characters) never came to fruition, and recognizing this earlier in the project could have led to more focused designs.
Low Number of Playtesters: Because of the number of mechanics and the relative dearth of mechanical instruction, the project falls far short of providing a full game experience. As a result, I was reluctant to organize playtesters (especially at early stages) in the name of completion. As the few playtests provided innumerable refinements, this was an unwise choice of priority and reflects in the paucity of later balance tweaks.

Takeaways:

Planning Is Good: Top-down development can restrict projects and force them in unnatural directions, but can also provide a solid bedrock for the root balance of a system. The key is planning for the appropriate elements and allowing for flexibility in the design.
Task Planning is Essential to Scoping: Setting reasonable goals is impossible without a proper assessment of the elements involved in a project. To develop a full game, time needs to be devoted to more than the numbers and the application of those numbers to entities—it should also recognize the value of feedback to players and provide time for examining player experiences with the system even at the rough early stages.

Gallery