Before I go on with the last part of Eternal Land's history, I would like to thank everyone who had nice things to say about the previous articles, and shown support. I would also like to explain the relatively long gap between Part IV and Part V. There were quite a few reasons that delayed it, such as being very busy, and not having a lot to add. So I wanted to wait a little and write a more interesting article. In addition to that, people interested to see what's going on could also read my blog.
Server Administration
After I 'left' Eternal Lands, I still continued to work with the rest of the team, but not directly. It was more like 'working from the shadow', so to speak. Two of the developers started to work at the server, and they made various modifications, mostly balancing things in the game and improving various aspects of the server code, such as adding an auto harvesting system to respond to wide criticism about people getting their mouse and hands ruined in while harvesting. A few months later, in January, they both quit. I can't really blame them for that; after all, I did the same thing just a few months before.
Someone had to work on the server side, because having no server developer would mean total stagnation. For an MMORPG that is equivalent to its death. Fortunately, it seems that the Universe (or God, or chance, if you like) had some other intentions, and we found another server developer. He was already a client developer, and he is from Romania, so our communication was always very good. He also knows a lot about security and Linux administration, which is extremely important for server-related work. With him in charge of the server, things started to move again at a slow pace, but they were moving nonetheless: a few new items were added, some bugs were fixed, optimizations were made. Combined with the client changes (which were more frequent and drastic, due to it's open source nature) we even had a few updates.
Choosing Between Working on Barren Moon or Eternal Lands
Meanwhile, I was working on my new MMORPG game, Barren Moon, with two of the volunteers that used to work for Eternal Lands. One of the Barren Moon developers had to go in the army for 4 months, so he wasn't able to contribute much to the code during that period. The other developer, while he did contribute significantly in the beginning, was either too busy or didn't have enough motivation, so he basically quit.
Until July of 2005, I worked a lot on Barren Moon's server, and accomplished quite a few things, such as making the plants grow, leave seeds and die, then have new plants 'spawn' from those seeds. I even implemented a much better harvesting system, where the resources are limited, and some respawn after a while, while others don't. Most of the city building system was done, and the last thing I worked on was making a voting NPC where people can vote for their leaders, or make a referendum and remove some leader from his position, in case someone abused his power.
However, while the project went out pretty well, there was too much work for one single person to handle, and Eternal Lands was not doing that good, as the server-side improvements were relatively minor and rare.
Once the Barren Moon developer that was in the army (Wytter) returned, he started to work more on the Eternal Lands server, rather than Barren Moon's, and I was a bit overwhelmed with the amount of work needed to finalize BM, so I had to make a decision: Continue to work at BM and finish it in a few years, or put the project on hold and work at Eternal Lands until it's more mature and able to generate some income that we can be used to fund additional projects such as BM.
Meanwhile, Wytter and another client developer (Grum) became EL server developers. They implemented quite a few nice things, such as changing the player format to a more robust one, adding a better GUI for the storage system, making the trade system a bit more secure and allowing trading from storage to storage, adding new quests, supporting the ability to listen to multiple chat channels at once, and so on.
In August, we (my wife and I) went to Romania for 2 weeks, where, among other things, we met with Mihai (the Romanian developer). We did a lot of brainstorming about the future of EL, and I knew that he alone doesn't have enough time to implement all those ideas, which made me choose to return to the EL development.
Other Events that Took Place in 2005
Password Stealing Exploit
In around July, someone reported that he found a bug which allows him to steal passwords under special circumstances. He even provided some source code. Now, that was very nice of him to do, and we would in fact have rewarded him, had he not actually used those passwords to log in as other users. While doing this is against our rules, I would have overlooked that, had he not stolen people's items. In a short period, he robbed about 10 players, stealing their best items. Because that was unacceptable, I banned him and wrote a complaint to his ISP on this issue. We were also able to recover most of the stolen items and return them to their original owners.
Just after we banned him, he posted his exploit code on quite a few EL related forums (mostly on various guild sites). To make things worse, at that time all the active server developers were offline, and I was unfamiliar with the location of the source code on the server, as they changed a lot of things after I left. Luckily, one of the previous server developers that left in January returned just a few weeks before, so he figured out which directory has the 'production' code, and together we managed to find what the problem was and fix it. Two hours after the exploit code was publicly posted, the server was patched and restarted. One of the players told me that this was the fastest response time he had ever witnessed :)
And not that I want to brag about it, but when the whole World of Warcraft (WoW) items duplication exploit was found and published on slashdot.com, Blizzard denied it for quite a while, even though many people confirmed that exploit (from what I've read on Slashdot). I didn't follow the rest of the story, so I don't know what really happened and what Blizzard did about it. But the point is, we reacted faster than they did :)
How the Exploit Worked
We had a bug in the chat routine that didn't check for the length of the text. So under some circumstances (when an invalid packet with a null length was sent) the server sent back whatever was in a global buffer where all the data from the clients was stored. Normally, that buffer is overwritten every time data is received from the server, but the buffer was not cleared. So by sending a special crafted message, the server returned the content of the buffer until the first NULL character. With a program that constantly abused that bug, it was possible to get the username/password combination from the log in the string issued by a client. Getting a specific username/password pair was very hard, as that would require knowing the exact time your target is going to log in, but stealing random username/password pairs was less difficult.
Macroing Detection Implementation
Another important event that was finalized in October was some macroing detection implementation. For obvious reasons, I can't detail how it works, but here is what happened:
In July we got some reports that an entire guild is using an illegal client. We even got a copy of that client, so we analyzed it and found a lot of illegal stuff in it, such as a 'war window' that automated a lot of combat-related things, giving its users a clear and unfair advantage over those using the legal client. Furthermore, it contained many 'improvements' to the manufacturing system and various other modifications that were not really illegal but we didn't approve them; so technically they were not allowed. After analyzing the client for a while, we discovered a way to reliably detect it while keeping the false alarms to a very low level.
Meanwhile, someone else devised a way to catch generic macroing, regardless of the method used. The server was modified accordingly to log and report suspected macroing activity, and a week later we announced that everyone who was macroing had 3 days to admit it, in exchange for a 30% reduction of all of their experience. Those who didn't admit and were caught would get a 70% reduction.
For the first 2 days, no one admitted it. On the 3rd day, they found out that we got our hands on their client so they decided to come forward. Most of them did admit, with a few exceptions. Those who did not admit were given an extra chance, 45 hours of community service (helping newbies at the newbie spawn point) in exchange for a 'mere' 30% experience reduction. Most of them took that offer and some of them even completed their 'patriotic work'. Users who didn't admit were banned.
Mistakes & Lessons
As promised in the previous articles, this part will contain a list of our mistakes. Actually, "mistakes" is the wrong word, because it is my belief that everything that happens, happens for a purpose. And our mistakes did contribute to our relative success, so they weren't that bad after all. But if/when I will start it all over again, here are a few things that I will do differently:
Mistake #1: Releasing the game too early, when it was nothing more than a buggy chat room.
Why it was a mistake:
Many people tried the game and assumed that it will never improve, then left never to return. We also sent some horrible screenshots to some game sites, some which are still there, which doesn't really help the image of the game as most of the people first look at the graphics, and if they don't like them, they won't bother going to the game's website to look at the newer screenshots, let alone download the game and give it a try.
How I would have done it differently: Do not promise any release date, and instead, release the game when it is playable and relatively bug free. I would have a private alpha testing version, using a web form to recruit volunteers that are approved by us on a case-by-case basis using various criteria such as age, skills, previous gaming experience, and so on. This way, the bugs and balancing issues can be solved before the game goes public, sparing the developers a lot of embarrassment. Only then, would I submit a press release to game-related magazines and announce that the game is open for beta testing.
Mistake #2: Releasing the game without a solid plan for how the gameplay will work.
Why it was a mistake: We had to experiment with different ideas, which inevitably led to a lot of problems, such as having to do some partial and total skill wipes. In addition to that, its bad PR to release a game that changes so much in such a short time, as this will confuse the players and destroy some of their achievements. The programming is also more difficult, because a lot of code had to be rewritten (rather than modified) to accommodate new changes.
How I would have done it differently: Preferably, I would have a solid design document first, and only then actually implement it. Not only will that solve the above-mentioned problems, but it would also give you fanbase, especially if the game design is unique. A good design document should include things such as basic gameplay rules, a list of items, spells, skills, attributes, maps, a brief history of the game, and maybe some screenshots and/or concept art. Having that information on your websites would make it more likely to get more people to help with your project.
Note, I am not saying that you shouldn't start working at the game before every single design detail is carefully reviewed. If you do so you will never start working on the game itself and you will spend your whole time changing minor things then changing things constantly. Instead, I believe that you should not only have a pretty complete idea on what and how you are going to do things, but also design the code in such a way to allow easy integration of subsequent ideas or changes. Of course, those who try to make an MMORPG should keep in mind that no matter how detailed their document design is, once the game goes public many things will require adjustments, or even a total redesign, as the MMORPG players are well versed in finding weaknesses in the system and exploiting them to their advantage, which often ruins the game for others.
Mistake #3: Not telling the people in the beginning to expect a total wipe.
Why it was a mistake:
This was the single most biggest mistake. Since not having a good plan in the beginning, all the new features we added had to be designed in such a way to compensate the previous oversights. For example, the first skill we introduced was "harvesting", which was not really well done in the sense that we placed the resources without any logic. Therefore, for a while, people were able to make a lot of money by harvesting various flowers just outside the flower shop (or for a few days straight from inside the flower shop) and then sell them for very quick profit. Needless to say, when the manufacturing skill was implemented, we had to make the formulas take into account the resource placement (in order to avoid formulas that required neighbouring resources). Initially, we didn't have the wisdom to do that, so our original formulas were pretty convenient for many players. Later on, we had to readjust the ingredients list for some of the manufacturing items, and make it so that the resources necessary to create powerful items are not all placed together in the same map. For example, right now you have to go in quite a few maps in order to gather the materials necessary to manufacture a sword. There are ways to circumvent this problem, by buying some materials from other players and/or using the in-game storage (banking) system and withdraw previously deposited resources for the purpose of making new items. Right now, an estimated 25% of the online players are near a storage or another.
The second example is the items price. As the shops were not planned properly, neither was the buy and sell price for most of the items. At that time we didn't have a lot of players and we didn't have much time to actually play our game. So I set the price for the items in a pretty arbitrary and erratic way. The sell (to an NPC) price was based on the buy (from an NPC) price, and the buy price was based on my idea of how hard would it be to buy it or make the item yourself. This is not a bad way to set the prices in an MMORPG if you have a planned total wipe. That way you can actually try it in an empirical fashion, and see what does good and what doesn't. But if you do it empirically without a wipe, then a lot of things will go wrong (you can see an example on how it went really wrong in the second article in this series).
How I would have done it differently: Make it clear from the beginning (preferably on the download page) that there will be at least one total wipe in one year. While such blunt honesty might reduce the number of people trying the game, at least you can have the peace of mind that all your economy and gameplay-related mistakes will end by the time of the wipe, enabling you to have a clean and better start. Of course, if by the end of the year you are not ready for the wipe (i.e. more things have to be tried) you can always announce that it will take a few more months and most of the players will not really mind, as they get to keep their items and skills for a little longer.
Mistake #4: Picking wrong people for various positions in the game.
Why it was a mistake:
In the beginning we weren't very experienced with running an MMORPG, and due to that fact we made some regrettable choices when we picked some of the moderators or newbie helpers. While I will not get into details of what happened (I feel that this article should not be seen as me trying to put down other people), I will post some info just so that others might avoid our mistakes.
Basically, the problem was that people we didn't know very well ended up in more or less official positions in the game. A few of them had various mental issues and couldn't resist abusing their powers or being abusive towards other members of the team and us, the developers. When they were finally removed from the team, a few of them caused us a lot of problems such as spamming our forums, telling everyone how unfair we are, and so on. Needless to say, taking care of such problems considerably slowed down the game development and upset many of us. But it would be unfair to say that everyone we removed from the moderators or newbie helpers team caused problems after their removal. Some of them just left, or continued to play the game and even help other players.
How we would have done it differently:
New moderators or newbie helpers have to be approved by core moderation team first. This helps because they usually play the game more than we do and interact a lot with other players. So their decision is usually better than mine. The only disadvantage is that this way there can be some 'nepotism' among the moderators. But then again, there is no perfect solution to this problem so we have to settle with the best available one.
Mistake #5: Listening too much to player complaints.
Why it was a mistake:
As mentioned in the previous parts of this article, the players are usually unhappy with any changes, unless of course, the change simplifies things or makes things easier to do. But whenever the change requires them to change their strategies, there is widespread complaint, cries that the developers don't listen and want to ruin the game, threats to leave the game and so on. The mere announcement of future changes makes them very nervous, and they usually don't bother to read the full announcement, but rather immediately jump to [wrong] conclusions. There are, of course, some players that do like changes, and there are some players that don't care. But the bulk of the replies to any "future change announcement" is usually "Omg omg teh devs want to ruin teh game!11!!". Often times we just gave up modifying some stuff that we believed would be good for the game, but the players cried about it.
While the players usually play the game more than we do, most of them only care for their best interest. It is up to an objective 3rd-party to carefully examine the implications of any game system modification. That 3rd party is us, the developers, who unlike what some players think, want only the best for the game. It takes someone with a global vision of the entire project to decide what would make the game better for everyone.
A while ago, I was reading an article written by some web-based MMORPG developer who was dealing with similar issues. I can't find the URL to that article (I did try to google for some keywords, with no success). Basically what the author said was that after a while they just ignored the complaints and went forward with the implementation of those changes. And with time, the players actually liked those changes, despite of their initial overreaction. Reading that article was very informative and encouraging to me, so I vowed to do things in a different way from now on.
How I would have done it differently: Starting with the last change announcement, I made it clear that any complaints within a month after changes go live will be deleted, and those who persist in complaining about it on the forums will get their forum accounts suspended. A month after the changes go live, they will be allowed to criticize them, and I promised to listen to the criticism. However, I pointed out we will just listen to them, not necessarily do anything about it. This one month period should act as a buffer, allowing them to actually see if the changes are as bad as they imagined, or if they are actually good.
