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.
Wograld is a free-software, 2d, multi-player online roleplaying game based currently on the crossfire engine. Development is, unfortunately, done by developers, supernatural entities that seem to posses software users and force them to hack away writing software code for hours on end.
Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts
Thursday, July 18, 2013
Monday, October 15, 2012
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.
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.
Tuesday, August 21, 2012
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.
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.
Labels:
bugs,
code,
crossfire,
crossplatform,
Java,
programmers,
version control
Saturday, June 2, 2012
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.
Subscribe to:
Posts (Atom)