Character and System Developing

Happy 2024 to all! Another year, another effort to get myself back into developing games over playing them. 🙂

I received Baldur’s Gate 3 for Christmas, which is VERY good. I’ve also been a steady player and fan of Fallout 76, which continues to add new content and make small changes to make the game more accessible to new players. (The most recent update added small faction bases near the starting location to introduce you to the various groups early on.)

And I recently started playing Animal Crossing again after around two years; my villagers acted like they had seen a ghost when they saw me! That usurious little bastard Tom Nook at least had no new things to put me in debt with… (Anyone think AC needs an enemy? Maybe an evil counterpart to Tom Nook, who’s plans and projects constantly fail, but he’s too much the narcissist to stop. And his name will be… Elon Muskrat!)

But, I did play enough Roguelikes to come to some conclusions on things character and system related with my TI-99/4a Roguelike:

• 

  Moldvay’s D&D Basic Book

  Pretty much all of them directly rip off D&D or AD&D rules sets from the early to mid 80’s. This makes sense; they were using what everyone was familiar with. There is small adjustments here and there to accommodate the computer but it’s otherwise the same design: six ability scores, hit points, classes, levels, experience, etc.

• No matter how much variety of procedural generation you put in, sooner or later your system becomes predictable. You can even see this in modern PG games like No Man’s Sky. After awhile there’s no real surprises and it’s a lot of same-old same old…
• Curiously, the early Roguelikes stick to a linear “floor 1 to floor 2” approach. I’ve decided to have the option of forking levels. Which is, funny enough, easy to generate as unbalanced binary trees. This creates some new stress where you may go down several levels on one fork and have to traverse back again. (This entry edited due to Ontor, see below)
• Almost all Roguelike’s interactions with NPC’s are combat. It’s not easy to envision, but I like the idea of having monsters who aren’t immediately hostile that you can negotiate and carry a short conversation with. And even engage in trade and barter. More on that later…
• Related to above, money is usually only used to gain XP, if the system is using the old-school “gold for XP” approach every edition of D&D used prior to 2nd Edition AD&D. Having it be a useful resource for trade and other things would be cool.
• All Roguelikes are turn-based. I think I’ll do the same. I had a moment of “Well maybe real-time would be kind of interesting…” but generally if you go RT, then the game becomes more about quick thinking and being good with a controller or keys, rather than a game of tactical thinking and consideration. I much prefer the latter.
• Perma-death… Again, this is a staple of Roguelikes. But I am not a fan of this. As a middle-aged gamer, my time is valuable. I don’t want to spend it playing a game where a single random factor can end it and waste hours of play. Plus, most gamers cheat by backing up saved files. So why have the mechanic if it can be circumvented? What I may do instead is have a “limited” number of reloads based on difficulty level, with standard being unlimited.
• Dungeon/cavern generation. I’ve some working models on both of these, but I realize I need the character system defined to really give the game the depth it needs first.

So I have tentatively started mapping out my “character system”, by which the player can advance and get more powerful. As part of this, the algorithms for attacking, defending, damaging, and so forth get created as well.

Roles (or Classes)

Right now, my plan is to have four roles:

• Warrior
• Wizard
• Rogue
• Adventurer

The first three are self-explanatory, they encompass the typical range of abilities for fighting, spell-casting, and skill usage. The last one, the Adventurer, is a blank slate which the player can mold into the character of their liking.

What, no cleric? Yeah, I’m not a fan of divine magic, clerics, or gods in my computer games. You can see this in Realms of Antiquity; I prefer to keep magic as a secular force. That doesn’t mean the classic “altars” of Roguelikes won’t make an appearance, though.

This is by no means the final list; I may add additional roles in later design.

Races (or Lineage, Species, ???)

Wait, you ask, what about races? Elves, hobbits, dwarves, orcs, and whatnot?

Well, my initial plan was not to have them at all. When Ultima removed all the Tolkien monster references in Ultima VI onward, I found I agreed with the logic that Tolkien races are VERY overdone.  It’s derivative and boring. In Realms of Antiquity, the only playable race is human; other well-known fantasy races are referenced but not encountered or playable. (With one exception…)

But, with a Roguelike, I think I can make it work. The important thing is that whatever race you choose should have significance with the game-play, beyond just some statistic adjustments.

D&D before 3rd edition was an interesting design. Most of the “demi-humans” (elf, dwarf, halfling) had significant advantages over the baseline “human”, such as infra-vision, immunity to various effects, better XP bonuses for high ability scores, bonuses to armor or attacks against certain foes, better abilities to detect secrets and traps, or in the case of the elf in classic D&D, the ability to cast spells like magic-user but wear full armor and use weapons like a fighter!

