Why PVP based Multi-Player Online Roleplaying games should be open source

This is a post based on a reply I made on Reddit.  When I read the initial post, I realized how my game is using the power of open source to solve some inherent issues with PVP based Multi-player Online Role Playing Games.

The first issue mentioned was performance.  While open source itself does not help directly with this, the Wograld policy of keeping system requirements low helps a lot with this issue.  Who cares if the graphics are beautiful if you can barely play due to the frame rate.  Forget about pvp then, because performance will be so abysmal for many people that you will hardly be able to pvm.

The next two issues are things that are directly resolved through the useage of open source for both the client and server of the game.  Bugs were explictly mentioned.  A lot of games (I'm looking at you Runescape.) have ongoing bugs that are never fixxed even though the developers probably know about them. With open source, the playerbase can directly fix bugs and actually commit a fix in order that the bug just goes away.  Eric Raymond is famous for his quote "With enough eyeballs, all bugs are shallow." Well, now by having all the code, both client and server open source, it will be shallow enough that finnally the bugs can get fixxed.

The second issue deals with game balance.  Ideally, the developers will understand game balance and how communities work.  They should understand the underlying dynamics, and while they should listen to the players, they shouldn't necessarily give them what they ask for, instead they should make a game that creates a healthy and thriving community, and not one where all the players quit over time because game balance is too broken. Sometimes, the developers fall into blind spots and never actually understand how communities work.  If that happens, the original game code still exists and the community itself can fork, and players can play a balanced non-broken game instead of a broken one.

The last issue mentioned deals with cheating. Some people think closed source software somehow prevents or lowers cheating, but looking at all the closed source proprietary games with cheating problems proves that closing up the source code does not prevent cheating.  Instead, some games though they could prevent cheating and still have certain calculations running on the client side.  Cheating can be prevented by running things on the server side.

Bank Boxes and Bugs

Last weekend, my lead programmer finished implementing bank boxes. I kept saying how most RPG's have bank boxes.  For those who do not know about what that means, let me explain.  Characters in computer role playing games often have an inventory where they carry stuff they might need in the course of the game.  That can end up being a lot of items with no real way to organize them.  In addition, in some games, items can be lost upon death or stolen.  Characters may also have a weight or item limit for what they can carry around.  Bank boxes allow characters to put items in them for later usage.  In between adventures, the character can visit the bank box to deposit or take out items.  This bank box can be only accessed in certain usually safe locations, such as towns.  The rest of the time thesse tiesm are not accessable.
Most multi-player online roleplaying games of any size have this feature, so I knew that wograld should have it as well.

I tested the bank boxes and I have not found any bugs with the feature so far.  Unfortunately, I found another serious bug that will have to be fixed before we can even consider a permanent multi-player server.  That is, if you disconnect the client a certain common way, the server will crash.  I have told him to fix that. 

Back to development

I finally had a chance to get back to wograld development.  I was actually ready a couple months agotoget back to work on the project a couple months ago, but I wanted to redo my computer with a new set of distributions on it, so I did that in April.  I got that done, and then I had an awful month in May. My cat got very sick and died, and I also had my car totaled.

June is started out well, I got a chance to test some code, add and remove things from the bug tracker, and commit more artwork.  I can't believe I forgot about the bug tracker for years. I think if I had used it more from the beginning, I would not have to keep track of so many things in the development, particularly in cases where I put the project down for a bit and picked it back up again.
I've been daydreaming about writing a book on free software project development, but then I realize half the information I think should be included in the book, I don't actually know, I could ask someone else, but I'm not sure they would know the answer either.  Also I don't want it to get into too much of an argument, such as what distro is better, what desktop GUI is better or what programming language is better etc.  I know people get very opinionated on these things, I know I do.  I don't want the book to be come across as too biased even though I have strong opinions on those topics too, I know not everyone shares my opinions.

I guess you could ask questions like  Should your project use a bug tracker? Should your project use version control? I guess you can get away with not using them if its a very small project, but I've found anything more than 4-5 files it would probably be better to use version control anyway.  With the bug tracker its nice to keep track of things even if no one else ever reads it, because then you know what you fixed and what you did not fix yet.

Map Editor Progress

I don't know if you are aware of this, but we are working on gridarta now. That means modifying gridarta so that it works with wograld, and not just crossfire and a couple other games derived from the crossfire source code.

Gridarta is the new map editor written in Java.  It is much nicer than the old wogedit x11 Athena widget editor that came with the server.  Furthermore, it will be able to run under any operating system.  So you won't be stuck using Linux or another Unix system to run it.

We currently have it in the cvs under java editor and intend to submit a patch to Gridarta once we have all the folders straightened out.  The current build would break the other projects, and it has a few other bugs, but it does work, so if you were dying to make wograld maps you can now do so. 

One of the major bugs is the collected arches don't work.  There are also a few display problems when using certain functions. You can import archtypes for the the wograld folder and edit maps now, however.

I haven't been doing much coding on it myself, just testing it and continuing to submit new artwork to wograld.  The last commit I did, was the skeleton, I think. 

Performance and Messed up Tiles

Well, we got the java client working, doing what it was supposed to do, but then I tested it, and every time I walked into the zoo, it just moved too slow.  It got so bad I could not move my character at all although the rest of the game seemed okay, but still slower than I would have liked.

So a change in algorithms was an order.  Unfortunately the new one doesn't work so great.  Instead of refreshing the whole screen, the new algorithm seeks to only draw those objects that have changed. Makes sense, but unfortunately pieces are not showing up properly, and you can see items, both still, and animated sticking together the wrong way. I would love someone else to look at the algorithm, but who wants to?  It seems there is a rule about free software projects, first make a game people want to play because it doesn't suck, then fix the things that are wrong with it.  It ends up that the first few developers either make or break a project, and if you don't know the correct algorithm to use, then you are out of luck.

jwogclnt now connects to the sever but..

I figured out what was holding development up.  We were having some trouble importing the project into netbeans until I figured it out. Unit tests on jxclnt do not work in netbeans.  The orginal developer of jxclnt suggested using Intelej IDEA instead.  So I tried that.

We found some bug with the server as well, probably better not to blog about it here. 


so now, the new client connects to the sever, but does not display the tiles yet properly.  I hope to have that fixxed in the next few days.

Meanwhile, I wonder if our CVS version control is holding us up.  One of the things that concerned me is sourceforge is moving to the allura platform.  At first I worried CVS would not be supported, but it looks like it will be supported on allura.  Also, later versions of netbeans require you to download a plugin for CVS rather than it coming out of the box.



I've been looking at distributed version control systems, both git and mercurial are under consideration.  At first I was kind of leaning towards git, but it looks like mercurial is easier to use, espeacily for windows users, probably the main platform with lots of gamers who want to be developers. Of course the server probably does not work all that well on windows, but I havn't really tried it, not being a windows user myself.  One of the reasons I choose a java client is the fact it will just work regardless of the underlying platform os.

The thing I don't really like about mercurial, is it is written in python. Python is a fast moving language that changes to fast, so I worry if its going to break future releases, although I don't really think that's highly likely as I would think for smaller projects.

What's my name? Java Development

For the past six months or so, I have just basically been trying to learn to code in Java. I have done the occasional upload of artwork to sourceforge as well. But mostly I have decided to focus on learning Java really well so I can modify the new crossfire java client enough to work with the wograld server. For those who don't know, Wograld originally forked from the crossfire code. Since then the projects have gone in different directions. Crossfire has the same bad game play and artwork and while fixing some bugs, while wograld fixed some ugly artwork and game play while adding new bugs and keeping only the awful messed up x11 client. That is the brutally honest assessment anyway. I understand that user interface developers are the best of the best in the world, and that you could search endlessly to find one who can make such a thing. While I can do the basic hello world, and have been learning some object oriented and graphical user interface, my knowledge isn't quite up to the level to comprehend the entirety of the crossfire jxclient code base yet.

Top Ten reasons not to play Wograld right now

Most people go about promoting their games, saying how great they are, only to be disappointed by bugs and poor game play, as well as bad "programmer art" I on the other hand, will beg and plead with you do not go to the cvs, download wograld, try to compile and run it, and worse yet, try to actually play it. I will give you ten reasons that even though the code is right there, you should not touch it, compile it, run it, or even look at it.

10. Its only been tested on Linux... trying it on the windows system like enough said.

9. You have to follow the admin install directions, if you are the sort of person who is reading this and doing it anyway, even though I said not to , you are not a person who follows directions, so you are not going to do well with getting it set up so it works.

8. Missing artwork. There is only one character class and race that shows artwork in game, otherwise you will be playing an invisible character.

7. Same poor game play as crossfire, only with some missing artwork, so you won't even know what killed you half the time. If you want crossfire, just go play it, but why would you considering how awful it really is.

6. No permanent server set up, how fun is it really going to be playing with yourself...

5. You have to play as root or it won't save your character, or you have to change the permissions on some folders.

4. Did I mention the bad game play, lets go into detail, one hit killed as a newbie sorcerer with a swinging door. Should sorcerers really be that frail? No freaking way!

3.Level system, and experience loss when you die, you lose stats too, so you can get worse than a newb fast.

2. You don't have to die to lose stats and experience, fighting certain monsters will also do this.

1. Ta Da, the number one reason not to play Wograld right now... The user interface is really bad. You won't be able to figure it out. It is ugly, has buttons that do nothing, and no way to know what macros you have easily.

Fixxed the Segfaults... BUT

Well, the segfaults are fixed. At least I think they are as fixed as a cat after neutering. As fixed as a eunuch programmer (like instead of a unix programmer with the stereotypical neck-beard)
Anyway, enough with the stupid puns. The user interface for the map editor still sucks dangling donkey parts. You still can't click on things in the pick maps and expect them to show up in the object window of the map-editor. The co-ordinates are all off. Furthermore, all the items in the pick-maps do not display properly. I tried messing with them again a couple days ago.
Instead of fixing the user interface however, my wonderful lead programmer decides to add a bunch of stuff that is in the wrong perspective and the wrong size, into the cvs arch folder. These new arches are from other crossfire forks. I told him he does not need to do that. When I saw what he was starting to do, I got horrified. Except he doesn't use the cvs add command. Now his folder is littered up with a bunch of ? marks in front of the new arches. He really should not have done that. Only one more day until my other programmer comes back from vacation. Then we really won't get any work done because she will be too busy obsessing on cleaning and telling our lead programmer what a lousy job he does wiping the floor and taking out the trash.

I started working on my web comic again and making new 45 degree 64x64 and 64x128 tile objects that we can hopefully add once lead programmer stops trying to add stupid arches and fixes the map editor bugs.

I recently read about something called "programmer art". Apparently programmer art is when programmers do quick and dirty artwork to make demos of some software project. It looks really bad like they can't draw. In most cases, they probably can't, but it is more of a case they don't care how bad it looks. Our project suffers from the opposite problem. I feel like we have a lot of artist code. Code that is just in there to show off the awesomeness of our artwork. It seems like no one on this project really wants to work on the code, and would rather be doing art. You can't play a computer game without the code, however.

Who's Fault? Segfault

Sometimes I just get so frustrated with this project. I have been looking at the segfaults and trying to find out what is causing them. Just because I know what some x11 functions do, does not mean I have figured out how to fix the segfault errors. serpentshard fixed some of the other crash bugs, but the editor still looks as awful as ever. We never managed to change it so that it would allow you to select the proper area on the screen. The areas you select and input tiles into are still from the old maps. So, although it displays the new tile sets, when you click on them, it is mapped to the old way that things used to be arranged. I don't know how to describe it exactly. So, basically, it looks okay, but it acts like the tiles are still the old 32X32 square tiles.

Well, actually, if you want to see, just download the server with the map editor, wogedit from today's date or a bit earlier and see what I am complaining about her on the blog. If we could have fixed the tiles to begin with, we would not have this problem. I don't know why fixing it in the map editor became so hard. It just did.
I am not sure if the any of the segfaults are directly related to the major display user-interface problem that I described. Actually, one of them is not. If you left click in a box on the top of the editor. When you are over a tile, there is a top part of the editor that displays what is on the tile you clicked. (of course it maps the wrong tile) Then it segfaults on you. That is not nice. But it is what we are stuck with until we can figure out how to fix the code bugs. No one else wants to look at our buggy code, so we are stuck fixing it ourselves. I had thought that open source meant you could get better programmers to do you dirty work like fix major bugs, but I guess that is not how it works. Maybe my essay about keyboard monkeys seems a little naive now.

Adventures in CFLAGS

For those who don't know what CFLAGS is, it is a variable in Makefile, that is the file that appears in every directory of your program that lists the flags gcc uses, such as -Wall or -g . In this case, I want the debugger flag -g, but unfortunetly, I have to go and edit the 25-30 or so different Makefiles by hand to change the CFLAGS. I figure there has to be a better way to get the debugger to work, but every time I run ./configure even when I try to change the enviroment variable by adding something like ./configure $CFLAGS = "-g" or something, it doesn't work. I tried it forwards, backwards, with export, and still the configure keeps giving me the same makefiles with nothing added for the CFLAGS. I'm going to read through the entire autoconf and automake file. I've already been looking through them trying to understand what the various macros do in the configure.ac, I'm still not 100% sure what all those different configure files do yet. I'll probably have to run autotools and rebuild the configure again. I was hoping there would be some simple command line thing I could do, but for some reason this does not appear to be the case. I've also heard about changing enviroment variables, but I have no idea how to do that.

Bug hunting, the continuing story of gdb

Finding the bugs and using gdb is not so simple as it first seemed. First I tried to compile all those files with the -g option, but even after asking around, I could not get it to give me the exact line in the program where I was getting the segfault error. The lead programmer had not made any progress with it for several months. He is useless now, it seems, so I will have to do something I have never done before, find the bugs in wogedit, and fix them myself.
I ran some x11 tutorials in gdb. They work great, and gdb gives me the line number when I introduce bugs (I quickly found a way to add a segmentation fault bug to the x11 tutorial) . So it seems I am stuck looking at flags in the makefiles. For some reason, the flag FFLAGS, a flag that is supposed to be for the fortran compiler is where my -g flag is showing up. I thought it would give me the c flags instead, but it does not seem to be doing that. I wonder why the makefiles include it. I know this project still has strange bits of code I have not looked at yet, but as far as I know, it does not use any fortran. I don't even think I have this F77 compiler installed on my machine. I don't know anyone who uses fortran for anything nowadays.
So, I am reading up on autoconf, automake, and make in hopes that I can solve this mystery before I die of old age.

Artwork commit and gdb

Recently I did a big artwork commit to the project. So for those of you who wanted to see all the new tiles, you can go ahead and access the cvs and get the latest arch. (Yes, it is working on sourceforge for now, but who knows for how long) I also edited the admin install yet again. Please let me know if the directions for installing the server and client in linux are unclear.

Also I have been trying to learn gdb. For those who are unfamiliar gdb is the Gnu Debugger. I got tired of waiting for my knight in shining armor, my prince charming (well actually my evil wizard) to debug the code. So there are two major map editor bugs (possibly more) are still there to be found and fixed. They are

1. segmentation fault crash when you move a scroll bar

2. some of the tiles do not show up correctly, they appear to be blocked out by other tiles although this works perfectly in the client.
As always new contributors are welcomed.

sourceforge CVS issues

The project CVS is down due to problems with sourceforge. I had hoped sourceforge would somehow escape some of the issues that plauged savannah. Back when I was choosing project hosting, I picked sourceforge for a couple reasons. Here is the update on the situation. http://sourceforge.net/blog/2011/02/

1. the prior project I forked it from, crossfire, is hosted there.
2. The other major free (as in beer) free (as in freedom) software project hosting service http://savannah.gnu.org/ had recently had a major outage, with people losing a days work or something. I don't remember all the details since it was years ago anyway.

And I chose CVS, because at the time, subversion was just coming out, so CVS had a lot more books and such written about it. People were just making the switch to subversion at the time, with most projects still on the CVS. Back then, I'm not sure if GIT was used, or even existed. If it did, it did not have a lot of free project hosting.

Now it looks like my reluctant project team might have to learn a whole new version control system.

Basically this means that it will be some time before you can go download and test out the project. In the mean time, we we continue to make more artwork and try to hunt down the bugs, dealing with the version control when it comes back up or we find out more information. Worse comes to worse we can already re-upload it without all the crappy version history. (meaning goodbye empty folders and misnamed files)

Art Tiles = Project Motivation

While the editor bug is still there and taking a long time to find, at least I am making some progress in the game. I have been working on the art tiles. The new tiles are the 45 degree isometric perspective. While many of the tiles have already been replaced, some have not. Also, some of the old perspective tiles when converted to the new perspective do not look good, although they did not look good in the old perspective either.
Our lead programmer says that seeing the new tiles gives him motivation to sit down and find the bugs.
I went back to an old message forum to read my ancient post about recruiting Wograld developers. No one there was interested. Not only that, but someone commented that only insane masochist programmers would want to work on the project. That is the wrong idea. After all, masochism is one of the nine stupidities. So it seems that all over our developers already have the qualities nessessary to complete the fool quests in Wograld.

1) Indescretion. - this blog is prof of that.
2) Lust - I'm lusting after Wograld, I want it so bad.
3) Foolhardiness - Well, if this project kills me, my only hope is some other foolhardy adventurers follow in my footsteps.
4) Paranoia - lead programmer though someone was entering his house, but it is just the furnace.
5) Masochism - Wograld developers have already been labeled as Masochistic. Why else would we spend so much time on it.
6) Vengence - this is revenge for all those times that rpgs like Ultima Online and World of Warcraft did not live up to my standards.
7)Thievery - We copied the code from crossfire, not exactly thievery,
8) Humilation - We have humilated ourselves over and over trying to promote this pre-alpha project.
9) Skepticism - hmm, I don't believe in C programers, oh wait...

