Eternal Lands development journal

Second set of stats

2011-12-26T00:01:00.001-05:00

Chars created: 878
Tut started 514 (58%)
Got Reca 330 (64%)
Finished harvest 246 (47%)
Killed rats 211 (41%)
Made fe 196 (38%)
Found Kane 181 (35%)
Got sulphur 158 (30%)
Got Novac 146 (28%)
Got Xaquelina 113 (21%)
Got money 89 (17%)
Got sigils 83 (16%)
Got reading room 78 (15%)
Finished tutorial 62 (12%)

It seems that there is virtually no change in the numbers that started the tutorial, just 1% more. With the new trail of markers towards the tavern, there are a bit less finishing the first objective. Of course, it can be just some random fluke, not a big enough sample size.

Some statistics

2011-12-01T17:47:00.002-05:00

At the last update, I added some tracking code, to see how many of the new players start the tutorial, and how many finish it.
Here are the results (for 15 days)

1 log ins: 1907
3 log ins: 1428
5 log ins: 1267
Chars created: 740
Tut started 429 (57%)
Got Reca 294 (68%)
Finished harvest 226 (52%)
Killed rats 207 (48%)
Made fe 190 (44%)
Found Kane 175 (40%)
Got sulphur 144 (33%)
Got Novac 120 (27%)
Got Xaquelina 99 (23%)
Got money 85 (19%)
Got sigils 79 (18%)
Got reading room 73 (17%)
Finished tutorial 49 (11%)

The numbers are not too bad, but I want to see if I can improve them a bit, especially the percent of people starting the tutorial, and the percent of how many finish the first objective.
So for the next update there are two minor changes: The tutorial NPC is a bit bigger, and has white clothes, so he is more visible. The other change is that there are more map markers towards the tavern, so it should be easier to find even without the Tab map.
I am going to post the new results in two weeks.

For the next client update, sometime in late December or early January, I want to have a new tutorial island, with a new tutorial quest, which should slightly improve the number of people that don't give up.

Eternal Lands's is 8 years old now

2011-02-11T23:24:00.002-05:00

Actually, it will be 8 on Sunday.
8 years for an online game is a long time. Some our first players were young children, and now they are college age. Some were 15, and now they finished college and got a job. During these 8 years, some people met and got married. There are even a few children born because of EL. And, unfortunately, some of our players died too.

The game graphics quality has improved every year, and we have big plans for the near future. I hope to finally have some terrain in the game by the end of the year, and a better lighting model too. There are also some new changes to the texturing management system, which will bring faster map changes time, and less delay when walking in crowded places such as storages. We are also thinking of moving the engine to OpenGL 2, which will remove compatibility with some older video cards some people still use, so that we can focus on even more graphic and improvements. But we won't do that any time soon, probably not earlier than late 2012, so people will have plenty of time to update their systems.

One last thing: We are going to have some contests and events this weekend, to celebrate EL's 8th anniversary. Some of those contests were announced on the forums, while other events were not. So if you want to win some nice stuff, try to be online this weekend.

Achievements and more web site stuff

2010-11-30T17:38:00.004-05:00

Now that the new web site is almost done, I want to add a bit more integration between the game and the web site.
Recently I added some achievement system, where after finishing some quests or other tasks you would get a mention about it on your player page. The player page is located so far on the game server, and I want to change this.
Ghrae worked at a nice caching system, where the player statistics are cached in an MySql database on the main web site. When requesting the player stats, it will check first if the information is already cached, and if not it will get it from the game server and cache it. This system makes it easier to integrate it with the web page layout and saves quite a bit of bandwidth. It will also display the achievements nicely, with graphical icons. Hopefully this new page should go live in an few days.

Website redesign

2010-10-15T02:37:00.003-04:00

We are focusing a bit on modernizing the website and forums.
We upgraded to the latest version of IPB forums and gallery, and since the IPB 3.x skins are not compatible with the 2.x skins Roja is remaking the whole website (forums skin, web pages layout and theme, link locations, etc.)
Hopefully everything should be ready in about 2 to 3 weeks, possibly earlier.
We also want to add a bit of dynamic content to the main page, stuff like displaying the latest news, latest forum posts, and possibly latest events. Of course, we need to moderate very closely what ends up on the main webpage, we don't want links to penis augmentation or Nigerian scams being displayed prominently on our site. So we might have to restrict the posts displayed to forum sections where only moderators can post.

Right now I am not sure how to get the data from the IPB forums. I know that the IPB guys have an add-on, called IP.content which can do something like we want to do, but we are also looking at other available options. I think we only takes a few lines of PHP to extract the info we need, and it doesn't make sense to pay for money and tech support for IP.content. I will have to look more into it.

Webserver problems resolved

2010-09-22T01:20:00.001-04:00

Fortunately, our host got the web server back up pretty fast. The motherboard died, and it had to be changed, then there were a few problems with the Linux kernel not booting, but everything is back up, with no loss of data and relatively minor downtime (only a few hours).

Web server hardware failure

2010-09-21T14:03:00.002-04:00

My webhost contacted me about a hardware failure with our web server. It seems that the motherboard died, but the data is intact. They changed the motherboard, and the stock kernel won't boot, so now they have to see what is the problem. Hopefully it should be back soon.

Some advertising and a "Facebook, WTF?" [update]

2010-04-20T00:35:00.007-04:00

Many of our players suggested that we create a Facebook page for Eternal Lands. After a lot of reluctance, I finally got to it, and it's been pretty popular so far. The address is here, for those of you who are interested: http://www.facebook.com/pages/Eternal-Lands/102799149763320

At the same time, I wanted to spend some money on online advertising, and was trying to sample a few sites and advertising networks, to see where we can get the best result for the money. The Project Wonderful network is nice, and we got a lot of views and clicks, especially from The Noob comic, which is right on our target.
I tried Google AdWords, where I managed to get a lot of displays and clicks (about 400 clicks for 30 bucks), but they are low quality clicks, most of the people not creating an account with us.

Then I wanted to see if we can get a better result using the Facebook advertising network. So I created a FB advertiser account, carefully read the rules, and started to create an ad. In my humble and uneducated opinion, the ad was pretty tame. I added my CC info, and waited for the ad to be approved. I got no response over the weekend, then on Monday, I see the ad being rejected, for a violation of their guidelines: "Per section 5 of Facebook's Advertising Guidelines, this content is prohibited from being advertised on Facebook."
Their guidelines are here: http://www.facebook.com/ad_guidelines.php
For the life of me, I can't understand how our game violates that section (or any of the subsections). I took a screenshot:

This got to be one of the must puzzling and WTF moments of the year. I wrote them an e-mail, asking for more info about what part of their guidelines we violated, but I doubt they will respond. Meanwhile, we will use our advertising budget on Google and some other sites. I guess our game (and money) is not good enough for FB.

Update:
Got a response from the FB people, just as descriptive and helpful as the original one:

Hi Radu,

Thanks for writing in. Over the past few months, we've received significant user feedback about the quality of ads running on our system. As part of our continued efforts to improve our ads system, we're taking care to ensure that all ads adhere to the high standards that help to uphold the user experience on Facebook. These standards include accurate and truthful representation of the product or service advertised, the disclosure of all relevant consequences of participating in the advertised offer, as well as the protection of all user information received as a result of advertising on Facebook.

As a result, we will not accept ads that we've identified as promoting misleading offers. This includes ads for toolbar and game downloads that may affect the user's computer or browser performance in unexpected or undesirable ways. Please delete any ads that violate this policy within 48 hours in order to bring your account into compliance. We will not allow the creation of any further ads for these types of products or services. We appreciate your cooperation.

Thanks,

Lola
Online Sales Operations
Facebook

Finally an update

2010-02-14T01:58:00.005-05:00

I've been very lazy lately, didn't update my blog in over 6 months.
Well, this is going to be a short post, but I promise I will update the blog more often in the future. I don't have time to respond to the many comments I got since my last update, but I did read them all.

Anyway, Roja almost finished an overhaul of the most of the artwork, and we are now having higher resolution textures, better looking 3d objects, and a cleaner interface. We are going to hopefully have a public test client in about a week.

Meanwhile, a small preview of the new artwork:

Quests and new NPCs

2009-07-17T02:48:00.002-04:00

As posted in previous blog entry, the current focus is on the quests and NPCs.
I added 45 new NPCs, and 3 quests, and I don't plan to stop from doing that any time soon. Most players seem to enjoy the quests, and a lot of them actually talk to the NPCs and finish the quests. The increased rewards do help a little, I guess.
I also started to upgrade the scripting engine, such as adding the ability to make objects dissapear, and get notifications when a monster is killed. There were very few improvements to the scripting system since I originally added it in 2004, so now it's time to add a few more things to reflect the changes in the game since then. For example, there is no way for the script to know if mines or wards are in an area, and that can be used for some interesting quests.

There are a few quests that are kind of hanging in the air since 2004, and some players expressed their desire to have them continued, so I am brainstorming on a big quest related to the pirates that plague Portland.

Hopefully, by the end of the year we will have at least 10 NPCs in almost every map of the first continent, an by the next summer in almost every map of the game.

Quests

2009-06-02T15:11:00.002-04:00

I kind of run out of ideas for new things to add to the game, and I decided to focus on one aspect we were lacking: Quests.
In fact, I always wanted to have a game with lots of quests, that can be played much like a single player game, if the players chose to. But there were always other things getting in the way, so for the past 4 years there were no new quests (besides for a few new god quests).

Adding quests is a lot of work, and you have to be really careful and test them properly, or else there will be problems. Implementing a good quality quest can take 20+ hours, but since I have to do other things as well, it can take more than a week to add a new quest.

One of my dreams was to have about 10+ NPCs per map, all which are part of quests, or at the very least give some background information, to make the game feel more alive. All those NPCs must be connected in some way or shape, for example the NPCs on one map will talk about the NPCs on that map and even NPCs on nearby maps. Ultima 7 and Ultima 7 II do exactly this, and for this reason they still have a pretty big fan base.

Anyway, for the next few months I will try to focus most of my development work on adding more quests, and I hope people will enjoy it.

P.S. Most, if not all of the future quests will give experience in some skill[s], which will eliminate part of the boring, repetitive aspect of the game, and will give the new players a chance to level up faster. For example, if a quest gives 10K attack and defense exp, that's a lot for a level 20 newbie, but very little for someone who is level 80+

Cellphone games

2009-05-02T23:18:00.002-04:00

I've been thinking more and more lately about trying to enter the cellphone/PDA/PMP game market.
The advantages are quite big:
1. Big companies don't compete, so there is enough room for the small guy.
2. Those devices have limited capabilities, so there is no need for fancy graphic (3D) and anything complicated. Many devices don't have a touchscreen so the control has to be done with just a few buttons.
3. Since the development time is relatively small, you can sell the games for cheap (1-2 bucks), and most people would buy such a game if they like it, since no one cares about 2 bucks.
4. It MIGHT be possible to find some manufacturer to license your game and include it by default on their device. I am thinking mostly of the chinese PMP makers.
5. Porting the game on different platforms should be relatively easy, because we are talking about 2D games here. No external libraries are needed except for Zlib, which can be statically linked with the code, and all I need is to access the frame buffer, read/write files, read the buttons state, and sleep().

The only problem is the different screen sizes and orientations. Probably a different set of artwork would be required for each screen size, so the scene will look the same. I think it is poor taste to resize images on the fly on such limited devices, because it consumes CPU time, and, implicitly, battery.

What I have in mind for my first game is 2D quest game. It will look similar in a way with the Mario games, or the old Dizzy games, but, of course, with better graphics. So you'd be able to move left, right and jump. There will a key for accessing your inventory and using objects. In total, 4 keys, perfect for a cellphone or small device.
This game will use artwork from EL (pre-rendered), and will be based on the EL universe. I'll let you know if/when I have something to show.

Harvesting changes

2009-04-17T00:33:00.002-04:00

Recently I made a few changes in how the harvesting works. Mainly, I increased the number of events, which force you to actually pay attention to the harvesting process, to restart it when it stops due to those events.
Now, for those who don't harvest AFK, and harvest only resources that require a level smaller than their harvesting level, the change is not too drastic. There will be a slight decrease in the rate of the harvesting, perhaps 5-10%, but since it happens to everyone equally, I don't consider it to be a problem.
There were 3 reasons for this change:
1. The economy was flooded with too many items and resources, and almost every day more gold was coming in the game than going out, by about 15% on average.
2. Gold farmers had many harvesting characters which were used to make gold and then sell for RL $$$. Now, I don't have a huge problem with the gold farming, so long as you have to actually work for it. But having multiple harvesting characters that generate gold is not good for anyone except for the farmers.
3. Some players had harvesting characters which they used to supply their main character. While that is illegal, not everyone gets caught, so this will have a negative impact on the cheaters.

I expected that most of the people will welcome the changes, since it fixes some of the inflation, while at the same time impacts the cheaters and farmers, with relatively little impact on honest players.
But it turned out that I was pretty wrong. A lot of players complained that, omfg, now they can't harvest from school/work, or harvest while eating breakfast and taking a long crap in the bathroom. Others complained that now the harvesting is too boring because they actually have to pay attention(!) while harvesting.

Based on my tests, and the tests of some other players, if you don't harvest AFK, you don't have much to worry about, the resources harvested are about the same as before (and you get more harvesting exp in the process). Nevertheless, the rate of the random events was slightly higher than I wanted, so I will drop it down just a little bit.

Unlike most of the other games, in EL harvesting is almost painless and automatic. We have map walk, so you can get to the storage with just a few clicks. Harvesting id done with a few clicks as well. I think that those complaining should try some other games, and see if they enjoy it more there.

Anyway, the end result is that some people quitted, and many of them don't bring their harvesting alts online anymore, resulting in a players drop of ~10-15%. I am not really crying over that loss, but we will have to focus more on bringing new players and increase the player retention rate.

New stuff

2009-03-31T01:24:00.003-04:00

I have decided to focus a bit more on events and bringing more strategy to invasions.
Until recently, the invasions revolved around being strong and using the best gear. For the high end monsters, only the fighters had a real chance, and there was very little team spirit.
With the last monster, Mare Bulangiu, and to some extent with the Bulangiu, the things changed a little. Those monsters are pretty hard to fight in melee combat, due to their high armor and damage. In order to kill them, it is best if you employ some different methods at the same time.
For example, people can harm them, while the archers can shoot at them, and the summoners can summon rats to save the tanks some hit points. And with the last Mare Bulangiu, people actually did that.

So now I was thinking to improve that a little. I want to implement a few new things:
1. New summoned monsters that will be relatively cheap, but be better tanks than the rats, who die in one hit. Another monster would have the mirror skin perk, which can help a lot. Maybe even something with the self destruct perk. This new monsters would need a relatively high summoning level, however.

Then I can add some special mines that do more damage vs invasions, and some special arrows and bolts that can have some new effects over invasions as well. I am not sure when I will add all those new things, but I hope I'll do it in a month or less.
Afterwards, a lot more people can contribute to the defeat of the evil forces :)

The economy

2009-03-07T01:36:00.002-05:00

EL has a really big economic side to it, and although players often complain about stuff, they mainly like it if they keep playing the game.
One of the biggest problems is that the manufacturing skill does not bring enough income. This is mainly due to the fact that there is a very fierce competition between the players, and often the end product is sold at a loss. Many players try to make great swords, in the hope that they will get lucky and produce an enchanted version. The non enchanted versions are sold at very low prices, because the demand is smaller than the production rate.
I always told those who complained about the economy, as though it is my fault, to actually take the matter into their own hands, and not lower the price to below the value of the ingredients. Now, it seems that they finally realized that it might be a good idea to do so, and they agreed to go on 'strike' and not sell items at a loss, which is great.

Now, there are a few solutions to this problem, but, as with anything, some people will love them, and others will hate them. For example, one solution would be to increase the break rate of the great swords (which I did). Before doing that, there would be one or two great swords breaking each day, which is not that much considering that there are probably 100+ players using them. Assuming a totally equal chance to break one, that means that each player has a chance of about 1.5% to break a sword in a day, which means that a sword would last, statistically, 2+ months. Given the fact that the cost is only around 20-25Kgcs, that's about 400 gc per day, which is not that much.
Another solution would be to make a formula that produces the enchanted version of each sword, so that the manufacturers can reliably make them. Of course, the formula would have to be quite expensive, and use ingredients that cost at least 200 Kgc. The formula would also need to require a very high manufacturing level, in order to reward those who worked harder.

Another way to help the economy in general is to add new gold sinks. The more important the gold becomes in the game, the more valuble it is, which drives costs down. On a related note, the archery skill is not that useful (although it has some uses).
So to address both issues at the same time, I came up with a new potion that cost 15Kgcs, available for now only from the NPC (which means, it is a gold sink). This potion permanentely increases by 1%, up to 60% the chance to do a critical shot with the bows and crossbows. A critical shot means that all the armor penalty is removed.
So a player who spends 900Kgc and has a high ranging skill can be quite competitive in PKing (especially if they are in a team).

New stuff

2009-02-15T03:05:00.002-05:00

Well, it seems that it will take a little while until I'll start working at the map editor, so in the past few weeks I did some 'clean up' stuff. Things like adjusting some monsters to be more useful, changing some spawns, removing the TS 'loop hole', adding a few new special days, etc.

Right now I am working at two potions that will decrease the attack and defense levels by 5, up to -30 of your current level. They will use dragon scales, and will require a high potion level, which takes care of a few issues: Too many dragon scales in the game, top potioners not having enough potions to do for their levels, and some fighters who fall in between monster levels will now be able to gain more exp. Now the attack and defense levels increase every minute towards their nominal value, even if you are hungry, so this kind of training will be quite expensive.

I am also working (right now in the design stage) at an awards system. It will be similar to the top players list, but it won't be based on levels. Instead, it will be based on 'achievements', like how many rostogols stones lost, how many rare items harvested or manufactured, how many Leonard kills, etc. It will be reset every month, so even somewhat new players will have a chance to be there. There will be no in game advantage if you win those awards, it will be just for fun (and some glory :D). I am hoping to have this sytem implemented by the end of March or earlier.

Update on the new engine

2009-01-25T01:36:00.002-05:00

The new engine Xerafax has been working at is going pretty well. Right now, it can load and display all the EL maps. It is not yet ready to be integrated in the client, because there are a few things still missing (LOD for the objects and reflections, the shadows system is buggy, the water is not displayed properly yet, and all kind of other small issues).
However, it should be good enough to finally start working at that map editor.

While I've been waiting to start working at the editor, I did a few nice things on the server side:
Implemented the potions god quest.
Added a new random day, where there invasions happen more often and are stronger.
Made a new potion, called potion of Speed Hax. What it does is double your speed, but will consume 1 unit of food every 2 steps (50% chance per step). Once the food level gets under a certain number, you will stop for about 1 second, then you will revert back to walking.

I have a few other things in mind, such as some new random days, an archery god quest, and maybe a new shape shifting form. I am not sure how many things I'll be able to do until I start working at the map editor, but I will probably be able to work at the editor and server without neglecting the other.

Update tomorrow.

2009-01-09T02:49:00.002-05:00

We are ready for the 1.8.0 update, I uploaded the clients, and the update and download page.
This client should be pretty stable, and it is, hopefully, going to be the last client using the current engine. I am not sure when the next update will be, probably by the end of the year or in early 2010.

