Showing posts with label concept. Show all posts
Showing posts with label concept. Show all posts

Monday, May 19, 2014

Mining system

Just a concept for now.

Resource gathering is an important part of every crafting system. An important resource would be ores and minerals mined from the depth of the earth.

It would, of course, be unthinkable for a wizard to take a pickaxe and perform manual labor to excavate minerals. Like everything in Pecosia, there is a branch of magic dedicated to these kinds of jobs: Geomancery.

Geomancery is the art of using magic to sense minerals in the earth and getting them to the surface. A geomancer hunting for ores needs two spells: A detection spell which tells him where the minerals are hiding and a mining-spell which gets them to the surface. More advanced minerals do of course require more advanced geomancery spells to find and mine.

Detection spells:


Prospect

The first spell cast by a geomancer visiting a new location. It tells them if and which minerals can be found on this map, but not where.

Probe

Tells the geomancer if there are mineral deposits in range and how far they are away, but not in which direction. It does so by telling the caster the level of mineral radiation at its current position. The closer they are, the higher the radiation. However, when there are multiple deposits in range, their radiation adds up which could mislead the geomancer.

Sense

Tells the geomancer the direction of the next mineral deposit, but not how close it is. When there are multiple deposits nearby, the vector-product is created and the angle of that is shown, so again, multiple deposits in range can be misleading.

 

The Mining spell

When the geomancer believes that she found the deposit, she will use the mine-spell. It will reveal any mineral deposits in range and turn them into items which can then be picked up. The mine-spell is much more MP-costly and slower to cast than the detection spells. So while a geomancer which just casts it randomly might find a deposit once in a while, one which uses probe and sense will be much more successful in the long run.

 

All of this should not be hard to implement. But before I start I need to work on some bugs. I am using a spreadsheet for a while to collect any bugs I find but do not feel like fixing right away, and it has grown quite long. Some are of the we-can-live-with-that-for-now level, but there is also a very critical bug which makes the whole network system unresponsive under some condition which I definitely need to take care of before starting with any new features. There are also some worrysome bugs which are not that critical, but very hard to reproduce. Multithreading is hell.

Tuesday, October 22, 2013

Balancing through number-crunching


After the stressful summer with the election and my sailing hours I wanted to continue development right away, but instead of that I decided to use the distance I gained from the project to take a 2nd look on some of my code, so I was doing mostly minor cleanups and refactoring.

Then I decided that it is time to start with the content. But when I wanted to do so I realized that I had no idea what I was doing. What's a good experience yield for a Level 5 monster? How much is a spell supposed to cost? How much defense should a level 10 robe have? Just making up values on the spot would not have been wise, as I would have to balance it through trial and error. So I decided to buy some Magic Chart paper (cool stuff, by the way. It clings to any surface through electrostatics. You can easily move them around without leaving a trace. You can draw on it with dry-erase marker and just wipe it away just like on a whiteboard) and summarized all the level-dependent formulas I have.

While doing this I realized some balancing errors which would have been quite bad in practice (MP increases quadratic but MP regeneration just linear - ooops). These handy charts will make it much easier for me to make up content.

Monday, February 4, 2013

Equipment revamp

While creating the buyable equipment for Wenibe, I noticed that there isn't much equipment can do. It can modify the players stats, but I would expect it to have more fundamental properties. Clothes should reduce damage and wands increase it. They should also be geared for specific situations.

Clothes

Clothes always have a general defense value, and can have special defense values for specific elements which are higher or lower. When the equipment has a special value for the element which is used by the attacker, that value is used, otherwise the general defense value is used.

When an attack hits the character, for each piece of equipment a random number is generated between 0 and the applicable defense value. Each of these numbers is subtracted from the attack. No total immunity is possible that way - even weak attacks have a low chance to break through high-end equipment. But considering that a player character usually wears 4 defense items (hat, robe, belt, shoes), the resistance is still pretty reliable when all of them give about equal defense.

Weapons

