Goldmine for tilesets

I knew something like this had to exist!

Once again, I was doing various Google search trying to find some free graphics to use and I found this: http://www.tekepon.net/fsm/. They have a bunch of tilesets free to use as long as you include the copyright text and link to their website.

Read More......

Out drag and drop, In context menu

Removing any possibility of drag and drop is a big hit for my project. Drag and drop is such a natural way to interact with an interface that it was clear in my mind that pretty much everything would be handle this way. Unfortunately, javascript,s drag and drop use way too much CPU and freeze everything else...

I tried different ways of integrating drag and drop without much success. The drag just takes too much resources and freeze every other loops required to animate characters and NPCs.

One way to deal with it could be to completely hide the "world zone" while dealing with interfaces such as inventory and to resynchronize everything when the inventory is closed. I'm still not sure if I really want this since it will give a very bad feeling of extreme lag.

The way I'm handling all this for now is with context menu. So in the inventory, each item have a menu appearing on right click with options such as "Equip", "Drop", "Unequip", ... It's less intuitive but doesn't look that bad either.

Note that I'm using Prototype and Scrip.aculo.us and that the performance problems I experienced with drag and drop aren't related to those libraries. It's just too expensive to constantly check for mouse movement and refresh the position of an object.

I knew that working with Javascript would bring some issues but so far I'm mostly amazed at what I've been able to do with it. Now I can't wait to test this on the Internet. I'll probably looking for a VPS in december (or maybe wait after the holidays) to test the Alpha version.

Read More......

Demo 4 - A first look at the real interface

It took a lot of work to come up with this first version of the real interface. I had to deal with a lot of performance issues and javascript voodoo magic. Yep, the more I'm working on this, the more I realize how powerful javascript is and how you really have to be careful how you put everything together. It doesn't take much to get something sluggish.

First, some warning about the video. I'm still trying to come up with optimum settings for Wink and I'm not very successful. The speed at which the characters are moving in the video is actually faster than it really is.

However, the "lag" you see when the screen load (NPCs suddenly changing places) is somehow normal. I added a check on characters positions when a zone load. The reason is that between the time the zone loads and the first events received by the server, some events are missed by the client so the characters are not shown where they should really be. With this check, I make sure the characters are all at the right position.

In the prototype, avatar animations were done using animated gif. Of course, it was only temporarily. Now, avatar animations uses sprites. You can see how it's done here: http://demo.rexsong.com/200705/Sprite_Animation

Here's a sample sheet



This sheet only includes the walking animation. The actual final sheet will include more stuff for things as melee and range attack.

All avatars are created using Charas Project (zoomed at 225%).

There's actually no new functions in this demo. It's only showing the code of the real interface in action. It also reveals the dimension I will use for the game, grids of 20x10 with cells of 48x48 pixels.

So here it is: demo 4

Read More......

How I handle action on the interface

If some are curious, there's a post here about the technique I'm using to handle events on the interface (characters and NPCs movements, attacks and such). Now the real question is how much the browser will be able to deal with before everything becomes too laggy.

So far I've only tested with 1 character and 4 NPCs at the same time and I had no problem at all. I'm guessing that if there was 50 avatars on the screen at the same time things would be a bit different but if that's ever the case, I guess that'd be a "happy problem".

I won't wait long before testing this since it might have an impact on how movements/events are dealt with.

Read More......

Getting a responsive interface

Now that one was a nice challenge. In the first 3 demos, you might notice that movements of avatars were done one after the other and not in a fluid way. Of course, it was ok for the prototype but it was clear it would be unacceptable for the final interface.

After 4 days of pulling my hairs, I finally got it.

My first shot was to lock the keyboard while movement was processing. What I mean is that when a move event was received, the interface couldn't send more /move commands to the server until the animation was done. You need to remember that avatars are moving inside a grid and there's no "free" movements here. So when you move your avatar, you're moving from one cell to another.

Of course, this first shot gave strange results. The avatars were lagging and strangely, I had some difficulties to reset the keyboard state (well, the keypress event) to allow back movements. Anyway, it gave me some weird looking code so I knew I was off track.

After I tried to separate client movement from server events, meaning that a player's avatar movements were handled only by the client while events were sent to server for other players to see. Again, that wasn't a good approach. I ended up with the avatar not showing where it should really be on the server and again weird code for synchronizing events sent with movement on the client. That and all my collision logic was thrown out the window this way (to prevent the current avatar to walk over buildings and such).

Finally, it came to me. All events really need to be raised by the server (as movement) to make sure that what is seen is really what is on the server (assuming there's no lag). Any avatar (current player included) should really only move when the server allow it. And an event sent to the server should really not be aware of what's happening on the screen. The delay between each moves is handled on the server anyway.

So now, each events received are added to an array of events linked to an avatar. Then each avatar has its own thread looking for events inside its array. If an event is available, it is executed and the loop is on hold to prevent 2 events being shown at the same time on screen. This way, I've been able to get fluid avatar movement while a key is hold.

All of this seems pretty trivial now that it's working but I had a hard time figuring out the good way of doing it. Now, I need to do some heavy cleaning on this code and will probably have to tweak some interval values for the loops.

The demo will have to wait since I want to have at least what I had in the last one before showing it. One's thing sure now, things are really getting exciting!

Read More......