From The Pile
Jump to: navigation, search
This article needs an introduction


Interface considerations

Interface mockup
  • Free-resize window.
  • Fixed-width sidebar.
  • Chat box with a sizing grip on top.

Money money money

Furcadia requires payment for several things, such as custom portraits, enhancements, pets and the ability to play as a human. Rule number one -- No ingame bonuses for real life money. If there's going to be payment to play this thing, it'll be to play in the first place. Special rights and pets should be earned or bought with ingame currency.


Probably have the players click on tiles to do some A* pathfinding. If the next tile in the path is blocked when you get there, reroll. Show a marker displaying the end of the path. Triggering an item from a distance should have the player move towards it first.

Spawn points

When a player connects, they'll appear at or close to their spawn point, which they can set through the tile context menu. If the spawn point is invalidated (because the tile became solid or nonexistant), they'll instead spawn at the default Common Starting Room.

Idle time

When requesting information on another player, this should include the player's idle time. To indicate this in a more straightforward manner, a player's avatar will decay as the amount of idle time grows longer. There are four states:

  1. Active - you're actively moving around and doing things. The tiles you occupy are considered solid to others.
  2. Idle - you haven't moved for a short while. You still look the same, but your position is not considered solid anymore.
  3. Not Even There - you've been gone for quite a while now and your avatar is grayed out and/or translucent to indicate this.
  4. Gone - when you come back, you'll be at your spawn point.

Types of things



  • owner -- whoever owns the map gets to place tiles.
  • name -- something descriptive such as "Town Square".
  • tile[] -- an array of tiles, ofcourse.
  • editors[] -- an array of other players who are allowed to place tiles.



  • image -- what the tile looks like.
  • solid -- can the tile be stood upon? Perhaps should have a default per tile...
  • floorHeight -- if the tile can be stood upon, how high should the thing be offset? If difference between current and next tile's floorHeight is too much, consider it solid.



  • image -- what the player looks like.
  • cash -- how much monies the player has.
  • decay -- the player's decay state. Read-only.
  • spawnpoint -- the location of the player's spawn point. Read-only.



  • image -- what the prop looks like.
  • owner -- whoever owns the prop can do anything with it.
  • map -- what map the prop "belongs" to.
  • solid -- can the prop be stood upon?
  • height -- if the prop is stood upon, how high?
  • Lua scripts for several things -- activate, pickup, drop...
  • The previous known "good" location in the map.
  • permissions
    • can be taken from the map -- owner, anyone, noone
    • can delete -- owner, anyone, noone
    • can pick up -- owner, anyone, noone
    • can clone -- owner, anyone, noone
    • can change image -- owner, anyone, noone
    • can change scripts -- owner, anyone, noone

A prop should store its previous coordinates on the map when picked up, so that if you attempt to take it out of the map and the required permission isn't set, it can be placed back where you took it from.


Touchplates are not a real thing on their own. They are nonsolid props with a script for being stood upon.


This part needs expansion

Will be executed server-side. The server sends side-effect messages to the clients.

Auto-locked exit

Starting with a prop, be it a hidden touchplate or a front door, set the activate script as follows. The exit will only work if Kawa is online at the time.

-- Assumes the activator variable is already set by the system.
owner = GetPlayer("Kawa")
if not owner.IsOnline then
activator:Message("The door is locked because Kawa isn't here.")
-- Perhaps grab the coordinates from another exit tile instead of hardcoding them?
activator:Teleport("The Lounge", 4, 4)

Example setups

This part needs expansion


Doing things causes short messages to be sent and recieved. They are in the form of XML snippets for easy parsing, and corruption can be detected by well-formedness constraints.

From the server

These messages will be sent on certain triggers and from scripts.

<movement player direction /> player takes one step in direction. Sent to all players on the map.
<turn player direction /> player turns to face direction. Sent to all players on the map.
<port player x y direction /> player instantaneously changes position to [x, y]. Sent to all players on the map.
<enter player map x y direction /> player enters map on position [x, y]. Sent to all players on the map, including player.
<leave player /> player leaves the map. Sent to all the other players on the map.
<drop player prop direction /> player drops prop in direction. Sent to all players on the map.
<take player prop /> player takes prop. The server can ascertain if the prop is within reach. Sent to all players on the map.
<message [source] type>... Displays a message in the chat bar of the given type. Types include things like speech, actions and notices.
<tile map x y id /> Tile on specified position is changed. Sent to all players on the map.
<playerchange oldhash newhash /> Player with oldhash has been edited, resulting in newhash. If newhash is unknown to the client, request information. Sent to all players on the map.
<propchange oldhash newhash /> Prop with oldhash has been edited, resulting in newhash. If newhash is unknown to the client, request information. Sent to all players on the map.
<player hash>... Describes player with hash in detail. Sent only to the client that asked.
<prop hash>... Describes prop with hash in detail. Sent only to the client that asked.


Client Server
Player presses a switch -- let's assume the switch is referred to as ID 7.
<trigger id="7" />
Server runs a script for that switch.
treatCloner = FindCloner("Vending Machine A's Cloner") -- null if not found.
treat = treatCloner:Trigger() -- null if failed, perhaps because cloner was empty.
-- we could check for that here and produce a more proper result.
activator:Message("The vending machine produces a treat.")

The script produces several side effect messages. Let's assume the Finalize call assigned ID 8 to the treat.

<message type="feedback">

  The vending machine produces a treat.
<newprop id="8" hash="...">

The player sees the treat and picks it up.
<take id="8" />
<take player="Kawa" id="8" /> (sent to all players on the map)
The player presses the switch once more. Another treat is produced, but with another ID.
<trigger id="7" />
<message type="feedback">

  The vending machine produces a treat.
<newprop id="9" hash="...">

<take id="9" />
<take player="Kawa" id="9" />


I've decided to tackle the various component parts first, in smaller testing projects. So far, I've got a reasonably functional pathfinder. It's nowhere near A* in quality, but it's pretty cool for something I wrote from scratch ^_^


If it were A*, it wouldn't duck into that alcove, but my point stands.

Personal tools