Squashed Bugs or Sqaushed Egos?

Every so often it gets tempting to start doing something else instead of the difficult Wograld project. Even to this day, I do not consider myself a very good programmer. Sure, I did some C programming, and I have written some text based programs, that were mostly made of other programs stuck together with the variables renamed. Unfortunately, when it comes to basic things like understanding how C reads and writes to files, as well as how to use the x11 libraries in the code, I still lack understanding. Instead, I have been relying heavily on my lead programmer, a man with an ego problem (his problem being a lack of ego rather than, like most programmers, having a giant ego) to fix the bugs.

He has been stuck for a long time on the editor bug.
The editor crashes when you use it and try to scroll down. Also, some of the tiles do not appear like they should, instead they blank out the other tiles when they try to appear on the screen. Instead of having my describe it to you, you should actually just download the latest cvs release, as well as the old crossfire maps, and test it out to see what I mean.
I would like to put the bug out there for others to solve, but I worry it will hurt his poor ego. I'm sure he does not want to read this blog where I talk about him and his problems with self esteem.

Learning C++

I decided to take some time away from just working on the project to learn C++. If you have been reading my prior posts, you know how much I hate Dependency hunt. Dependency hunt, for those newbies who do not know, is when you run all over to try to install library dependencies that are needed for some user applications in GNU/linux.
I am on the 7th week of it now. We are on chapter 5, having started on chapter 0. After chapter 2, it got hard, so people wanted a week to catch up. I just read chapter 5 today, but have not tried to do any of the exercises yet. I really have no idea how to do them. I will probably go around playing with the code and changing various things before I understand what is going. I still don't understand some things about chapter 4 (or even 3 for that matter) But I want to move forward and learn new things. If I know enough C++, theoretically, I could fork every project that requires SDL and other stupid C++ libraries so they have no dependencies and people can just compile them from source without errors. I could do this by renaming files in the C++ SDL libraries and in the code so that I could find the right version of SDL to make it work. Then I could include this in the code, making it part of the code body rather than a separate dependency that breaks everything else if you decide to upgrade it.
I know for a fact that later versions of SDL are buggy and incompatible with some code. I do not think you should rely on consistency in libraries done by some one who probably doesn't even know, nor care about your project.