Weapons could have these effects:
  • Increase damage
  • Increase range
  • Decrease casting time
Staff Rod Wand Stave Scepter Cane
Damage X X X
Range X X X
Cast Time X X X

I think I should make these percentile boni.

Just like with clothes, a weapon has a general value and specific different values for specific elements.

Each of these effects could only apply to a specific element. That way you have to choose between a general-purpose weapon which boosts all elements or a specialized weapon which only boosts your favorite one while giving a malus to the opposite element.

I could also imagine rare weapons which give all spells a special property, like making all spells vampiric.

Friday, January 18, 2013

Rest system number crunching

I did some more number crunching with the rest system, and noticed the two constants which are most important:

1. the base of the logarithm
2. the reduction factor per minute

The reduction factor - how many percent of rest the character loses in each minute where it does something exp-worthy -  is most important to define the "cutoff duration" - the length of a play session after which the exp bonus becomes negligible. Due to the exponential decrease it doesn't matter much with how much rest a character starts out. This affects the duration just by some minutes. A reduction by 1% makes it possible to play from dawn till tusk until the bonus falls below 1.5%. A reduction by 2% gives you an afternoon of good exp. With 3% reduction, it's about an evening. When I put it up to 10%, the fun is over after less than an hour. When I set it to a whooping 50%, you burn through your exp bonus in 10 minutes.

a lower base of the logarithm makes the rest system more effective overall, especially after longer breaks. The lower the base of the logarithm, the higher the rest bonus a character starts with after a break.

Sunday, December 30, 2012

New and improved quest API?

The current concept for scripted NPCs has various shortcommings. When I want to implement scripted quests with interesting tasks, I also need to add scripting abilities to killed monsters, item pickups, map areas and lots of other stuff. All of that wouldn't hurt, but it makes programming of a complex quest awkward, because the code is in all sorts of different places. It would be better when it would be possible to implement a quest from start to finish in a single file with no or minimal editing to the entities which are part of the quest.

So I thought that it might be better to define each quest as a list of quest steps. I would have a global ScriptManager, which manages the current quest of each player character which is currently ingame. When some event happens somewhere which could be relevant to a quest of a player character, an InterMessage is created and caught by the ScriptManager. It then checks the current quest step of the player. When it is resolved, a script function attached to the QuestStep is executed. This script can either return a new QuestStep, or nothing to end the quest.

Quests are started by scripts. Usually during talking to NPCs, but I could imagine other situations which trigger quests. NPCs should gain a "quest hint" property, which consists of quest ID, a minimum level, a variable and its value. When a player fulfills these criteria, has no active quest, and hasn't completed that quest yet (which should be indicated by the value of the variable), the NPC should be highlighted.

These are possible types of quest steps:

QuestStepKill

Kill a mob spawned by a specific SpawnArea.

QuestStepCollect

Own a specific number of items.


QuestStepExplore

Get to a certain location.

QuestStepNpc

Interact with a specific NPC.

QuestStepScripted

Wait for a certain variable to change to a specific value.

Players should also be able to abort a quest at any time to start a new one. When a player does that, the quest needs to be started from the beginning.





Wednesday, November 28, 2012

Script for the tutorial

  1. player learns how to equip an attack spell
  2. player kills some non-aggressive, they drop a piece of equipment
  3. player learns about equipment
  4. player fights some aggressive enemies
  5. player gets a healing spell and is instructed to heal to full hp
  6. player learns about trading by selling the loot of the monster they just fought and buying a barrier spell
  7. player is instructed to use the barrier spell to survive a gauntlet-like scenario

Thursday, November 15, 2012

Get rid of accounts?

After I moved into my new apartment I again have some spare time for my game. I wonder if I should maybe get rid of accounts and instead have passwords for the characters themselves. Really, what do I need accounts for? I don't plan to bill by account, and when a player wants more than one character, they can just register a second one. Having accounts just adds a whole lot more complexity without actually adding much value.