There are a few nice features we have in the 1.8.0 client:
1. Support for riding (for now, we only have horses, but in the future we can have other mounts).
2. Support for running. This feature has been requested for ages, and we finally decided to implement it.
3. Some GUI improvements and minor bug fixes.
4. Updated artwork (3d objects, monsters and textures). Now some parts of the game look much nicer with larger textures.

Update coming soon

2008-12-27T02:57:00.002-05:00

We released the second RC a few days ago, and almost everything works fine, with some small problems that were fixed. I'll release another RC tomorrow, then if there are no other problems, we'll have the update sometime during the first week of January.

Today me and Roja did some tests with polygons and textures. I told her to make some spheres with 180K triangles, and map them with 4 4096x4096 textures, then place about 40 of them in a map with few other objects.
This test had a few objectives:

1. See if on modern video cards the fill rate is a concern (and it isn't, replacing the textures with 256x256 variants didn't affect the frame rate at all.

2. See if the camera rotation jerkyness in some maps is due to the number of triangles or the number of objects. The results of this test were a little surprising. All those objects were placed in a small map with water all around them. The shadows were on too, so the scene had around 15 million triangles. With reflections, the frame rate was somewhere around 35 fps. The camera was very jerky, even though at that framerate it should have been pretty smooth. Disabling the reflections increased the FPS to about 45 (a little less than I expected), but the jerkyness was virtually eliminated.
Furthermore, in Kusamura Jungle, a map with 15K objects, if the reflections are on the camera movement is very sporadic, and the FPS is around 25 FPS. With the reflections off, the FPS is just a little higher, but camera is very smooth. Even stranger, by limiting the reflection distance to 30 meters (it was 100 before), the camera is as smooth as when there are no reflections at all. I really have no idea why the reflections cause this problem..

3. See if there is any speed benefit in consolidating a few objects into a single one (same number of triangles, but fewer objects for the scene management.) This test is not done yet, we'll have to do some more tests tomorrow to see.

All in all, this test took very little time to do, and the results were pretty useful. One idea I came up with is to add in the map editor a way to automatically flag the objects that should not cast a reflection. For example, an object that is far from the water, or near the water but very small, should not cast a reflection. Similarly, a bigger object like a cliff should cast a reflection even if it is further from the water. Right now, all those decisions are made in the scene management routines at runtime, which is not the best way to do it.

In other news, Xerafax went on a nice vacation and will be back sometime in mid Janaury, and I won't start working at the map editor until then, because I need his help. That means I'll have some time to work at the potion god quest.

New engine

2008-12-10T14:40:00.002-05:00

Now that the first instance is on the main server, and I almost finished implementing the next instance, for levels 80 to 100 a/d, it is the time to disclose my plans for the future.
After finishing the second instance, I'll take a break from server programming for a while, and work at the new map editor, that is using a new engine written by Xerafax.
This new engine is quite nice, because it will use vertex programs only, so there is a significant performance increase. It will also work on most of the video cards our players have, including the Intel 950. Unfortunately, we'll have to drop the support for some really old video cards, such as Intel 8** cards, TNT 2 and other cards that don't support vertex shaders. Based on the information the client sends to the server about the video card capabilities, less than 5% of the players will be affected, and those people will have to update their computers/video cards.

So anyway, I am going to spend some time working at the new map editor. I would like to do some texture painting for the terrain, implement a function to randomly add detail 3d objects such as vegetation, small rocks, etc, and other misc. things to make the map editor usable.

I am not sure how long this will take, but I am looking forward to do it because for the last few years I've only done server programming, and it gets a little boring after a while.
Of course, that doesn't mean there won't be any more server updates soon, because I'll still add new items and more instances, but there won't be a lot of new features until the map editor works the way I want it to work.

Instances (again)

2008-12-02T00:38:00.002-05:00

I finished about 70% of the instance work, and have a limited test yesterday with a few moderators. I am still working at adding more unique monsters and some unique items for prizes, and I hope that in a few days the instances will be available for everyone to test.

For now, there will be only one instance, for those over level 100 a/d (although on the test server everyone will be able to go). The reason why there will be only a high level instance available initially is so that if there are any bugs, the problems will be limited to only a few players.
Since the instances take place on maps not available on the client yet, those who want to participate will have to manually download the maps. This will, of course, be fixed with the next client update, which I hope to have in a few weeks.

Instances

2008-11-19T01:12:00.002-05:00

I decided to add some instancing to EL, to spice up the fight.
This is how it will work (although some things might change).
There will be a few new maps that are instanced, and the following conditions will apply:
1. One player can go there every so often, which is defined by each instance type. The time between going there again will be something like 100-200 hours.
2. Most, if not all of the instances will have minimum and maximum a/d requirements, so for example a pr0 player won't be able to go and spoil the fun for the newbies.
3. Each instance type will require a certain number of players to go in (a minimum and maximum number).
4. There might be a cost associated with going in an instance.
5. Most (or all) of the instance monsters will be unique monsters, with unique drops.
6. To join an instance, a group of players will have to join a secret channel that they chose. Then they will all go to an NPC which will teleport them to the desired instance. To prevent abuse, all the players from that channel must stay near the NPC.
7. If you die in an instance, and you have a rostogol stone, you will be placed at the beginning of the instance, so that you can rejoin your friends.
8. There will be 5 (or more) monster waves, that is, if you kill a wave, the next will spawn shortly after. Those waves will be somewhat random, from a predefined set of possibilities. The final wave will be a 'boss' type of monster.
9. The drops will be unique items that can not be obtained in any other way. My current plan is to make some really powerful items, but they will have a high chance to degrade, so the game won't be full of them.

That's pretty much it. I don't know exactly when they will be in the game, probably in a month, if everything goes well.

Kqueue implementation done

2008-11-16T14:31:00.002-05:00

Last night I fixed the last remaining bug in my Kqueue, and now everything works great.
Right now, there are 823 connections, and the server is taking less than 7% CPU. Before implementing this, it would have taken close to 20%.
And there are some other, non network related optimizations I can do (especially the stuff that trashes the CPU cache), so it's a good thing.
But more about them later.

Kqueue working

2008-11-13T23:00:00.003-05:00

Sometime last week I finished the Kqueue implementation, and after a failed deployment (where it crashed the server an hour after the restart) I did some final touches and now it works great. There is still a bug to fix where sometimes a socket attempts to send data to an nonexistent client, but this is pretty rare and will only cause someone to be disconnected from the server.
I am, however, trying to see what causes that problem.

And now for the performance results:
Using SDL_net to check which sockets had data, the server was taking about 15% of the CPU with 700 connections. Now, with Kqueue, it rarely goes over 6%. The nice thing about Kqueue is that it scales very well. For example, if it takes 0.01 ms to check a socket, it will take 1 ms to check 100 sockets. With select() or poll() it might take 0.01 ms to check a socket, but 5 ms to check 100 sockets, and 20 ms to check 200 sockets (all the data is made up, just for an illustration purpose).
What this means for those who do not understand technical terms is that before this change, the server couldn't have handled more than, say, 1500 connections (with enough spare CPU for an invasion). Now, I think it can handle up to 5K connections or more.
It also means that the server should be more responsive than before, although there is not much of a difference if the server responds in 130 rather than 140 ms (most of it being the network latency).

The conclusion of working with Kqueue is that it is well worth the effort to implement it, and it is also pretty easy to do so, once you understand how it works. However, the documentation is not very good, and it is wrong, or at least misleading in some areas.
For example, if you try to change an event in the same call where you also get the pending events, your pending event will not be changed until after, which can cause problems.
And there is a nasty bug where if you add a listening socket to a kqueue, the sockets added after that via accept() will become, for kevent, listening sockets as well, so you won't get any notifications from them. The way I did it was to create two kqueues, one for the listening sockets and one for the normal sockets.

Last week's work

2008-11-04T02:36:00.002-05:00

There has been something in the last week that significantly reduced the time I spend working at EL. That something is Fallout 3, a game I've been waiting for almost 10 years.
I ordered it off Amazon and got it delivered on 28th, and ever since then I am playing it like a maniac. Usually, I don't play video games, maybe I spend 50 hours a year playing video games. But Fallout 3 is way too addictive, and I think it is the best game I played so far.

Anyway, this past week I almost finished the server programming for horses. We tested them on the test server a few days ago, and there are very few bugs left, so if everything goes well, we'll have the client update sometime in December. And as expected, everyone who tested the horses loved them.

Regarding my optimizations, I finally finished setting up a local FreeBSD machine for my tests. This test machine is an old laptop, a Pentium M 1.7 Ghz with 1 GB of RAM. I had some problems with the standard FreeBSD install, so I used PCBSD instead.
So today I ran the server for the first time on my FreeBSD test machine, and I've noticed something perplexing: It is orders of magnitude faster than the machine we currently use for the main server!
That machine uses an older Xeon @3Ghz (made in 2004 I think), and runs FreeBSD 6.x and gcc version 3.4.6 [FreeBSD] 20060305
My laptop test machine thingy runs FreeBSD 7.x and gcc version 4.2.1 20070719 [FreeBSD]
On the main server machine, an empty (just the AI) server takes about 1% CPU. On my laptop, it takes 0.00% (!) CPU. Now, you might think that an empty server shouldn't take more than 0.00%, but the thing is, there is a lot of AI (over 1.3K entities, most of them moving around).

This is very strange, and I am not sure why my laptop is so much faster. It could be that GCC 4 does a much better job, or the new FreeBSD is much better at handling stuff, or maybe the main server machine is not configured properly? I'll have to ask my host to do a few hardware tests, and possibly update the OS as well.

Profiling and optimizations

2008-10-25T01:37:00.003-04:00

In the last two or three weeks, I spent a lot of time optimizing the server.
I rewrote all kind of functions, and fixed a few bugs while at it. The profiling results were kind of surprising, for example the most expensive function in my code is was a big loop, mostly empty, that looks something like this:
for 0 to 6K
if()
if()
if()
if()
//only maybe 30% of the times the execution gets here.
do some stuff, not very time expensive

Now, this function is called 8 times a second, but even so, it was a little bit unexpected that such a little innocent function would take about 0.7 ms at each run.
So, I focused all my m4d hax0r skillz on optimizing this function, which meant making a few lists to get rid of some of the ifs. But this required reordering some networking code, which took a while.

After doing this, I was expecting the CPU usage to drop a lot. But, to my surprise, it did not drop at all (nothing noticeable, anyway).
And then it finally realized it:
The problem was not in the server code, the problem was on the networking side!

For example, a server with no players, but 1300+ AI (which do most of the things players would do) takes about 1% of the CPU.
But a server with 100 players takes about 2%, and a server with 800 players (and player run bots) takes 18% of the CPU.

From the very beginning, I relied on SDL_net for the networking, but until a few days ago, I didn't even look at the SDL_net source code to see how it is doing things. So I took a look, and didn't find any problems, except that it has to go through the list of all the connections once, and through the list of active connections twice. Then the server must go through the list of all the connections once again, to check for data.
Obviously, this is not optimal.
After doing some research, I found out that the select() method, which SDL_net is using, scales very poorly when there are a lot of connections, because the kernel must do a lot of expensive operations as well.

Well, Learner told me today that on FreeBSD there is another way to check to see if the sockets have any data, with kqueue.
After doing some more research on the matter, I found this. It explains in details how kqueue works, and why it is so much faster than the good ol' select().
So I am going to implement kqueue on the server, to be used on the 'production' server, but also leave the SDL_net way in there as well, because my development is done on Windows.
Right now, I am downloading Desktop BSD and will run it on a virtual machine, to help me with my local testing. Once I actually start implementing the new system, will let you know how it went.

Optimizations

2008-10-08T01:50:00.002-04:00

Today I finally finished optimizing something that I always wanted to optimize, namely the system which checks who sees who. The old system was checking if someone moved, then if it did, it will check against everyone one the map. For under 20 or so actors on a map, that was pretty fast, but when there were hundreds, even thousands actors (such as during events or invasions), then things were very slow.
For example, the server would use about 33% of one CPU with 1607 invaded monster in one map.
The new system uses sectors, so the players are only check near the nearby sectors, considerably improving the speed. Right now, with 1607 monsters in one map, the server is using only 7-8% of the CPU, so the speed improvement is ~450%. Of course, that is obvious in extreme cases like this, but it should also work better than the old system in any maps with over 10-15 players.

On a related note, tomorrow we hope to unveil one of the secret features me and Schmurk worked at. I am pretty sure that people will be very, very happy when they will see it :)

Mules going live, server optimizations, new things

2008-10-03T02:24:00.003-04:00

Well, the mules went live a few days ago, and now people can make them and their food.
I didn't see too many mules in the game, which is good, the last thing I wanted was everyone to become a mule. But there are many mule glyphs and pets food being produced by players, so there must be some demand for them. And because the creature food requires a refined vegetal mixture, a lot of people are using a lot of harvestible items that were previously not so useful.

The optimizations I made a while ago proved to be almost useless, there was no visible reduction in the server CPU use. I mean, the CPU works less because of them, but there are other tasks which tax the CPU much more, so they are sort of like a drop in the ocean.
I was a little dissapointed and mentioned it to Schmurk (the guy who implemented the arrows, finished the sky and the 1st person view, improved the camera movement and animations, etc.) and he gave me a really good idea bout how to optimize some stuff. And not only that, but he wrote a program to test it, so I am going to use part of his code (with modifications) to improve the server speed.

As I said before, there are two new (and secret) features coming in the game soon (this year). One of them is almost 90% done (still needs more testing), and the other is ~60% done. I hope that we will be able to test the first feature in a week or two, and the players will see what it is. I am confident that everyone will enjoy it a lot, it's been requested quite a few times. Unfortunately, they both require a client update, so probably we'll have them on the main server sometime in December (we need to wait for other stuff to be done as well).

Quite an eventfull week

2008-09-20T23:47:00.002-04:00

This past week has been pretty busy, with some important changes happening:

1. The polymorph skill is in the game, although the glyphs to actually shape shift are not obtainable in the game except from the shop. This will change in a few days, when they will become manufacturable under the summoning skill.

2. KF (the most popular PKing map in the game) was made a non items drop on death map. This has wide implications for the game economy, because now a lot of people go and PK there, and they use all kind of potions and essences, as well as break all kinds of gear. So it's a nice push to the economy, gives players the chance to match their skills against others for free, and generally makes everyone happy. The downside is that there will be fewer rostogol stones used in the game, so less money for me, but this should be offseted from the high end items breaking there.

3. I am doing an important "behind the scenes" update in the server logic, which should improve the speed of some critical functions. This will allow faster response time (just a little), as well as being able to add some very neat things (which are secret for now). That code almost works, and today I just finished fixing the latest bugs, and, hopefully, it should be on the live server some time next week.

4. A few years ago, the server was crashing every once in a while because of an error that shouldn't have happened. I prevented the crash by adding a specific check for that error, so now it is logged whenever it happens, and the crash is avoided. Well, today I looked over our critical errors log (where only the nastiest, "shouldn't ever happen!" stuff is logged), and I've seen that error happening maybe once or twice a month. So far it is harmless, but I'd rather find out what the hell is going on and fix it, so I added additional debugging information. Hopefully, it should happen again soon and with the extra debugging see why did it happen.

Shapeshfting again

2008-09-13T00:52:00.003-04:00

Well, it seems that the client crash mentioned in the previous post was actually due to the server sending something wrong. Once that was fixed, shape shifting works fine for the most part.
However, there are a few issues with special effects. The problem is, most of the special effects were done assuming that the actor that casts spells or get harvest effects are human like, and have a hand bone.
Since mules do not have such a bone, that leads to a crash. Error checking FTW :D
The bug was fixed in the CVS, but not everyone can build their own client, and the abuse potential was high. For example, triggering a harvesting event or casting a spell on someone while being a mule could have caused arbitrary client crashes for those around you.

Initially, I wanted to check every single special effect, and if the person who casts a spell or receives a harvest event is a mule, do not send that effect to anyone.
This is pretty tedious, because there is a lot of code to modify (all the harvesting and spell effects), and I wasn't really excited about doing it.

Today, however, I came up with a better idea: It is not realistic (as far as realism goes in a game) to have a mule casting spells or harvesting resources. In fact, it is not good for the game to allow that, because then everyone would be shapeshifted to a mule for anything that has to do with harvesting and manufacturing.
The idea of a mule is to CARRY stuff, not to do everything a normal player does. The game would look really boring if everyone in every mine or around every storage is a mule.

The way I see it is to have the mules as support player types, for example one player harvests while others goes and mules their resources to the storage (for guild projects, or for a fee).

So I decided to disable spell casting, harvesting and manufacturing for the mules, and possibly for the other pets as well. Because that will make the mules less usefull (to the power players), I will either make the polymorphing tokens and food cheaper, OR increase the load capacity of a mule. I am not sure which way I will go yet.

Shape Shifting

2008-09-10T01:13:00.002-04:00

Recently I started working at the shape shifting skill, and almost implemented the mule (90% done), and I ran into a big problem:
The client was not designed to dynamically replace an actor with another, so it crashes :/
This means that we need to fix the issue on the client, and then have a client update before we can add shape shfting in the game :/
There is a good news too though: We MIGHT implement two new, very cool and secret features that pretty much everyone will love. They are (almost) implemented on the CVS client, but they need server support (which can take a few weeks or more). So probably the shape shifting and the other cool features will be available in two months.

School started

2008-09-06T00:28:00.003-04:00

In many parts of the world, the school started, and that reflects pretty well in our players population. The number of players online at a time declined by about 60. I am curious what the weekend numbers will be.
This number (~10% of the online population at a time) is very consistent with our age polls, where only about 20% of the players are under the age of 18. From those 20%, it is safe to assume that only some will stop playing (or spend less time) in the game once the school started.

On an unrelated note, this apst few days I added 3 new potions in the game, and I am going to add a few more soon. Potion is the skill with the fewest makable items, with the highest potion requiring level 62, while the highest ranking potioners have over 100 in their potion skill. The last person in top 50 potion is level 82, so a few more potions are needed. There will also be a potion god by the end of the year.

Back from vacation

2008-08-21T00:53:00.003-04:00

I didn't update the blog in quite a while, mainly because I was busy with the update, then went over to Romania for 18 days.

The update went really well, in fact, I think this was the smoothest update ever. The client is rock solid, and there was absolutely no one that had any significant problems with this new client compared to the previous one.

And now, and update of the things I am (or will soon) be working on.
First, I want to finish the wards, which are some sort of mines that do other things, and they are triggered by movement. We already have the mana drain ward, and there are 3 more wards to go: Mana burn (does damage while removing the mana), Uninvizibilizer, and Magic immunity remover.
The last two wards will have a chance to remove the inivisibility or magic immunity, for example something like 30%+engineering/5 per step. Those are not the actual numbers, just an example.

Then I will make the ice dragon armor and scythe manufacturable (but first the books).

Next is another god quest (those are really boring, I hate working at them).
And finally, a shape shifting ability, where you will be able to transform into some animal. This will replace the pets idea, since you will become your own pet. I've been talking about it on the forums already, so I won't enter in details here, but the good thing is that everyone loves the idea.

One thing I will do with the shape shifting is implement half of it first, where you can just change your shape to an animal, but no special abilities, and sell them in the shop to make a few bucks. Once they are fully implemented, I'll stop selling them in the shop, and everyone will be happy.

Preparing for the update

2008-07-08T23:40:00.002-04:00

