Page 1 of 1

State of development for BZFlag version 3.0

Posted: Fri Feb 15, 2008 10:49 pm
by macsforme
Many of you have heard of the next version of BZFlag currently in development: version 3.0 (formerly called 2.2). For those of you who are interested in the state of development for this version, this is my attempt at summarizing where we're at with it. As a disclaimer, let me say that I am a relatively new developer and haven't been around long enough to see many releases. This is just my best shot at sharing some of my reflections based on some observations I've made.

First of all, it's important to keep in mind that the people who create code for BZFlag are generally self-motivated. There is no boss telling people what to do and when to do it, and there is generally no financial or material benefit involved. The developers work on the code to flex their creativity, to get a feature they want into the game, or for one of another limited number of reasons. Consequently, there is no grand overall plan or driving force behind BZFlag development. We work on the code when we want to, and it's out of our own free time.

3.0 will be different from the last several "minor" releases in the sense that we are "breaking protocol." Protocol is the language that the client and server use to communicate data to and from each other. A given protocol uses a certain set of terms and uses a certain way of sending and receiving them. The last several versions of BZFlag (2.0.0 - 2.0.10) have used the 2.0 protocol, which has allowed the different minor versions to work with each other without problems (for instance, you can use a 2.0.4 client to play on a 2.0.8 server). Over time, we run into limitations with the protocol. There are certain things we want to be able to do with the game that the current protocol lacks the capability for. In order to add these new features, we need to change the protocol, which makes the BZFlag version with the new protocol unable to communicate with or understand the old, and vice versa.

Breaking the protocol is a mixed blessing in that we are able to do new things, but all the users and server owners will have to update to the new version. For this reason, we try to do this as infrequently as possible. We put off certain new features until the next "protocol break." We try to anticipate what we'll want to do for the next several years, and incorporate the capability for those things when we create a new protocol. We try to make the new protocol as flexible as possible (while preserving efficiency, which is another significant issue) so that we'll be able to do things with it that we haven't even thought of yet.

So how does this affect version 3.0? Basically, since we want to break protocol as little as possible, there are certain things that we might as well do to the code while we're breaking it. Things like server-side shot tracking, separation of flag attributes from the static flags (to allow customization), and many more things. If it weren't for the fact that we want to do these things while we're breaking protocol, we could start alpha and beta testing 3.0 within several months, and see a release not long after.

The only problem is, no one is actively working on these things. People are working on other enhancements that are significant and really cool (for instance, one mainstream developer is working on custom tank model support), but these less exciting things (primarily moving code around and adding support for the new behavior here and there) go unaddressed. BZFlag development has also been slowing down for a while. You can see some interesting statistics here. We do gain new developers from time to time, but we also lose old ones and active ones become less frequent with their contributions. This is the unfortunate fact of the matter, but I believe it's a fair summarization of where we're at.

So what about a timeline for the BZFlag version 3.0 release? Many users ask for a timeline, and the developers are hesitant to give one (generally replying with something like "It will be released when it's done"). This is an unsatisfying answer, we know, but the fact of the matter is that we really don't have any way to predict the future activity of development. Sometimes we go weeks without a contribution, while other times we will have a hundred commits in a week. Unforeseen fluctuations in development activity can affect the release time by months or even years.

Personally (yes, this is nothing more than my personal opinion, and not in any way that of the development community, project admins, or maintainer), at the current rate of development, I don't see BZFlag 3.0 being released for another year to two years. Yes, I said the current rate of development. Many things affect this. Our participation in the Google Summer of Code last year brought about a tremendous (while temporary) surge in development activity (although that work did not directly affect the client or server codebases significantly). While I hope that it will be much sooner, this is my honest personal opinion.

So what can we do to make it happen sooner? We need your help. Yes, you. People often refer to the "developers" as if we were some mysterious group of wizards who possess the sole power to work on the code. The fact of the matter is that in an open-source project like this, the developers are the users, and the users are the developers. Please do not say things like "I can't program in C++" or "I lack the ability to contribute code"... do you think we were born with the knowledge of C++? Not at all; we learned it like people learn anything else. Computer programming may come more easily to some than others, but I believe that everyone has something to contribute.

