 |
Show Changes |
|
|
|
Recent Changes |
|
Subscriptions |
|
Lost and Found |
|
Find References |
|
Rename |
|
Administration Page |
|
Topic Locks |
| Search |
History
| 10/25/2007 6:07:29 PM |
| Eiji |
| 10/25/2007 6:01:58 PM |
| Eiji |
| 10/25/2007 5:59:12 PM |
| Eiji |
| 10/25/2007 5:58:28 PM |
| Eiji |
| 10/11/2007 6:40:29 PM |
| Eiji |
|
List all versions |
Iron Thunder is set in the near future, when Virtual Reality has progressed to the point that a game is created that is played at centers called Battleplexes. At these centers, players load into a virtual reality chair and participate in shared combat scenarios.
Some games have talked before about how it takes 8 hours to walk from one end of the game world to the other. Some games talk about how huge their scope is. But how much of that is actual content -- areas that players actually want to be in? One game brags about how there is mystery and adventure behind every corner, and thats true -- for about a week after an expansion it released. Then everything is plastered all over google, and the mystery and adventure is replaced with whiney teenagers asking in chat channels how to do a quest over... and over... and over.
Instead, we are designing around the concept of a VR. We have IO Nodes, which are present in sectors. You can teleport to a sector by knowing its address and visiting the nearest IO Node. Instead of it taking 20 minutes or 45 minutes to get a replacement, instead of the replacement having to run through hordes of monsters, we focus on getting the players to where, odds are, they want to be -- playing the game.
Our chat system is based on XMPP, which is sometimes also called Jabber. One of the things about this is that we can interoperate with other chat systems, including Google Talk. Because of this support, it is actually possible to send a URL from in-game to a friend (via Google Talk, etc.) and have that URL launch our game, and take you straight to where they are (there is a restriction here -- you have to be in a system city).
As the game progresses, players begin writing small cheat programs that they sneak in. The VR is controlled by a set of rules and simulation, anything that occurs outside that set of rules is a "hack." The earliest hacks involved knowing what rules the VR did not actually enforce, and then exploiting them. Later hacks involved modifying code. Hacks are a "magic" system -- they are not "technically" magic, but they behave almost identically to "magic" in a fantasy setting.
White hacks are hacks that are entirely within game rules. White hacks are typically minor, short abilities. In a typical Fantasy MMORPG, we're talking about things like Armor buffs, Stealth, etc. the bread and butter type spells.
Gray hacks are hacks that skirt the edge of the game rules. In game terms, they operate based on "bugs" in the simulated VR. They violate basic game "rules" that are normally in effect, and as such may draw system attention if overly used (this is represented by temporary system faction damage). They also may cause zone corruption, but they are less likely to cause this than black hacks. This represents basic attack spells, most debuffs, etc.
Black hacks are hacks that outright violate the game rules. In game terms, these are hacks that inject code into the VR. These are extremely dangerous effects, and can cause significant corruption to zones. They will draw system attention (permanent system faction damage), and typically require assistance from an AI both to learn and to use (the AI usually, but not always, will be a daemon).
Daemon/God hacks are hacks that are used by the Game Masters/Referees and certain System Faction AIs. In some specific scenarios, a God hack may be granted (temporarily) to a player during a quest episode, when it is in accordance with the storyline for that episode. This class of hack also may be used during live events. God hacks never damage system faction. Daemon hacks will cost all permanent system faction if used in a system sector, on a system faction member, or if used in presence of a system faction member.
One way of thinking about this is also that you have standard abilities and feats. Those are your bread and butter abilities, straight out of any battle suit anime. Then there are hacks. If you've watched Code: Lyoko, for example, that is where we are headed with the hacks (roughly).
When gray, black or daemon hacks are used in a zone, they create corruption. This is tracked regionally in the zone grid. As a zone becomes more corrupt, the following things will happen:
* Daemons will tend to visit the zone more frequently
* Basic game rules will start to go haywire (for example, gravity might go to .5 -- or walls and floors might become bouncy and instead of leaving a dent, you might be rubber banded, etc.)
* Daemon portals (generators) will start to appear more frequently
* System (white) hacks will start to lose effectiveness
Daemon and some of the nastier Black Hacks will tend to cause this sort of damage nearly immediately. Gray hacks will have to be used fairly heavily to make even the most minor adjustment. This is tracked based on the cells the abilities are used on, so if you spread out the locations where you're using black hacks within the zone, you will be less likely to trigger corruption effects.
In a typical fantasy game, you have a tank who runs up close to a mobile, takes a lot of damage, and "holds agro." You have a ranger, standing back, firing arrow after arrow (and usually paying for ammunition). You have a caster wearing no armor, standing back, and flinging massive spells inflicting insane damage.
In order for this to be balanced, the tank and mage must have expenses equal to the ranger, and firing arrows at a distance must be no more nor no less effective than standing and tanking. It should not require a "magic party" to be able to go and complete an episode. Certain abilities should be beneficial, but there should always be more than one way of winning.
This is why hacks take ammunition, and all attacks use power. You can pick hack skills and ranged weapon skills, in any combination, but you'll be limited by the ammunition you carry in your ability to use them. This means a caster and a ranger are equals. There is no "first tier DPS" and "second tier DPS." Melee and ranged/hacks, likewise, can be picked in any combination. With melee, you don't have ammunition and you have a higher (not lower) damage. I want to point this out -- you give the melee class a higher damage, because they have to take damage for a longer period of time before they are able to counter attack. So melee needs to be higher damage, not lower, than mages.
During a charge, the archers attack the melees. Once the melees get to the archers, the archers are killed. Thats the historic model for archery vs swordplay -- the swordsman wins.
Specifically what I'm after is a more "street fighter," "Tekken," "PSO," "Samurai Showdown," etc. feel for the melee combat. That doesn't mean it plays like these games, but that it should feel more like those games -- where you have attack and counter attack -- than like EQ2 or WoW, where blind button mashing often can result in equal results to a well thought out strategy.
A melee player versus a ranged, at point blank, should have a distinct advantage. Watch a MA movie, like Jackie Chan, Chuck Norris, Jet Li or whatever -- when someone using MA gets to point blank range, someone with a gun is not going to be nearly as effective. Again, thats the sort of feel I'm going for, there may -- in fact -- be specific attacks for melee vs ranged, at point blank.
Similarly, time spent on similar difficulty encounters should be an equal level of reward. It is effort vs reward, not risk vs reward. Someone putting forth no effort also has no risk. In an easy case, where no effort is required, the two systems will yield equal results. Setting effort versus reward, on the other hand, is a much better system. For example, if someone spends four hours getting to a mobile, then (contested or not) that mobile should drop nice items. If the mobile is contested, in an open area, surrounded by weak mobiles that are soloable or one groupable, then that mobile carries no effort and the drops should not be as good.
This is my basic issue, for example, with how Sony does things. You have a contested mobile that is roughly the same difficulty level, maybe slightly more, than a mid-boss or late-boss, rarely of an end-boss, in a raid instance. There is no fight ramping up to it, there is no danger getting to it, in some cases, it is off on its own, with just wide empty space around it. It spawns on a regular schedule, a set number of hours after it was last killed, which allows a guild to keep it on a schedule.
My issue here is that the effort to kill even an early raid mobile in most raid zones is much greater than the effort to kill the contested mobile. Both are of equal risk. But the reward on the contested is much greater. Combined with the timer, it tends to result in guilds playing in some time zones being excluded from attempting contested mobiles, and it tends to result in one guild monopolizing the contested spawns. Before someone says this is whining, I've been there and done that. In EverQuest 1, there is no contested through Qvic in Gates of Discord that I have not killed more times than I can count. Been there, done that, have the T-shirt (literally). In EQ2, I've killed a few contested. But I hear the same complaints in the level channels there as I did in EQ1 -- namely that one or two guilds monopolize these spawns, and nobody else has a shot at them. Some of the contesteds we've gotten have been, ironically, because major raid guilds are holding some zones open overnight (by not zoning) in order to extend the time they have to work with them. Because they're doing that, the mobile spawns and some other guild gets a shot at it.
Then, if you look at loot distribution, rarely do the major raiding guilds just /random loot. Usually they try to ensure that loot is fairly split between members, either using a point system, or by letting the raid leader/officers pick who they think should get items. Many times, this is accomplished by having class leads.
The point system has the benefit of giving everyone who attends a raid "something" in return. The "something" represents an item on a later raid that they may be able to get. The raids that are the most progressed will always have a system better than randoming loot in place, and usually it will be a point system. The issue with leader/officer loot is that it is too easy to fall into a trap of favoritism where one or two players receive the bulk of the loot, or are perceived to be receiving the bulk of the lot. The advantage to a points-based system is that in a points-based system, there is no partiality or partisanism.
Going on...
My intent is to make sure everyone on a multiple-group raid in our game receives something in exchange. This doesn't mean immediate gains. Recognizing that most guilds use a point system, my thought is to simply implement it in-game instead of it being something managed outside the game. The basic concept would be to, again, use the rank system:
S-Rank: Incredible effort. Beat the event very quickly, completed all optional events, no disabled raiders
A-Rank: Really good effort -- beat the event very quickly, got all the optional stuff, not a lot of disabled raiders
B-Rank: Beat the event fairly quickly, got most of the optional stuff, not a lot of disabled raiders
C-Rank: Beat the event, didn't get much optional stuff or had a lot of disabled raiders
F-Rank: Failed the event
The idea would be to award tokens based on this scale, based on the "tier" or difficulty of the encounter. Then you can redeem those tokens for the actual prizes. This means everyone has to wait for their first items, but that they (eventually) get a choice of a rare item if they continuously perform well.
In my experience, games like EverQuest that using pathing nodes tend to perform very badly relative to games that use grid systems. Note that this does not imply that you can't have arbitrary geometry. You can still have a hand-drawn zone, where each grid cell contains unique geometry.
The difference is that a grid system can very quickly compute line of sight, for example, and mobiles can path with A*. You apply A* once on the grid as a whole, and then when necessary, you can apply it a second time to an individual cell that has geometry. The advantage to this is that you can very quickly determine line of sight, without consuming much processor power.
Similarly consider clipping. The fastest way to speed a task up is to avoid doing unnecessary work. In order to clip against a fulstrom, you must transform all objects to world, and then you must transform world to camera. You have to process all of those points and ploygons, and then determine which ones cross the fulstrom.
With a grid system, you draw two lines, and fill between them, and those are the cells that are potentially visible. If you have something like a mountain or a wall, both common scenarios, you can flag that and not process the squares that would be blocked (not visible) extremely efficiently. This means before you perform any transforms at all, you've eliminated 75% of the points, in a typical case. Similarly, the mobiles can use this same approach to quickly determine what they can -- or can't -- see.
If you use an octree, portal, or similar system, then you spend a lot more CPU cycles to eliminate a lot less polygons. For example, I can use 16 bytes across and 16 bytes up and down to represent visibility for a 104x104 grid of visibility. I can use 64 such arrays to store potentially visible for 64 steps of rotation. This is accurate enough. This works out to 16k. I can, extremely quickly, apply a bitwise and to compute potential visibility. This is much lower cost than any other mechanism, including portals and octree. I can then walk the rows quickly, and propogate blockages, to even further reduce polygon cost.
It is all about how many CPU cycles you need to eliminate how many polygons. The more work you can avoid, the more time you have to perform the other work that you have to do. Its also about using a data structure that can be multi-purpose. The AI code needs this same information, and a grid system allows the most effective AI. When you have pathing nodes, NPCs do stupid things. A* run across a grid never will almost never do anything stupid. With pathing nodes, the NPC still probably runs A* across the pathing nodes, but it causes the NPC to make poor decisions that can often be exploited by players, if every single node isn't tested.
It also has problems if you try to simplify the system. EQ1, for example, tried to ignore altitude for a long time. So rather than tracing a path through a castle to a balcony, the mobs would spaz out and run in circles underneath it. That is just bad design. With A*, they should have pathed through the castle. But that would require pathing nodes to take into account vertical displacement.
Note we aren't "dual engine," like a lot of games are. A lot of games have a dungeon engine for inside zones, and an outdoor engine for outside zones. Because we eliminate cells so quickly, we don't need two engines. A dungeon (in fact) will ramp up performance by a fair bit. 
Usually, it will be better than an Octree or portal system would be. It would be possible to place a portal system on top of it, but that should not be required or advantageous.