Any per-account limitations I could enforce would just cause people to register multiple accounts to circumvent them. Any per-account perks for players, like easier item exchange or easy switching between characters, could be substituted by adding a "link character" feature. You log into characer A, click on "link account" and enter the name and password of character B. Now the two characters - as well as any characters already linked to them, are then considered to be owned by the same player. The player can then switch between them without needing a password and can easily exchange items between them.

This would allow to have "lazy registration" like, for example, in forumwarz. The player can play the tutorial without registration and is prompted to register after completing it. This results in a really low entry barrier.

Thursday, October 18, 2012

Rest system

Lately I was again thinking about how I can make my game attractive to those players who already have jobs and thus can't treat an online game like one.

To get some mental input on this I asked this question on gamedev.stackexchange.com. I was actually pretty surprised to get an answer from someone like Josh Petrie, a Guild Wars 2 developer. But the other people who answered and commented also had some interesting points.

I decided that the first thing I will do to level the playing fields will be a rest system. After a lot of number crunching in LibreOffice Calc, I came up with a rest system which works like this:

For every minute - online or offline - your character gets a "Luck" point (60 per hour, 1440 per day, 10080 per week). Your character has a luck bonus which is equal to log10(luck)-1.

All gains of skill EXP and SP are multiplied with your current luck bonus. The chance to get rare drops is also increased: Whenever you kill a monster, you roll ceil(luck_bonus) times for each drop. One successful roll is enough to make it drop. When multiple people kill a monster, the best luck bonus of all participants is used.

Every minute where at least one event occurs which uses the luck bonus, the luck points are reduced by 1% (that means your luck will never fall below 100, so your luck bonus will never be below 1).

So when you go to sleep at 10pm and continue the next evening at 8pm (after 22 hours) you will have 1300 luck points, which means that you will get a x2.1 multiplier for a while. After your 120 minute session, you will have about 400 luck points left, so your bonus will have dimished a bit to x1.6. These 400 points will roll over to the next day, where you will have a multiplier of 2.3.

Let's compare that to an unemployed power gamer, who will play 8 hour session, interrupted by 16 hours of rest. He will have 960 luck points the next morning, which is still a bonus of 1.98, not notably worse than yours. But after four hours, his luck bonus will be depleted and his exp rate won't get far above x1. It won't be above 2 the next day either.

Variables for balancing:
  • Increase the percentual luck reduction to make the multiplier go down faster
  • Increase the luck gain per minute to increase the exp multiplier after shorter rests
  • Reduce the base of the logarithm to increase the exp multiplier after longer rests

Sunday, October 7, 2012

Procedurally generated spells?

I played a lot of Borderlands 2 in the past weeks (great game, by the way) and noticed that the procedurally generated weapons are the greatest motivator in that game. I wondered if I should do something similar with the spells. Instead of having a number of predefined spells, players could find scrolls with spells which have randomized attributes.

Spells aren't learned anymore. Instead of that spells are items which are dragged&dropped in and out of the spellbook while in towns. Spells will still have a wisdom capacity they use and swapping will be impossible outside of towns, so players need to think carefully about how to design their spell palette. When each spell is unique and can only be used by one character, each character will have an unique playing style.

Balancing this will be really hard, but in the end it could be really worth it.

Input for randomization:
  • Element
  • Skill level requirement (primary indicator of the "power level")
  • Rarity
    • Rarity means more special effects, better chance for a more obscure area of effect, more extreme values for range and casting time and a chance for more damage.