So with all that, why would you EVER play a human? Well, for one, experience level costs for demi-humans were higher. The aforementioned elf, for example, required double the XP a normal human fighter did to get to the next level. There was also a level cap for demi-humans so that they’d eventually stop leveling and get no more powerful, where humans had no limit.

So after some thought, I think I could add a lot of little special traits and things for non-human characters that make them both advantageous but also a disadvantage at other times. Plus possibly level limits as well, which means an easy ride in the upper levels but an increasing challenge in the depths. Could be fun!

Ability Scores (or Attributes)

Ability scores are, in most tabletop gaming design, the statistics that exist for all living creatures in the game. I want to shake things up a bit with some changes to the typical D&D baseline:

• Strength – As expected, used for hitting, damaging, carrying capacity, opening stuck doors, and all that jazz.
• Dexterity – Used for ranged attacks, dodging, picking locks, disarming traps, etc.
• Fortitude – Used for resisting physical ailments like poison and disease, hit point calculation, and so forth.
• Intellect – Used for spell casting, energy calculation, reading mysterious writings and interpreting scrolls, magical trap disarming, resisting spells, etc.
• Perception – Used to spot traps, secret doors, searching, avoid gaze attacks, insight into negotiations, determine item values, and similar.
• Chutzpah – Used for reactions from NPC’s, trade and bartering, intimidation and deception checks, resisting mind effects, etc. (Won’t lie, I stole this one from classic Paranoia.)

Other Roguelikes copy D&D by having ability scores run 3-18, with more advanced ones like Nethack using the percentile system for exceptional Strength introduced in AD&D. I’m not doing that. The current plan is to have ability scores run from 1-32, although that’s subject to change. Also, sticking with integer math is just a good idea on older vintage systems unless you have a real crucial need for that degree of accuracy.

A fun side note: During 3rd edition D&D’s development, the question arose whether or not the actual ability scores (3-18) should be abolished and only bonuses kept. If only the bonus is ever used for any calculations, why have the original ability score at all? After some debate they decided the ability scores were a “sacred cow” that they couldn’t remove without angering the fans. (They had a similar debate on hit points.)

So I’m also considering why not have every point of an ability score matter? The main reason to retain it is if you want fractions; that you have to gain more than one ability score point before it impacts algorithms. I’ll need to work out all the various calculations and see which scales best to what I need.

And one last thing is how often ability scores change. I want them to be a bit more flexible than my past game designs, where they remained largely static most of the game with only end-game items letting you raise them. Old school D&D expected the DM to take some latitude and have pools or magical encounters that could raise and lower attributes permanently.

Potions (or… Potions)

A common staple of Roguelikes is that a lot of items in game aren’t immediately identifiable. You have to find out, through identify magic or trial and error, what things are and what effect they have.

With potions, the design is often to give them a color which is randomized for each game. So a “blue potion” may be a potion of healing in one game, and a potion of poison in the next. Some more advanced Roguelikes let you label a potion after you’ve tested it so you can remember what it does.

For my own, I’ll use 12-bits (1024 possible combinations) with a potion’s color, appearance, and smell as the random descriptors. Some examples:

• Bubbling crimson potion with a citrus note
• Steaming teal potion with a sour note
• Clear maroon potion with a metallic note

I could probably just use color, but I like having fun with it. 🙂 Whether or not you can re-label them after discovery I’m still considering.

I’m also debating if I want to introduce an age-old idea from AD&D, the “potion miscibility table”. (As usual, Gygax uses a ten-dollar word where a simple one would do. Miscibility refers to the ability of one liquid to completely dissolve in another liquid solvent.)

The idea is if you already have a potion’s effect on you and you consume another, what happens? The table of old would allow for them both applying, one canceling each other out, one having their effects doubled, or worst case the character exploding. Could be fun, could be frustrating. Worth testing!

 Scrolls and Spells

The original Rogue game used a random spew of characters for scrolls, which looked kind of like magic words. I had a better idea…

Borrowing from Ultima V, I thought it would be cool to define spells in the game as a series of verbs and nouns, describing the spell’s effects. Then, I could randomly generate syllables for each verb and noun and have a magic language constructed for each game, giving the player a chance to interpret a scroll based on the words.

• Fireball – “Create Fire Movement”
• Heal – “Create Life”
• Vanish – “Alter Creature Light”
• Charm – “Alter Creature Knowledge”
• Detect – “Sense Danger Knowledge”
• Cure Poison – “Remove Toxin”