Bug and Features tracker on Sourceforge

I added some tasks to the bug and features tracker on sourceforge. I will add more as I assign tasks to people. I also added the ability to post commits to the cvs list, but I have not tested out its usage yet. It is supposed to mail the mailing list subscribers every time a commit is made to the project just like I have seen on other projects. I do not know why it took me so long to get to that or realize how it worked, but it did.

Also, another project admin felt that she could improve the website so that is being worked on now as well.

Food on a CVS Book

A pristine book is a book that has not been read. That is my motto. Unfortunatly, some other people do not get it. If you need your books perfect, don't read them. They can look nice on a shelf and take up space. However, I do not believe that books should be used that way. I care about one thing and one thing only when I get books, that is the contents of the book.

One of our developers was complaining that her book had food all over it. I do not notice or care that books are not perfect. I do not get distracted by pencil marks, doodles, crumbs, fingerprints, blood smears etc on a book. In fact I like the fact that it feels well used and worn, Some how it gets me more involved in the material. When a book is perfect, it feels like it is a harder book to comprehend with more difficult material that no one has understood before. When it is old and worn out, it feels like territory other people have gone through, so I can always ask some one else about the material if I do not understand it. Also, the more I read a book and practice with it, the better I understand the text. That is probably why I always feel more comfortable with old books rather than new ones. The other nasty thing about new books is they are more likely to lead to paper cuts if you are not careful. Certain kinds of paper is worse at this than others, and not that the book has particularly sharp paper, but I have learned that I have to be careful with paper because it could hurt me.