Randomized attributes:
  • Damage (proportional to level requirement)
  • Range
  • Casting time (lower is better)
  • Area of effect
    • Single target (most frequent)
    • Splash damage with range X
    • Splash damage with range X, targets the floor 
    • Line damage (damages anything in a direct line between caster and target)
    • Chain damage (damages X enemies, each apart a distance of Y)
  • Special effects
    • Vampiric (steals HP)
    • Ethereal (damages MP instead of HP)
    • DoT (when combined with splash damage, it's an area denial spell)
    • Causes status effects
      • Curse (stat debuff)
      • Snare (reduce move speed)
      • Silence
Attributes calculated from those listed above
  • Mana cost
  • Wisdom cost
  • NPC value

To make all this a bit easier to balance, I could use a "building block" system where each spell has some randomized basic attributes and then gets a number of random blocks which modify it further.

  1. Start out with normal mana cost, damage, wisdom cost and range.
  2. Multiply mana cost, wisdom cost and damage with the level.
  3. Randomize all attributes just a tiny bit for some micro-variety
  4. For each rarity level:
    1. Do a "trade-off" - make one attribute worse by 25%, improve another by 25%
  5. Calculate base name based on the trade-offs made
    1. Good damage: Blast
    2. Good range: Arrow
    3. Good damage, bad range: Shock
    4. Good range, bad damage: Hex
    5. Good damage and range: Strike
    6. Bad damage and range: Trick
    7. Normal damage and range: Bolt
  6. For each rarity level above 1, do one of these bricks (discard duplicates). Each one increases cast time, mana cost and wisdom cost by a different amount.
    • Change the AoE (overrides the base name)
    • Make vampiric
    • Make ethereal
    • Add DoT
    • Cause a status effect on the enemy (multiple different ones are allowed, but not the same multiple times)
  7. Generate the name: [adjectives for bricks] [element] [base name]

Sunday, September 30, 2012

Large scale trading

Player/player trading is definitely a must-have because it allows to pass items in-the-field between party members.

But when it comes to facilitating a large scale ingame economy driven by supply and demand, this tool quickly gets to its limits. It's hard to find out who buys and sells what for which price. Players will have to help themselves by creating an external trade platform like a marketplace forum or (when there are some skilled but bored web developers in the community) a marketplace website. And even when people make deals via this platform, they still need to arrange an ingame meeting to fulfill the deal.

To make it easier to trade items with each other, I need an ingame trade platform which allows the players to:
  • place offers
  • browse other players offers (smart searching would be a plus)
  • accept other players offers and perform the transaction, even when the other party is offline
There are two types of items players can offer:

1. commodity items which are in high supply and demand
2. unique items

For commodity items, the price is the result of the current supply and demand in the community. They are often bought or sold in bulk quantities. For trading these items, I would like to create a stock-exchange like system where players place buy- and sell orders ("buy 25 ruby for 50 bugs each"). Like a real commodity market, the system automatically matches these orders and publishes the current price as a guide for buyers and sellers.

For unique items, this approach wouldn't be feasible, because they aren't so interchangeable that you could place a buy offer for them ("buying robe for lvl 25+ with at least 20 fire defense and +10 on ice magic skill and not too high weight and a beautiful color would be nice, too"?). So I would rather prefer an auction-house approach for selling items where players can offer items they found/made and other players can place offers for them.

There are a lot of interesting approaches to auctions, like the Vickery auction or the Dutch auction which might be interesting to try, but the eBay system where sellers place items with a minimum and maximum (instant-buy) price is so widely used that players might expect this system. I could still try to offer all of these auction variants in the same interface, though. The Vickery variant is especially interesting to me, because it doesn't discriminate against casual gamers who only check the market every few days and don't have the time to log in every hour to check that nobody overbid them.

Friday, August 24, 2012

How to do shopping

The shopping window allows the player to both buy and sell items. This is an important dialog window. Making errors while buying or selling could cause some serious damage to the player. But on the other hand, players will use this dialog quite often for annoying but unavoidable routine tasks like getting rid of vendor trash or stocking up on stock consumables.

So how should I design this from a usability standpoint?

The one-click solution

I put a "buy" button and a "quantity" input field (default: 1) next to each item in the vendor menu. While the menu is open, a "sell" button with a "quantity"(default: current amount) is added to the item detail area.

The drag&drop solution

Items are bought by dragging them from the vendor window to the inventory window. Items are sold by dragging them the other way.

While this is pretty intuitive and places the bought items right where the player wants them, it makes it hard to buy whole stacks or sell partial stacks (maybe ask it with a popup window?). It's also hard to communicate how much money the player will make with selling an item.

The bargain solution

This would mostly use a dialog I plan to use for player/player trading. The player drags the items they want to sell or buy from their inventory and the vendors inventory into a box. The sum is calculated on both sides and the difference is listed below it. When the difference isn't larger than the money the player got, the buy button becomes active.

This especially makes it more comfortable to replace equipment with more expensive one.

The Tibia solution

No, seriously. That's ridiculous for both usability and immersion. Whoever thought that using a chat parser to do NPC trading in a MMORPG would be a good idea, was either lazy, stupid or both.

Saturday, June 23, 2012

How to pick up loot

Putting items directly into the inventory.

Pro:
  • Very easy to implement
Contra:
  • No choice not to pick up items
  • Players might find ultra-rare items and not even notice it before checking their inventory
  • No way for the players to directly control who gets loot in a party

Picking them up from the ground.

Pro:
  • Enables drop-trading
  • you can see what other players around you find
  • Adrenalin rushes when you see something valuable drop
  • Enables mob/item interaction
Contra:
  • Either Inventory icons must be designed in a way that they look OK both in the inventory and on the ground, or every item needs an additional floor sprite
  • Enables drop-stealing
  • Items on ground can be unreachable or overlooked
  • A lot of netcode traffic is used for communicating drop position

Open a window to pick from when clicking on a carcass


Pro:
  • Convenient to decide what to pick up, especially for parties
Contra:
  • When killing a lot of enemies at once, checking them all for loot can be a chore
  • Additional click required to pick up items


I think I will first implement the "put directly into inventory" method, because everything I need to code for that also needs to be coded for the other methods.

Thursday, June 7, 2012

No quest log clutter

The problem with many RPGs of today - both single-player and multi-player - is that they figuratively bombard the player with quests. When you come to a new town you can quickly fill your quest log with 10 or so unrelated things to do. The order in which to do them is left to you. When you are like me, you prioritize all these quests after practical concerns: minimizing travel time, prioritizing quests with rewards I need, or do those first with the lowest level requirement.

The problem with that is that it really kills the narration of each individual quest. Adventuring and storytelling is replaced with managing a checklist. How can you expect the player to follow ten story arcs simultaneously?

For that reason I think that it would be better to abandon the quest log for a mission system like the GTA series. I give you lots of quests to choose from, and you are free to do them in any order you like. But you can only have one active quest at a time. You can abort a quest when you are stuck, but then you have to start it from the beginning. Quests won't be that long, so you won't have to redo too much. Longer storylines will consist of a series of many consequitve quests. The next quest of the series should be offered right after the previous, so that it's clear that they belong together. They still give you the option to decline for now and pursue other quests first.

That way you will be able to fully immerse yourself in the story of a quest without being distracted by the twenty other quests on your questlog.

But what about sidequests? Little surprise challenges along the way? These should also have a space, but they need to be designed in a way that they can be done in the direct vicinity so that you aren't taken too far away from the quest you pursue at the moment.

How will this look in practice? Quest givers will still be marked with different icons telling you 1. if they offer a quest of a new line or the continuation of an existing one (shape) and 2. the length of the quest line (color). These icons will be visible while being on a different quest, but you won't be able to interact with the quest givers yet.

Quest lengths:

quick: a single quest which can be done in the direct vicinity of the quest giver. These can be taken without interrupting an on-going quest because they will be too short to distract too much.
short: a single quest which requires some travelling.
medium: 2-3 consecutive quests, or one with a very long travelling distance and/or multiple optional sidequests along the way.
long: 4-6 consecutive quests, or less but with long travel distances
epic: 7 or more stations, might include planned interruptions where the next quest giver won't be obvious right away or which have "nested" quests - quests which require that other questlines (which will be integrated into the narration) have to be completed in-between.

Example for an epic quests with nesting: 1. find out about an artefact which is broken into three pieces, 2- complete three separate medium-length quests to collect the pieces, 3. reconstruct the artefact 4. use it to destroy a boss monster.

Sunday, April 15, 2012

Doing mapping with an external editor

  1. Copy the map file to your workstation.
  2. Load the map with the editor.
  3. Copy your changed  map onto the server with a temporary name.
  4. Warp to the temporary map name. Because there is no instance with that name yet, the server will create one based on the file.
  5. Test the map.
  6. When there are errors, go back to your map editor, replace the temporary map file and use the reset_instance command to reload the map instance.
  7. When the map is OK, replace the original file and delete the temporary one.
  8. Use reset_instance on the original map to activate the changes. Alternatively, restart the server.
An external version control system like git is needed to care about revisioning on the server.

Admin commands for mapping with the client

This concept applies to the option of integrating the map editor into the client. I haven't decided this yet.


Storing of maps: All map layouts are stored in the database. The database holds all past versions of each map.  The most recent one is the one which is used. 


Map editing: The mapper can change the layout of the current map on the client-side, but the server won't respect these before the changes are sent to the server using the map save command.

Gloassary:

Local map version: The map on the client side. Identical to the current map version until the mapper starts mapping.
map version: A version of the map stored in the servers database for version control purposes
active map version: The latest non-wip version of a map. This version is used for gameplay


Mapping commands:

map create [name] [l] [r] [default tile]* creates a new map. The first and active version has the given size and is filled entirely with the default tile.
map versions request a list of all past versions of the current map with timestamp, author and if it is active or not
map save [data] creates a new version of the current map which is identical to the local map version. The new version is not active yet.
map activate* the latest version becomes the active version.
map load [time] loads a version as local version which doesn't necessarily needs to be the active version. Time can be omitted to load the latest version.
map copy [name_to]* creates a new map name_to. The first and active version of this map is identical to the local version of the current map.
map overwrite [name_to]* creates a new version of map name_to which is identical to the local version of the current map. The new version becomes the active version.

*It should be possible to limit the permissions for create, activate, copy and overwrite commands to specific namespaces to prevent mappers from creating a mess of garbage maps.


Workflow without QA:
  1. The mapper teleports to the map which needs to be changed
  2. The mapper does the changes 
  3. The mapper uses map save to save the changes
  4. The mapper uses map activate to activate the changes
By restricting the activate and overwrite command to selected people a QA can be enforced. Workflow with QA:
  1. The mapper teleports to the map which needs to be changed
  2. The mapper does the changes
  3. The mapper uses map copy to create an active copy
  4. The QA teleports to the active copy and tests it
  5. The QA uses map overwrite to  replace the production map
To restore a map to an earlier state:

  1. The mapper teleports to the map which needs to be changed
  2. The mapper uses map load to restore the version
  3. The mapper uses map save to create a new version identical to the past version
  4. The mapper uses map activate to re-activate the past version

Sunday, February 26, 2012

Ring equipment system

This system should be adaptable to any fantasy-themed game.

A human has ten fingers, so why should one be limited to one or two powerful magic rings? Shouldn't one be able to wear a ring on each finger? And why should one wear only one ring per finger? One can easily wear more than one on each.

The reason is game balance. Allowing so many rings would mean that they would have to be pretty weak compared to other equipment, otherwise they would outclass everything else.

So I came up with a system which allows one to wear as many rings as one likes, but many rings disturb each other, so that they don't give their full effect. So the more rings you are wearing, the less effect does each single ring have. My formula is:

Efficiency per ring = 100% * (0.9 ^ (number of rings - 1))

Coincidentally, the effect of this formula is that adding more rings after 10 results in a reduction of the overall stat bonus instead of an increase, so there is no reason to do so. Exhausting this maximum is only advisable when all rings are of equal power. Otherwise the weak rings will drag the strong ones down.

Number of rings Efficiency of each ring Sum of effect of all rings
1 100% 1
2 90% 1.8
3 81% 2.43
4 73% 2.92
5 66% 3.28
6 59% 3.54
7 53% 3.72
8 48% 3.83
9 43% 3.87
10 39% 3.87

In my mage-war system - should I decide to use it - rings should only increase basic attributes and elemental protection. For tactical reasons any offensive elemental specialization should be visible on the character.

Saturday, February 25, 2012

A non-sucking combat system

There is no melee combat, only magic.

Each spell has a casting time of several seconds (so lag doesn't matter so much). You see exactly who is casting what spell and how long it takes (by a progress bar over the casters head) but not what's targeted. When an enemy casts a spell on you (or you assume that you are the target) you have three options:
  1.  move out of range before casting is finished
  2. cast an appropriate shield spell on yourself (you can only have one active at the same time)
  3. hit the attacker with a weak but fast spell hoping to break its concentration (useful when he isn't protected against your element)
Protection spells only protect against one element, so you must be prepared to change them when an enemy attacks with a different one.

Mana regenerates but health doesn't. Not a problem because everyone also has healing magic. But preventing damage with protection spells is always more economic (both in mana and in time) than healing yourself.

SpellDescription
Quick ShieldQuickly cast reaction shield, with a small buffer against one element
Strong ShieldTakes too long to cast to do it spontaneously, but offers a much larger HP buffer when you know what element you will be dealing with
Team ShieldA quick shield on someone else instead of you. Note that you can only have one shield spell active at the same time, so while your teammate is protected you are vulnerable. On the other hand these shields are cumulative, so a large party can make one of them almost invulnerable. You can also use it to help out a party member who is attacked while casting a powerful spell
BoltStandard attack spell.
BlastMuch quicker to cast than the bolt, but less powerful. A useful counter-spell.
StrikeTakes very long to cast, but is deadly when the enemy doesn't manage to do something against it.
HexHuge range, but low damage. Mostly an annoyance and distraction.
BallAn area-of-effect attack,
StormA large area-of-effect attack. It does damage over time, so it can be used for area-denial.
Cast-CancelVoluntarily interrupts the spell you are currently casting. You lose the mana, but you may keep your life.
HealRecovers hit points. Can only be cast when the target is not protected.

Attributes:

Willpower: Your max HP and your ability to avoid interruption while casting.
Intelligence: Damage of your spells
Wisdom: Max MP and variety of spells you can cast
Creativity: MP regeneration

The Spellbook:
Every mage has a spellbook which contains the spells he or she can use in combat. The spellbook can only be edited while in town.  It has a maximum number of pages which depends on the users Wisdom stat. More advanced spells take up more pages.

Spells can gain experience and can be leveled up. For each level, the spell can be enhanced with an upgrade point on damage, range, mana cost or casting time when added to the spellbook. But each enhancement increases the number of pages the spell takes up. So a player might decide to trade power for flexibility.

Equipment:
The most important equipment of a mage are hat, robe and staff (other equipment are gloves, shoes, belt, amulet and rings, but their stat boosts tend to be a lot lower). They tend to enhance only a single element, and also tend to be color-coded accordingly. So when you face an opponent dressed in red, you should prepare your fire shield. Said opponent could, however, be bluffing and has his spellbook filled with spells of entirely different elements. He might not get any equipment bonus for them, but the element of surprise makes more than up for it.

Why MMORPGs suck

Yesterday I felt like playing an MMORPG again (Runes of Magic, to be precise). And soon I remembered why I don't like them: They are boring! Sure, they throw in a lot of gimmicks, ways to advance your character and improve its equipment. But all the icing and decoration on the cake can't mask that the combat gameplay itself - and that's still the core of every MMORPG - is just crap.

You go to a mob spot, click a mob, push your skill hotkeys in the optimal order you've figured out after 10 minutes, and then pick up the drops. Again and again and again and again. Sorry, but that's not an interesting past time for me. Not when you have do do it hundreds (literally) of hours to advance. That's like working an assembly line.

But how could one create a combat system which is more challenging, more surprising, and requires strategic ability or fast reaction? In an MMO you have to deal with two limiting factors: Realtime and network latency. The realtime nature means that you can't pause your game and plan your strategy, like in Bioware single player RPGs. You can't have a combat system which requires fast reactions either (like in the Elder Scrolls single player RPG series), because of the network latency. Everything that happens on the server reaches the player between 100ms and 1000ms later, once in a while even much longer due to a lagspike (and that could mean a very frustrating death in the middle of combat).

But is it really impossible to design a fun combat system around these limiting factors?

Friday, February 24, 2012

Another scenario concept: Technology vs. Magic vs. Religion

A world in which magic, powerful gods ad science fiction technology coexist.

Technology
The followers of technology try to understand the world around them through research. Their enemies are the religious, because the technologists perceive their dogma to understand the world through the holy scriptures instead of verifiable facts as dangerous for the mind.

Government: Democratic
Values: Objectivism

Religion

The religious worship the gods - incorporeal beings of incredible magical power - and get favors from them in return. They believe that the magic users are stealing the magic which rightfully belongs to the gods. In their opinion it is a grave sin for mortals to use the power of the gods directly. For this sacrilege the magic users must be purged.

Government: Authoritarian
Values: Fundamentalism

Magic

The magicians are striving to control and shape the magic powers radiated from all living beings. They realize that ecological damage caused by the technologists is slowly destroying the ecosystem of the world and thus reducing the worlds magic. Their goal is to stop the technologists from harming the ecosystem and thus harming both the magicians and the gods.

Government: Anarchy
Values: Environmentalism


NoviceTankDamage DealerSupporter
TechnologyStudentMutant
A walking biomedical experiment. Mutants always seek to improve themselves through genetic modification, cybernetics and dangerous pharmaceuticals.

Weapon: Maces
Engineer
Gadgeteers always experimenting with new inventions. An engineer takes pride in designing and building their own equipment.

Weapon: Guns
Scientist
The theorists among the followers of technology, always wanting to understand the principles of the world around them.

Weapon: Emitters
MagicApprenticeRune Knight
These magical warriors - while physically merely average - use the arcane powers to enhance their combat abilities. They can conjure magical weapons and use auras in battle to distract and hurt their enemies in melee combat. 

Weapon: Amulets (used to conjure weapons)
Wizard
Masters of directing magic in form of destructive spells.

Weapon: Wands
Sorcerer
These magic users use their power to heal and empower others.

Weapon: Orbs
ReligionAcolyteTemplar
Fanatic warrior monks who defend their church with heavy armor and swords. In combat they pray to their gods for strength and protection.

Weapon: Swords
Exorcist
The exorcists duty is to find the enemies of the church and direct the wraith of the gods onto them.

Weapon: Knives
Priest
Demagogues who preach the word of the gods. They instill fanaticism in their followers and bless them with their gods powers.

Weapon: Staffs

Tuesday, October 18, 2011

Raid system: The cave of eternity

Randomly assigned parties progress through an endless series of small, auto-generated dungeon levels. Players can join existing parties at any time.

To get to the next instance, all monsters in an instance must be defeated. Then the party is automatically teleported into the next.

The larger and more powerful the party, the stronger the enemies, but also the bigger the rewards (even when divided through the number of players), so that large parties are encouraged. But because the monster power scales with the number of players, good teamwork is required for large groups.

Rewards are given at the end of each instance, but only to those which participated from the start of the instance.When you die, you can't rejoin the party until after the next instance has started. This means you miss out two rewards. You can, however, join a different party immediately and miss only one.  By encouraging switching over waiting to stay, parties are encouraged not to let people die and to create a friendly environment where people want to rejoin, otherwise the group will lose members and get worse rewards.

To spice things up, there will be rarely encountered special rooms, like boss rooms, extra hard "danger rooms" with deadly traps or "treasure chambers" with freebies for everyone.