My experimentation in this area proved quite humorous… computers generating random syllables can easily get out of hand and make some very strange and funny combinations. You can read a tech story about this here:

The Automated Curse Generator

Some samples I generated:

1st Set:

• Spell: Fireball – HU FUHON GWIN
• Spell: Heal – HU CRAM
• Spell: Vanish – TARO BPAK CEROD
• Spell: Charm – TARO BPAK TNED
• Spell: Detect – BA YEWEK TNED
• Spell: Cure Poison – MA TAROT

2nd Set:

• Spell: Fireball – CE FOTI YOKE
• Spell: Heal – CE PEMU
• Spell: Vanish – JI DOYO WAHU
• Spell: Charm – JI DOYO GOZI
• Spell: Detect – KI CUPEW GOZI
• Spell: Poison – CE ZAFA

3rd Set:

• Spell: Fireball – MI KUEB GE
• Spell: Heal – MI ZU
• Spell: Vanish – HI RAY HEW
• Spell: Charm – HI RAY MAN
• Spell: Detect – TOD YO MAN
• Spell: Poison – MI YEAH

After playing around with different algorithms to generate words, I realized that there was NO WAY, on a vintage system at least, to prevent a potential bad combination of letters making weird, funny or offensive words. So the best approach is to use my generator to create two, three, four, and five letter random words in large sequences, pick the best ones for data tables, and  use those to generate magic words.

The Display

Roguelikes started as text-only games, using the ASCII table (and later the extended ASCII table, usually CP437 which is the IBM’s set) to represent all objects, structures, and mobiles in the game. The player was always the ‘@’ symbol, walls were a mix of ‘+’, ‘-‘ and ‘|’ characters, monsters were always the first letter of their name, money was ‘$’, and so forth.

Even later games like Nethack continued this tradition, only grudgingly offering a graphics mode at times. And inspired games like Dwarf Fortress embraced the ASCII graphics, albeit with the option to add actual graphics. (It comes as no surprise to me that Dwarf Fortress for Steam finally left this behind; we’re not far from a point where ASCII will be just something grumpy old men talk about.) Games like ADOM start with graphics but can be switched to ASCII at anytime.

The problem with this approach? Every graphic tile in the game also needs an ASCII equivalent.

Some Roguelikes overcome this limitation by using the extended ASCII set which includes a lot of variant vowels and characters like arrows, simple graphic shapes, and so forth. Or they use colored characters to differentiate between types. Neither of these options are easy to implement on the TI-99/4a for these reasons:

• As a computer developed in 1981, the TI-99/4a has no extended ASCII table. It could be introduced, of course, but it means deciding WHAT extended set to use, and then making sure it fits the available size. (6×8 in text mode)
• The TI-99/4a 40-column text mode is monochromatic; there are only two colors available, the text color and the screen color.
• Using colored text is somewhat rude to those with color-blindness; the CRPG Addict has ran into this before with other games including Nethack, and I don’t care to contribute to the problem.

I plan on using full graphics for the game, but I’m debating on how to assign letters for a “text only” mode. We’ll see if that happens.

Monsters (or Abnormal Entity of Inconsistent Temperament)

And finally, we have the monsters.

Unlike my past project, Realms of Antiquity, a monster’s appearance will be just a single character, as opposed to a colorful 16×16 or 32×32 graphic. This means I need to give them a lot more depth than just a set of combat statistics.

Much like bending a little on classic fantasy races, I think that I will also have some more classical fantasy monsters, such as goblins and hobgoblins. (Not orcs. Still too Tolkien-esque.) As these terms for monsters predate fantasy gaming, it’s easy to fashion them into your own. Monsters from mythology such as medusae, minotaurs and similar are good too.

One aspect of older school gaming I want to bring in is the reaction roll. If you read old D&D manuals, it was not assumed that every encounter with monsters was hostile. There was always a chance of a conversation, negotiation, and even a peaceful conclusion. As computers couldn’t really simulate this, early CRPG’s and Roguelikes had to focus on just the combat aspect.

So I’m exploring the idea of having individual or even small groups of monsters being amenable to conversation. They may let you pass them unharmed in return for a bribe. Or be willing to barter and trade items.

And possibly, the player starts to develop a reputation that makes future negotiations easier or more difficult. Although there it will be fun to use the races as potential sources of trouble. Maybe being TOO friendly to one group makes you anathema to another.

Conclusion

So there’s where I’m at so far! I’m going to continue to define and work on system design until I have a good idea of everything I want to implement. Still a ways off from an alpha engine.