What does this have to do with wograld project development? I realized that we did not know what version of the game we were using. Our lead developer said he fixed it so the crash bugs are gone, and it seems to work fine on my machine. However on our other developers Solaris system, the thing crashes just like it used to, not the same crash bug actually though, because it doesn't get as far as loading the maps that were not finished. It doesn't even get to scorn. Just walk a few feet and the whole thing crashes. I realize that we need some way to keep track of different version of the game, and using tags in CVS seems to be the way to go. I brought up subversion and how people think it is better, but that would require either waiting for the book or reading the pdf files, neither of the other people on the project are particularly interested in version control. It just seems like a nessesary evil. The thing is how to use it effectively, something I don't feel that we are doing.

I read that some newbie developer on some other project team messed up the CVS. I hope we don't end up having that problem. Then again, I feel if someone does not want to learn version control, they should not be working on a project, because it is something that has to be done.

Maps and hunting down bugs.

I finally got the lead programmer to do some work on the project again. Maybe it was because I took away his big bag of chips and soda pop, as well as two certain people being away for a week. Anyway, we finally got the major crash bug fixed. You can now walk around on the scorn map and not crash just because you try to enter places like the scorn school. I heard those areas were never finished even in the original crossfire. I also started working on the graphics again. I have completed an undead lady from four different directions with two frames each to replace the same 8 frames that all crossfire characters have. I also did a few terrain tiles. Map changes are still tedious and the map editor could use some work to fully display the new tiles. It would be nice to have some more help on the project, but I really only need someone who is dedicated since the project requires a lot of getting up to speed, figuring out how the code and maps work etc. Unlike the artwork, the code seems to take a lot of getting up to speed on it, rather than just making things of a certain size and copying them in, and then running some scripts. The directories are still the crossfire directories. It should really have separate directories for wograld. You also have to run the server as root, otherwise it will not have the permission to write to certain folders and you will not be able to save your characters or maps.
The reason the map and editor is so critical to fix, is because I need it working so I can see how my new terrain tiles look before putting them in the game. Not that I have not already done some of this work in the gimp. Also, Wograld is not crossfire. I want it to be a completely different game with different areas and maps.
There are many things I would like to add such as wearable clothing, but I think it is important to get the basics down first, by that I mean things like the menus and maps not crashing when you teleport into them. For some reason, our lead programmer found a bug where if you walk into nevar, it crashes. There is also buffer overflow errors. I don't want to add tons of new features over that kind of serious buggy code.