MMO Demo 5 - Skill training, crafting, player housing

Click here for demo 5

Just a little disclaimer, I'm still not very good handling those videos. The "lag" you see is a result of this.

In this demo, you'll see better movement handling (because of point and click), skill training, crafting and how players can have a house.

For this demo I created 2 NPCs. Bob is a merchant selling houses, wood and iron. Jack is a skills trainer.

This demo shows Dak learning how to craft a small chest, buying wood and iron, craft his chest then buy a house and place his brand new chest inside his house. You'll even get a small glimpse at the guild interface but that's just a misclick from me...

You'll notice that the interface doesn't always react correctly (like on the first try to craft the chest, the first wood wasn't added correctly) but I'm still satisfied with it's current state considering it's still pre-alpha. I was expecting much more problems or glitches than that.

And don't worry, those horrible colors are just there to make it easier to spot different zones while testing. Like the red zones all around the play zone are used to move the character to adjacent zones.

Hope you'll enjoy this demo!

Read More......

Movement: Arrows VS point and click

From the start movement has been handle by keyboard arrows. I'm not really a fan of point and click movement in 3d games and my model was SWG. Move with arrows and click on skills located in the toolbar.

I never really looked back until yesterday when I was messing around in my 2 zones world.

If your gentle with the keyboard, the actual system works just fine. However, when you start doing fancy maneuvers (long run, switching direction really fast), the results are unpredictable.

It's true that it's been a long time since I worked on movement and that I'm now at that point of checking back everything but the technical limits of javascript and browsers might bring some problems.

When an arrow is pressed, a message is sent to the server, the event listener for keys is detached from the browser and is reattached half a second later. The listener is detached because constant key pressed brings some heavy loop that the browser have some difficulties to handle.

While the /move action is sent to the server, others /move action can be receive from it to show movement of the character on the screen. Between each /move action received, an animation process takes place to animate the character going from point A to point B.

As you can see, a lot of things are happening to move a character and synchronizing all of this can become quite difficult (and I'm not even talking of what happens if the client computer slows down). The character on the screen might not be at the exact real location with the result of the player holding too long the arrows and then the character moving 1 or 2 square too far from the desired location.

Like I said, all of this is not a problem is you're gentle with your keyboard... but I don't expect players to be (or the right thing to say would be I can't ask players to be). Now the question I'm really not sure to know the answer right now is "Will I be able to make the movement process more stable the way it is currently handled?".

There's probably some tricks I'm missing or maybe those tricks would be a bit difficult if not impossible to do in javascript. So that brought me to think about point and click movement.

First, a lot less signals would be sent to the server. To move 10 squares left, only one click would be needed compared to 10 /move commands with the keyboard.

Second, the ending position would really be for sure the desired position. No more "oops, I hold too long the arrow while the interface was trying to catch up".

So far it's all good. The downside is that more work on the server is needed to calculate character's position when a movement is asked (well, a new coordinate to go to is sent). I don't see this as a great problem but there's surely a small challenge there.

With arrows movement, the server is dumb. It only check if movement is allowed in this direction. With point and click, it needs to calculate all coordinates the character needs to hit in order to get to the desired location. I could do this in two ways.

The first would consist of going in straight lines. Player clicks on the interface, character try to go in this direction, if there is an obstacle it stops. The player then have to click somewhere else to get around the obstacle.

The other way is to use what the NPCs' AI is using: path finding. The code is already done for NPCs so I could easily use it for PCs as well. Player clicks on the screen, coordinate is sent to the server, server calculate best path to reach the destination, movements are sent back to clients one after another with the correct downtime between each movement (so the animation match the real location of the character) and if an obstacle is met, the character will go around without the need for the player to click elsewhere.

The main (only?) problem I see with the latest is that characters might sometimes go to places players didn't expected to reach the destination. Of course, the player would be able to change it's course by clicking elsewhere, sending a new destination coordinate to the server while the previous path to be sent is dumped.

What impact this would have on the interface? It's probably a bit early to know exactly since the toolbar isn't yet implemented. For now I'll probable just add it anyway while keeping the old method not too far and alpha testing should shine some light on this.

Anyone have some comments on this? Any links to keyboard VS mouse articles?

Read More......

Log as guest feature

If you're like me, you probably created accounts on numerous web sites just to take a look at a service or a game. And if you're like me, you're probably getting tired of it and most of the time you just don't bother with yet another account creation process.

Inspired by Maid Marian, I added a way to easily "see how it looks" with the "log as guest" feature.

For Chasing Tortoise, I made sure visitors could take a look at the game without having to create an account. Screenshots being limited, I felt this was a good way to get people more easily into the game. For this project, the "log as guest" feature will allow anyone to enter the world, freely walk around and chat just by clicking a button with all other features being locked.

There is 4 access level available so far: Guest, player, GM and admin. Each command is linked to an access level. Each time a command is sent to the server, a check is first made to make sure the current character has the correct access level to execute this command, higher access levels being able to invoke lower access level commands.

So commands like /addzone, /deletezone are restricted to the admin level. Commands like /createnpc, /ban are restricted to GM. All other commands are restricted to the "player" access level (like /open, /use, /trade, ...).

The only commands available to the "Guest" access level are /logasguest, /logout and /move. This way, guests are unable to trade, buy from merchants, open their inventory, open containers and so on. I'm even thinking of restricting guests to some zones to make sure this feature is not used for scouting or any abuse. The point here is to show what the game looks like so people can decide if they want to create an account or not.

The name of a guest player is automatically set to "Guest[guest id]", [guest id] being the first number available starting at 1 and counting up. When a guest leaves, the number becomes available again. I'll probably have to add some filter to prevent characters' names being set as "Guest###" at the account creation so each name remains unique.

The to-do list of features I really wanted to have at start now looks really short which is a good news. It means that really soon I'll do another pass at all commands to do code revision in prevision to start alpha in January. That's still a lot of work but I'm getting closer!

Read More......

Lazy design story - House pack-up the SWG way

House pack-up as explained at the top
http://swvault.ign.com/View.php?view=DevNotes.Detail&id=64

Read More......

Design story - SunTzo creates a guild

SunTzo has a dream. He wants to create a guild. He clicks on the "Guild" button and the guild window appears.

Two options are available: create a new guild or asking to join an existing guild. SunTzo type the name of his guild, Elite Tactical Unit, and then type the acronym that will be used for it, ETU.

He clicks the "Create" button and SunTzo receives a notice that the guild has been created.

Dak heard a lot of good things about ETU. He talked a bit with some of its members and decides to send an admission request.

He clicks on the "Guild" button and type the name (or it could be the acronym) "Elite Tactical Unit" and click on the "Ask to join this guild" button.

SunTzo opens his guild window. In this window, he sees on the left the current members of the guild and on the right the request to join the guild. He sees that Dak has requested to join the guild. He right click on Dak's name and select "Add" from the context menu. Dak is now a member of ETU.

From now on, SunTzo and Dak are able to chat on the "Guild" channel which is a private channel available only to members of ETU.

From the guild window, SunTzo also have the possibility to kick members out of the guild or even to delete the guild. Dak's options are limited to quiting the guild, see the current members list and see the join requests. Options shown for Dak and SunTzo (guild leader) are different even if they both click on the same button to access the guild window.

Read More......