From Newerth: Savage Wiki

Jump to: navigation, search

Where to start? Maybe it would be a good idea to start from the beginning when I managed to get access to the code base of SFE, and the obstacles I've had to overcome for the team to even start thinking about adding new features collaboratively to Savage.

Let's start with the mess that is the Savage code base. When I got access to the SFE code, it was unfortunate to find out that it was totally undocumented, apart from the odd comment within, and that it was not written in an object orientated fashion (for those of you who don't know, Object Orientated Programming techniques make extending an application less complex, that's the simplest explanation I can come up with anyway). To add to this the majority of changes implemented by people, which had contributed to the changes in Savage, (not just Uttar) had been hacked in, without any consideration for or foresight into maintaining or adding new features to the game. This all contributes to one large pain in the ass and maybe one of the reasons previous developers who worked on improving savage had such a hard time fighting against bugs in the versions they released. So with this in mind, I decided that the only real way to tackle these issues would be to have very stringent and methodical alpha and beta testing of any release the team would make of XR. This lead me to think about how best to support such testing in the development process.

To be able to test XR successfully the team would need a foundation or framework for working together collaboratively. Adding to this problem were the issues of developing savage across multiple operating systems. I think its also worth mentioning the nightmare I had trying to get the Linux version to build, but that is Linux for you, always user-friendly. Anyway, since the previous Auto-updater (or AU, as the development team knew it) was none-functional, and very difficult to extend, I decided to start there.

I completely rewrote a new Auto-updater as a separate application from savage so that any bugs might introduce, in savage, would not interfere or prevent updates to the game. If you are in the Savage 2 beta you will know what a pain this can be and bandwidth wise, with its limited resources, can ill afford this to happen. Anyway for the new Auto-updater I decided it would be a good idea to combine it with SVN, a piece of software that versions changes made to files, and allows the team to contribute changes to the same files concurrently. This elevates the problems that occur when someone makes a change that affects your code, causing your code to break and is essential when more than one person is working on the same piece of software and at the same time.

Using SVN to manage new versions of code, from a central location, lead me to create a system that allows a developer in two operations (2 mouse clicks), to build Savage remotely without the need to upload any files from a developers local machine (but if they wish the system also allows the game to be built and uploaded on a local developers PC) and make the new version of game live for testing on all XR clients for both the windows and Linux versions of the game. The Auto-updater, on your PC, then works by copying changes on SVN, made to the game by a developer, into its web root for downloading by the local Auto-updater software that is run before Savage starts. For the more technically minded or for people that are interested, below is a simplified UML implementation diagram of the system:

image:Auumlt.png Click image to enlarge

This system allows for instant feedback, from testers, on whether new features break on Linux when a developer is coding on windows or visa-versa, as well as allowing changes to be reverted instantly. It speeds up the development process and reduces the time wasted building, uploading and distributing the game (again if your in the Savage 2 beta you will know how long it takes for new versions to go live). The most innovative feature of this system is that it also accommodates changes to flat files, (configuration files, textures, music, 3D models etc.) not just the game code, something which versioning systems have not been normally used for, in the past, within software engineering projects such as Savage: XR. Another feature of the system is that it caters for two versions of the game, a 'Production' version released to the public and a 'Testing' version for developers and testers. The Autoupdater is also multi-threaded and should mean that updates are downloaded at full speed! Bellow you can see a screen shot of the AU in action, something you will become vary familiar with when XR is released:

image:Au-t.jpg Click image to enlarge

What does the Auto-updater mean for all you people playing savage? Swift resolution to bugs, found by Savage: XR users, that could make the game unplayable; and rigorous testing to prevent bugs, in Savage: XR, from being released to the public in the first place.

So to conclude my long ramble, I hope you can see the massive amount of time spent (maybe a few thousand hours of work) so far on setting up the development framework, how little time I've spent personally adding anything feature wise to the game and that my main role at is concentrating on project management so things don't end up in a mess.