It's that time again, the time before an update.
This is pretty stressful, because a lot of things that do not depend on me must happen:
1. The players have to test the last RC, and report possible problems.
2. The Mac and Linux clients have to be built.
3. When the update comes, people have to follow some basic instructions.

So far, it seems that enough people tested the RCs, and there are no significant bugs out there. In fact, I think this client, with all the new features, is more stable than the previous two clients. But there are always players that don't want to bother testing the RCs, and after the update they start posting on the forums on how the game is not working anymore, or that it causes problems on their systems, etc.

Some of the new things available in this update are:
1. Full camera control, similar to a hybrid 1st/3rd person view, with a sky dome, moon, sun, stars, etc.
2. Improved weather.
3. New context menus for some windows.
4. Bug fixes.
5. New weapons and armor.
6. A level 60 a/d arena in Desert Pines, next to the level 40 arena. While we have other level 60 arenas in the game, they are not really used mainly because.. well, they are not near the Desert Pines Arena, which is more or less one of the most famous things in the game. So, hopefully, some players will move on from their 40 a/d skills and try the new place.

The update should happen in a few days, depending on how soon the Mac client is built.

Client 1.7.0

2008-06-17T23:32:00.002-04:00

Yesterday I posted a RC2 for the new client, version 1.7.0
No one reported any significant problems with this client, so we might have an update in a week or two, depending when a new feature is implemented. If that feature is not implemented in time, we can go on without it, but I'd love to have it in the client.
After this update, the next client will probably use a new engine, that is currently written by Daniel. This engine is more flexible, faster, will allow terrains, materials, better lights, better shadows and better reflections.
It will probably still take months until it is done, then probably a few more months until it is integrated with the client, but it is very promising and I am really looking forward to it.

On an unrelated note, two developers that were working at integrating the map editor with the client quit the team because of some differences of oppinions, which kind of sucks a little, especially that we really need some people working at the map editor for the new engine. Many maps will have to be adjusted to include the terrain, a new terrain editor must be made, and so on. Hopefully we will find some new people to work on that, or I might start doing it myself.

Eternal Lands demographics

2008-05-19T01:05:00.002-04:00

Few weeks ago I made a demographics poll on our forum, to see where our players are from, how long are they, and for how long they've been playing.
Here are the results:

Age:
0-17 14.95%
18-25 26.17%
26-35 28.27%
36-49 25.23%
50-60 4.21%
60+ 1.17%

Continent:
North America 44.39%
South and Central America 2.34%
Asia 2.10%
Africa 0.47%
Europe 48.13%
Australia and Oceania 2.57%

Started playing
0-30 Days 0.47%
1-3 Months 1.87%
3-6 Months 6.31%
6-12 Months 10.05%
1-2 Years 23.60%
2-4 Years 43.93%
4+ Years 13.79%

The age results are virtually the same with the poll we had last year, and the conclusion is that most of our player base is 18+
I am little bit surprised that we have more players from Europe than from North America, and I also thought we had more Central and South American players.

One other surprising thing is that very few people that responded to that poll (less than 20%) started playing for less than a year. Of course, many new players do not have forum accounts, but I would assume that someone that's been playing for more than a few months would already get a forum account, so it's strange that we have so few new players.

Partially because of that fact that our population remained constant in the last +1-2 years (just a slight increase in the number of people playing), I made the newbie tutorial easier, and gave new players more attack and less penalties when they die, until level 12 overall.
Not sure if this will make a difference, it is too early to tell.

We are also considering spending some money for advertising some time in June, and since we are doing that I want to change the website a little bit as well. For example, the main page could tell people more about the game, what happes in the game, who is the game for, etc.

We don't really need a lot of new players, but adding 100 or more players online at a time won't affect the server in any way, and there are a lot of resources and spawns in the game for much more players than there are now.
The schools will be over soon, and that is a good time for advertising.

Sky client

2008-05-02T00:00:00.011-04:00

Thanks to the work of quite a few people, especially Emajekral and Schmurk, now we have a sky dome, and a much larger viewing distances and viewing angle.
Everyone is very happy with it, and we hope to make it the next official client. There are some more tests to be done, but things are coming up nicely.

People with slower machines might have to use the 'standard' mode, where the camera angle is limited, but they will still benefit from the new light colors, which are much better than what we used so far. For example, the light color changes at dusk and dawn.

It is really amazing to see how much our little game evolved. Here are two screenshots, the first being about 5 years old, and the second is with the new client (pre release).

Reward system

2008-04-21T00:23:00.002-04:00

Today I came up with an idea that so far players seem to like:
Every week, there will be some small to medium scale events, for now only invasions, but possibly other things later on.
If the players manage to complete the objective in a certain time frame, they get 3 points. If it will take longer, they get two, 1, or 0 points, depending on the specific event.
At the end of the week, there will be a certain number of points that player can use, by voting, for things such as: Getting a few hours of a positive day, getting new monster spawns, and other things I will think off in the future.

There are many advantage to this system:
1. The whole community can participate (weak players scout to find the monsters, and the stronger players come to finish them off).
2. It promotes more exploration, so now players will want to familiarize themselves with the geography of the game (finding secret places, exploring caves and caverns, and so on).
3. Makes people work together as a team.
4. Gives them an opportunity to vote for the reward, so that there will be no more complaints that a certain group is favored (such as the fighters).

So far, everyone can vote, not only those participating in the invasions, and this might be a problem. If it becomes a problem, maybe I can devise a system so that only those participating can vote, although this will be hard and will require some thinking. One way would be to make all the invading monsters drop an item, then go with that item to a voting NPC and trade it for a vote. By placing weaker monsters along with stronger monsters, even those who just scout can get a kill and make their vote count.

Arrows and the economy

2008-04-07T00:42:00.003-04:00

The bows/crossbows are in the game for 2 days now, and from all the gold-sinks ever implemented by me, they are the best.
People love the new archery skill, and it seems that they do not mind spending a lot of gold on it. For example, we have an average of 4.5M gold coins entering the game every day, and about 3.7M exiting. The average gold increase is between 0 and 1M per day (which is normal, since many players are saving money, and many new players start playing for a while, then give up).
On April 5, we had 400875443 gold coins in the game. Now, 2 days later, we have 384574915.
That's an decrease of almost 4% in 2 days. The first day, ~11M went out (after deducting the gold income), and today another ~5M went out (again, after deducting the income).
Not bad at all. Obviously, this trend will not continue for too long, but I expect that the net gold increase in the game will be negative for another 2 weeks or so.

I am really curious if this deflation will affect the inter-player trade, and if so, how will the market react to it.

Update 1.6.0

2008-03-31T23:33:00.002-04:00

After more than a month of pre release candidates, we finally rolled the update on Saturday.
Unsurprisingly, because of the extensive tests we've done, there were not many problems, and I would say that 95% of the players were able to update without any modifications to their system, while the rest had to either update their video drivers or modify some EL configuration settings.

The archery is included in this update, but the ranged weapons can not be bough until next weekend. This is because we had some big PK contests a few months ago, where the promissed prize was having bows before everyone else. Schmurk, the developer who wrote most of the ranged skill code also got all the bows and missiles.
One other reason for this delay is that people can test the other features first, without being too distracted by the new skill.

Speaking of new features, it seems that the players are very excited about Leonard the Leopard, a new AI entity that is actually pretty intelligent, and will stalk players, flee from combat when wounded, change maps, and even level up. He even talks in lolcat on the events channel, when he dies or when he kills some player.
There have been quite a few "Leonard hunting parties", where people try to locate and kill him.

Next on our to do list is to release a patch for an experimental client with a sky and 1st person mode. This client is pretty functional, but there are a few problems here and there. It also takes more resources, and the frame rate is a little reduced (since there are more objects to render). We hope to release this patch by the end of April, and it will not require a client update (it will be an optional download).

Update coming soon

2008-03-13T00:38:00.002-04:00

Today we released Pre RC 11, which fortunately runs on pretty much any computer our users have, although some people with SiS and S3 video cards need to manually add something in their el.ini file. I hope I might be able to correct this issue automatically, but if it's not posible, people can always do it manually.
We have very few people with such video cards, so that's not a problem.

There are just a few things that need to be done before the update:
1. Change some of the animations duration in order to match the server speed (mostly the archery animations)
2. Test the maps that were changed.
3. Release a final RC.

I am hopping to have the update done in 2 weeks or less, then we can finally move on with the development. We have some big plans for the future, stuff such as 3d terrain, normal maps, better lights, etc. I'll talk more about it soon, so stay tuned.

First archery public testing

2008-03-05T02:07:00.004-05:00

The bows and crossbows are in the game for more than a month, even on the main server, but they are not available to the players because they have not been tested enough, and because a client update is needed.
Both the client and the server are 'almost there', although the final client still needs some 'polish', and the server needs some fine tuning.

Until today, the arrows have been tested only by a few people (mainly me and Schmurk) on the test server. There were no known bugs, but as with anything, massive testing will usually reveal new problems.

Well, today I wanted to profile the test server, but in order to do a proper profiling, many players are needed. And just asking the players to come on the test server and walk around usually doesn't work very well, so I 'bribed' them with free bows and arrows :)
That worked quite well, over 45 players logged in on the test server.
After distributing the free bows and arrows, we went to KF (the most used PK map in the game), and played a little.

The testing went much better than expected, with virtually no problems except that some people had bad lag. I am not sure if that's because of a bug in our code, or because they don't have the latest files, so we'll need to look into this issue.
Another small problem was that a few arrows got stuck in mid air, but this can be because the map on the test server is newer than the clients map. One player crashed once, but one crash in 30+ player hours is not significant, so it won't impede the update.

One concern of mine was the possibility of the server being slowed down if there were too many missile fire requests going on at once (we do real time ray tracing, 3 times for each arrow), but after I finished profiling the server, I realized there is absolutely no significant CPU time taken by the ray tracing. Schmurk did a really good job :)

For those of you who missed this test, don't worry, there will be a few more public tests before the update. In fact, I will put a new NPC that will give free bows and arrows to people. I hope I won't forget to change the prices once we are done with the update :)

MMORPGs Economy (part 2)

2008-03-02T00:25:00.003-05:00

Ins and outs, revisited
Monster drops
It goes without saying that stronger monsters should, generally, drop better stuff than weaker monsters. However, there are a few exceptions. One exception is having weak (newbie) monsters drop some really good items, but with a very, very small chance (perhaps around 1/5K). This will help some lucky newbies. The second exception is that, depending on how the exp/leveling is implemented on the server, some monsters are better than others to level on. Therefore, it can be a good idea that the "good to level on" monsters drop less stuff than some weaker but more inconvenient monsters.
To add more diversity to the game fauna, you can have a few monsters of the same level but with different abilities. Example of abilities are self healing, spell casting, the ability to go invisible, and so on.

Player made items
Making items over and over again to level up is not the most fun thing in the world, and it can produce an over abundance of items, which as discussed previously is not good. For the manufacturing system, there are a few things to consider: Can a player make items everywhere in the game, or do they have to be in a certain workshop? If there are workshops in the game, should some of them give better experience than others? For example, you can make a hard to reach workshop that will give +15% experience.
You can implement schools, where you don't get any of the produced items, but get more experience in return, which helps with the over production problem.

To reduce the amount of items in the game, you can make it so that each time you fail at making an item, you lose the ingredients. The failure rate would depend on your level + a random factor.
Finally, you can introduce a concept of "item quality", for example if your skill is much higher than the skill required to produce an item, you have a chance to produce an improved version of that item (a more powerful sword, a more protective armor, etc.)

Collecting resources from the environment, tips and tricks
Do not put the expensive ores right next to a shop, workshop, and storage.
If possible, do not place resources right next to each other, especially if they are needed to created the same item or perform the same task.
Consider making the resources that should be rare actually be rare, by either placing a limit on how many can be harvested each turn/hour/day or by requiring expensive items to harvest each resource, all this in addition to a higher harvesting level needed to harvest them.
Depending on the game type, an interesting but hard to implement idea is to put a limited quantity of resources in a mine. When the mine is exhausted, players would have to find and build another mine. Or perhaps go to some god and perform a ritual to rehabilitate the exhausted mine.

Broken items
If you are going to implement a system where items breaks, you will have to decide what should happen with the broken items. They can either disappear from the game, or degrade to a weaker version. Of course, you can have both in the game, where the weaker items just disappear, and the more expensive items degrade. The fate of the degraded items can vary with your design, but there are a few common uses for them:
a. Use them for a quest. This can make the quests harder, especially if the quest asks for an expensive item that it's hard to degrade.
b. Have an NPC that fixes them for a fee. Maybe allow the NPC to sometimes destroy the items in a failed attempt to repair them, and keep the fee.
c. Allow the players to fix them, maybe even have a repair skill in the game. Obviously, allow some chance for failure, based on their skills and on how hard it is to repair it.
d. Make other items with them, or use them as parts to repair other items (for example, two broken armors + some metal = new armor)
e. Recycling plant: You go to a recycling plant with the broken item + a fee, and get back the metal required for that item.

Shops
Buying and selling items to and from NPCs is most likely going to be a big part of your economy. It is, therefore, important to do it right. While the possibilities are virtually endless, I'm going to give you a few ideas:
a. Set an affiliation (or faction) for the players and the NPCs, based on their race and/or quests. If a player and an NPC with a similar affiliation interact, the prices should be better, and those with opposite affiliations should either have worse prices, or refuse to buy or sell at all. One thing to be careful about if you are going to do that is the fact that in a free game people might have multiple characters of different affiliations, and mule the items in such a manner to use the best character for the job.
b. Some NPCs can require a player to complete a quest in order to buy or sell items.
c. Some NPCs can buy and sell an infinite amount of items, others can buy and sell only the items they have from the players, while others can be set to buy and sell only a certain quantity per day. Finally, some other NPCs can keep track of how many items they bought or sold to/from a player during one day, and only allow a limited quantity. Of course, you will have to be careful about players that mule. For the NPCs selling a limited global quantity of items per day, you will have to implement some measures so that players from a time zone won't exhaust the NPCs, and when others start playing for the day, they will find all the stores open with a full stock. A solution to this problem is distributing the items quantity per hour, rather than per day.

Proper Testing
No matter how good your economy looks on the paper (or on your screen), once you actually implement it and players start playing your game, you will notice a lot of shortcomings. Testing games is notoriously hard, big companies pay people (Beta Testers) to play the game and find problems. But when it comes to a MMO, it becomes economically unfeasible to pay thousands of people for a few months to test the game and report bugs and flaws. This is exactly why many MMOs have an Open Beta stage, where you can play for free for a while. As a side note, Open Betas for pay to play games also acts as a viral marketing tool, many players will be attracted by the free aspect of the beta, then continue to pay for the game because they are now addicted.
Unfortunately, the independent developer does not have the marketing resources to advertise and hype their unfinished game the same way a big company does. So what a small indie team can do is have some in-house testing (which has a very limited value), then release the game and hope for the players to come and find bugs. Only that by the time the economy problems become apparent, it is generally too late; a lot of people in the game are way too rich, there is a huge items surplus in the game, and the new players have no chance against those who started just a few months before.
What can be done about it? Well, there are a few things that can save you from a lot of headache:

1. Create daily backups. Not only they can be very useful if you have a hardware crash, but they can save you and your players a lot of frustration. For example, let's assume you make a change to a formula, and due to either a typo or because you didn't anticipate the outcome, the whole economy is ruined overnight. Maybe by mistake you added an extra 0 to the price of a flower, so people become rich by selling tons of those flowers to the flower shop. Or maybe you added a new sword in the game, without realizing that it can be used to kill the strongest monster in the game and get massive drops in minutes. If you have backups, you can always rectify the mistake and restore the state of the game to what it was before the update. Of course, players don't like rollbacks, but they would rather have a 1 day rollback than have the whole economy ruined. It actually happened to us last year. We implemented some special days, and one of them increased the chance of manufacturing rare items. Well, due to the fact that we didn't have enough time to properly test it, we had a 'small' bug. The nature of the special days in Eternal Lands is that they are random, relatively rare, and many (which means that one special day will, on average, happen once every few months). And so it happened that this special day of increased rare manufacturing started while I wasn't home.
The 'small' bug made it that everyone had a close to 100% chance to make rare items. I originally made it so that the increase would be something around +5% of the initial chance. One other developer found the problem only 20 minutes after it started and did a manual override to change this day to some other kind of day. When I got home, I used my logs to see how many rare items we are talking about. We had many thousands, which is about 100000% greater than normal. We had to do a rollback, and most of the players agreed that a rollback is necessary. Given the fact that we had daily backups, most of the players only lost a day or less of work, which is not that bad, considering that it was the first (and last) rollback in more than a year.

2. Make it clear to the players that the game is Beta, which means that prices, formulas and drops can and will change at your discretion. In fact, it is a good idea in the early stage of the public testing to change stuff pretty often, or else the players would take things for granted, and then, when you want to change something, they will complain a lot. As the game advances and you get more players with different skills and higher experience, you will notice that some things do not work the way you expected, so other adjustments must be made. But as the game advances and time goes by, the prices and formulas should work pretty well already, and your priority should be adding new stuff; changing things all the time in the later stage of the beta test can be frustrating for the players. Imagine living in a world where the milk price fluctuates by 500% every week. You wouldn't like to live in such a world, yes?
The trick is to find an equilibrium between changing old things and adding new things, and this is not something I can help you with, every game is different.

3. In the late stages of the beta, if you want to change things you should change them slowly. For example, if a potion gives +20 dexterity and you think that the proper value should be +10, first reduce it to +15 and see what happens. It might turn out that +15 is enough, and you don't really need to reduce it all the way to +10.

4. Finally, it might help to do a total reset of the game (deleting the world status, and all the players items and skills) once you are confident that the economy is relatively stable (usually by the end of the beta). This is, of course, optional, but the idea behind it is that the first players might have had an unfair advantage by being able to use a system that wasn't tuned properly, possibly using bugs and exploits that were not yet fixed at that time.
If you do plan to do such a total reset, you should tell players in advance about it. Preferably, tell them before they even start the game, somewhere on the download page perhaps. And remind them about the reset every once in a while, some sort of memento mori kind of thing. :) Then, at the end of the beta, just before the big wipe, have some sort of huge PK party (if the game mechanic allows) where the winner[s] get some small prize just after the reset, so that they have a small advantage in the beginning.

The interaction between the economy and other aspects of the game
A MMO is an unitary system, where many subsystems converge to ideally create a seamless world. That can vary with the game type and design, but typically you will have a graphic subsystem (what the player sees on the screen), the network subsystem (the data flowing from the server to the clients and vice versa), the sound subsystem, the combat, and finally, the economy.

Economy vs. Combat
The economy is the soul of the game, the reason people are playing. While some would believe that the combat is the soul of many MMOs, this is generally not true. For example, many fighters like to fight so that they can loot monsters and players, then sell the loot so that they can buy various 'power ups'. You will also notice that the majority of fighters will usually not attack those who have a high blacksmith skill (replace blacksmith with any skill that a fighter needs for supplies). The reason for this is that the fighter constantly needs weapons, armors and ammunition, and the blacksmith is often the only person that can reliably and affordably supply them. If the fighters alienate those people by PKing them, it will be very difficult for the fighter to find good items for good prices. While there are many blacksmiths in the game, the more you alienate, the lower the chance is to find good items, and the more you will have to pay for them, as there will be little competition left. That is, very few will be willing to do business with you if you PK them.
Any good MMO is self policed by the players. As explained above, different classes will create all kind of symbiotic relationships. This is nice, but sometimes it can be boring, and there are a few things you can do to spice things up. My favorite is putting some expensive and rare resources in PK areas, so that the harvesters will have to go there and collect them. Most of the top fighters should not have the harvesting skill necessary for collecting those resources, of course. This can create all kind of alliances and protection fees, with the PKers guarding their allied harvesters against enemies.
If your game doesn't have PK zones, or if it is not feasible to put rare resources in PK zones, you can at least place some very high level monsters in that area, which will require the harvesters to be escorted by fighters.

