1.0 Release Roadmap

It’s been 18 months since our BETA made an ironic splash on April 1st 2012. We figured it’s time to communicate what our goals are for a 1.0 general release.

But first, a quick recap of what our team has accomplished in the last year and a half:

Player movement
: The player movement code (pmove, for short) has been significantly refactored to feel more like *Quake II*, but more consistent and accessible to new players. Also, mods will now be able to provide their own pmove implementations, thanks to efforts to move client-side prediction into the cgame module. We hope that this will encourage more inventive ports of popular *Quake II* mods like *Action* and *D-Day*.

PhysicsFS
: The popular [PhysicsFS](http://icculus.org/physfs) filesystem abstraction library used by the *Build Engine* and other notable games replaced our Quake2-legacy virtual filesystem (VFS) implementation. *PhysFS* is highly performant, completely portable and well-tested. It also supports numerous archive formats such as `.pk3`.

PK3 Archives
: All of *Quake2World*’s assets are now bundled in *Quake III: Arena* `.pk3` (ZIP) archives. This brought our game data down in size from 500M to 200M. Our BSP compiler, [Q2WMap](/books/documentation/creating-levels/bsp-compiler), has been updated to automatically create `.pk3` archives from your custom maps, too.

GtkRadiant support
: Mapping for *Quake2World* has never been easy, especially for Windows users. We have teamed up with [GtkRadiant](http://icculus.org/gtkradiant) and taken **tremendous** strides to eliminate the barriers and snags to mapping for *Quake2World*, on **all 3 major platforms.** More on that below!

GLib
: The core foundation of the GNOME platform, [GLib](https://developer.gnome.org/glib/) was integrated to provide universal string handling, path name manipulation and collections management. The consistency and efficiencies gained by leveraging GLib throughout the code allowed us to eliminate dozens of small, old bugs and greatly reduce level loading times.

Github
: Slightly late to the game, *Quake2World* migrated to [Github](http://github.com) back in June. The code and data live in separate repositories: [quake2world](http://github.com/jdolan/quake2world) and [quake2world-data](http://github.com/jdolan/quake2world-data). If you find bugs in the current BETA, you are encouraged to file issues there.

Jenkins
: [maci](http://github.com/maci0) was good enough to invest hours and hours into setting up a proper [continuous integration](http://ci.quake2world.net) environment for us running [Jenkins](http://jenkinsci.org). While the Jenkins portal itself isn’t directly helpful for end-users, it has greatly improved the availability of our builds.

So What’s Left?
====

Maps!
—-
**Our highest priority for the 1.0 general release is to provide quality remakes of the classic *Quake II* deathmatch levels**. [Panjoo](http://tastyspleen.net/~panjoo/) has started us off on the right foot with his superb rework of *[The Edge](/books/media/edge-panjoo)*, and [TRaK](http://trak.mercenariesguild.net/), before retiring from the project, gave us an excellent head-start with initial cuts of *The Frag Pipe* and *The Warehouse* featuring his own original textures.

[flickr-photoset:id=72157636463823775,size=-]

**We are seeking new mappers** to pick up the torch and see these maps through to completion, and to port the remaining *Quake II* deathmatch levels as well. And to that end, **we’ve upped our game by providing the very best tools and support we’ve offered to date**.

GtkRadiant
—-
Since *Quake2World*’s inception, the [NetRadiant](http://dev.xonotic.org/projects/xonotic/wiki/NetRadiant) editor has been our tool of choice for level editing. Unfortunately, NetRadiant seems all but unmaintained these days, and several long-standing issues with it led us to seek an alternative. While we may eventually support NetRadiant again in the future, it was time to make a change..

By joining up with [TTimo’s GtkRadiant](http://icculus.org/gtkradiant/) maintenance effort, we have fixed several long-standing issues for mappers on the Windows platform. Namely, *GtkRadiant 1.6.4* now supports per-user game data directories, so mappers no longer have to navigate the perils of placing their custom assets in the official game directory (where *Quake2World*’s Update process will delete) them just to make them visible to Radiant.

Additionally, [Q2WMap](/books/documentation/creating-levels/bsp-compiler) now integrates with *GtkRadiant*, allowing *BSP process monitoring* through the in-editor BSP compilation menu. This allows *Q2WMap* to send realtime feedback directly to the Radiant user interface, and select malformed brushes, point the user to leaks, etc. Moreover, all of the compiler’s output gets logged right in the Radiant console — no more console window popping up and then disappearing before you can read the results.

For the first time ever, users of Mac OS X will be able to create levels using *GtkRadiant*, too. As a Mac user myself, it was imperative for me to have a working editor, and so I’ll now be providing packaged OS X builds of *GtkRadiant* for users running *Lion* and *Mountain Lion*. *Snow Leopard* users will be able to compile their own copy by following [my build instructions](https://github.com/TTimo/GtkRadiant/blob/master/apple/README.md). Look for the OS X builds of *GtkRadiant 1.6.4* to appear on the [project site](http://icculus.org/gtkradiant/downloads.html) soon.

Finally, the *Quake2World* entities definitions file for *GtkRadiant* has been completely rewritten to be more accurate and readable. Frankly, it’s at least as good as *Quake III: Arena*’s, which should make mapping for *Quake2World* less confusing and more productive than ever.

Linux server binaries
—-
While client binaries for GNU / Linux have proven difficult to provide in any distro-agnostic way, we are committed to providing dedicated server builds for i686 and x86_64 Linux, complete with an **rsync-based update channel**. Expect to see this in Q4 of 2013.

More goodies
—-
As we march towards these primary goals, many smaller fixes and enhancements will continue to flow into the project: revamped weapon models, weapon spin-up times, new player models, expanded gameplay modes and more general polishing are sure to come. In fact, you can keep tabs on the items we’re tackling for 1.0 by watching these milestones on Github:

* [Quake2World Issues](https://github.com/jdolan/quake2world/issues) – [1.0 milestone](https://github.com/jdolan/quake2world/issues?milestone=3)
* [Quake2World Data Issues](https://github.com/jdolan/quake2world-data/issues) – [1.0 milestone](https://github.com/jdolan/quake2world-data/issues?milestone=1)

I’d also like to mention that, “post-1.0,” we’ll be taking on more major challenges such as **AI and bots**, upgrading to SDL 2.0, and providing more user-friendly in-game menus. But for right now, we’re focused on our 1.0 goals and..

We need your help
====
Sounds like a lot of work, doesn’t it? That’s why we need your help. **Contribute or spread the word!** If you have a skill set like mapping, texturing or programming, or if you know someone who does, please get in touch on our forums or [IRC](/pages/irc) (**#quetoo on irc.freenode.net**). Want to help beta test? That’s cool, too — post a thread or say hello on IRC. All levels of contribution and participation are welcome.

Thanks for taking the time to read this,

Jay (jdolan)