State of development for BZFlag version 3.0
Posted: Fri Feb 15, 2008 10:49 pm
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.
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.