Economy vs. Networking
It is generally the case in MMOs that the bandwidth for an area increases exponentially with the number of players in an area. The reason for this is that in a crowded place, each movement from each actor has to be sent to all the other actors. So it is a good idea to avoid, as much as possible, people congregating and 'camping' in areas of interest. By area of interest, I mean a place where people need to go to do something or another, such as a store, a storage, bank, workshop, and so on.
The solution is pretty simple: create multiple similar points of interest in other areas of the game. If you notice that a shop is always busy, created another shop further away. People usually don't like the lag, and they will tend to go to less crowded places if available. However, if you put a store in the middle of nowhere, chances are good very few people will go there. Just like in the real life, people don't like going too far for something they can find nearby. The malls are good examples of that; many people go to the mall because there are a lot of stores in a small place. So don't put just one store in the middle of nowhere, put 5 stores. This way, that area will lose it's status of "middle of nowhere".
If for some reason you need to place just ONE store in a remote area, and a similar store is available in a populated area, have the new store offer better prices, or perhaps a few more items. That's why people go to shop at WalMart.
Using the same rationale, spread the resources around too, don't put them all together. And, as a general advice, whenever you see a big crowd of people in an area for a few days in a row, determine why they like that spot so much and try to create an alternative in some less populated map. It might take some time for them to get used to the new spot, but they will eventually. If they don't, ask them why they don't like it (see the "player feedback" section).

Economy vs. Graphics and Sound.
This is pretty much similar with the Network, with some exceptions. If there are too many players in an area, in addition to the network latency (lag) the players with older computers (or even with some not so powerful new laptops) might experience a drastic decrease in the frame rate, which can reduce the playability of the game. In order to alleviate this problem, in addition for spreading the points of interest, you should talk with your 3d artists and make sure that such places are not graphically overloaded. The less polygons in crowded places, the better. It might not be always possible to reduce the number of polygons from the player models in a scene, but you can (and should) reduce the polygons from the static geometry. Don't put tons of unnecessary objects in/near a shop. If the shop is in a city, you might not have much of a choice, especially for the first person games, where you can see the whole city while going to the shop.
Most of the sound cards can mix only so many channels, so if you use footsteps sounds each time a player moves, you will have problems in the aforementioned places.

Player Feedback
As soon as your game is online and people start playing it, they will start expressing their opinion, whether you ask them for it or not. Somewhat ironic is the fact that those who are smarter and stronger in the game will usually not post on the forums or send e-mails complaining about things or suggesting new features. There are, of course, exceptions from this rule, but if you watch any MMO forums you will notice that most of the suggestions are worthless.
The problem is, when someone complains about some aspect of the game, the complaint will be egocentric, focused on their particular problem, and not on the overall benefit of the game. For example, some players want certain items to be cheaper so that they can afford one, without thinking that making the item cheaper will cause in-game inflation.
My personal experience with asking for feedback from the entire community (such as an open forum post) is bitter. The majority of people will NOT even bother to read your post, they will just read the title then click on the "Reply" button. And even if they do read your post, they will still think about what benefits them, and not the game as a whole.

Instead, try to find an 'advisor'. As a game developer, you will most likely not have enough time to play the game too much, and be as competitive as a player that players 8+ hours a day. This is why it is important to find a few high level players from different trades (fighter, miner, blacksmith) and ask for their opinions and thoughts in private. Usually the top players in their trade are mature and intelligent people, and they know a lot about what's going on in the game, often times much better than you do. Given the fact that MMOs are so competitive, it takes a lot of work and planning in order to become a top player. In the beginning I was surprised on how calculated were all the actions of such a player. They compute everything, even how long it takes to get from point A to point B, or the exact amount of potions and ingredients to take with them while fighting each kind of monster.
Once you found a reliable advisor, try to actually pay attention to what he or she recommends. That doesn't mean you should implement or amend whatever they recommend, and you should still check the item logs just to make sure. But, overall, it is a good idea to at least consider their advice. If you have multiple players that you can trust, try to check an idea with all of them; two heads are often better than one.

Conclusion
Designing a MMO economy is not very hard, but you need to be very careful about every change and addition you make. Sometimes it might seem like a fun job, but there will be times when you will feel like screaming and curse the day you came up with this bright idea of becoming a MMO developer.

I hope this article was helpful, and even if you will never become a 'MMO economist' it can be useful to know what kind of work goes into designing and maintaining a game.

Radu Privantu
The author can be contacted at: radu.prv at gmail.com

MMORPGs Economy (part one)

2008-03-02T00:22:00.002-05:00

A lot of people e-mailed me about my other MMO related articles, and expressed their wish to do a follow up with an article about setting a MMO economy, and here you have it.
But first a disclaimer:
This article is for your information only, and you should not trust everything you read here. Some advice might work for you, and some might not, therefore it is up to you to decide which, if any, methods you want to implement in your game. Many people complain about Eternal Lands economy, so please be advised that, although I do have years of experience in this field, I, like any other human, make mistakes.

Now that we are done with the disclaimer, let's focus on the real thing.

In most MMOs, regardless of the genre and type (text only, browser based, independent client), we have resources (items, money) coming in and going out of the game. Ideally, the ratio should be 1/1, that is, for every resource coming in the game, something of equal value must go out. Obviously, a perfect 1/1 balance is often impossible to achieve, but there are some tips that can help.

Tools to use
The carpenter has the hammer, the navigator has the compass (or satellite assisted navigation system), and the chef has the stove and pots. It is obvious that each profession requires, or can be facilitated by some tools. Designing a MMO economy is no different. Here are your tools:
a. An office suite such as OpenOffice, which is a free, multiplatform alternative to Microsoft Office. A document editor is important for writing your design document and formulas. A spreadsheet can be useful for quickly testing formulas, and determining the ingredients price, experience gained and so on.

b. A program to draw diagrams and UMLs. Dia is a free, multiplatform program that is relatively easy to use. Making diagrams of how your economy is supposed to work can be very productive both for you and for those who work with you. Sometimes you can also show it to the players so that they will have a better idea on how the economy works.

c. A note taking program. I am using Evernote, which is a shareware Windows program. The reason why a note taking program is can help is because it just sits quietly in the system tray, waiting for you to use it. If you quickly come up with some idea while doing something else, you just click on it, write down whatever you need to remember, then return to what you were doing, knowing that the information will stay there, ready for when you need it.

d. A text (ASCII) editor. If you plan to store your economy related files in a text format (such as XML), a document editor such as Word will not do, because such programs do not usually output a pure text file. I use Textpad, a Windows only shareware program. You can of course use Notepad, or various other free or non free programs, but for me Textpad is the be-all-end-all text editor.

e. An 'in house' tool made by someone in your team that can digest economy related information, and give you a quick look on how one change in a formula affects another. While making such a program is by no means trivial, it can be very helpful in the long run. What this program would do depends on what kind of MMO you plan to make, and how much time your programmers have. One example of a task where it would help is determining how much time it would take a player to make a sword, if he does everything by himself (mining the ore, smelting it, molding the sword, etc.). The program would take into account factors like the time needed to harvest each ore, the time to smelt the ore, make the sword, let it cool..
One other task could be to determine how many monsters of a certain type some player must kill in order to advance to some level. Or, perhaps, simulate a fight between two players where you manually introduce the data (skill, racial modifiers if any, weapons, armor). This way it is easier to test new weapons and armors.

Ins and outs
Before we start with the economy, we need to determine how the resources come in the game, and how they leave the game. Note that we will focus only on the items that actually enter and leave the game, not on the items that a player loses or gains. For example, if two players barter, they will both lose and gain some items, but no new item entered the game, and no old item exited the game. If a player drops an item when he dies, the item is still in the game; it can be picked by some other player.
Please keep in mind that this list is not exhaustive, and obviously, depending on the game mechanics, some methods of entry and exit will not apply. In the second part of the article, I will elaborate on some of them.

Points of Entry:
a. Monster drops. Perhaps the most common, it includes both the normal drops (such as bones, meat, some gold coins) and the rare or very rare drops.
b. Collecting resources from the environment. Mining would be one example. Usually the resources are infinite, but a cap can sometimes be placed so only a limited quantity can be extracted per day, or perhaps per player.
c. Player made items. Those items are usually made by combining two or more items.
d. Daily allowance. Some games give every player a certain number of resources every day or turn. The number of resources given to each player can be the same for everyone, or it can depend based on various factors such as experience, items the player has, virtual estate and so on.
e. Quests. Once a player completes a quest, there is usually some reward. This is not to say that the only possible reward is some money or some item.
f. NPCs. That is usually the case with the merchant NPCs, where the player sells or buys items. Generally, some item is lost and another item is gained.
g. Real life. A few games officially sell in-game items for real money. If a player sells gold to some other player for real money (gold farming), there is no new item entering the game, it is just transferred from a player to another. Therefore, if the game is properly designed, gold farming shouldn't be a big issue.
h. Contests. The contests are different than the Quests because they are usually a one time event with a limited number of winners. The prizes are often given directly by the developers/game masters by using 'artificial' means (some admin command). Sometimes players can organize contests, and give their own possessions as prizes, so no new item enters or leaves the game.
i. Hand of God. This includes every item that artificially arrives in the game via an admin command, and is not a contest prize or bought for real money. Examples can include holidays (where the developers give gifts), a reward for finding a bug, an item meant for testing purposes, and the list goes on.

Points of Exit:
a. Items used for mining/gathering resources. A player can be required to use some pickax each time they mine iron ore (the pickax breaks). Other items such as flowers can be mined without spending anything.
b. Player made items. Resources need to be spent in order to create items. Furthermore, you can make it so that sometimes the player loses the ingredients while failing to create the item.
c. Taxes. A virtual taxation system can be imposed in a game, where a player will have to pay a tax for each virtual estate they have, maintenance fees for the player based factories, salaries..
d. Quests. Not all the quests will give you a reward in resources. Sometimes you will have to spend some money or items in a quest, in order to get something greater (experience, unlocking of a secret area, the possibility to start some other quest, etc.)
e. NPCs. No matter if you buy or sell something to an NPC, some item will exit the game. If you buy, the money will exit, if you sell the item you sell will exit. Other NPCs can charge you a fee to restore your health, give you a blessing, let you cross a bridge..
f. Broken items. Stuff breaks. We are talking about weapons, armors, ammo (if you can't reuse it after being fired). An 'natural disaster' system can be incorporated in the game as well, but more about it in the second part.
g. Natural decay. Some items have a limited life span: the food getting stale or items that are left unattended for a while being stolen by some virtual thief (that is, the server just destroying it).
h. Used items. A very common exit 'destination', it includes potions that are drunk, magic rings that are used, books that are read.
i. Fines. Sometimes, when a player is caught doing something wrong, part of the punishment depending on the circumstances can include an in-game items fine. You curse in a public channel, you need to pay 1000 gold coins, or else you get banned for a day. This can be a pretty effective deterrent, no one likes spending their hard earned money because they have a 'dirty mouth'.

Know thy items
Something you should do is have your server log each and every item that comes in and leaves the game.
All this information should be logged every day (or hour, turn, whatever is easier for you), and the information should look something like this:

Gold coins
Entry - 100000, Exit 120000

Entry method:
NPC: 10000
Monster drops: 80000
Other: 10000

Exit method:
NPC: 100000
Other: 20000

This way, not only you can keep track of the total amount of items that are in the game, but you can also see where most of the items come and go. If you game has a manufacturing system, you can even go as far to log where the resources go during the manufacturing process. Something like:

Iron ore spent on manufacturing: 1000000
Spent on
Short sword: 5000
Long sword: 100000
Chain mail armor: 90000
etc.

Based on those logs, you can determine the following things:
a. What items are the most used.
b. What items are the least used.
c. What items are rare (not enough of them in the game).

Once you determine which items have problems, you can adjust all kind of factors, like the monster drops, manufacturing formulas, the cost from an NPC, and so on.
If an item is not used too much, for example some magic ring, you can change it's price, or perhaps make it more powerful. If an item is used too much, you can increase the price, the resource cost, or make it weaker. Asking for player feedback is very useful as well in determining why an item is overused, or not used enough. But more on player feedback later on.
One final word of advice before we move to the next section is that you should wait for a few days or weeks before you jump to conclusions, because the number of items in the game varies from day to day, so you will want to have at least a week of data before you take some decisive action. And, of course, you should correlate the number of daily items with the number of players that played during that day. During the weekends there are usually more players in the game. Therefore, more items will enter and exit the game than during the week days. In-game events can cause great fluctuations too, as the players prepare for that event (producing or consuming more resources). New items sometimes are underused for a while, until all the players know about it and incorporate it in their strategy.

Make your currency strong
Different games have different currencies. A medieval game typically uses the omnipresent "gold coin", while a futuristic game has something else, such as "credits". But they all represent the same thing: the 'official' currency.
So what makes a gold coin valuable? Why would people trade in gold coins, rather than, say.. chain armor or sea shells?
Long time ago, people used to barter for goods and services. A fisher would go to the marketplace with 10 fish, and buy vegetables. Or a blacksmith would trade his sword for a sheep. This system went on since the man started to form communities, and only recently (a few thousands years ago) they started to use 'money'. The advantage of using money, as opposed to bartering, is obvious. It is more lightweight, it can be stored indefinitely without spoiling, it's easier to conceal, can be traded for anything, and the value of a coin is relatively small, so you can buy only one fish if you want, rather than having to buy 50 fish in exchange for your sheep.

An interesting question is, when and how did people accept the concept of a coin? Why would someone trade their sheep for 10 coins? After all, you can't eat the coins, and they have no inherent value. The coins by themselves are useless, and you need to find someone willing to sell you stuff in exchange for those coins. In this day and age, the gold does have an inherent value: a lot of products require gold as an ingredient. But thousands of years ago, you could only make jewelry, statues and coins with it, and all those items are not necessary for survival, or even for wealth.

In a MMO, people are not so willing to accept the official currency unless if they have some use for it. If no NPC accepts it in exchange for items, and if no game functionality needs the gold coin, then you might as well not implement it, because the players are not going to use it.
If an NPC requires 1000 gold coins to sell you some armor, but you can get that armor from a player for 100 flowers, then the gold coin will lose it's value and all the other prices will increase.
Preventing this is relatively simple. Implement some rare and expensive items that can NOT be obtained by any other way except by paying an NPC with gold coins. Implement game services (creating a guild, buying a house, solve a quest) that require gold coins. And do NOT make the gold coin too common! (see the next paragraph).

Managing a player based economy
As previously explained, a system without a 'state controlled' economy is not good. You need some NPCs to buy and sell your currency.
But a system without a player based economy is equally 'ungood'.
There are multiple reasons why you will want the players to buy and sell items to each other, rather than buy the from the shops.
a. It encourages player interaction, which strengthens the community.
b. It creates some sort of self policing game; few people would buy or sell from someone who is constantly causing trouble, or is known as being a bad person.
c. Allows all kind of interesting cool things, such as price dumping, monopolies, protection fees, sabotages, theft, etc. While those things are not so desirable in the real life, I think they are great in a game; they are the salt and pepper.

Implementing such a system is very hard, because you are dealing with humans, which are very unpredictable creatures. You might design the game assuming that people will play only a few hours a day, but in reality many will be playing for much longer, sometimes up to 18+ hours. Or you might expect to take someone 10 months until they can get to a certain level so they can kill a monster, mine a resources, or make an item, only to notice that someone did some 'mad leveling' and they are there in 3 months. And of course, there will be some macroers as well, which will pump a lot of items in the game until they get caught, and perhaps some exploits that allow faster production of items.
While those issues can not be completely avoided, the 5P rules applies (proper planning prevents poor performance). Here are a few tips:
a. Make it so one skill is dependent on another. For example, have some items required for mining or producing other items be available only as monster drops, that only the fighters can get them. Similarly, the fighters will need items they can't make (swords, potions, magic ingredients). This will encourage players of different trades to cooperate.
b. Have some NPCs sell most of the common, non rare items for a high price in order to prevent people in manufacturing related trades from overcharging other players (if they charge too much, people would buy from the NPC instead).
c. Since most of the games work on the principle that the player has to create a lot of items in order to level up in some skill, there will be a lot of excess items flooding the marketplace. This problem is very difficult to avoid, but what you can do is create some quests where the NPC will need a high quantity of those items, so at least some of them will be removed from the game. You can also make it so that some higher level items will require low level items as ingredients.
d. High level items that can be manufactured should require at least one relatively rare ingredient. This is so that the end product will still be rare, or else even the newbies would afford it, due to the fact that the item is mass produced. Think for example of the computers, in the real life. In the beginning they were so expensive that only a few companies in the world had one. Then 50 years later, we are running out of IPs (4 billions of them) because everyone and their grandmother can buy a computer for 300 USD or even less. While in the real life this is a good thing, you do not want that to happen with your 'rare' items.
e. You can combine c. and d. and have the rare items require a LOT of low level items, this would also make them rare and expensive.

This is the end of the first part of the article. In the second part we will focus on the following aspects:
Tips on the ins and outs of the resources, what mistakes to avoid.
How the economy interacts with other game subsystems (networking and graphics).
Getting feedback from the players.
Proper testing of the economy while in the Beta stage.

Radu Privantu
The author can be contacted at: radu.prv at gmail.com

Problems with OpenGL implementations

2008-02-25T03:01:00.003-05:00

For this update, we are having 3 major new (new as in for EL) OpenGL features:
1. Using vertex programs to render the actors.
2. Using a different selection mode to determine what we have under the cursor.
3. Pixel shaders for the water.

The first two features can increase the frame rate a lot, as I posted before, so it is very important that we can use them in this new client.
Unfortunately, there are a few problems with different OpenGL implementations.
OpenGL is a standard, and it mandates how the programming interface with the video hardware is done. It's not very flexible in terms of the API used, so, in theory, all the video cards that are OpenGL compliant should be 100% compatible, although they don't have to support the same set of features.

The problem is that many video drivers from the major 3d card makers (Intel, NVIDIA and ATI) have problems. Usually, older drivers have more bugs than newer drivers, although this is not always the case.
Some of those bugs are pretty bad, where even if your program respects the OpenGL specifications, it can still crash due to an error in the driver.

If a new player downloads the game, he or she might not have the latest video driver, so it is important that the client detects their specific driver version, checks to see if there are any problems with it, and if so, disables the features that will cause problems.

Xaphier proposed to have an ini file where we can store which OpenGL extensions must be disabled for each video card manufacturer and each driver version.
The problem is, there is no standard way to find out the driver version, so we must rely on the OpenGL Version string returned by the video driver. Sometimes the driver version is there, and sometimes it is not. We asked our players to post some information about their video cards, and then based on that information we might be able to compile that ini file.

Once we are done with it, we will be able to use the auto update feature to constantly add new information in the ini file, so in case a new driver will missbehave we can maybe solve the problem 'on the fly', without a whole client update.

Eternal Lands' 5th Birthday

2008-02-15T03:45:00.003-05:00

Yesterday, Eternal Lands turned 5.
It's quite amazing to look back and see how much the game changed since the first day it was 'released'. 'Released' because at that time, it wasn't really a game, it was mostly a 3d chat, and there were many bugs.
It took us almost 1 year to break the 100 players online barrier.
We have some old screenshots, and as you can see, it had a totally different look.

We are going to have all kind of events this weekend, and since a lot of people will gather in some small locations, it will also be a good time to observe the server load, and plan for more improvements.

Speaking of improvements, this new client release will have lots of them. People with real 3d video cards (Nvidia and ATI) should be able to get up to 1000% in FPS (in extreme cases, such as 100 dragons right near them), but in practice probably something around 50% or so. People with older video cards might not benefit from it, because they lack the new extensions we are using.
The camera should be more responsive as well, and this will benefit pretty much everyone.

Because of these new speed improvements, and because of the arrows, the update will take slightly longer than we estimated, the release date will be probably sometime at the end of March.

No title

2008-02-10T02:17:00.000-05:00

Since my last blog entry, the following things happened:
1. We bought IPB Gallery, an IPB forum add-on that allows people to post images. So now our players with a forum account won't have to host their screenshots on 3rd party sites. While there are free image galleries out there, IPB Gallery is integrated with the forum, so the players won't have to create multiple accounts, and the existing moderators can moderate the pictures as well.

2. We added an unregistered caregory in our forums so that guests can post stuff too, mainly for asking troubleshooting questions, or to confirm their validation (we have lots of spam bots that try to register our forums daily, so an admin validation is required for all the new users).

3. Just an hour ago my host installed FreeBSD 6.3 on the server (we were using 6.1 I think), and the server has multiple CPU support. While the server is not threaded, multiple CPU support helps by running the 3 servers we have on different CPUs (if needed), and also for the system and interupt code (which is mostly network related). Later on, I will start adding some threading on the server, to make it even faster.

4. We didn't have as many users as we expected from the c't magazine. Before it was published, I thought they will give us a bigger review, but it turned out our little game was one of many other games in that magazine, and we just got a few paragraphs. That's not bad, we are not ready for a lot of new users at once anyway,

5. NASA wants to develop a MMO, and they are asking for the public to come up with some ideas. I submited a document with my ideas, and I'll see if they are interested (the deadline is February 15). While I don't have much hope they will select my design (who knows how many people and companies submited theirs), it would be cool if they at least pick some of my ideas.

6. Xerafax is working at a better mouse seletion algorithm (the part where you get the object or player under the mouse). This should increase the frame rate by up to 100% in some situations (but mostly 20%+), and also increase the sensitivity and accuracy, especially for small monsters. We discussed some ideas today, and we'll see what happens.

7. I added a new item in the game, called "invasionmeter". With a few invasions every week, that new item is quite useful. What it does is show you how many invaded creatures are in the game at one moment, and how strong they are. This item has a 10% chance to break on each use, so it will be good for the economy too.

New web server

2008-01-30T02:56:00.000-05:00

Because we are expecting a lot of visitors after the c't magazine is published, and because our old web server was kind of slow, we decided to pay more money but get a better server.
As with the old one, this server is in France, and is managed by our host.
We have 100mbps (no traffic shaping), fast CPU, and 1GB of RAM.

Transfering the forum was a pain, because we also wanted to update from IPB 2.1.7 to IPB 2.3.4 Long story short, it didn't work very well, so I had to contact the IPB support (we pay $30 a year for it). They were very fast and professional, as always, and fixed our problems. The only problem left is that our custom skin is not entirely compatible with this new forum version, so Roja is working at fixing it.
The end result is very encouraging, this server is significantly faster than the old one. Now I am confident enough that the website should handle whatever c't will throw at us.

As for the game server, we did a stress test where we had about 1.1K connections, and CPU was at 35%. Based on this information, I would expect to be able to handle around 2500 players at the same time. There are a few more optimizations that I can make, such as multithreading some time expensive routines, which will allow us to accomodate even more players, maybe 3K or so. But before that, I need to profile the server again and see which parts take most of the CPU time.

The client is almost done for the update, arrows and shaders work fine, we just need to do some more testing and we can have the update in 2 or 3 weeks.

Latest news

2008-01-18T15:16:00.000-05:00

The arrows code is done, both on the client and on the server. While we still need some more tests, and probably various fine tunning, everything works fine right now.

Xaphier is working at a vertex shader rendered for the cal3d animations, and he is making good progress. There are still various issues with his code, but once it is done, there will be a significant frame rate increase, especially for people with good videocards. The idea is to move some of the CPU workload to the GPU, for two reasons:
1. Sometimes videocards can do the animation faster than the CPU can.
2. Sometimes the CPU is busy with other stuff (such as compressing video, compiling a program, rendering images, etc.), so by having some workload switched to the GPU, you can play the game at a decent frame rate even while the CPU is busy with other stuff.

A big German magazine (c't) will include EL on their DVD a the end of the month. They will also review the game, and have an article about it.
Now, this is a big magazine (400K readers), and if even 1% of their readers decide to try the game at the same time (like, say, the day it is published), we will have some problems handling so many users.
I am going to increase the server users limit to 2.5K, and hope that there will be no issues. I estimate that our current game server should be able to handle over 5K people at the same time, but the CPU load does not increase linearly with the number of users, so we'll just have to see what happens.
The web server, on the other hand, might not be so lucky, so it is quite possible that for a few days after that magazine is published the website will be very slow, or even unreachable at all.

But of course, those small problems are worth it, it's not often that you can get your game exposed to almost half a milion people (and probably even more if the article will be published on the website too).

Arrows

2008-01-08T04:32:00.000-05:00

The arrows code is almost done, thanks to Schmurk who contributed with a lot of code (about 70% of the client and server missiles code is done by him).
I am almost done with my part of the code, and in a week or two we should be able to have a complete test on the test server.

So far, I am very excited about the whole misisles thing, it's been something I always wanted to have but never got the time or knowledge.

The misisles will server quite a few purposes:
1. Make combat more strategic.
2. Give people of different trades new items to make.
3. Moneysink. There will be two kind of arrows: Training arrows, which will be buyable form an NPC only, and will cost 10gc a piece, and the 'PK' arrows, which will be made by players, and will cost more (will also be more powerful and accurate). Of course, you will be able to PK witht rainign arrows, or train with PK arrows, but doing so might not be a very good idea.

PK server

2007-12-31T03:44:00.000-05:00

A few days ago we started the PK server (we erased all the characters from the PK beta testing), and so far we have over 200 accounts, with over 60 players online during the afternoon. So far, I think that's pretty good, and everyone is having fun there.
I had to make some additional modifications compared to the main server, such as removing the NPCs that sell high end weapons and armor, and making the summoning stones have a 75% failure rate, in order to avoid fights by proxy, where players just summon bears to kill the enemy's bears.
After people start getting higher levels, perhaps around level 60 a/d, I might add those NPCs back and make the summoning stones work without failure. But that's something to determine later on, depending on how the game will progress.

I have a secret character there, and I even play the game, partially because it is fun, and partially because it is easier to see what changes or additions should be made to improve it.
For example, I have an idea for a new perk (that will also be implemented on the main server, although it will be far more useful on the PK server). This new perk will be called "Night Stalker", and will cost 8(?) pick points. It will greatly increase your stealth at night, so you can evade enemies, or ambush them from the shadows. It will be cool if a whole guild takes this perk and becomes some sort of assasin guild, where they collectively go and ambush strong enemies.
One reason this will be even more effective is that many people will drink potions right before a fight, so if they don't see you prior to you attacking them, they won't be able to get their potions, but you will be able to.

I am not sure when I will have this perk done, perhaps in a few days or so. Which means that if you are a PKers, regardless of which server you play on, you might want to save a few pickpoints for it.

Wind of change

2007-12-19T00:34:00.000-05:00

A lot of stuff happened in the last 10 days.
First, I started a beta version of the PK server. So far, we got about 130 sign ups for the PK server, which is great.
Then one thing lead to another, and some players expressed their interest in incorporating some changes meant only for the PK server to the main server as well.
One of the changes is caping the attributes to level 48. The other change is having a mage class, where rationality affects the power of the spells.
We have a poll on the forums about the level cap on the main server, and the majority of players (about 3 out of 4) agreed that such a cap is necesary. Interestingly, all the top level fighters that also commented on that thread agreed with the change.

The only thing that hasn't been decided yet is on the restoration spell formula. There are a few versions being discussed, and there is no general consensus about which one is the best, so there is still some work to do.
But after all the changes are made, I think the PK will be much better, because with the caps in place, people will actually have some weaknesses, so we won't have virtually invincible players.

Killing the bugs

2007-12-08T03:16:00.000-05:00

Short status update:
Some of the client programmers expressed their wish to have a better bug tracking system, and now they got one, thanks to Placid.

We gathered all the known bugs together, and we are trying to fix them. Some were already fixed, others are harder to reproduce, which means it will take a while to fix them. Hopefully, by the end of the year, or early next year, we'll have the bug fixes update. The good thing is that this time people will be able to use the release candidate on the main server, which allows a few thousand people to test it and see if they experience elss problems.

On an unrelated note, I added a summoning menu, which allows you to control how your summoned monsters will behave. It makes use of the new server push up menu system. That menu is usable only when your summoning level is 30 or higher, which means that most of the PKers will eventually have to spend some gold coins on leveling that skill, so more money flow in the economy, towards the small guy. So it is a win-win situation.

Update and problems

2007-12-01T00:27:00.001-05:00

We had our update Monday, and I am not entirely pleased with the results.
The good thing is that for most of the people, the client is working fine, and they had little or no problems installing the update.
But for a small minority (around 6%) there are constant problems that make the game unplayable, and the game crashes on most of the computers, but not very often.

In the last month or so, I did very little programming work, and focused mainly on coordinating the update, do the testing, suggest bug fixes on the forums, try to find more information on things, and so on. This is getting frustrating, because there are quite a few new features I would like to add, but can't, due to lack of time.

The crashes are not entirely our fault (the blame is shared between our code, 3rd party libraries and drivers), but we need to find some workarounds anyway, because it is frustrating to have unstable code. Generally, if you do not fix the bad code in the early stages, and keep adding on it, you will be in a bigger mess with each new update. Because of this, I decided to have another feature freeze until we can identify and solve the most common problems.

While we are at it, I want to expand the debugging support for the client, so that when the client crashes we can have some meaningfull information which we can analyze. Right now, only a minority of players (those who can compile their own client and run a debugger) can send us precise information on where/why the code crashes.

The update

2007-11-22T03:53:00.000-05:00

Everything is ready for the update, except for the Linux and Mac client. Hopefully, we'll have the Linux client by tomorrow, and the Mac client in a few days.
The final release for this update for windows has been released so that people can predownload, and if the stuff is not ready by Friday, we'll push the update to Monday (I don't really want to do it during the weekend).

Most of the PK server maps are almost done as well (mainly changing them all the PK, with the exception of a few maps), and we are expecting the PK server to go in some testing mode in early to mid December (we'll have a one or two weeks beta, with an item wipe at the end of it, so that we can test various variables that will need to be adjusted).

Invasions

2007-11-18T04:25:00.000-05:00

A few weeks ago, we started a new 'tradition': During the weekend, we'll have a No Drops Day (you don't lose your stuff when you die, monsters don't drop anything). During the NDD, there is a general invasion for everyone, with monsters ranging from Spiders to Giants and sometimes Dragons, and this invasion is free style, pure hack and slash fun, almost no rules (although we encourage players to fight monsters their own levels, and not kill the monsters designed for the newbies).
The second part of the day is a big invasion on one single map, where we start with 520 giants, 60 red dragons and 20 black dragons (the numbers can vary a little).
The objective is to clear the map in a given time period (around 4 hours). If the players manage to do that, then the next weekend they get a similar event. If they fail, then the next weekend they will get a weaker invasion, and no No Drops Day. However, if they do kill all the monsters in the allocated time, they get another NDD next week.

Until now, we had the final invasions in Bethel, a small desert map which is mostly.. deserted. Being a small map, 600 monsters are allover the place, and it is very hard to kill the first 100 or so (you basically die within the first 1 to 10 seconds in the map). However, after the monster density decreases, it's relatively easy (ie. not insanely difficult) to kill the other monsters.
Given the fact that most of the fighers enjoy No Drop Days, they work together as a team, regardless of their alliances or wars. Lower level players that normally can not kill giants also participate in the invasion, either by acting as cannon fodder, and/or mages, harming and poisoning the monsters.

After the last invasion, one of our players, Conavar, came up with an idea on how to spice up the invasions.
He suggested that there should be some secondary objectives to an invasion, that would give the players some bonus such as extending the deadline, removing some monsters from the map, give the players access to some hidden supplies, and so on.
The secondary objectives could be escorting a player to safety, having to kill a player, etc.

I immediately fell in love with this idea, mainly because it reminded me of one of my favorite childhood games, Tie Fighter, which is a futuristic combat flight simulator. I am not sure how many played that game, but the idea behind it is that you pilot various ships and you need to accomplish some well defined goals. Goals like destroy a certain ship, protect/escort another ship, disable one ship and then protect it, and variations on this theme. Those missions were very well constructed, and made the game really fun. Most of them had a primary goal that had to be completed, and secondary, or bonus goals, which were optional.

Because Bethel is such a small map, it was impractical to run any side missions there, since the monster density won't allow it. So instead we used Idaloran, which is a BIG map. There were two announced secondary objectives, one of them being that in 1 hour the city must be clear from any monsters, and the other one was to find and escort Gicu (the character I run invasions with) to safety. The first secondary goal failed, but the second one was completed. Near the end of the invasion, I added a 3rd secondary goal, where two black dragons in another map had to be killed in 30 minutes. Players completed that goal as well.

Overall, it was a very nice invasion, and pretty much everyone who participated enjoyed it. A lot of good items degraded during the fights, which contributes to the economy and our pocket :D Many health essences and rings and mana potions were also used, which contributes to the economy alone (not to our pocket).

I'm looking forward to the next weekend, and have to come up with some new ideas about secondary missions.

Update status

2007-11-11T02:51:00.000-05:00

Short update about the.. update.
Most of the bugs were fixed, and the only thing remaining to be done is finishing the new file management system.
Basically, on Windows, the settings, counters and logs will be saved somehwere in c:/my documents/elc/ (for Linux and OSX, there will be no significant change).

The main reason for this is that under Vista you do not normally have permissions to write in c:/program files/, where EL is normally installed. Another reason is that we finally want to unify stuff so they work the same on all the OSes we support.

This will complicate things a little for the end user, but it's not our fault that all the modern operating systems require applications to write their data somewhere else. Besides, most of the programs already do that, so who are we to disagree?

We will probably have a final RC in a few days, then, if there are no problems, we'll have the update in a week or less.

RC1

2007-11-02T03:59:00.000-04:00

A few days ago we uploaded the first Release Candidate for the update.
The biggest new feature is the sound, which requires a lot of testing. Other new things include the support for engineering objects (mines, snares, etc.), lots of clothes, a menu system that the server can send to the client, support for the tailoring skill, and a new file management system.

Most of the tests went well, but there are some bugs left, so we'll need at least one more RC. The good thing is that we don't have show stopper bugs.
The way things are going now, we should have the update by the middle of this month, although we do not make any promise, as Murphy never sleeps.

Increased storage space

2007-10-21T23:32:00.000-04:00

When we added the storage to the game, some 4+ years ago, we had 100 slots. At that time we had maybe 200 items.
Two years later, we had around 400 items, and the storage space has been increased to 200 items.
After this update is done, we'll have some 850 items in the game (about 300 of them are books).
Many players complained that they have not enough storage space, and they asked for more. Until now, it wasn't really needed, but with some 70+ items to wear, one would need a lot more storage, if he or she wants to have one piece of everything.

There were two reasons why I didn't want extra storage:
1. I was feeling that 200 slots are enough (and they were, for most of the people).
2. The storage command couldn't send more than 200 items because that's too much data (over 4KB) and a big waste of bandwidth.

Well, now things changed, and I am going to add another 100 slots either shortly after the update, or before it, if we have a long testing period.
The #storage command will also be modifed, and you will have to specify a category, and it will only list the items in that category.

Tailoring skill

2007-10-18T21:32:00.000-04:00

I got a few questions about the tailoring skill, which I am going to answer here.

Q. Will new items make it to this update?
A. Yep, about 54 new WEARABLE items for the tailoring skill alone!

Q. Will the thread and gloves be moved to the tailoring skill?
A. That won't be necessary. There will be over 70 items to make with this new skill (including dye and fabric), so there is no need to move items around. When I decided to make the tailoring skill, I didn't think we'll have so many items.

Q. Will the already existing items (adventure caps, bandanas) become tailorable?
A. I don't know yet. Possibly, but we have a lot of items as it is, so we'll see in the future. If we make them makable, they will be very high level (around 90-100).

Q. What will be the highest level item makable under tailoring?
A. With the current items we have, excluding the items currently available only from the shop, probably somewhere around level 80-90 or more. However, Roja likes making new items, so this might change to even higher levels, possibly even 120+

Q. When will the update be?
A. We still need to add those items to the client, test them, then test the mines again, have a release candidate or two.. So maybe in about a month, of things are going fine. Hopefully no later than the beginning of December.

Q. What about the PK server?
A. We'll start working at it during the release candidate testings, and will be released after the update.

Preparing for the update

2007-10-13T03:39:00.000-04:00

Our little experiment with Pawn didn't go really well. We had some unexpected crashes that were very difficult to debug, because the crashes were not in our code, and they were not in the Pawn code either. Instead, they were in various external libraries such as SDL_net.
But since we've been using those libraries for years without any problems, we are reasonably sure the problem is either in the Pawn scripting, or in our implementation (the C interface).

Either way, we decided to just switch back to Small which still has most of the things we want, and everything we need.

Meanwhile, we are preparing for the client update. We are not sure yet which features will make it to this update, but we are confident that the new sound engine will. There will also be the new tailoring skill, some support for mines (possibly not the explosions though), and MAYBE some rudimentary implementation of a shader engine where we can add shaders per materials.

I've decided not to release any server updates any time soon, and instead hold them back for the client update. The things I am working on now (landmines and tailoring) are not compatible with this client anyway.
I am also hoping that in 2 weeks we'll have some pre release candidate where people can test the new additions, and depending on the bugs found, the update might follow in another two weeks or so. Of course, this is just a guesstimate, so don't count on it.

PK server

2007-10-02T14:29:00.000-04:00

Recently, I came up with the idea of having a PK only server.
This is not exactly a totally new idea, there were some previous suggestions, but until now I didn't really consider implementing it, mainly because I didn't think we'd have enough players to actually play there.
But after posting about it on our forums, and having a poll about it, it seems that there is some interest in such a server. We have a saying in Romania: "Pofta vine mancand", the word by word translation would be "the appetite comes eating", meaning that sometimes it is necesary to start a thing, and then things will fall in their place.

This new server will be quite different than the main server, in the following ways:
1. Most of the maps will be PK, with the exception of Isla Prima, the underworlds, and the cities (only the cities, not the whole map).
2. There will be a level cap for attack and defense, at level 100. This cap might be initially lower, and increase in time.
3. Some negative perks will be removed, so that players won't be able to artificially pump themsleves up.
4. As a result of the above changes, the economy will be totally different, and there will be all kind of alliances, protection fees, possibly territorial control and fights, and so on.
5. Rostogol stones will be cheaper and less rare, and no other items will be sold from the shop.
6. Less moderation, no rules against multiplaying, however there will be a one time 5 usd fee to start playing on that server.
7. Since most of the updates on the main server are now targeted towards high level players in non combat related skills, this PK server will not be updates as often.

Now, obviously, this server is not for everyone. In fact, the average EL player won't like it much at all. But it will cover some special needs, and who knows, in the future it might work better than expected.

Changing to Pawn

2007-09-25T00:58:00.000-04:00

Our server side scripting language is called Small. It's a nice, C like scripting, which is easy to integrate with C and has a JIT VM as well, which means it is very fast.
We were using a very old version (since 2005), and since then there have been some new changes to this scripting language, which is now called Pawn.
Some of the changes add features, some fix some problems, while other changes break backward compatibility, especially in the host C functions, which didn't really motivate me to update, as we were pretty content with the version we were using.

However, since we are going to be using this scripting language on the client as well (for some dynamic maps and player based cities), we thought it would be a good idea to finally upgrade to the latest version. Learner did most of the updating work, and we've been tested it on the test server for a few days. Aside for some problems which are now solved, everything was pretty smooth.

Since we are waiting for the testing to be finished (another few more days), I've started to implement some extra new items that were supposed to come later on in the game. One of them is a 'lightmeter', which will be used to determine how visible you are at night or in caves, on a particular tile. Useful for stealth or ambush type 'missions'. The reason this device is useful is beause the server and client calculate the light in a different way. The server uses a square attenuation, while the client uses a linear attenuation, so some areas are really dark while they appear not so dark. This might change on the next client update, althogh if we use a square attenuation on the client, many areas will appear to be very dark, so some players might not like that.

Onc we are done with migrating to Pawn, I'll start finishing the landmines code, do more testing, then prepare for the client update.

Tailoring skill

2007-09-10T00:25:00.000-04:00

Roja always wanted to make a lot of new clothing items for the game, but until recently, she was busy with other things. In the last few weeks, she made a lot of clothing items. Pirate outfits, fancy clothes, and so on.
We had two choices:
1. Sell them from the store and make big $$$ (well, not really).
2. Make a new skill so that the players can make the items themselves.

We decided to go with the new skill, because it would add more fun to the game, which eventually means more $$$ for us (indirectly). We are so devious, aren't we? :)

Anyway, this skill will be very difficult to implement properly. Why? Because the idea of the nice clothes is that they have to be EXPENSIVE, or else everyone has them and they are not rare anymore.
Imagine everyone was able to make clothes, who would be stupid to buy them?
Now, imagine everyone had to do 500 shirts a day just to get more experience in order to make suits. The shorts would not be very valuble on the market, would they?

So the idea is that people should be able to level this skill without actually making [many] clothes. One way is to add a lot of low level resources to the game, such as fabric and dyes. So the low level tailors would just make fabric and dyes, until they reach level 30 or so. Making those things will be time consuming, so many people will not take the skill, leaving only a few selected, dedicated people to do most of the clothing in the game, which they can sell for a lot of gold coins.
Another idea is to move some items from manufacturing to tailoring, such as the scarfs, gloves, etc. But if I do that, I'll need to find some replacement items for the newbie manufacturers, to fill in some gaps.
This skill is still a few months away, so I have enough time to decide how to do it, and will ask for some player feedback as well.

Pets

2007-09-06T00:02:00.000-04:00

One thing I want to work on, after I am done with the astrology and the landmines, is a 'pet' system.
I didn't finish designing it, but here is an outline (which might change):
1. Each player would be allowed to have ONE pet.
2. In order to get a pet, you will need to buy an egg. To prevent the overcrowding of the game with pets, those eggs will be expensive (100K gc or more).
3. There might be different kind of pets, and some might be available only for real money. However, all the pets will be equal, they will just look different.
4. Pets will level up, but not by fighting (because if they level up by fighting, a lot of spawns will be taken by people and their pets). Instead, you will level them up by 'feeding' them with various items. Not sure yet what items, how much they will cost, and how many would be required for a level.
5. The pets levels will be different than player's levels. I plan to have only a limited number of pet levels, maybe 10, maybe less. Each level will considerably increase the power/combat capabilities of the pet. For example, level 1 will be good enough for rabbits, level 2 for wolves, level 3 for armed goblins, level 10 for yeti. Again, those levels will need to be determined by testing and by players feedback.
The attributes for the pets (coordination, physique, perception, etc.) will automatically increase with their level.
6. There might be a few classes of pets (pets that use magic, pets that summon, pets that are meele fighters, and so on). However, they will all be free in terms of real life money, and the paid versions will only have a different avatar, not different capabilities.
7. The pets will have a limited 'life', and they will die after a while (probably depending on their level). Players will not be able to heal them or to prolong their life. However, they will be able to ressurect the pets, with some special stones, which will cost in the 100-1000 gc range. I think I will have stones for different levels, so if you have a level 3 pet, you will need a level 3 (or higher) stone. The higher the level, the more expensive. The stones may or may not be manufacturable by the players, this is yet to be decided.
8. There will be an 'upkeeping fee' for the pets, in order for them to keep their level. If you don't 'upkeep' them every month, their level will decrease. The method to upkeep them has to be determined.
9. The pets will fight animals/monsters in normal maps, and other players or pets in PK maps. Some maps might not allow pets (such as Isla Prima). However, the pets will not gain any experience from fighting.
10. Pets will follow their masters, but they will not be able to change the map (when the owner disconnects or changes maps, they will die).

This is the basic outline for the pets, but things might change by the time I actually start working at implementing them. I don't know when they will be done, but I think they will be in the game in less than 6 months.

The astrology system is on the main server

2007-08-29T00:41:00.000-04:00

After a few days of extensive testing, the astrology system is finally in the game. It's not 100% done yet, I still need to implement two modifiers, and the astrology reading stones, but so far it seems to work great.
Most of the players like it, although it did create a lot of confusion (which was not unexpected).

I expect the whole thing to be done in another 2 weeks (including the testing), and then I can focus on other things. I don't expect to add or modify anything related to the astrology once I am done with it, so it is important to do it well.

Once I am done, I will start working at the landmines and finish that code, so it can be tested with the CVS client for the client update (which should be somewhere in November).
Speaking of client updates, I think that it is best to keep them rare, something like 2 releases a year. Too many updates are not good, they thend to confuse some players, and the more often we update, the more bugs creep in. When the updates are rare, there is more time to properly test them and remove most of the bugs.
For the server updates, I think that 10-14 days is the best, to give time to the players to adjust with the previous changes, and to make sure that every update has enough new things/changes in order to make the players look forward to it.

The astrology system and some new books.

2007-08-20T00:12:00.000-04:00

Today I finally started to work at the astrology system. I guestimate that it will take about a week to fully implement, and perhaps another week of testing, then maybe a month or two of adjustments, depending on players feedback and stuff.

For the time being, we will have the following modifiers: chance to make rare items, chance to harvest rare items, chance for an item to degrade in combat, accuracy, attack, defense, critical to hit, critical to damage, items failure rate, and magic (attack and resistence).
Other things might be implemented in the future, but for the time being, I think this is enough.

The modifiers will go both ways, negative and positive, depending on how the planets are on the sky relative to your sign. I won't give much details about how it will work because I don't want the players to figure it out by themselves.
Instead, I am going to have an astrologer NPC that sells some special stones. One stone for each modifier. When used, they will provide information about that modifier (for example, if the current failure rate is high or low). Those stones will dissapear after each use, and they will cost probably around 100-200 GCs.

I also added some new fighting books, for some medium and high level monsters (ogre, phantom warrior, fluffy, yeti, giant, and the dragons).
The dragon books are very expensive, close to 300Kgc, but I think they will be worth it for the high level players.

Back from the vacation

2007-08-12T12:52:00.001-04:00

We just got back yesterday evening (7 pm).
The trip itself was nice, but the transportation sucked.
AirFrance managed to lose one of our luggages, where I had my cellphone charger and other stuff. What really bothered me is not that they lost it, but how they handled it. Instead of notifying us in the plane, we waited at the luggage pick up place for like 1 hour, then we went to ask WTF is going on. Only then they told us they lost it.. So we lost half an hour waiting for it, which could have been avoided.

We had Internet access most of the time, via a CDMA modem, so I was able to see what's going on in the game, and answer some e-mails. Fortunately, there were no problems with the game while we were away.

Now that I am back, I will add a few new manufacturable items, then work on the astrology stuff. There are some other small changes I plan to do, but more about them later.

2 weeks vacation

2007-07-26T01:58:00.000-04:00

This entry is going to be pretty short:

Today we (Roja and me) will be going over to Romania for a small vacation.
Being a vacation, I don't really plan to do much work, but I should be online every once in a while, depending on how good our mobile internet connection will be.
I do however plan to do some design work, especially with the astrology system, and some other stuff that I will talk about later.

If anything interesting happens, I'll try to post it here.

Astrology in EL

2007-07-19T22:38:00.001-04:00

A few weeks ago, I came up with the idea of adding an astrology system in EL. I didn't start implementing it yet,and in fact I didn't even fully design it. I will do that on the plane, on my way to Romania for a 2 weeks vacation.

This is how it will work:
Every player in the game will be assigned a random star sign. I am not sure how many star signs there will be, probably 12. Those signs will be unique, not using any existing horoscope.

Players will not know what sign they are, unless if they go to some astrologer NPC that tells them, for a fee. That NPC will also (for a fee) tell you how the next week is going to be for you, from an astrolgical point of view.

There will be a number of planets; the number is yet to be determined, but probably around 7 or so. One of them will be the planet where everyone lives, and the other planets will influence some activity. For example, one planet will influence the defense, one will influence the chance to get rare items while you manufacture things, and so on.
Each planet will orbit around the sun at a different speed, just like in the real life.
Depending on the angle between the planet everyone lives on and the planet that influences a certain activity, and the star sign of the individual, a chance will be computed for each action.
I might even implement a moon, and the phase of the moon will weaken or strengthen the effect.

This whole thing will require a lot of math (especially trigonometry), so I'll make sure to bring some formulas with me on the plane, as I won't have internet access during the plane trip.

New invasions

2007-07-05T23:42:00.000-04:00

Last year I implemented the automatic invasion system.
Most people enjoy it, but it's been pretty boring, with only one invasion route.
The system was designed to be easley upgradable, to allow multiple routes, randomly selected by the server. Unfortunately, until now, I didn't really have time to add more routes.

This has changed now. Today I spent most of my day by adding alternate routes, so now most of the important first continent maps are covered by invasions.
The continent two invasions will be even more interesting, but I won't give any details here. You will have to experience them :)

And now a little about an idea of mine that would give some limited invasion control to the players.
What I am thinking about is to have some "invasion stones", that are basically some sort of 'eggs' that players can place wherever they want, with some exceptions.
Then the eggs hatch, in a random time interval, ranging from 30 minutes to 300 minutes. When they hatch, monsters spawn.
There will be a few different egg types, each spawning a different monster. The quantity of eggs will be limited per day, to prevent abuse.
I am not done yet with the details, when I'll decide how exactly it will work, I'll post about it on our forums.

The PK top implemented

2007-07-02T00:31:00.001-04:00

In my last post, I was talking about implementing a PK score, and a PK top as a measure to make PKing more fun/rewarding. Of course, this is not the only measure I plan to do, this is only one of them.

Now, the original idea was that each time someone is PKed, he would lose a point, and their adversary would gain one. Then some people came up with the idea of having an asymmetric system, where someone would lose more (or less) points than someone would win, depending on their previous PK score. Under this system, someone with a high score killing someone with a low score would not gain as many points.

Eventually, trollson came up with an even better formula, and some graphs too.
Since his formula was simple but elegant, it got implemented and tested. No one had any objections, so it's now the official formula, on the main server.

Now, another idea that I came up with.
Many people are complaining about the fact that since the rostogol stones were implemented (which cause you not to lose items when you die), the PK has never been the same. Other people were complaining about the cooldowns on using items, saying that after that has been implemented, people stopped PKing as much.

So I am willing to 'fix' those issues, by having a map where there are no cooldowns, and where the rostogol stones do not work. I am really curious if this will be a popular map or not.

PK points

2007-06-25T23:59:00.000-04:00

A while ago, I added a feature where guilds can declare total war, and whenever someone killed a player from a guild they are mutually at total war, his guild would win a point, and the opponent's guild would lose one.

This system isn't very popular, most guilds avoid total wars at any cost.

However, someone proposed extending this system to individual kills. I was also thinking of something similar a while ago, but my main concern was cheating (someone creating an alt so that he can kill that alt and gain points, or have a friend's alt do that).
Today, I think I came up with a solution to this problem. Not a perfect solution, but it should solve most of the cheating problems: Only the players with a relatively high attack and defense rating would be able to participate in such a system. So if you attack and kill a newbie, or if a newbie attacks and kills you, no one gains or loses a point. Besides, leveling an alt to a very high level, just so that you can gain points with it is impractical; you can use that time to actually level your main char and get more points.
As a failsafe, we will monitor suspicious fights, and if we determine that someone is cheating, he will lose all the points.

There are two possible systems we can implement: Symetric and asymmetric.

The symetric system is the easiest: You lose a fight, you lose a point, you win a fight, you gain a point. This way, the sum of all the points in the game is close to 0, but not necesarly 0 (for example, if someone destroys their character, or if someone is punished with a points reduction).

The asymmetric system differentiates between combatants. If you kill someone of a lower level than you, you get little points, and the opponent loses few points. If you kill someone of a higher level, you gain more points and the opponent loses more points. Determining the levels of the players is tricky, some suggested to use the number of points each combatant has, and implement something close to the ELO Rating System. Another way would be using their skills and attributes as a level. Both methods have various shortcomings, and I will ask the players which system they would like most.

Land Mines

2007-06-15T00:13:00.001-04:00

In the last few days, I started working at the land mines.
First time I wanted to have land mines in the game was about 4 years ago, but I always had other things to do. In addition to that, some people (like Roja, for example) complained about them not fitting in the game theme.

After doing some research, it seems that the first documented explosive land mines were developed in 1530, which is at the end of the medieval period. That means, they fit the game theme.
Of course, those are the explosive mines. However, devices such as caltrops were used thousands of years ago.

Anyway, originally I just wanted to make a mine that goes boom when you step on it, and hurts the person that does so, and the nearby people. Then I came up with the idea of having proximity mines, which explode when someone is near them.
And when I started implementing them, I started with the data structure that holds them (I always do the structures first, and the code later). And it dawned to me that there are so many other things I can do. For example, I can make wards.

A ward can have multiple uses, such as:
Heal the person that placed it when nearby.
Make invisible players visible, when nearby.
Drain the mana of nearby people (including the caster's mana).
Increase the skill of the caster when nearby.
Decrease the skill of everyone nearby.
And many other cool stuff.

Then we can also have traps, where when you step on them, they will prevent you from moving for a few seconds. Or caltrops, that will damage you and possibly destroy your boots. Or, poisoned caltrops, that will poison you.

And, finally, we can have barricades. They will be temporary walls that can be used for defense or even offence (like trapping someone inside them).

Obviously, there will be some restrictions concerning the and mines and related objects:

1. The person that places them needs to have a certain engineering level, the more lethal/complex the mine, the bigger the level needed. So engineering will be the only skill that is required to actually USE some item, not only manufacture it.
2. They can only be placed in PK maps (not in PK areas, such as arenas).
3. In order to prevent their abuse, the land mines and associated objects will have a limited time, after which they will dissapear. The time will be probably around 10 minutes or so. They will dissapear if the player that placed them leaves the map (including death and disconnection). Most of them will be indiscriminate regarding who they affect. So if the person that placed them is not careful, they will hurt him too.
4. The proximity mines needs to be activated by a remote control device. Otherwise, they would prematurely detonate when the person that placed them moves. In order to activate them, you will need to be pretty close to their location, but outside of their sensitivity radius (you can activate them inside the sensitivity radius, but that might not be a good idea).

The mines will be implemented relatively soon (in a month we should have at least some working kind of mines). But, since they require client support, they will not be in the game until the next client update, which should be around november. However, we will have tests on the test server, for people willing to compile their own client from the CVS. We will annouce such tests, so everyone that can compile (or get acompiled client) can test them.

EL Player Statistics

2007-06-10T21:58:00.000-04:00

Until recently, I had no idea how many active players we have. Now, I have all the data avaialble (the logs) but no time to process them, or to make a script that does.
A few weeks ago, I was talking with Scafativ, who is the owner of Gossip, an offline messaging bot. Our game does not have offline messaging capabilities, and we didn't really want to add such a thing, because the forums can be used for that.
However, some players wanted some ingame offline messaging, so a few bot owners implemented that. Gossip is the most popular bot. In addition to that, it has some other functionality, such as matching people for PvP training, and so on.

I asked Scafativ if he can compile some statistics about our player base, because his bot 'spiders' the online players page every few minutes. Being a data analyst, I figgured that he would be the perfect person for such a job. He agreed, and today he PMed me the results, and I decided to make them public:

date, #characters, #char_minutes, #char_hours, avg_min/player
20070518, 2115, 591448, 9857, 279
20070519, 2237, 649464, 10824, 290
20070520, 2255, 693748, 11562, 307
20070521, 2090, 565108, 9418, 270
20070522, 2028, 549622, 9160, 271
20070523, 2008, 536354, 8939, 267
20070524, 2014, 546426, 9107, 271
20070525, 2051, 550980, 9183, 268
20070526, 2166, 618758, 10312, 285
20070527, 2203, 645926, 10765, 293
20070528, 2230, 658270, 10971, 295
20070529, 2160, 589010, 9816, 272
20070530, 2115, 559502, 9325, 264
20070531, 2096, 566532, 9442, 270
20070601, 2128, 556018, 9266, 261
20070602, 2215, 649506, 10825, 293
20070603, 2236, 641708, 10695, 286
20070604, 2122, 580180, 9669, 273
20070605, 2159, 596986, 9949, 276
20070606, 2173, 599336, 9988, 275
20070607, 2246, 600140, 10002, 267
20070608, 2219, 592132, 9868, 266
20070609, 2324, 707704, 11795, 304
20070610, 1606, 306690, 5111, 190 (partial)

Anyway, we both remarked that the numbers are surprisingly consistent. As you can see, the number of players per day fluctuates around 2150 per day. Now, when he will compile weekly statistics, we should be able to determine the total active population (for example, not everyone logs in every day).
I am not sure what the numbers will be, but I am guessing it will be around 4K.

Roadmap for the next update

2007-06-08T00:07:00.000-04:00

We are planning to have the next client in November, but this is, by no means, any promise. It's just what I would like.

If all goes well, we'll have the following things:
1. Working landmines/proximity mines.
2. Missiles (mainly arrows, but hopefully also stuff like 'medieval hand grenades' and smokebombs).
3. 3D terrain.
4. New special effects.
5. Speed improvements.
6. Normal maps.

Now, I am not really sure we'll have all that in November, or even at the next client update, whenever that will be. However, we will have at least some of those features.

One feature I want to talk about now is the 3D terrain.
As you probably know, our terrain is mostly flat, with some mountains or mounds here and there. The water is also slightly under the ground, at the same level allover.
Daniel is working at a 3D terrain, based on heightmaps.
The pros:
1. The game will look nicer.
2. The game will be slightly faster, especially on newer video cards.
3. Newer maps could be easier to make.
The cons:
1. The maps will be bigger.
2. Since we will use multitexturing for the terrain to blend two texture layers together, older video cards that have only two texturing units will not be able to display the clouds shadows and the normal shadows.
3. All the maps in the game will have to be re-created to some extent.
4. We will get rid of the 2d objects layer (the stuff on the ground, such as leaves, etc.)

Now, there might be some issues with getting rid of the ground tiles, and having only a height map. Especially in some inside maps, where the floors are littered with lots of 2d objects, such as blood, bonse, etc. So we might keep the tile mode as well, but we'll need to see about it.

We are also thinking of adding some new features that would make the game incompatible with some very old video cards (most of the computers in the last few years should still work, we are talking about really old videocards, older than a GF2). Again, we are not sure of this yet, we'll need to have some sort of poll on our forums and see how many people would be affected by such a change.

The update, finally done!

2007-06-04T22:27:00.000-04:00

Yesterday we had our update. A few weeks later than originally planned, but it went remarkably well.
99% of out players had no problems, the rest had some problems with the sound, which caused their client not to start. We fixed this problem by telling them to disable the sound (it took a while to figure the source of the problem).
Now only a few players (less than 5) have some other problems that prevent them from playing the game, and we are trying to help them too.

We did, however, forget to include some #defines in the client, and the windows version is compiled without a few bug fixes, so there are some minor problems affecting other players. We are planning to release a patch soon, that should fix them.

We also moved all the downloads off our website, to external mirrors, which made the forums and the rest of the site more responsive. We are still pulling between 2 to 4 mbps every day, mostly because of the forums. We might have to get another server for the forums alone, and use the current one for the rest of the website. Or just move to a more expensive webhost.

Ode to Intel

2007-06-03T02:18:00.000-04:00

Ever since we started working at EL, there were times we had to contact a hardware manufacturer (usually video card manufacturers) for some problem or another.
Until recently, we only got in touch with nVidia and ATI/AMD. Both were pretty responsive, and were willing to assign one of their driver engineers to work with us.
Nvidia actually helped fix one bug in their Linux drivers, without us even contacting them (one of their developers seen my post on a forum, and volunteered to come to our game and reproduce the problem). It's worth mentioning that this happened in 2003, when EL was still in it's infancy, and we didn't have more than a few hundred users (in total, not online at a time).

Last week, I sent an e-mail to the Intel tech support people, explaining that we have a problem with some of their OpenGL drivers, and asked if they would be willing to assign an engineer to work with us.
To be honest, I expected a negative response, something like: "We don't have time to help you", but I figured that hey, what can I lose?

And even though I was expecting to be disappointed, Intel's response was perplexing..
They basically told me that the game is not officially supported by them (duh!) and to either update my drivers, or go to the game's website and see if they released any patch that maybe addresses this issue(!!!)

Which means that they didn't even READ my e-mail, but just sent me a canned reply, probably generated by a machine.
This is totally outrageous, especially since I have two Intel computers (and two AMDs). And our game server runs on an Intel CPU. It shows that Intel doesn't give a fuck about it's customers. In fact, we care more about their customers than they do, we held back the update for two weeks just to fix this particular problem with their video cards.

Because of this, I will never buy anything made by Intel (CPUs, network cards, video cards, and so on). One good thing about capitalism is that it gives people the option to vote with their wallets.

Future server optimizations and multi-threading

2007-05-28T01:34:00.000-04:00

Personally, I think that the threads are the root of all evil, especially in a MMO server. They make debugging very difficult, can cause serious and hard to trace bugs if not done properly, and the speed benefit is not that great (about 30-40% in practice, if done right).

All this being said, there are some cases where multi threading is a good idea for a MMO server:
1. When you are processing a lot of data that is not dependent on other thread's result.
2. When you are CPU limited.
3. When you want the fastest response time possible (lowest latency).

Some MMO servers use a blocking/threading model. What that means is that you have 1 thread for each player (or 1 thread for a number of players), and the server uses a blocking socket (the execution of the thread is intrerrupted until there is any incoming server activity).
Other MMOs (like Eternal Lands) use a non blocking, non threaded model. That means that a socket will not block the program execution when it doesn't have data, and, instead, you move to the next socket to process the next player.
A third category of MMO servers use a hybrid model: Non blocking, threaded.

This is what I plan to work on, after we are done with the update.

So, how will it work?
Right now, there are two routines that take most of the CPU time: the path finding, and the range calculations (the part that determines who sees who).

And it so happens that those two routines are not dependent of previous results; they can be done in parallel.

The range calculation is basically done like this:
for each map,
for each player on the map
test to see if you can see each player on the same map

How can this be switched to multi-threading?
Well, we can have multiple threads (as many as the physical number of cores in the system), and each one will do one map. Once it finishes, it will move to the next unprocessed map. Of course, there will be some state table so two or more threads won't do the same map, wasting time and causing conflicts. This table needs to be locked each time it is accessed (read/write) to prevent other threads from doing the same and mess things up.

The path finding is slightly more complicated. Why? Because right now, we use an "as you go" model, where the path finding routine is called whenever a path needs to be determined.
However, most of the time it is not necesary to have a path right away, although in some cases it is (such as for determining if you can access a certain location or not).
So then the path finding function, which currently looks like: int find_path(int player_id, int target_x, int target_y) will be modified to look like: int find_path(int player_id, int target_x, int target_y, int urgency)
The urgency value is a boolean, and 1 means I need the result right now, while 0 means that it can wait for a while.
If the value is 0, the server will not attempt to calculate the path, but just set a variable on the player structure that a path is needed.
And after all the stuff is read from the sockets, we can have a global path finding routine, which checks every actor and calculates the path for those who need it. Then each thread can do a different path in a similar manner with the range calculation, since the paths are not dependent of eachother.

Currently there is really no need for this, because even with 750 player/bot connections and over 1300 AI entities, the server never went up more than 15% CPU.
However, this will slightly improve the response time (by a few MS), and will allow us to host even more players (maybe up to even 10-20K, depending on how many CPUs we have).

Problems with the Intel video cards

2007-05-26T21:52:00.000-04:00

Everything about the update is ready and tested, but what holds us back is a problem with the Intel videocards under Windows.
Under some circumstances (not often, that is), they will not display any 3D stuff. That happens at night only, in some areas.

Given the fact that none of the developers or programmers have such a video card, it is very difficult to fix it.
While we have a 'no one left behind' policy, that is, we try not to release a client until it works fine on everyone's computers, this time we might have to make an exception, which means release the client and then if we find the bug later, issue a patch. This is not a critical bug, because the game is still pretty enjoyable, except that in some areas you need to turn the camera around to see stuff. And given the fact that it affects few players, I decided to just go on with the update.
Probably we'll have a new client for pre-download on Monday, then have the update on Tuesday.

Status report

2007-05-17T22:25:00.000-04:00

We released a RC a few days ago, and, as expected, there were a few problems.
Now most of them are fixed, and we'll have another RC tomorrow.
There is at least one client crashing bug, which happens when fighting armed orcs, and possibly some other monsters, but the problem is that it doesn't affect everyone.
In fact, very few people are affected, so that makes debugging quite hard.
The good thing is that KarenRei's client can crash via fighting armed orcs, so last night we worked at this problem (well, she did the debugging while I did the orcs summoning/fighting). Hopefully she will be able to fix it tonight, and if not, prior to the update.

One thing is certain: the client is looking much better with the new special effects, but there is a severe cost in the frame rate, when there are too many effects in the game at once. When we are ready with this update, we'll be looking into using vertex shaders for some of them, which should significantly improve the speed. There are a lot of new plans for the future clients, and I'll post some of them here in the near future.

The Release Candidate is almost there

2007-05-12T23:47:00.000-04:00

Most of the bugs and problems have been fixed, so this coming week there should be a RC available, and depending on how it goes, we should have the update before the end of the month.

Meanwhile, I did a lot of server stuff, like adding new monsters, changing some spawns around, the new books for the Engineering skill, new manufacture formulas, a new harvesting resource, adding new items and changing some item images (for the items we didn't have images before), and all kind of other behind the scenes work.

Of course, they will need to be tested on the test server before we have the update, so, unfortunately, we can't surprise the players (at least not those that bother to test stuff on the test server). But then again, we have a pretty open development policy, and we don't have many secrets about upcoming releases. For example, the yesterday's update had all the new engineering books, so people know what to expect from this skill.

Getting closer to the update

2007-05-05T23:50:00.000-04:00

The update was planned for sometime in May, and we are making good progress.
It seems that each new client has fewer problems than the one before it, although some people still report isolated crashes and performance problems with the new particle systems (the eye candy).
If everything goes well, I plan to have a RC (release Candidate) by the end of next week, and an update around 20th of May.

This update will add a new skill (Engineering), new armors and weapons, new animals, and, for the first time in a long time, no public new maps (we do have some guild maps, and fixes to existing maps).

Meanwhile, while waiting for the client to be fixed, I am doing some behind the scene server fixes and code cleanup, plus adding the new monsters, items and books. The manufacturing formulas for the new things will be added after the update.

Once we are done with it, we will be working at implementing the missile system on the client, land mines and caltrops, new special effects, and various other improvements. It is yet too early to have a date for the client update coming after this one, but I would like to have it in October (longer release times allows the client developers to add moe reliable code, since no one likes to work under pressure).

The new bags system is on

2007-04-30T16:08:00.000-04:00

Last night we had a server update to include a new sword, some new books, and the new system of sending the bags to the players (I mentioned it a few posts ago).

It seems that the impact on the bandwidth is significant, the traffic going down by about 10-15%. For the people with dial up connections, the maps should load much faster, because instead of getting all the bags on a map at once, they get only the bags in their visual range. And a bag that was once seen will stay on the client until the bag dissapears (times out or is emptied), which takes care of sending a lot of bags when going back and forth an area with lots of bags.
In addition to that, some bandwidth is saved because when a bag is placed, only those nearby will get the message, rather than everyone on the map.

This allows us to have dynamic maps (the cities, in the future) without using more bandwidth than we used prior to this update, for the same number of players online.

EL Age Demographics

2007-04-29T18:07:00.000-04:00

Someone made an age poll on our forums, and the results are pretty interesting.
As of the time I am posting, it will seem that people over 20 outnumber 2 to 1 those under 20.

between 5 and 10 [ 0 ] [0.00%]
between 11 and 15 [ 33 ] [10.00%]
between 16 and 20 [ 74 ] [22.42%]
between 21 and 25 [ 57 ] [17.27%]
between 26 and 30 [ 47 ] [14.24%]
between 31 and 40 [ 67 ] [20.30%]
between 41 and 50 [ 39 ] [11.82%]
between 51 and 60 [ 9 ] [2.73%]
older than 61! [ 4 ] [1.21%]
Total Votes: 330

If we assume that half of those between 16-20 are over 18, then only about 21% of the players in our game are minors.

This is not so surprising, a lot of kids come in the game only to start yelling "OMFG THIS GAME SUCKS!!1!!". Older people are less likely to do that.

Huge Yahoo Mail Security Problem

2007-04-26T19:16:00.000-04:00

Today, for the first time in about 10 years since I am online, I almost got phished.

What happened was, while checking my yahoo mail, I got a message in my inbox (as opposed to the Bulk folder). So, as any other person would do, I opened it.
It was a message in Romanian, along the lines: "Hey, how are you, long time no see".
It was kind of strange, because I didn't know that person, but since there was no advertising or anything I figgured that maybe it's some old friend I forgot about, so I copied the address and pasted it to the Search box, to determine if I had previous messages from this person.

At that moment, I got redirected to the Yahoo log in page (or so I thought).
The URL was: http://us.f237.mail.ymauth.com/login_verify/?Y=someid

Now, that didn's look suspicious for the following reasons:
1. It looked like the Yahoo log in page.
2. My session was about to expire.
3. It had my username there (so I guess the phisher had unique IDs for each username he sent the phising to)
4. I didn't click on any e-mail links (I thought that I must have accidentally perform some Opera gesture like the back button, and my session just expired).

So I innocently typed my password, then Opera asked me if I want to save it...
Oops. Not good at all. I immediately closed the browser, hoping that the password is sent only after telling Opera whether to remember it or not. Then just in case, I quickly changed my password and forwarded the e-mail to the Yahoo abuse team.

Now, I admit I had some fault in this too, I should have looked at URL location as well. However, I think the biggest problem is with Yahoo, by not doing a proper sanity check of the e-mail (for example, anything that changes the URL without the user's permission should not be allowed).

I was lucky this time, but many others might not be so lucky.
And since a lot of people have all kind of passwords associated with their Yahoo accounts, prepare for a new wave of internet fraud (especially eBay and PayPal).

P.S. Here is the content of the e-mail: http://&/#x77;ww.custodia.it/images/custodia2/us/?id=removed&val=open&cookie=

I tried some online URL decoders but couldn't decode it properly, and I am too lazy to decode the whole thing manually.

New bag bugs

2007-04-23T00:05:00.000-04:00

A few weeks ago, I thought I finally fixed the last problem with the bags.
In case you don't play the game, the problem happens when you open a bag but can't get its content.

There were two other problems with the bags, which were fixed in the past, and I thought that this problem was related, so fixing those two bugs would fix this one as well.
One of the bugs was with the client, and when people still reported the problem, I dismissed it to them not using the latest CVS.

3 days ago, I was testing the new way of sending the bags to the client, and specifically asked everyone that wants to help to come on the test server ONLY with a recently compiled client from the CVS.
Some people reported a few issues with the bags, so in order to check if the problem is with the new way of sending the bags, I switched back to the old way, and people still reported issues.
Based on those reports, I added additional debugging code on the server, which pinpointed the problem: The client was sending spurious "close bag" messages.

The client is supposed to send a "close this bag" message only when the player presses the "x" button on the bag window.
However, the client code has been buggy for like 3 years, and it was sending that message each time the bag was closed, regardless of the way it was closed.

So this is what happened:
1. Player opens bag.
2. Player moves to another bag.
3. Server detects the move, and closes the bag the player has open, sending a "close bag" message to the client.
4. The client gets that message, and wrongly sends a "close bag to the server".
5. Sometimes: LAG
6. The player moves to another bag and opens it.
7. The server finally gets the message from the client: "close bag" (step 4)
8. The server closes the NEWLY opened bag.
9. Player tries to get the items from the bag.
10. Server sees that the bag was closed, and will not allow the client to get items from it.

Learner fixed the client bug, but we are having some problems with the CVS which is not working for most of the team members (server won't authenticate them).
Hopefully by tomorrow we can test the problem again, and put an end to a 3 years old bug.

Behind the scene changes

2007-04-15T15:20:00.000-04:00

There are a lot of "behind the scene" changes in a MMO server.
For example, one of the things I don't like about how the EL server handles stuff is the way it sends the bags to the players.
Right now, whenever you enter a map, the server sends you ALL the bags on that map, which is a waste of bandwidth. Each time a map is added or destroyed, the server sends that message to everyone on the map, which, again, is a waste of bandwidth, and it is a minor security problem. For example, I am sure that there are some modified clients which scan for such messages, and can tell a player if a spawn is taken or not from the frequency and location of those bags. (If you are a 'hax0r' and think that it would be a good idea to implement this in an illegal client, don't bother, it will be fixed soon.)

The cheating potential is relatively minor, which is why I didn't really bother to fix this problem. A fix is pretty time consuming, so I always did other things instead.

This is about to change, however. Before the Engineering skill, the problems were: extra bandwidth + slight cheating potential.
Now that we plan to add land mines, and later on the player built city stuff, we need a more flexible way of determining what a player sees in terms of dynamic map stuff (dynamic stuff includes bags, mines, and city buildings).

So what I need to do is actually add a mechanism similar to the code on how a player sees another player.
Each map has a list with all the bags that are on that map. Soon there will be another list for the mines, and later on another list for city objects.
Then there will be a super list that contains all those other lists, with an index to point out to the actual object (the actual bag, building, etc.), object type (bag, mine or building), it's location, and some other data.

Then each player, whever they move one step, will go through that super list and determine what objects they can see, and only those objects will be shown. That list will be cached on a per player basis, to speed up the processing.
Speaking of processing, this new system will increase the CPU usage by maybe 20%, but that's OK, because right now the EL server usually runs at 10-11% of the CPU, so with those new changes it will run at under 15%. Even with an estimated 1.5K players online, we should still have plenty of CPU left.
Furthermore, the whole calculation can be done in parallel with the player vs. player seeing distance calculation, since this two routines do not depend on eachother.

Bug fixes and a feature freeze

2007-04-09T22:44:00.000-04:00

The client is in a feature freeze, meaning that no new things will be added until after the update, and the focus is on finding and fixing bugs.
There are a lot of changes in this version, such as finally moving to a more optimized object format, compressed maps and objects, using the zlib library, much better special effects, a few bug fixes from the previous versions, and so on.
The problem with so many new things (submitted by many contributors) is that there are new bugs, which need to be found and eliminated before we release the update.
After all the known bugs are fixed, we will release a Release Candidate (RC), and invite people to try it and report problems. After the problems have been found and fixed (that can take from days to weeks), we will release another RC, until no serious bugs are found, and then we will proceed with the client update. Hopefully it should be ready by mid May.

Speaking of bugs, we had a few small bugs on the server that were relatively harmless, but sometimes annoying.
One of those bugs was the fact that when trying to open a bag or enter a door from a distance, you would stop just on top of the bag, or near the door, without opening the bag/entering the door. This didn't happen too often, and was impossible to reliably reproduce on the main server. On the test server, it just didn't happen at all.

Debugging a MMO server is very difficult, because you can't just use a debugger (imagine a break point being triggered late at night, when no developer is around, and have the whole server frozen until me or Learner check the debugger Window).
So since hardware break points are out of the question, and the bug was not locally reproducible, I had to write a lot of logging code, to log various function parameters and see if certain pieces of code are executed.
In pseudocode, it looked something like this:

function()
{
some code
log if the program got here
more code
log if the program got here
call some function
log the returned parameters from that function
}

Eventually, me and Learner narrowed the problem to two functions, but we still didn't know what's wrong, so even more debug code was needed. I went as far as placing software 'hardware' breakpoints, such as a piece of code to constantly analyze a variable and see if it changed when it shouldn't (I was fearing some buffer overflow destroying some variables).

Eventually, it turned out that the problem was a return in a for loop. I should have used continue instead :/ And this bug has been here for almost 4 years...

Well, at least that bug is fixed now. Another bug that is fixed is the possibility of getting two bone stacks instead of one, when taking off an equipped bone. Again, not really a big deal, but sometimes a small bug can hide a bigger one. It turned out that there was no bigger bug, and due to the fact that someone was able to reliably reproduce it, I managed to fix it pretty fast.

Our 1 week vacation

2007-04-03T22:57:00.000-04:00

I live in the US for 4 years, and this is was my first vacation here (my previous ones were to Romania).
We went to Orlando, Florida, and I must say that I was very impressed with everything there.
Florida is a very nice place, and Orlando is even nicer, being built from scratch as a tourist place. They have good public transportation, restaurants and fast food places everywhere, and anything you need in a walking distance.

We visited Disney World (MGM and Animal Kingdom), and SeaWorld.
If you haven't visited them, and you have the opportunity to, I highly recommend them, especially the Animal Kingdom and SeaWorld.

As with any tourist, we took a lot of pictures. You can see some of them here. I will add more soon.

One would assume that a 1GB XD card is enough for a whole trip, but with a 7 MP camera that wasn't the case. The XD card could store something like 250 pictures at the max resolution, and there were days when I filled the whole card in just a few hours. The reason I needed so many pictures is the fact that the camera we have takes about 1 second to focus, so since the time you press the button to the time it actually captured the photo you have to wait about 1 second, then another few seconds to save it to the memory card. This leads to a lot of missed shots, especially if you want to capture a particular moment, such as when a dolphin is in the air or when a fast paced stunt is performed. The only easy to mitigate that problem is to take a lot of shots, hoping you will get lucky and some of them will capture what you wanted to.

My new laptop was very useful during this trip. Besides for downloading the photos on it so I can free the XD card, I used it for e-mail, Skype, news, reading the forums, and even delivering some items in the game. It is the first time I am taking a laptop with me on a vacation, and it proved to be very, very useful. I am definitely going to take it with me next time I go somewhere. The only downside of having a laptop with you is that you will not relax 100%, and you can't help from doing some work, which will sometime defeat the purpose of going on a vacation :)

Statistics and Databases

2007-03-21T23:31:00.000-04:00

As I explained in one of my articles, I don't really like storing the players data in a database. Instead, we use flat files, which, IMHO, are easier to work with and faster.
But a disadvantage of flat files vs. a database is that it is hard to obtain statistic information. For example, checking to see the total quantity of an item in the game using flat files requires opening every single player file, which is slow and inconvenient. Then if you want to determine some other statistic information, you will need to reopen all those files again.

Luckily, our server is designed not to need any such statistics. If some statistics are needed, they are saved in a special file, and loaded whenever they are needed, or just kept in the memory.

But often times it is a good idea to have a quick glance at some stuff that is going on, for example seeing how many gold coins are in the game, and the top 100 players in terms of how many gold coins they have. This is useful for many purposes, including balancing the economy, creating new formulas, adjusting some rates, and even checking to see if there are any item duplication bugs.
As previously mentioned, it is hard to get all this data without a database.
Which is why I worked at actually storing all the stuff I am interested in an Sqlite DB.

Sqlite is a public domain database (SQL) library. It's not a database server, such as MySql or MSSql. Because of this, there is less time involved in accessing the database (no indirection layer), and you don't have to worry about having a server running all the time.
Because it is public domain, we can embed some server code in the program that is generating the statistics. With GPL code it is slightly more complicated (in theory we can use GPL code in our server, and not be required to make our source code public, because we do not distribute it; however, GPL3 is going to change that so we'd rather not use any GPL code at all).

Writing the program was relatively easy, Sqlite is very easy to use, at least on Windows. The problem was in having a script that would feed that program with every player file name. As I am developing under Windows, I didn't have native access to the powerful and very useful Unix commands, such as bash and find. The Dos/Windows .bat is not that powerful, and I couldn't find a way to get all the files in a directory, recursively, and send them to a program of my choice.
So what I did was download Cygwin, which is for Windows what Wine is for Linux (well, sort of).
One problem that I had is the fact that it would seem that the bash version that comes with it is using an internal version of "find". So when typing: "find ." from the bash prompt, it complains about some bad parameters... Eventually, I just renamed find.exe as find_1.exe and used "find_1 .", which seemed to work better.
The script looked like this: "for i in $(./find_1 .); do ./stats.exe $i; done" (Lachesis helped me with it).
The player files I used were taken from the previous night's backup.
The script worked, but it was very, very slow. It took about 4 hours to process 101K files. I am not sure if this was because of Cygwin, or because of Sqlite, my program was pretty fast.
I talked with Learner about it, and we are going to modify the program to get it's own files, so it will not have to rely on an external script. Making it get it's own files will also make it faster, as it doesn't have to open and close the database for every player file.

Despite for all those small problems, once the database was created, the end result was very nice. I was able, in seconds, to get the total quantity of the gold coins in the game (about 200M). Not bad, that would be about 2K gold coins per player, on average. Of course, as with the real life, the amount of gold coins in the game is not evenly distributed, some players have over 2 million coins, while others have considerably less. In fact, here is the top quantities of gold coins for the players (I am going to publish only the quantities, not the player names, for privacy reasons).

3117212
2788486
2581151
2486154
2076652
1679400
1616314
1603558
1528248
1428579
1386501
1373042
1301485
1284118
1256488
1203808
1164721
1134737
1101526
1099434
1061115
1058531
1027778
996269
960114
948841
948784
882865
858820
842955
809451
786818
765751
746009
740049
723096
711036
674987
674701
671717
657964
642701
632000
597026

The irony is, more than a half of the players in this top never bought anything from us, so the game can very well be played without paying anything. As for those who do buy items from us, I suspect that the reason they are in the top is because they like the game a lot and play a lot. After all, you wouldn't buy items if you didn't play a lot, right?

Another interesting thing is that a lot of rare items are pretty abundant in the game. For example, there are 15K enriched fire essences, and they sell for around 3.5Kgc each. If they belonged to one single person, and if that person had enough buyers, he could sell them for about 20K USD (not bad). Of course, they do not belong to one single player, and very few people have more than 20 in their inventory. The reason there are so many of them in the game is that for a year or so, I didn't check on how many were entering the game vs. how many were exiting the game, and we had quite some disparity (about 2 entering for each that was exiting). Now that I made them more rare, more are exiting than entering, so in a few months their numbers should decrease by a few K.
It is also worth mentioning the fact that some of those players are no longer playing, so the real quantity might be something close to 10K, but that is impossible to know for sure.

To end this long post, I am glad I spent some time to write this program and use Sqlite. It proved to be quite useful, and will help with the ongoing task of constantly improving Eternal Lands.

Finally all the cross attributes are used now

2007-03-15T01:44:00.000-04:00

EL is online for a little more than 4 years, and the attribute system is almost as old as the game. Until recently, two cross attributes: charm and perception were totally unused, and, unsurprisingly, most of the people did not invest a significant amount of pick points in them.

The perception was finally added in the last update, and it dictates how far you can see at night. In the future, when we will have the range attack skill, it will help with it as well.

The charm, on the other hand, was more difficult to integrate with the game. Initially it was meant for quests and better prices from NPCs, but eventually I abandoned that goal and just let it unused. I even considered changing it's name altogether, and possibly use it for the ranged skill.
Today I made up my mind, and charm will still be charm, and it will have to do with the summoning skill. It will modify this skill in two ways, but this is a surprise for the coming update. Hopefully many people will like it, although I don't expect everyone to suddenly start investing pick points in it.

Different visibility system

2007-03-10T00:05:00.000-05:00

Something I wanted for a very long time is finally in the game now (on the test server, and soon to be on the main server).
I am talking about a system where you can hide during the night time, and use camouflage and night vision items.

How it works: When you are inside a dark cave or dungeon, or when you are outside at night, far from a light source, you will be less visible than those near light sources. Those with a higher perception cross attribute and those with night vision equipment (not available now) will be able to see further away at night. Wearing armors and weapons will make you more visible to others.

This system allows for more variation during the combat, especially effective in a team work. For example, a player with a high perception attribute and a high magic level can hide in dark places and cast Harm or Mana drain on an enemy. Or an ally can cast heal on you, without the enemy noticing that.
In addition to the combat itself, the engineering skill (when implemented) will be partially used to produce equipment that makes use of the different visibility system. For example, we will have at least two camouflage capes (active and passive camouflage), night vision helms, a lightmeter, to precisely determine the light level of where you are, and some device to briefly show you the players that you see but they don't see you.

Another use for this system is in my "to do" list, and will probably be implemented this spring or summer. The idea is that all the bags and land mines/traps will have their own visibility. A bag will be more visible than a mine, of course. However, at night, it will be harder to see the bags that are not too close to you.
This means that the higher your perception skill is, the further you see the players and bags, and the better your chance will be to detect the landmines so that you can avoid them.
For the time being, all the clients get all the bags on a map, even if those bags are at the other end of the map. I don't really like this, it helps people cheat a little (if they use a hacked client) and it wastes some bandwidth (not a lot though).
So my next project is to change the way the bags are sent to the players, which will involve some quite CPU expensive code. Fortunately, this code can run in a thread in parallel with the code that checks if a player sees another player, so on a multi CPU system there will be little to no speed penalty. In the future, I am also planning to use some additional multithreading where it's possible, but more details about it later.

Lot of improvements and new stuff soon

2007-03-06T02:28:00.000-05:00

Today, for the first time in months, I downloaded the client CVS and compiled it, in order to test the new object format, which has a few improvements over the old one, such as the materials ordered to minimize texture changes, and redundant faces removed.
Daniel finished the new format, fixed a few problems with the converter, and added the support for it in the map editor, which means that now we can finally switch to a more efficient format.

In conjunction with the compressed maps, objects and textures, the client loads faster and it is slightly faster.
We had a test today, with a pre pre release candidate, and it seems that there weren't any problems with the latest changes.

The only thing I don't like about compressing everything is that the download file size is much bigger than before. The reason for this is that with the objects uncompressed, the installer compresses all together. If they are compressed individually, the file sizes increases. One way to mitigate this problem is having the objects uncompressed, then after the game is installed the installer can run a script (a bat, maybe) to compress them and delete the uncompressed versions.

On the server side, I am almost finished with the light maps and the different visibility based on the light (nearby lights, time of day, etc.). It should be ready for testing by the end of this week.

Lightmaps

2007-02-27T21:10:00.000-05:00

For a long time I wanted to have two things in the game:
1. Night time shadows.
2. Different visibility based on your location, ambient light, nearby light sources, what you wear, what your attributes are. For example, someone sitting in a shadow at night time, with no armor on, would not be visible by someone sitting a few meters away. However, the person in the shadow would see someone that is in open space, under a light. Wearing shiny (metal) armors would make you more visible. Having a higher perception skill would make it easier to see people hiding in dark places.

Last night I spent about 8 hours (going to bed near 6 AM) to write a quick and dirty server side light map generator. The idea was to take each walking tile, see what the nearby lights are, trace a ray from the tile to the light, and if it isn't blocked add an attenuation base done the distance to the light, then store the info.

The generation was relatively easy an painless, due to the fact that I used the collision detection routines that were already there (same as for the arrows). It was fast too, it took only about 12 seconds to generate it for Whitestone, which is the biggest map size we have in the game.
I wasn't pleased at all with the results though. First problem was that most of the lights are placed inside lamppost or fireplaces and so on. Which meant that the ray collided with the object and the tile was marked as not illuminated. I fixed this by checking the end collision point, and if it was less than 30 cm away from where the light was, I assumed the collision was with the lamp post (or whatever other object is used to represent a light source) and marked it as illuminated.

The next problem was that even if a small tree branch is occluding the light source, a whole tile is marked as shadowed. Not good. This could be solved by adding about 10-20 rays with a small displacement, then computing an average value to see how many made it to the light source.
Then I realized we have two more problems that can't be solved with the current algorithm: The collision thing does not take the texture into account, so many trees obscure a light source even if the leaves would allow the light to pass. Now, this could be solved by taking the texture into account, but then some function would need to be severely modified. The second problem, which is far harder to solve, is that the client does not have this information, as we have no light maps. So even if a tree obscures the light, if a tile or object is close to a light, it will be fully illuminated. This would create a lot of confusion for the players, as they wouldn't know where are the good spots to hide, or where they can expect some hidden player to be.

There are quite a few other problems which I won't even go into, such as the fact that to do it right, we'd need like 6 bytes for each walking tile, to take the light intensity at different heights.

I talked with Schmurk about it, and we decided that the best solution to this problem would be to use lightmaps on the client.
Now, there are a few problems with the lightmaps, especially with high quality light maps:

a. They can take many GB of hard disk space, for one map alone.
b. They will take many MBs of RAM, possibly up to 512 or so per map.
c. They can take forever and ever to generate, possibly a day or two for a big map, on a fast computer.
d. Given their big size, they can't be included with the client download. Even compressed they might add up to 1GB or more for the whole game. So we will have to use p2p networks to distribute them, and maybe even sell a DVD with the prerendered maps.
e. They do not work with dynamic maps.
f. They do not work with moving things (players, animals, etc.)
g. If you make a change to a map, you will have to regenerate the whole lightmap for that map.

Now, for the advantages of using them:
1. Once created, the server can use them as well (with some modifications).
2. We can have true shadows during the night and in indoors areas, we can have as many light sources as we want, and a light can be visible from as far as we want it. Additionally, we can have soft shadows, and shadows from multiple lights (so there won't be only a shadow or no shadow).
3. The game will look so much better with them.

I already contacted a former developer, who is very good with math and OpenGL, and he will implement them for us (we'll pay him for it).

Until then, I am going to ignore all the collision with the lights, and use only a linear attenuation on the server, to determine how visible a player is. This is a good way to test the system, and when we have the light maps, we'll use them on the server too.

Collision detection

2007-02-20T02:27:00.000-05:00

During the past week, I spent most of my time working with the collision detection code provided by Schmurk.
He did a really good job, so there were very few problems with it. The first test, on the test server, started friday. There were very few issues, mostly due to the fact that I was setting the collision height a little bit too high (150 CM). Another problem was that I forgot about some 'ghost objects', which are deleted objects that are still in the maps in order to preserve the ID sequence for some other objects. So in a few cases ghosts objects were interfering with the collisions.
After fixing those two problems, and after Schmurk adjusted a few settings in his code, everything works fine now.
Now we still need client support for the arrows, which will be a lot of work as well, but then we can have arrows flying through the game, and a new skill (Range).

I am pretty exciting about all the things we can do in the near future. Things such as having some monsters attack you only if they see you. Or some magic spells where you must to have a line of sight with the enemy. Or, maybe, even for some quests.

What we are working on

2007-02-11T15:32:00.000-05:00

Learner tried (with pretty good results) to make use of the zlib library that is linked in the Windows version to the binary (it is needed for the XML parser). He tested compressing the maps and 3d objects with it, and it seems that now the map loading time is faster.
He didn't do extensive tests yet, but it only makes sense for compressed files to load faster, after all the HDD is the slowest thing in a computer, and with today's fast CPUs the decompression is almost instantaneous.

Then we have our 'special effects guy', KarenRei who has almost completed integrating his new special effects in the client. He posted some screenshots here.

I am already working at integrating Schmurk's collision detection code in the server (should take a few more days, plus a lot of testing), and then Learner will add the gzip support to the server as well, so that the maps will load faster, which will mean reduced start up time, which will hopefully compensate the reduced start up time from the collision detection initialization stuff.

All in all, things are pretty good for, and we hope that we will have a new client update around April or May with the new special effects and some speed ups. The arrows are not going to be in the next client though, there is still a lot of work to be done.

Windows Vista

2007-02-10T15:24:00.000-05:00

Vista is out for almost two weeks now, and EL doesn't seem to work on it. We don't really know why, no developer has Vista, nor do we plan on switching to Vista any time soon. In fact, I am thinking about moving to Linux or FreeBSD in a few years, when they will be more mature for desktop use, and when the percentage of XP computers will drop under 30% (or when the majority of hardware manufacturers will stop releasing drivers for XP).

It seems that the majority of our players don't care too much about it either. Now, that poll is not the most accurate reflection of their will, since many didn't care to vote, but nevertheless it is good to see that about one third of our players use non MS OSes.

I am aware that many people buying new computers (that come preinstalled with Vista) might not be able to play EL, and this doesn't concern me for the time being. We are right now in a 'comfort zone' where the amount of players is just right. 500+ more players and then it will become kind of crowded for one server, then we'd have to look into more servers, which is a lot of work (see my previous entry).
Of course, sooner or later someone will address those issues so our game will work fine on Vista eventually. But there is no rush.

One other thing I am curious about is the number of people that will say no to MS and go with alternative OSes. If things go as I believe they will, in 2 years the percent of non MS OSes will be somewhere around 10%. Right now the percentage of non MS operating systems it's about 7%, divided mainly between OSX and Linux (4% OSX and 3% Linux). It is difficult to find an accurate source for those numbers, some sites reporting Linux to around 3% and OSX to around 4%, others reporting more or less than that.

867 concurent players

2007-02-01T02:56:00.000-05:00

Last saterday, we had a new record: 867 players, and counting the player run bots, about 950 connections.
I think that this new record is a little bit inflated, it was Stakhanov's day (*3 harvesting experience) and some people also brought their alts on, to level them up faster.
Nevertheless, it was an interesting experience from a development standpoint; the CPU usage almost doubled compared to just 800 connections (it went up to 22%).
A big part of the increase was due to the operating system itself, such as the time spent dealing with intrerupts (hdd access, networking).
Now, 22% CPU is not a lot, but it seemed that the increase was almost exponential, which means that we might not be able to accomodate more than 2K players on a single machine. So in a year or two, we might have to have another server.
This is a logistic nightmare in itself (we would need new moderators for that server, new forums subsections for each server, more time spent to update the servers, and so on).

On the other hand, we need more data, especially to see what happens when we reach 1K connections on a daily basis. We are currently not using full optimizations during the server compilation (we use O1, not O3). We can also try a few more tricks that would reduce the server load a little bit, but it is really hard to predict how the CPU usage will look like with 2K connections. If we are lucky, we might be able to push the limit to 3K players, especially because we ony use a P4 @3Ghz, which is an OLD CPU (about 2 years or so). A newer CPU with more cache might make a big difference.

But one thing is clear, in the future we will have to have more than one server, and need for that is an indication of our success. And by the time we will need that, we hope our financial status will allow us to hire a few full time team members to take care of the moderation issues associated with our future growth.

Announcing the new skill and latest plans

2007-01-23T17:38:00.000-05:00

As promised in a previous entry, I will reveal the new skill.
It is called engineering, and will be used for the following things: creating landmines and RC bombs, repairing weapons and armors, and possibly in the player based city construction.
This skill will require a client update, so it should be there around April or May.

In the last week we had some talks on our forums about implementing missiles in the game. Today we had a meeting in the game with Schmurk, the one who is implementing the code, and we decided to try and see if a BSP tree structure for the object would work or not. A BSP tree would be slightly slower than having each map tile store a list of objects that cover that map, but it would use significantly less memory.
Either way, it will take longer for the server to start, given the fact that we have to load all the 3d objects and possibly some other data structures. Our estimate is about 30 seconds more, which is not really a big deal, except when testing new stuff and have to restart it often.

The beauty about having a 3d collision detection system on the server is the flexibility it adds. For example, we can calculate a true lightmap, doing a raytracing between each tile and the nearest lights. Or, later on, in the distant future, we can even give up the tile based movement and implement a true, free movement system. We are a long way from that, but one can dream, no? :)

One other goal of mine, which seems to work pretty well so far, is to have some 'commercial districts' in the game, made entirely or partially from player run bots.
This is good for everyone: it is good for us because we have more points of interest in the game. It is good for the players because they can find a lot of bots in one location, so they don't have to waste their time running back and forth.
And finally, it is good for the bot owners because more players come to visit their bot.
The first 'district' is almost completed, 3 bot places left. Next, we will have to find some other districts to populate, mainly in C2. Once they see how many people are visiting the first commercial district, I am sure they will agree to move their bots together, in other marketplaces around the game.