Fantasy MUDs with Area editors and OLC tools
Generic fantasy MUDs often fall into Tolkien traps where elves are dexterous and dwarves are sturdy with no deeper mechanical integration. This guide implements a cultural vector system that ties race selection to class affinity matrices, generating dynamic lore helpfiles and faction standings while maintaining strict 80-character terminal compatibility. You will build a system that makes unusual race-class combinations mechanically viable but culturally distinct, stored in persistent OLC-accessible files.
Map Base Races to Cultural Vectors
Define race constants using bitvectors to represent cultural traits (nocturnal, urbane, feral, arcane-focused) rather than copying Tolkien stat bonuses. This allows mechanical distinctions between culturally similar races. Edit structs.h to add cultural_vector to the race_data structure, ensuring each race has a unique combination that will later restrict or enhance class access.
#define RACE_CULTURAL_NOCTURNAL (1 << 0)
#define RACE_CULTURAL_URBANE (1 << 1)
#define RACE_CULTURAL_FERAL (1 << 2)
#define RACE_CULTURAL_ARCANEFOCUSED (1 << 3)
struct race_data {
char *name;
int cultural_vector;
int stat_mods[6];
int max_str, max_int, max_wis, max_dex, max_con, max_cha;
};⚠ Common Pitfalls
- •Hardcoding Tolkien-esque stat bonuses without cultural context
- •Creating races with no mechanical distinction from existing templates
Build Dynamic Affinity Matrices
Create a 2D array in const.c mapping race indices to class availability using percentage modifiers (100 = standard, <100 = penalty, >100 = bonus) rather than binary restrictions. This permits 'unusual' combinations with trade-offs visible to players. Initialize the matrix with values that reflect your cultural vectors: feral races might have 130% affinity for Rangers but 60% for Mages.
const int race_class_affinity[MAX_RACES][MAX_CLASSES] = {
/* WAR MAG THI RAN KNI PAL */
/* HUMAN */ {100, 100, 100, 100, 100, 100},
/* NOCTU */ {80, 120, 110, 90, 70, 40},
/* FERAL */ {110, 60, 90, 130, 50, 30},
/* URBAN */ {70, 110, 120, 60, 90, 80}
};⚠ Common Pitfalls
- •Using boolean restrictions only, removing player agency
- •Forgetting to validate matrix bounds against MAX_RACE and MAX_CLASS constants
Integrate Lore into Helpfile Generation
Write a utility function that parses race-class combinations to generate dynamic help entries describing the cultural tension or harmony between choices. Ensure descriptions wrap at 78 characters to accommodate 80-column terminals, storing the generated text in your helpfile index. This bridges mechanics and lore without requiring manual writing for every combination.
void generate_race_class_help(int race, int class) {
char buf[MAX_STRING_LENGTH];
char wrapped[MAX_STRING_LENGTH];
int affinity = race_class_affinity[race][class];
snprintf(buf, sizeof(buf),
"%s %s: %s\r\nAffinity: %d%%\r\n%s",
race_table[race].name,
class_table[class].name,
get_lore_blurb(race, class, affinity),
affinity,
affinity < 80 ? "Warning: Unusual combination." : ""
);
/* Wrap at 78 chars for terminal compatibility */
wrap_text(buf, wrapped, 78);
add_helpfile_entry(wrapped);
}⚠ Common Pitfalls
- •Exceeding standard terminal width with lore dumps
- •Generating passive voice descriptions that obscure game mechanics
Implement Faction Standing Modifiers
Hook race selection into initial faction standing calculations in comm.c during character creation. Races with specific cultural vectors should start with diplomatic baggage: nocturnal races might begin at -200 reputation with solar-worshipping factions. Store these modifiers in a readable struct array so builders can adjust starting politics without recompiling.
void init_faction_standing(CHAR_DATA *ch) {
int race = GET_RACE(ch);
if (IS_SET(race_table[race].cultural_vector, RACE_CULTURAL_NOCTURNAL)) {
ch->pcdata->faction_standing[FACTION_SOLAR_CHURCH] = -200;
ch->pcdata->faction_standing[FACTION_VAMPIRE_COVEN] = 100;
}
/* Communicate starting standings to player */
send_to_char(ch, "Your race affects faction standings:\r\n");
display_faction_summary(ch);
}⚠ Common Pitfalls
- •Making faction penalties permanent without redemption arcs
- •Failing to communicate starting standings to players clearly
Configure Skill Cost Scaling
Modify the practice command handler in skills.c to calculate learning costs based on race-class affinity values. Poor affinities (below 80%) should require exponentially more practice sessions (using pow(1.5, difference)), while strong affinities reduce costs linearly. Display the calculated cost to players before they commit to training.
int calculate_skill_cost(CHAR_DATA *ch, int sn) {
int race = GET_RACE(ch);
int class = GET_CLASS(ch);
int base = skill_table[sn].min_mana;
float affinity = race_class_affinity[race][class] / 100.0;
/* Exponential penalty for poor affinities */
if (affinity < 0.8) {
float penalty = pow(1.5, (0.8 - affinity) * 5);
return (int)(base * penalty);
}
return (int)(base / affinity);
}⚠ Common Pitfalls
- •Hidden penalties that frustrate players
- •Linear scaling that fails to deter genuinely poor combinations
Validate ANSI Color in Descriptions
Create a validation function in utils.c that checks generated lore text for 256-color ANSI codes (\033[38;5;Nm) unsupported by legacy clients like tintin++ or standard Mudlet installations. Ensure descriptions remain meaningful when color is stripped, testing against monochrome terminals. Reject any helpfile containing extended color codes.
bool validate_ansi_compatibility(const char *text) {
/* Reject 256-color codes \033[38;5;Nm or \033[48;5;Nm */
if (strstr(text, "\033[38;5;") || strstr(text, "\033[48;5;")) {
log("Error: 256-color code found in lore text");
return FALSE;
}
/* Verify readability without color: check contrast markers */
char *test = strdup(text);
strip_ansi(test);
bool readable = (strlen(test) > 0 && isalpha(test[0]));
free(test);
return readable;
}⚠ Common Pitfalls
- •Using 256-color codes unsupported by Mudlet or tintin++
- •Relying on color alone to convey mechanical information
Create OLC Integration Points
Add builder commands in olc.c that allow online adjustment of affinity matrices without recompiling. Store the 2D array in a flatfile (data/affinity.dat) that loads at boot and saves when builders use 'olc save'. Implement bounds checking to prevent invalid race/class indices from crashing the game during runtime modification.
void save_affinity_matrix(void) {
FILE *fp = fopen(DATA_DIR "affinity.dat", "w");
if (!fp) return;
for (int i = 0; i < MAX_RACES; i++) {
for (int j = 0; j < MAX_CLASSES; j++) {
fprintf(fp, "%d %d %d\n", i, j,
race_class_affinity[i][j]);
}
}
fclose(fp);
log("Affinity matrix saved.");
}
void load_affinity_matrix(void) {
FILE *fp = fopen(DATA_DIR "affinity.dat", "r");
if (!fp) return; /* Use compiled defaults */
int r, c, val;
while (fscanf(fp, "%d %d %d", &r, &c, &val) == 3) {
if (r < MAX_RACES && c < MAX_CLASSES)
race_class_affinity[r][c] = val;
}
fclose(fp);
}⚠ Common Pitfalls
- •Requiring full reboot to update affinity tables
- •Storing matrices only in memory without flatfile backups
What you built
This implementation creates mechanically distinct fantasy races without resorting to generic tropes, while maintaining the text-only readability critical to MUD accessibility. By storing affinity data in persistent files and validating output for 80-character terminals, you provide builders with live adjustment capabilities and players with clear mechanical feedback. Test edge-case combinations (feral mages, nocturnal paladins) to ensure the exponential cost scaling creates meaningful choices without rendering characters unplayable.
.