User Tools

Site Tools


absalom3demomodifications

Absalom 3 Demo Modifications

Overview

Absalom was one of the first flash RPG series. Games 1 and 2 were pretty fun. Game 3 was never finished. The game's author Kinsman released a demo, but it had a severe flaw. I have an idea to fix it.

TODO: replay the game to refresh my memory of it.

Summary

  • Replace the overhead map engine
  • Tweak the battle engine to have more action

Map modifications

Review of map systems

Absalom 1 and 2

Absalom 1 and 2 had side-view maps. The player clicked at the edge of the screen to move left and right. Continuing off ether side of the map would lead the player to the adjacent map. Additional paths could be accessed by clicking on background objects.

Absalom 3 demo

In Absalom 3, the view is overhead. The player's possible paths are marked by a series of yellow dots. The player must click on adjacent dots to move to the next dot.

Advantages:

  • The one map allows for branching paths in a single map.
  • RPG players are used to overhead maps.

Disadvantages:

  • Terrible UI. Having to click on every single dot is excruciating.
  • The distant perspective reduces the player's emotional attachment to the characters since you no longer see the closeup of the moody hero lumping around.
  • The player's perspective is changed, which will annoy fans who want everything to stay the same.

Proposed replacement map system

Turn the paths into vectors, or sets of vectors. Draw arrows on the maps in the general direction of each path. Clicking on the arrows or the target destination will cause the player character to start moving along the pre-defined path.

TODO: I should draw a picture of what I am talking about.

The paths should be designed so that a player can press one of the four arrow keys and it would be obvious what direction the player should go.

If the player is near enough to the end of a path, the adjacent paths should become visible. Selecting one of them will continue the player on the current path until the branching point is reached.

Possible retention of old movement system

Certain environments like cities could use the old close-up view system for old times' sake, with the new map system used for travel between locations.

Combat system modifications

Review of combat systems

Absalom 1 and 2

The combat system in Absalom 1 and 2 resembled Dragon Warrior or Phantasy Star in that you see a picture of your enemies on a black background. When any fighter made a move, you see static drawings of the fighter's actions.

Absalom 3

The combat system in the demo shows a horizontal view of the battlefield. All fighters are visible. You tell your party member who to attack and they run to their target and carry out an animated attack.

The distance to the enemy leads to a slight drop in hit chance, but not enough to make much of a difference in the game or to make the options of advancing or retreating worth doing.

Advantages:

  • Niftier than the old battle system.

Disadvantages:

  • Battles take longer. It's enough to negatively affect my opinion of the game.
  • Distance is not implemented well; there is no reason to advance or retreat

Potential improvements to the combat system

Speed of attacks

Different attacks may have different preparation, action, and recovery times. For instance, the brawler may be able to launch several attacks in the time that it takes the gun guy to fire and recharge his weapon, while Emma's spells may have a long preparation and a short recovery. Taking time into consideration, attack damages would have to be adjusted to rebalance the game. Generally, rapid attacks would need to be nerfed.

An attack could be considered as a series of actions with associated animations, with only one of these being the damage-dealing component.

Sit and watch

Give your fighters orders, possibly a set of several, then sit back and watch them carry them out.

Command Interrupts

You can give new orders on certain occasions. As to what occasions, that would need to be decided by the developer. Possibilities:

  • On player demand, by pressing a key or button to pause or slow the fight
  • Every ten seconds.
  • Every three attacks.
  • After a target is defeated.
    • Alternatively, fighters may be given enough AI to automatically attack the next target of opportunity.
Action Interrupts

For another form of interrupt, an attack may have a chance of be canceled by in-game events. For example, you are casting a spell when you get knocked upside the head. That might end the spell casting.

Emma gives the orders

Since Emma is the party leader, giving orders to the other party members may take some of Emma's time. If Emma is down, either someone else becomes the designated leader or the player is unable to give orders

Sub-Types of attacks

Attacks may have subtypes:

  • Feints - The player steps back after attacking. This greatly reduces both damage and enemy hit chance until the player rebalances. It also reduces the time it takes to carry out the attack.
  • Normal - The player moves to the enemy's position and attacks. No modifications.
  • Charge - The player moves to the enemy's position and keeps moving if the enemy is in a feint. This increases attack damage and damage received while in a Charge. It also adds slight delays immediately before and after attacking.

Some attacks may not be usable as feints or charges, particularly ranged attacks.

Attack subtype AI

The fighters would have a simple AI which automatically chooses what type of attack to use. You can set the team disposition to cautious, normal, or aggressive before a battle.

AI attributes might include:

  • Bravery - A base that never changes. Some fighters are more aggressive than others.
  • Morale - Increases when the fighter scores a hit, decreases when a fighter is hit or an allied fighter goes down. Mood is reset at the start of each battle based on the fighter's HP.

You may also adjust your team's mood by ordering a charge or retreat.

An AI is necessary for attack subtypes for two reasons:

  • We should not force the players to select this level of detail.
  • Monsters will be doing it too, so an AI should be necessary.

Blockers

Add a rule that a fighter cannot run past an opposing fighter who is not fighting anyone. You might give orders to go after the enemy archer standing in the back, but there a swordsman in your way! The rules are:

  • A fighter who is engaged in melee combat cannot block.
  • A fighter becomes engaged when attacked by an enemy fighter.
  • A fighter becomes un-engaged when the enemy fighter is defeated or chooses to attack a different target.
  • An advancing fighter must engage the first opponent met who is not currently engaged.

Fighters in certain states may be able to block multiple fighters, although they would be at a disadvantage when fighting multiple enemies.

Certain enemies may have the skill of avoiding blockers.

Certain ranged attacks may be blockable, and only target a blocker or nearer enemies.

Engagement malus

A fighter who is swarmed by multiple enemies may have difficulty dodging their attacks.

  • When a fighter attacks an enemy, that fighter becomes engaged to the enemy.
  • When an unengaged fighter comes under attack, that fighter becomes engaged to the enemy.
  • When an engaged fighter is attacked by someone else, the attacker has a bonus to hit percentage.
  • Engagements are broken when either fighter is defeated or the distance between them exceeds a given limit.

Defensive "attacks"

AI-controlled fighters may go into a purely defensive posture that greatly reduces the enemy's hit chance and damage while improving their morale and willingness to attack.

There is little reason for a player-controlled fighter to defend. RPG battles are won by attacking.

Defensive “attacks” would take a very short time and may be used by the AI when an enemy attack is imminent.

Area-effect attacks

The battle system could support area-effect attacks. The question is whether it is desirable to have any in the game.

Metadata

{“TOPICINFO”:{“author”:“DeltaTango”,”date”:“1315882403”,”format”:“1.1”,”reprev”:“1.1”,”version”:“1.1”},”TOPICPARENT”:{“name”:“WebHome”},”GameAboutFormTemplate”:{“GameGenre”:“Unspecified”,”Inspirations”:false,”GamePerspective”:“Unspecified”,”ProjectLegality”:“RightsRequired”,”ProjectDifficulty”:“Unspecified”,”TargetPlatform”:“Unspecified”,”TargetERSB”:”???”,”YearOfIdea”:false,”DesignVersion”:false,”DesignCompletion”:“Needs Work”,”CodeVersion”:false,”CodeCompletion”:“No code”}}

absalom3demomodifications.txt · Last modified: 2013/11/28 04:30 by deltatango