User Tools

Site Tools


places:advtutviii

PLACE COMBAT PROGRAMMING OVERVIEW

By Dirk Vanderhuge

On these and following pages I will attempt to outline in detail how I created a system for player combat inside Places against whatever monsters and NPCs a Place owner wishes to pit them against. This system can be found in A Metal Ring in the Sand (two south of New Pittsburgh) at the moment, but also in Stonehenge/Valskyr (three south of CC404) at a later time. Before I begin, it is necessary to lay the foundation by which I proceeded:

  • This is a resource intensive process. By which I mean it will require massive amounts of wood, stone, C&Cs, memory chips, programming grids, rows, and columns, Builder's Brews, and above all, your precious time. I could not have achieved what I have without the efforts of a great many others who assisted in providing what was needed.
  • I do not think of myself as a particularly clever programmer with the Place system. It is very likely that someone more clever than me will see what I did and find a better way to do it. When I hit a wall, I tended to go with a brute force approach by throwing more resources at the problem. If you find a more elegant solution, by all means include it as an edit on these pages and footnote it.
  • I wanted this to provide a mechanic by which a scripted combat event could happen within a Place, whose resolution could then be used to conduct other programming actions within the Place, while still allowing for Role-Playing writing to have a major role. In short, I wanted the system to inform the RP, not replace it. One could even opt out of the event's mechanics entirely if one chose and bypass the program straight to the resolution. To encourage the use of the system, this ABORT OPTION would have a mechanism in place that would limit the resolution phase to the minimum actions necessary to advance the plot of the encounter, such as incrementing a quest status memory state, unlocking or revealing doors, showing post-conflict dialogue page links and things of that nature.
  • I wanted the potential combat encounter to include multiple enemy types with varying difficulties. Enemies are classified as either Mooks or as Bosses. Mooks are cannon fodder, serving little purpose in the fight other than as an obstacle that must be overcome, in such a way as to make the player character look good. They are the faceless stormtroopers, the orc horde, the generic Nazis, ravening alien swarm type foes. They have no “hit points.” A successful attack against a mook takes that mook and potentially other mooks out automatically. Bosses have hit points, and at the present you can fight only one Boss type in an encounter.
  • For group play, an encounter represents that player's “share” of the fight. Obviously people are going to have characters who are not good fighters, or prefer not to engage in toe-to-toe combat with slavering monsters from Beyond as a matter of roleplaying. The ABORT OPTION allows them a way out of having to deal with this, so that they may do what they wish in Story instead.
  • Encounters are what I am calling “semi-global.” What I mean by this is that one player triggers an encounter, which flags that encounter into a global memory. Any other player who does a page refresh in that room or who enters after the flag is set will have that encounter “loaded” into their individual memories, thus “picking up” the fight. This flag will remain set until someone completes that encounter, at which point the global flag is set to zero. This means that once someone has resolved their encounter, no one else will be able to join in, while anyone who has already joined in will continue their “share” of the encounter. For players who don't want to use the system and ABORT, this can cause problems in group play that must be made known to the players early and often, as they can deny the encounter to their friends without meaning to. Having a banter tab set to local in an encounter room where everyone can chime in that they have the encounter loaded up before anyone ABORTs is perhaps the simplest solution to the problem without resorting to further programming.
  • To facilitate this system, there is an INVENTORY system that is an integral part of the Place game mechanic. A MELEE WEAPON memory slot, a RANGED WEAPON memory slot, a SPECIAL WEAPON memory slot, an ARMOR memory slot, and three GEAR memory slots were set aside for this purpose. Equipping a weapon or armor or gear will increment the relevant memories appropriately, and when a Character Stat update function is called, the weapons, armor, and equipment will increment the character's game stats appropriately. All equipment can be purchased and sold in several “shops” located within the Place, and a running tally of what is being carried can be accessed with a page link called INVENTORY where provided.
  • Player Characters select one of eight CLASSES for adventures in the Ring, or possess one of three VALSKYR STONE mementos for adventures in Stonehenge/Valskyr. One's CLASS affects what combat actions one can use within the combat mechanic. Each CLASS has a minimum of five SPECIAL ABILITIES associated with it, whose effects will be described elsewhere. SPECIAL ABILITIES have been limited to 3 uses within a single encounter. Resolution of the encounter will cause a COOLDOWN that resets their use. Future GEAR options may include a COOLDOWN within the encounter. Further SPECIAL ABILITIES may be unlocked through various means.

PROGRAM DETAILS

places/advtutviii.txt · Last modified: 2023/11/21 18:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki