The Cabalist

Kyr · Post by **Kyr** » February 5th, 2006, 9:33 pm

The idea

I have an idea for a unit that, when recruited, comes into play with another unit, an Automaton.

The Cabalist is the controller of the Automaton and can order it to Attack or Move. Any Cabalists attempting to issue commands to their Automaton outside of a 5 hex radius of the Cabalist, will be unable to control the Automaton and it will cease to function, unable to return enemy attacks.

The Cabalist himself is not learned in the arcane ways of shaping and harnessing energy to assault his enemies.

The Automaton is an extremly strong unit, capable of taking most blows without falling, and cutting asunder enemy ranks.

Descriptions of these units

The Cabalist is an apprentice in the art of Vivification, whose focus includes that of the life force of the beings around him. Through this understanding he can animate substances, like clay and special metals, into the form of his choosing, and order commands to the newly animated object. This complicated process requires that the cabalist spend a small amount of his lifeforce to fuel the Automaton. Whenever the Cabalist has the desire, and required life force, he may refuel his Automaton, restoring HPs.

The Automaton is the spent lifeforce of the Cabalist, animating the substance of choice through magical means. It obeys all commands given by the Cabalist. It is uncompatible with cabalists other then the creator, due to the nature of the ritual of animation.

Art

I have no art for these units yet, but if anyone else finds this idea worthwhile and interesting, feel free to post some very rough art.

Coding and Abilities

Any Automaton more then 5 hexes away from the controlling Cabalist will cease function, and be unable to return enemy attacks.

A Cabalist within 5 hexes of his Automaton may heal it for 8 HP every turn.

Any XP recieved by the Automaton will be transferred to the controlling Cabalist instead.

If an Automaton falls in battle, the controlling Cabalist may refuel the Automatons HPs, restoring the Automaton by 8 HPs.

Any cabalist who reaches level two commands greater control of all lifeforce, and bestows a 40% damage bonus to the Automaton.

Statistics

Cabalist

Level: 1
Cost: 24
Race: Human
Alignment: Lawful
Moves: 5
Unit Type: Small Foot
HP: 24
XP: 60
Advances to: Master Imbuer
Attack one: Staff (Impact, 5-1)
Ability one: Refuel Automaton (8 HP restored to the Automaton on the beginning of the controllers turn)

Often dabbling in arts other then that of the common Mage, the would be user of the esoteric turns his studies to another ancient art, that of Vivification. On becoming a Cabalist, the elders of the Cabal help the new Cabalist to construct and maintain his first Automaton, and from there on he continues to grow and sharpen his skills. Who knows what powers the Cabalist holds?

Automaton

Level: 1
Race: Living Construct
Alignment: None
Moves: 5
Unit Type: Armored Foot (Poison Immune, Drain Immune)
HP: 34
XP: Does not advance
Advances to: Does not advance
Attack one: Great Sword (Slash, 11-2)
Attack two: Bash (Impact, 3-2)

The creation of a Cabalist, the Automaton follows all orders issued to it by its creator. Constructed of magical Clay and imbued with the essence of life, the Automatons intended purpose is to be an unstoppable and undefeatable soldier of battle. Reinforced by the Cabalist, who has the ability to heal this unit, it can be ordered to Attack or Move. This unit will cease operation if its creator is slain.

Duke Guillermo · Post by **Duke Guillermo** » February 5th, 2006, 10:51 pm

I think that this is a little too difficult both in terms of coding and using. Where would the automaton appear when the cabalist is recruited?

Better, I think, would be to have two units, one cabalist, one automaton, that are both separately recruitable. The cabalist would have an ability Repair which functions as a heal of 8 HP, can only heal automatons, and can only heal one unit per turn. Automatons would have an ability Unhealable that would render it immune to all standard forms of healing (villages, heals, cures).

This would still encourage that 1:1 ratio and would be easier for both the programmer and the player.

I hope that helps.

Website · Post by **Sapient** » February 6th, 2006, 12:12 am

The automaton would also be immune to poison and drain I assume.

I think there is a golem unit in the path of the summoner or wizard wars Era. Hey, I wonder what happens if an animated rock gets stoned?

scott · Post by **scott** » February 6th, 2006, 2:02 am

I am envisioning a WML implementation of this. I have a proximity detection event, so that can be used to repair the automaton.

