Planet Mud-Dev

July 08, 2015



Another idea I had that can be pilfered from modern MMOs, but won't be needed until I get to actual combat stuff: instance dungeons.

In a MUD you typically have everyone exploring the one dungeon at a time, as it would normally be in reality, so multiple adventuring parties can run into each other, call for help, and so on. But in MMOs (I think it happens in WoW, the only one I've played that does it was Mabinogi) entering a dungeon with your group generates a new 'instance', that is, a completely separate copy of the dungeon just for your group. Nobody can get in, or out without escaping or dying. The entire group enters at once and has to finish it together.

Now, the nice thing is, this could readily be done in Smerg by copying the Rooms and Exits of a content pack. Make a new, temporary content pack with just those rooms and exits, that reference each other, and you basically have an instance nobody else can interfere with. The instance can be destroyed when everyone leaves the area (by dying, winning, or logging out, the last of which kicks you out back to the entrance of the dungeon). Every object in a content pack is already trivial to duplicate, so the only tricky part would be making the exits connect to the rooms in that instance instead of to the master copy (which nobody except admins would ever actually be in).

July 08, 2015 03:13 AM

July 05, 2015


Something something root of all evil

Additionally, I think that, at least for now, it would be best to abandon multithreading in Smerg. The motivation to do so was always for stability and not for performance reasons - but it introduces such a level of complexity that it would probably be counterproductive considering Smerg is supposed to be targeted for hobbyists. It can always be done later if it is deemed necessary, and redesigned if need be. There are other ways to get stability with better error handling.

That also means that the M in Smerg won't stand for Multithreaded any more. Given the huge push I'm making to get as many things as possible into Content Packs and Content Objects, SMERG will now stand for: Simple, Modular, Extensible Role-playing Game.

July 05, 2015 08:29 PM

Exits as Content Objects

So, I have come to a very tricky conundrum while converting Programs to Content Objects. I have been streamlining the program creation process to make it easier to pass along the information programs need to run, but a lot of it is copy-pasted code, which I have been chipping away at. But the final step is to move all stuff about being Programmable up to the parent content object class.

However, this isn't really that good of an idea, since things like Helpfiles and Emotes don't have programs because they aren't interacted with - they're not objects in the actual game world. So, my idea for a solution to this was to make an Entity class, which is essentially any content object that exists within the game world itself. So Rooms, Mobiles, Items, etc are entities while Helpfiles, Emotes, Recipes and so on are not. Then, only Entities can be Programmable.

However, content packs themselves are not entities; they merely contain them. They are currently Programmable but I will be removing that; instead they will simply contain the programs that get called (as all programs are going to become what used to be Common Programs). The old AreaProgramType triggers were RESET, TIME, ENTER and EXIT which can all easily be moved onto Rooms within the content pack, so no functionality is really going to be lost, just moved around.

All well and good... until we come to Exits, which should be programmable, and are interacted with by players, but aren't really content objects. At least, not at the moment...

Unfortunately this isn't quite as clear-cut as most other Content Object conversions.

On the one hand, Exits behave like content objects in that they should be programmable (when opened, closed, hit with a thrown object, locked, unlocked, etc...), saveable, and manipulated with the same New, Edit, Stat, etc commands as other objects.

On the other, because Exits are linking objects together, it's important to avoid causing confusion. While Recipes can use objects from anywhere, even outside of the content pack they are contained in, the majority of exits will be connecting together rooms in the same area. I could enforce a rule that exits -must- originate from the content pack they are in, or allow anything and simply make it a Best Practice or recommendation for MU* owners to avoid digging themselves into a hole. However, a more important benefit is that it greatly simplifies lookups; the most common thing to do with exits will be "Get me all exits for this Room". That said, whether Exits are in the same area or not, having a cache of them will help; the only issue then becomes invalidating the cache - which would happen any time an Exit is added or removed. "Must originate from containing area" can limit the scope of cache invalidations.

Another serious issue is that Exits cannot have duplicates. You can't have two North exits from the same room, for instance. This is normally easy enough to check, except that content objects created by the new command are in a default state - all of their fields are 0, null, etc. However, I've already bitten this bullet with non-Entity objects like Helpfiles and Emotes; it's not defined which one will be chosen if multiples exist, and I will be adding checks for duplicates later. However, while it might be easy to do a 'Duplicates' command that, given any Content Object type, can find all other Content Objects with the same internal identifier, Exits aren't referred to by name, so comparing identifiers won't help. I could instead use ContentObject.equals(), which I could override for Exits to make them compare source rooms and destination rooms, which would also make the actual algorithm for duplicate checking much simpler.

I could circumvent this by preventing Exits from being created with the "New" command and instead use a "link" command to connect rooms together, but that seems rather arbitrary if I'm going to make Exits into actual content objects.

One benefit of being able to edit exits in this way is that you could have things like puzzles where a north exit suddenly points to a different room because you flipped a switch and changed a set of up stairs into a set of down stairs. Of course, incorporating that kind of power into programs means that it's possible for exit cache invalidations to occur more frequently.

Perhaps I'm thinking about this all wrong. Let's try again from the top.

It's not as though it's impossible to represent exits as content objects, or to set them up. Currently there's an "addexit" command and similar functionality. Assuming both the source and target content packs default to the one the Exit is created in, if they were content objects the series of commands would look something like:

new exit assallus EntranceToCrypt
edit assallus exit ExitToCrypt direction Southeast
edit assallus exit ExitToCrypt sourceRoom TownSquare
edit assallus exit ExitToCrypt destContentPack Crypt
edit assallus exit ExitToCrypt destRoom Entrance

Which isn't -too- bad, it's a lot of commands but the edit mode discussed previously could help. Also there's nothing to say I can't ALSO add a link command that acts as a shortcut/helper:

link <source content pack> <source ID> <direction> <single/double> <destination content pack> <target ID> (<user-visible exit name>)

This would create an auto-ID'd exit in the same content pack as the source room. It would probably have an ID (assuming we linked the Assallus Town Square to the Crypt Entrance like we did above) along the lines of "TownSquare_SE_Crypt:Entrance", which is pretty long but would also be completely unambiguous if only the link command was used to create rooms. The user-visible exit name would simply be to change the enter/exit messages from "Codelizard leaves to the southeast" to "Codelizard leaves through the archway to the southeast" or similar.

Then, any further necessary modifications could be done with the edit command, like any other content object.

However, even if people do use the normal new/edit/etc commands, what's the worst that can happen? The various states the exit can be in are:

  • Newly-created. Nothing is set, so the Exit has no entrance, and can't be accessed.

  • Source set, destination not set OR destination set but invalid: This one is the most problematic, but a quick check can be done to see if the entrance is valid, and if not, the exit won't show up in the room.

  • Source not set OR source set but invalid, destination set: Without an entrance, the exit can't be accessed, so no big deal.

  • Source and destination set: Valid exit!

On second thought, I just realized that when an Exit is edited, the only cache that needs to be invalidated is the one for the old source room (if it exists) and the new source room, which greatly reduces the scope of cache invalidations. However, I also want to limit the scope of searching for exits, so I am still going to enforce that the source room of an exit must be from the content pack the exit is in.

The final problem, then, is when to refresh an invalidated cache. I could try to lazy-load exits and only bring them up when a Mobile enters a room, but to be honest, there's no real benefit. I might as well load up everything when the MU* starts up, and then as soon as the cache is invalidated pull down the new, correct set of exits.

I think I have a plan, then, so let me try to summarize (mostly for my own benefit):

  1. Content Objects will be split into Entities (things that exist in the game world) and Non-Entities (everything else). In the code there will be an Entity class that extends ContentObject, and then non-entities will just extend ContentObject directly without using Entity.

  2. Entity will contain everything needed for objects to be Programmable.

  3. Exits will become Entities, and by extension, Content Objects.

  4. They can be manipulated with new/edit/stat & friends but there will also be a link command that acts as a very nice shortcut to create a single or double (that is, two-way) exit in one step.

  5. Exits CANNOT connect two rooms from the content pack they are not in. The source room must be from the same content pack. (The destination can be in another content pack, which is how connections between areas are done)

  6. Rooms will contain a cache of exits, rebuilt when the MU* starts up and whenever the cache is invalidated. (Not too different from how things are now, actually)

  7. The cache is invalidated whenever an exit is modified, created with link, or deleted, for the source rooms involved. Invalid exits (where the source or destination don't exist) will be left out of the cache. If a duplicate is detected, a warning will be printed for admins to see.

  8. Exits will be sorted by: Source content pack, source room, direction. This means that all exits for a room will be grouped together when the list command is used.

July 05, 2015 06:04 PM

July 02, 2015

Optional Realities

Just Say No to Power Creep (Part Two of Two)

written by Donathin Frye (“Jaunt”)


In the first part of this article, I discussed how Verticle Design can lead to Power Creep in a number of different ways for long-lived online RPGs. In particular, I made an argument for why our more roleplaying-focused genre should approach the design of weapon and armor crafting from a perspective of Horizontal Design. There are many different ways and degrees to which one can accomplish this, as we’ve seen in newer games like Guild Wars 2 and Everquest Next, and others. In fact, many MMO designers believe that this sort of non-traditional design path is the future of the genre. Even though our games are far from being the multi-million dollar giants in the industry, we can certainly stick our hands up in the air and feel which way the wind is blowing. And we should. It doesn’t behoove us to rest on our laurels, after all.


I’d like to now share what I and the Project Redshift team are doing to approach the design of equipment and how its crafting works in our game, and then talk about how similar techniques might be applicable to other games in our genre.


To start with, a few things are paramount to understanding how combat and equipment works in Redshift:

  • Your equipment determines most of what you can do in combat. In interacting with the table-top style GUI, you click on a given square or coordinate, and then select from a drop-down menu whether or not you want to move to that space, target that space in a general way (for use of AoE gadgets such as grenades), or target a specific character standing in that space. You can then assign actions to a shortcut key bar to act without ever needing to type. This is all meant to make acting easy and intuitive in combat, no matter what “build” you use. Of course, you can still type out commands and roleplay during combat, too.
Redshift Combat GUI Proof of Concept

A Proof of Design for Ground Combat in Redshift


  • All combat equipment is contained within a single object. This is a major change from how most games in our genre work. To fully balance equipment horizontally, Combat Exo-Suits are a single object, as opposed to the helmet being one object, the leggings another, and so on. Additionally, utility items (like grenades and jetpacks) as well as weapons (both melee and ranged) are tied into the Exo-Suit’s power source in module “slots”. When you craft an Exo-Suit, you craft a certain number of utility or weapon slots. You then plug unpowered utility objects or unpowered weapons into those slots. Without the Suits, the weapons won’t work. You can always unplug a module from a slot to plug in a different module instead, giving the player flexibility without needing to craft an entire other suit. Because of this approach, we are able to use our Personal Economy for equipment to balance all equipment builds; this is the Horizontal Design aspect of what we are doing. Though there are nearly infinite combinations to craft and design, all suits will be inherently the same “quality” in terms of balance. It is purely the player’s ingenuity and the situational needs that will determine what suits are more effective than others.


  • Combat in Redshift has a strong group/crew PvE focus. PvP will exist and be balanced, particularly out in space (an entirely different combat system), but will not be the majority of the combat content of the game. We want players to play together, and to work together, and to roleplay together — and so we have designed combat to support that idea. Players will create the most effective teams for exploration and dealing with threats with a diverse variety of builds, allowing them to experiment with how different suits complement and supplement one another. Because of our Horizontal Design choices, we are able to tailor a wide variety of aggressive NPC artificial intelligence to be effective against certain builds, and less effective against others. Our ability to introduce new threats and areas for exploration means that we can help direct the ever-shifting nature of the equipment/build meta-game from behind the scenes.


  • Most actions have either a “cooldown” (for very powerful actions) before you can use that specific action again, and/or a post-action delay. Being in post-action delay means that you can move around and roleplay, but cannot take another major action yet (such as firing a gun). Post-action delay is the primary combat economy for Redshift, and is used to apply Horizontal Design to Damage-Per-Second, weapons, and utility actions like firing up a jetpack. That’s not to say that equal base DPS for all weapons means all weapons are exactly the same. For instance …


  • All weapons are inherently balanced, too. While all weapons have the same base Damage-per-Second, variables allow weapons to excel in specific combat situations. Fast-firing, weaker guns deal more damage to Armor Integrity (think: regenerating shields) over time; slow-firing, more powerful guns deal more damage to characters with high Base Armor over time. In addition, some weapons have increased natural accuracy (think: sniper rifles) at the cost of having a slightly longer post-action delay or lower base damage. The most damaging weapons might be very ineffective versus fast regenerating armor, and the weakest pistols may do very little damage to the heaviest and most protective armor. I won’t be sharing all of our lengthy, complex combat algorithms with you today, if only because they’re what’s most likely to change during testing. That said …


  • We’re all about transparency. In the Full Exo-Suit Documentation attached below, the first section shows a Standard Exo-Suit (the object that you will use to craft the Exo-Suit of your dreams), followed by four purchasable “finished” Exo-Suits with different strengths and weaknesses. The Standard Suit has the crafting economy attached to it and explained, for your perusal. All other Suits in the game will be designed by players, and will be a major driving force in the game’s economy. The rest of the document goes on to specify every other piece of Exo-Suit equipment that our players will find in Redshift when the game launches.


Combat Exo-Suit Objects (Click to Read the Full Document)


Great. But Redshift is a far futuristic Sci-Fi RPG! How could I do this on my High Fantasy RPG centered around Mages?

Well, I’d answer that question by being upfront. This is all quite experimental. No one game has found a formula for applying Horizontal Design that’s united game designers in the way that Blizzard did with Diablo 2 and World of Warcraft well over a decade ago.


But let’s imagine that I was designing a High Fantasy RPG with magical elements. Why not introduce magic to crafting in a way that allows for Horizontal Design? Let me give a very brief, but clear example below of his this could work. Note that the statistics are rather arbitrary:


In my fantasy world, certain elements can hold more magic than other elements. The more manufactured (touched by Man) an element is, the less magic it can generally hold.

A Wooden Staff – Damage: 2d4 – Enchanment Slots: 4
An Unrefined Iron Sword – Damage: 2d4 + 3 – Enchantment Slots: 3
A Refined Iron Sword – Damage: 2d4 + 6 – Enchantment Slots: 2
An Ornate Steel Sword – Damage: 2d4 + 9 – Enchantment Slots: 1


Above, I’ve created a horizontally scaling economy that states that one “Enchantment Slot” is equal in value to a “+3 damage bonus”. In designing Enchantments for objects, I would just make certain that an enchantment that uses one slot is comparable in average worth to +3 damage, or that an enchantment that uses 3 slots is comparable in average worth to +9 damage.


But, what about the difference between a Greatsword and a Dagger? Won’t the Greatsword always be better?

Well, only if you want it to be. The easiest place to start here is to make a chart:

Small Weapon (Dagger) — Damage: 1d4 — Post-Action Delay: 6 seconds
Medium Weapon (Sword) — Damage: 2d4 — Post-Action Delay: 12 seconds
Large Weapon (Greatsword) — Damage: 3d4 — Post-Action Delay: 18 seconds


Above, you’ll see that all of these weapons should deal the same damage over time on average. However, combat math is not so simple, and fighting rarely happens in a vacuum with no outside variables. The dagger, for instance, will deal more damage over-time than its counterpart Greatsword once strength and material bonuses (or whatever variables you design) are created that directly improve damage per hit. Likewise, armor systems that reduce direct damage will benefit Greatswords if damage is multiplied after that reduction occurs. And so, we may consider providing additional bonuses to each weapon-type when they score a critical hit (“crit”) that are comparable in effectiveness, but useful in different situations.

Dagger: Inflict bleeding wounds (static health loss over time) on a crit. [good vs High Armor]

Sword: Disarm their opponents’ weapon on a crit, doubling their Post-Action Delay. [good vs Greatswords]

Greatsword: Inflict a wound on a crit, causing static damage reduction for 36 seconds. [useful vs Daggers]


While all of these bonuses are a small, simple sample, they serve well as an example or template. Horizontal Design doesn’t have to stop at statistics. You can use secondary effects to further balance different weapon types versus one another, in an effort to encourage character and build diversity in your game. Of course, everything comes down to extensive testing.


But, but, what about quality? Wouldn’t a master blacksmith simply make a better sword than an amateur?

Absolutely. But, we addressed this problem in the initial design for our theoretical High Fantasy RPG. Since magic takes to objects that are less manufactured by man, we can still balance the “poor” objects without creating tiers of quality. Perhaps a young blacksmith can only make wooden and unrefined iron weapons, whereas your experience blacksmith can make steel weapons. With this system, I might actually prefer a simple wooden weapon, if I intend to then take that weapon to the town Enchanter to have them craft some magic into it. In this way, you retain your qualities, but create an avenue that allows a Wooden Staff to still be as potentially powerful as a Steel Sword in the right hands.


Just be sure not to force your blacksmiths to have to grind their skill level up forever before they can make those steel swords. Since wooden weapons will be just as effective as steel weapons, when enchanted, there’s no reason to force that grind be a process that takes months of progression and solo-play on that blacksmith player’s part.


And, remember, you can always give your crafters other rewards for their skill level, beyond just creating superior equipment. Reduced timers between crafts, reduced resource consumption, and the ability to re-string or customize objects are all other means to reward skilled crafters without thrusting your game head first into the bowels of Power Creep.


Well, that’s all well-and-good. But I want to create a Game of Thrones-like RPG, with a Low Fantasy setting. None of the examples above even apply to me at all!

First, and I have to say this, it’s okay to tell your players to suspend disbelief a bit when it comes to balancing combat. We’ve all played video games. We’re all okay with it, so long as there’s an attempt to explain why things are designed in a certain way in the game. Players will be willing to accept that a dagger swings three times as fast as a greatsword, but deals three times less damage, even if that’s not entirely believable. But, let’s create another set of examples, this time assuming a world where characters are unlikely to have access to magic. Instead of trying to 100% balance the weapons’ statistics, we’ll apply a different sort of Horizontal Design:

A master-crafted steel sword: 1d8+6 dam, expensive, partial functionality after taking 80 object damage (1d8+1 dam)
A poorly-crafted iron sword: 1d8+3 dam, average price, partial functionality after taking 200 object damage (1d8+1 dam)
A wooden spear: 1d8+1 dam, inexpensive, can be repaired up to 100% functionality (1d8+1 dam)


In the above example, we’re looking at something akin to a hybrid of Verticle and Horizontal Design, which may be more appropriate for your game. A long-lived, wealthy character may be able to afford master-crafted steel swords, but as they wear down with use, they’ll inevitably become only as good as a a brand new wooden spear. And even though the poorly-crafted iron sword will never be as good as a brand new master-crafted sword, it will retain its full functionality longer.


Sure, this isn’t exactly how swords work in real life. Again, sometimes good game design must trump reality, and so we suspend disbelief. Every game does this in hundreds of ways.


The above system creates an upkeep/maintenance cost for those long-lived characters should they wish to constantly buy new, undamaged weapons and armor, which is a strong design choice as an economy drain. Designing the system so that your game’s wear/tear/repair system favors lower quality equipment makes the system a Horizontal Design feature, because it doesn’t punish new players or characters that can only afford a wooden spear. This, in turn, partially balances the natural advantages that a long-lived character would have, economically, in a purely Verticle Design of equipment progression.


And that leads me to my final point. Horizontal Design may mean different things to every game. I’m not suggesting we take out all of the Verticle Progression from our games. But we must be willing to ask ourselves how we can encourage players to engage in the core activities that we want them to. Finding the right balance of Horizontal and Verticle Design is something that we should all consider. Our story-focused games tend to be very demanding on time, but we also have some control over how demanding they are. Challenge yourself to find ways to introduce Horizontal concepts that will cut down on Power Creep and grinding; as designers, we are inherently creative problem solvers, and we should be well-equipped to address these issues.


By reducing grind where possible and sidestepping Power Creep when we can, we make our games more accessible to more casual players who may not have hours to play every day to stay competitive. And we still allow for our most devoted players to spend more time roleplaying and interacting with other players than they could before. And that’s what it’s all about.


Jaunt is best known for his work as Senior Staff and Lead Roleplaying-Admin for Shadows of Isildur (Northlands and The Mines of Moria), and for being the evil mastermind behind the creation of AtonementRPI, as well as the popular game’s Lead Designer, Writer, and Co-Owner. He is currently the Lead Designer and Writer for Project Redshift, a professional RPI. He has created and worked on numerous RPGs over the past 20+ years, with an equal focus and passion for both storytelling and game design.

Join the Discussion!

The post Just Say No to Power Creep (Part Two of Two) appeared first on Optional Realities.

by Jaunt at July 02, 2015 07:25 PM