So, what can you do to help? C++ is our primary development language. If you are new to C++, I would recommend getting a book or using online tutorials such as this one to become more familiar with the language. Once you do, I would recommend retrieving a copy of the BZFlag "trunk" code (which is what will become 3.0) by using the instructions here, and having a look around. We have several lists of development goals that we semi-maintain; several are here, here (slightly older), and here (older yet). If you find a project that interests you, join us on our IRC channel (information here) and tell us you're interested in helping out with that project. There are almost always people around that will be very pleased to discuss the project with you (be patient though; people aren't always at their computers, and may take some time to respond).

One last thought to keep in mind: as we discovered over the Google Summer of Code last year, development is spurred on by more development. What this means is that when one person works on the project, many other people see it and three or four people will generally jump in and do more work, related or not. If development is slow right now, perhaps your willingness to jump in and help will be the just the jump-start that the project needs to get rolling again.

Posted: Sat Feb 16, 2008 9:56 pm
by blast
I'd like to expand a little more here on what Constitution said. I wouldn't even say that knowing/learning C++ is require to contribute. Some things that would help would just be building the latest SVN code for trunk. If there are build issues, those can be of assistance for us to be aware of.

Once a working client and/or server is built, the next step is testing. Reporting bugs in the code via the Bug Tracker would be a help in itself. Providing as much detail as possible is appreciated as well (stuff like operating system, build environment, SVN revision number, etc) and providing the steps or conditions to reproduce the bug really helps us track down and fix software bugs.

Again, C++ isn't necessary to contribute. Since another thing that could be improved is documentation. Even the in-game help menu could use some improvement.

So, there are quite a few ways to contribute to the project. If anyone has interest in such things, hang out on the #bzflag IRC channel on freenode. I'm on there quite a bit, as well as other developers and users.

And just a reminder that if you want the best possible experience on the IRC channel, just make sure to have patience (we're not always around at the time) and use a dedicated IRC client instead of a web based solution. Using a dedicated IRC client such as X-Chat (Windows version here) allows you to keep logs of your chat, so that you can refer back to what someone said last week. Just make sure that you enable them, because they are usually turned off by default. ;)

If anyone has questions, feel free to PM me or send me a message on freenode (I use the username 'blast007' there). Thanks.

Posted: Thu Mar 13, 2008 4:47 pm
by angryfirelord
If one were to develop for bzflag, would there be any specific software requirements? Do the gcc & g++ versions have to be exactly the same, or can it just be version 4.x.x?

Posted: Thu Mar 13, 2008 5:12 pm
by blast
angryfirelord wrote:If one were to develop for bzflag, would there be any specific software requirements? Do the gcc & g++ versions have to be exactly the same, or can it just be version 4.x.x?
BZFlag can be built with a number of compiler versions, including Visual C++. So there should not be any "requirements" for which GCC/G++ to use.

Posted: Thu Mar 13, 2008 5:12 pm
by JeffM
BZFlag builds under a number of compilers. Check out the various readme files in the source tree for more info on the needs for your specific operating system.

Also as a note to Constitution's initial statement, we are currently in a feature freeze for 3.0 and concentrating on bug fixes. We would like to have a 3.0 version released before the summer if we can. It will not be easy to do this but we would like to give it a shot. So if anyone would like to help out, there are plenty of bugs to spread around :)

Posted: Wed May 07, 2008 2:50 am
by Cheshire
:shock: Before Summer?! :shock:
Wow, i hope you do, 3.0 looks really cool :mrgreen:

Posted: Wed May 07, 2008 4:28 am
by lol_u died
Sounds exciting.... Wish you guys best of luck... Oh and if I want to help out...what can I do?

Posted: Wed May 07, 2008 4:44 am
by blast
lol_u died: Ways to help are already listed in the first two posts. Just building the latest client/server on a regular basis and reporting any bugs/issues can be a huge help.

Posted: Wed May 07, 2008 4:55 am
by lol_u died
ok...i'll try :P hehe

Posted: Wed May 07, 2008 11:28 am
by Cheshire
How do we build the latest client?
With a compiler?

Posted: Wed May 07, 2008 12:29 pm
by joevano
Yes, download the source code Trunk from the SVN and check out the README.<your> file in the 'bzflag' folder. Instructions and help for compiling are located there.

Posted: Wed May 07, 2008 4:48 pm
by Cheshire
Um... What all from ... nk/bzflag/ do i need to download?

Posted: Wed May 07, 2008 5:49 pm
by JeffM
read the wik and the other threads around here that have the info on how to compile.

You can then ask in IRC, or post new threads with specific questions, instead of trying to hijack other threads.