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
Sunday, November 4, 2007
Demo 4 - A first look at the real interface
Subscribe to:
Post Comments (Atom)
Posts
2 Comments:
Sweet :)
I wonder how difficult it would be to set up automated testing to see how all these different technologies hold up under stress. I suppose it would require creating a test server that can create any number of processes where each one attempts to log in, move around, chat, trade, log out, repeat.
Why bother? I suspect it might be difficult to get more than a handful of people together for testing initially, especially if it's early days and there isn't much to see. Just an idea.
Anyway, now for me excessively long rant/guess on how to scale a mmorpg simply:
One central data server - holds a copy of the world database (landscape, quests, monsters) and the player database.
Many world servers - each one runs a copy of the world and has a local copy of the world/player databases.
So - player logs in to central server, he selects a world to play on (any as long as the server isn't full). A copy of his player data is shunted across to the world server's player database. The player is passed to the world server and starts playing. Any persisitent changes to his stats or items are saved in the local player database.
Finally he logs out. Any changes to his data are then shunted back to the central data server to be permanently saved.
The advantage is you can start out with one world server and then add more as (hopefully) the game population grows. Plus, people can still make sure they log into the same world if the want, as long as it isn't full up.
If 50,000 people were online at once you'd need 50 world servers. The bottleneck shifts to that central data store. Problems would surface if large numbers of people tried to log in and out at the same time.
What I'd do is queue up requests to submit or query data from the world servers. The requests to save data (someone is logging out) get priority. This means if it gets really busy you'll get players waiting longer and longer to log in. This seems reasonable, especially if you can display appropriate warning messages and estimate time to log in.
I'm too wondering how to test it all. For the server part, I can easily create hundreds (or thousands!) of NPCs walking around. That way I could see how well the server part runs.
The hardest part to test is the web service (post/get request from the client to the server). I'll probably have to create a desktop application simulating multiple clients but I'm not sure how this could be set up to work correctly.
As for multiple world servers, that's something I'll have to work on to separate account information from world (so a player can play on different worlds without creating multiple accounts).
It's definitely something I'm looking at since I wouldn't want to fail with this project just because the game can only handle 200,500 or 1000 players at the same time.
However, besides the account information being separated, once a character has been created on a server, it will be attached to this server. I won't give the possibility to switch a character from server to server since this could cause some odd problems.
Thanks for your input!
Post a Comment