Allows for easy modification, open file formats, scriptable.Collision models are autogenerated from visual models.Open source (plans are for a BSD-style license).Very portable (Plain C/C++, no templates, no STL).Using only free components, SDL, SDL_Net, Vorbis OGG, and others.Efficient and autenticating UDP-only network.Only free (OpenSource, however no GPL code only BSD and LGPL) components were used for its development. And the final goal - portability - the Project should run on most anything SDL works on. Still another goal was to make the networking as free of lag as possible and the client playable over an ISDN line in at least a 8 client match. Another priority was to make it very snappy from the user itnerface side, your tank should feel 'part of you', as natural as the player moves his hand, the tank should move and control should be complete. Death is quick, but so is resurrection, explosions are large and the weapon effects insane. You won't see gore or blood or even humans in this game, just little tanks shooting and killing each others with various means. It is not an accurate tank simulation but a comic book style, driven by extremes, exploding toy tank online we-against-the-others shooting frency. Games are made so the player can have fun, this is also the topmost goal of Project 2501. The game and its components will be released under an open license (details to be defined), source code included except for the authentication layer for the network play. It uses its own 3D graphics and game engine and network library (based on SDL and SDLnet, it will run on anything SDL runs on). Project2501 is the working name of a first-person networked tank game similar in appearance and spirit to BZFlag but completely written from scratch in C++ using a modular, data-driven approach and using features of modern graphic cards (OpenGL, nVidia GeForce/ATI Radeon or similar recommended) for effects and visuals. This is a list of them for historical reference.Project 2501 THIS IS AN OLD PROJECT FROM 2003 - ARCHIVED HERE FOR HISTORIC REASONīy Frank Siegert, Contact: frank(at) Some of these development releases had there own pages for development planning. Development versions for major releases are generally not compatible with any other release, including different builds of themselves. These versions are where the developers work on the code that goes into each release. Versions earlier then 1.7c-X were closed source.Įvery release is preceded by a development version. There are currently 40 open source versions of BZFlag. On non-developer releases, the number is generally only incremented and reposed if there was something deficient with the version already posted. Lower patch numbers on a developer revision (where the MINOR number is an odd-number) tend to imply less stability whereas higher patch numbers tend to imply greater stability. Labels and comments that a given release is an RC (Release Candidate) version or that it's a beta or an alpha release are merely intended to describe the stability of a given version but are not part of the version itself. The build number is simply increment for each publishing.Ģ.4.0.1 and 2.4.0.2 are both builds of a 2.4.0 release. Releases are always done with even numbers in the first triplet. A special case is held for development of a new MAJOR version, it is done using the MINOR version of 99. Incompatable releases use an odd MINOR version. This is what we change to differentiate different downloads of the same code.ĭevelopment Versions and Release Versions ĭevelopment of a new version of BZFlag occurs on the odd version of the lowest required version number. It is updated often and represents only minor changes to the code or packaging system. The BUILD number is incremented each time a package is built and posted. The RELEASE number is iterated across the various releases of that given MAJOR.MINOR version and represents feature additions and enhancements that maintain compatability with all versions sharing the same MAJOR.MINOR pair. The MINOR number represents changes to a version that break it's compatibility with with previous releases. In this version numbering scheme, the MAJOR number implies predominant changes to the software system that makes it visually different from the previous version. This numbering scheme is similar to many open source software projects. The version system uses a 4 digit system that contains the following values The information in following regarding BZFlag's version scheme pertains to the system put into place for the v2.3 /2.4 release Version Numbering Systems History īZFlag has undergone several different numbering schemes over the years (decades) that can be roughly categorized as follows: the 1.7 alphabet soup series, the 1.10 through 2.0 series, and the "new" "quad" system currently in place. 1.3 Development Versions and Release Versions.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |