Jacob Santos

Background

There are three issues that are addressed here. The first one is security and developer trust, second is keeping the game site stable and working, and finally the developer tools.

When the game owner hands out FTP access to other developers there is an automatic trust established there. With FTP access, developers can destroy work, or upload anything from personal files to illegal stuff. That takes a lot, but it isn’t just the FTP, it is also access to the database, which can also be easily destroyed.

Giving access to the Repository is also a trust relationship, since the development database passwords would be on there. Locking out access to the developers and using the repository instead should not be seen as punishment. The repository will have commit hooks for the trunk and stable branches which will update the testing and live sites respectively.

It should be noted that the FTP site has many more folders than what the developers are interested in. I’ll most likely move the subdomains to the Battle Machines FTP. While for most it isn’t a major concern, on former projects, a few people decided to host files that weren’t project related. While I did discuss it with a few of the game owners, I really only want the FTP to only be used for game related files.

If you want to take the developer changes as they are:

1. Stable live site changes to keep from site downtime, even from a few seconds or minutes
2. Establishing developer trust between coder changes by telling who is doing what.

Subversion Repository

I like having as many developers working on a single project. However, giving every developer the same FTP username and password has security risks. It isn’t a matter of not trusting other developers, because I do. It is just that I don’t want to get online and have the message, “Um, do you have the backup of the game files? …Someone deleted everything!”

1. If a disgruntled developer decides to delete all of the files, can I easily find out who did it? Is it possible to get every change back afterwards?
2. What if someone decides to upload a copyrighted file and links to it? Would I know which person it was? How fast would I be able to find it? Would I even know to look until it is too late?
3. Opps moments. “Hey I lost…”, “Could you restore…”, “What happens if I do this?”, and other accidental changes.

The point is that developers don’t need direct access to the FTP server. Only the owner of the game and I (me being Jacob Santos) do and there are some cases where I own the game.

Live Testing the repository will be exported with each change to allow for testing before uploading to the live site.

The next focus, is that I want to track the development and what other developers are doing. There, I said it. I want to be Big Brother. It has occurred to me that I should allow the other developers the option to opt out of the online repository tracking feature I’ll be implementing. However, for my own personal entertainment, it would be interesting to know what the other developers are doing. I’m sure the visitors might be interested also, which is why I’m actively working on it.

Development and Production Databases

To further increase the trust between developers and players, all changes will be made to a separate database than the one the players are running on. This means that a screw up won’t affect the players. It should minimize downtime, between when the change is made and when the feature is implemented and fixed.

This also means that the other developers, besides the owner and me, won’t have permissions to access that database. There should be no way for developers to access the database information, since it will be on the FTP and the other developers won’t have access.

There will be an Admin Panel to allow game manipulation for developers, admin, and staff. This will be located elsewhere and no one but me will have access to that.

Wiki is your Friend

The Absidon Wiki will be the primary source for game documentation, developer documentation, and proposals. Once I start writing information, I’ll most likely also start redirecting answers to there.

It won’t just be some “cool” feature, it is a tool that should be used to help other users and developers on how the rest of the game and core works. I suppose, I’ll have to be the one that will have to jump start the new documentation for the project.

Bug Tracking

The bug tracker will most likely be used more by active members than developers for posting bugs. However, this also means that developers should check the bug tracker on some frequent basis (once the bugs start coming in, I’ll let you know).

If you can’t fix the bug yourself, either do not know how, would require too much work, or just don’t feel like it, then it would also be wise for developers to post bugs to the bug tracker also.

Choosing Bug Trackers

I’m currently using Mantis, I might either go back to Trac or try Bugzilla again. I like the bugzilla dependency bug lists that neither Mantis nor Trac have. Trac also has a importer, so it shouldn’t be difficult to go back to Trac, once Trac stabilizes.

Conclusion

This article and mandatory request may turn away some would be developers. I believe that after some “getting used to” phase wears off, it will be happy sailing. Some of the list have already been implemented.

I should point out that I’m not thinking that the FTP and Production Database lock out will happen within a few days or hours. It will happen in a few months time, the FTP and Database passwords are going to change and the other developers won’t be given them.

The database changes and Subversion usage should help to minimize downtime, allow for changes to be “rolled out” in increments using version and/or build numbers, and to allow the player to play without interruption.

Possibly Related Posts:

• Game Engine Development and Open Source
• Plans for Base CMS
• Bullet: E-Book Library Management and Content Server
• Using ZendFramework 2 beta1 For Directory Project
• Project Plans