We are not going to be able to take relay message outside of game server very easily for several reasons:

1. Game server level information associating character/player ids with sockets to preform a relay
2. Relaying is an input only event. We receive input messages and send them to a different source.
3. Routing and multi-casting needs to be done and this is also game server level information

I propose we keep it where it is but expand it to work on all messages that have a destination rather this be a character or a channel. We can simply look for the presence of a dst field in the input message (if just client to server there should be no dst the client just write the message down the socket) or if there is a chan field defined. These two conditions tell us the client wishes to relay this message to some other client on the server. I can think of a couple ways to implement this:

• Have the server check if dst and chan exist in the message if so run RelayMessage on it. Then if you want to filter by command have it check if that command has relay perms.
• Keep the structure much like it is and add explict calls in each cmd_X() to RelayMessage this way would be quicker but take up a bit more code bulk. This is of course its disadvantage it is not as flexible and needs to be rigidly defined.

A couple decisions we made:

• The background isn’t going to try to be photoreal, instead we will build layers. Similar to google’s ‘hybrid’, ‘map’, and ’satellite’, only more like checkboxes. One useful mode will be parchment map-like giving more symbolic cues than photographic ones. Also the ’satellite’ mode will be more about washes of colors and impressionism (you walk slower, the parchment lines show little inverse ‘V’s, the ground is brown with spatterings of white spirals… you get the feeling of being in the mountains, without having to visually see it).
• Movement rates and collision will use the same system, server-side: a simple grid division of your movement rate multiplier through the given area, and some possible flags (hinders flyers too, etc). The resulting grid that the vector lands in will be used for determination, regardless of passage.
• Map-based effect spells will be dumped into a linked list of shapes with a type (full square, circle, gridmap) for best-fit occlusion. These don’t scale that greatly, so there shouldn’t be that much emphasis placed on them.
• More emphasis will be placed on 2D-specific strengths: Oekaki-style drawing on the map will be able to be used as a communication medium between players.
• AoE spells might have a tradeoff of size of circle vs spread of damage, with minimum and maximums. Circles can be drawn easily with a click and drag (center->radius)
• Spells like summon wall, lifelines, etc can be easily drawn with a click and drag between two points. Some of these might snap to valid targets (players).

Some chat message types that we will need:

• msg - sends a message to a channel
• join - joins a channel
• part - leaves a channel
• mode - changes channel mode
• kick - kicks another member from a channel
• who - request list of members in a channel or by match
• roll - request a random number reply in a channel
• list - request list of public channels

There are probably 10x the number of client-side commands, but these are the message types to send to the server, and reply via.

I think most message types can be reused as return messages, since the server->client or client->server distinction will be obvious.

I am reminded of an atricle about games. To summerize players when interacting with a game expect feedback and the ability to change their input. They crave positive feedback, but negative feedback is a good learning tool as well.

CRAFTING

Let’s look at WoW for a bit and look at their crafting system. You gather the materials, aquire the correct recipe, and push a button. So there are 2 chances for fun: 1) Gathering materials, 2) Aquiring the recipe. In WoW #1 is usually the result of needing to grind certain monsters to get the materials. Grinding is typically boring. This brings me to a side point, making quests fun, but I will skip this tangent. #2 is either bought, or found on monsters. This part is really not hard nor too boring so i’ll skip this. Pushing a button is very boring and if you have to batch craft your in for a world of boredom. This is boring because they player is not involved in the process. His input into the situation is always the same it never changes. It is “OK, craft it.”.
We choose to eliminate the button press by making crafting interactive by using mini-games. By allowing the user to change inputs, providing solutions to the games you involve the player.
SKILLS

This is one place where it is easy in some sense and very hard in the other. By the vary nature of having skills the player is directly effecting what they are in the world. So they are able to see directly the result of their choices. The feedback loop is completed. On the other hand this is where we can fall into our biggest trap. If all skills focus on the same goal. Dealing damaging/stopping damage we have significantly flattened the whole scope of the character. This makes the other aspects of the game one dimensional. Skills need to reflect the other aspects of the game.
COMBAT

Combat is tactical and strategic. Information on your foe is just as important as having skill in a blade. This is not your typical select target and click. This kind of interaction gets boring and repeative. Having to change your tactics and stragetics based on your opponent and your knowledge of him make for a much more interesting combat that is hard to get bored of.

Another possible pitfall. Someone doesn’t want to be a scholar like job. They would not be able to figure out anything about the foe and would not enjoy the tactical aspect of the game. It would become click and prey for the character. I propose a basic information bar be provided to all characters so they can at least be stragetic and tactical.

SOCIAL

This is perhaps the easiest one. People provide their own interaction. We just need to make tools that facilite communication properly. I think we are going in the proper directions with our channel system.

WINNING

Winning in an rpg is a bit nebulus. Most people consider winning an rpg to either be the best or one of the best. Even this I don’t think is good enough. I think the real secrect to an rpg is you can NEVER win. If a player has won they are finished and have no reason to stick around. The trick is to keep giving the player positive feedback. Keep giving them more and more challenges. Look at PNP RPGs you can go on forever and ever with these things. So the challenge is creating more and more high end content to keep the players interested. PVP in this game promises to be more interesting considering the number of abilities and the slot
limits. PvP, raids, and PvP raids are a lot more promising in this system.

QUESTS

Quests are the part where we need to figure out how to make them engaging and not repeativite. Having live DMs helps with this but I think our automated quest system should be more advanced. I will post about this in another post.

I would like to go over some of our discussions and decisions regarding communication in the blog setting, so Jeremy, you can ignore the future-tone of this post:

Most MUD-derived online videogames (this means almost all of them), have an interesting duality: they continue along ’state of the art’ graphics, sound, story (ok, only sometimes), and ‘virtual world’ concepts. One thing that’s particularly ancient is chat. Most MUCK/MUSH/MUDs and IRC are actually MORE advanced and capable in serving a communication medium than MMOs are (granted, it’s all they have). Many ideas and discussions have been made about revolutionizing chat.

(more…)