I'm not sure how to enforce the 5 hex limit. The same proximity detector can be used in reverse, but you have to decide on what to do when the automaton leaves...
- Do you bump it back to the border? If so, you have to figure out where the border hex is if the unit started from inside the move limit radius
- Do you deactivate it where it is until the cabalist gets there? If so, it would not be intuitive that the unit could move 4 hexes past the radius before being shut down
- Do you bump it back to the starting hex? If so, it would not be fully intuitive that it did not get deactivated at the border.

Any of those options would be ok - you just need to figure out which one to use. I think the deactivation option would work out the best. You can make another proximity detector for when the cabalist moves and reactivate the automaton.

If you want any cabalist to work with any automaton, that would be pretty easy. If they are exclusive matched pairs, you would have to store each unit when it is created, increment and check the value of a running counter, then alter its user description to use the number. You would also give it a unit variable set to that number.

Post by **zookeeper** » February 6th, 2006, 9:40 am

Would it be possible to have a colored line (Blue is nice) between the Cabalist and his Automaton?

I don't think detail this is really doable. What you could have, however, is to match them up with for example symbols or numbers floating above the units. So a paired automaton and cabalist would both have the same number above or next to them.

I think it would be best to allow the automaton to move beyond the 5 hex radius, and just have it shut down unless a cabalist comes in range again. I think it would also be intuitive enough, if you think of the radius as the range in which the cabalist can "issue commands" to the automaton. The cabalist can tell the automaton to "go to 17,20" quite independently, but when the automaton gets there, it's out of range and unable to receive further commands.

As scott pointed out, this should be doable in WML. Do you have some planned use for these units in a campaign or something, or are you just throwing the idea?

Kyr · Post by **Kyr** » February 6th, 2006, 4:49 pm

I was brainstorming for something else when I came up with an unrelated idea, and thought it would be an interesting concept for Wesnoth.

toms · Post by **toms** » February 6th, 2006, 5:29 pm

Kyr wrote:I was brainstorming for something else when I came up with an unrelated idea, and thought it would be an interesting concept for Wesnoth.

I canÃ‚Â´t use it now, but IÃ‚Â´ll keep it in mind for later projects.

Kyr · Post by **Kyr** » February 7th, 2006, 10:39 pm

If anyone can point me to some WML event and ability code using some on death events and proximity checks, please do so.

Mustelid · Post by **Mustelid** » February 7th, 2006, 10:53 pm

I think the basic idea's good, but agree that it'd work better if Automata were separately recruitable. I'm also not sure if there's any compelling reason why one Cabalist shouldn't run multiple Automata.

It'd also make sense if Automata couldn't level, but the Cabalist's levelling mostly improved the Automata - either through a superpowered Leadership-like ability only applying to automata, or granting the ability to recruit different types of specialised automata.

toms · Post by **toms** » February 8th, 2006, 2:47 pm

Kyr wrote:If anyone can point me to some WML event and ability code using some on death events and proximity checks, please do so.

Ugh. ItÃ‚Â´s hard but possible.

Code: Select all

[event]
name=recruit
 [filter]
 type=Cabalist
 [/filter]

 [set_variable]
 variable=cabal_num
 add=1
 [/set_variable]

 [store_unit]
 variable=cabalist
 kill=no
  [filter]
  description=unit
  [/filter]
 [/store_unit]

  {FOREACH cabalist i}

    [unit]
    type=Mechanic(or how your cabalistic creation will be called)
    description=$cabalist[$i].description|-creation
    x=$cabalist[$i].x
    y=$cabalist[$i].y
    [/unit]

  {VARIABLE cabalist[$i].description cabalist|$cabal_num}

   [unstore_unit]
   variable=cabalist[$i]
   [unstore_unit]
 {NEXT i}
[/event]

[event]
name=die
first_time_omly=no
 [filter]
 description=cabalist[$i].description
 [/filter]

 [kill]
 fire_event=yes
 animate=yes(I expect that you want it animated, but you may set it 'no')
  [filter]
  description=$cabalist[$i].description|-creation
  [/filter]
 [/kill]

 {CLEAR_VARIABLE cabalist[$i]}

#Maybe the last command cause problems. If yes, set this before your endlevel:
# {CLEAR_VARIABLE cabalist}
[/event]

I slightly get crazy by seeing ideas gone, even if I posted the WML fragment for it in.

But I hope, like everytime when it is such a thing, that you donÃ‚Â´t drop it. Please.

Esp. because this idea is really nice.

Kyr · Post by **Kyr** » February 8th, 2006, 9:08 pm

There are no errors when I use this WML, but it dosn't seem to do anything. I'm using it on Across the river for testing purposes.