Blog

Blog

Top Bloggers

Who's online

There are currently 0 users and 0 guests online.

Upcoming file management features

For the next release of Wild Pockets, one of the areas that we are focusing our attention is on file management. The work we are doing is centered around three main areas:

  1. Access control (permissions) for resources, to allow collaborative access to resources/files;
  2. "Version locking" (what we refer to internally as "manifests") which will allow snapshotted versions of games to be released that will be "unbreakable" even if you continue development;
  3. A replacement for script mirroring that will allow local editing, better interoperability with source control, and will build upon the collaboration support introduced in point 1.

Development is still ongoing on most of these features, and so I can't go into the nitty-gritty details of each enhancement, but I'd like to give you a high-level overview of what each improvement is about and what it will mean to Wild Pockets developers.

1. Access Control

In the past, Wild Pockets has offered a single "public/private" flag for each file that you upload. The intention of this system was to allow developers to keep their assets private (if they want) but still release games that make use of them. In that, it was successful. However, we have always recognized that this is merely the first step of a real access control system, and so we are building out the features to make access control into a useful tool for both protecting and sharing your resources.

In the new system, each file will start out private, accessible to only you, as the developer. From there, you can grant certain permissions to individual users, or to the world. For example, you could choose to grant fellow developers on your team read access to the scripts for your game. You could choose to make some of your models readable by the entire world. You could choose to grant Bob the right to use some textures in a game he is writing. There are a handful of permission bits that you'll be able to use to grant exactly the right amount of access to the right people.

Perhaps even more interesting than being able to grant read-style permissions is the fact that you will now be able to grant fellow developers write access to resources. Oh yes- this means we will be implementing support for directories, which I know is a feature some people have been waiting for. So, you'll be able to set up a directory for your latest project, and grant everyone on your team write access to it. Then, you'll be able to collaborate on development without maintaining separate storage for each user, or trying to juggle using a single account for multiple people.

2. Version Locking

When you release a game, it is pretty much inevitable that you're still going to be doing tweaking on it after the fact. But, it has been difficult in the past to make sure that your tweaking doesn't break the game; after all, all of your scripts, models, and so forth, are live in the game.

Our solution to this will be the addition of a "manifest" system to Wild Pockets. A manifest will simply be a list of files along with pointers to exactly what version of a resource that they should refer to. So, for example, your game might refer to rharke/mainGameScript as its main script file, but the manifest will ensure that, when a person plays your game, they always get a particular version of rharke/mainGameScript- one that is frozen in time, and not affected by any modifications you might make. When you're ready to release again, you can update the manifest, but until that point, everything will be frozen.

As much as possible, we want to make the creation of manifests as automated and transparent as possible. The intention is that, as you develop, Wild Pockets will automatically build up the manifest, marking down the version pointers when you start referring to a resource for the first time. Only under particularly exceptional circumstances would you have to worry about the existence of the manifest at all- the goal is that it just "does the right thing" in the default case.

3. A New Script Mirroring

Our script mirroring system has been around for a while, and there is little doubt in my mind that it is much better than what we had before. However, we think we can do better. We are developing a new system with these key points in mind:

  • When you start working on a project, you will be able to download/mirror/sync your resources for that project to your own computer. From there, while you are developing, you will be able to edit the files directly on your computer, and Wild Pockets will use the local copies. Unlike script mirroring, where only scripts were stored locally, our intention is to expand this to virtually all types of resources, including scenes, models, textures, etc. You can, of course, also create new files on your computer, and they will also be used while you are developing locally.
  • You will be able to keep these locally-stored resources in your own version control system of choice (Subversion, Perforce, etc.) and other team members will be able to get the resources from there, and check in changes there as well.
  • When you have your game in a good state, you can resync your local resources back up to the Wild Pockets server.
  • Because the new access control system allows for directories with shared write access, you will be able to keep all of the resources in a common directory on the Wild Pockets server, and give all of your team the ability to upload to the server. Alternately, you could have your team only run locally, and check their resources into version control, then upload them yourself to Wild Pockets when it is appropriate.

The power will be in your hands to decide how you want to use the new system. The key will be that it will enable you to use source control, and it will enable you to collaborate on projects.

In conclusion

Hopefully this has given you some idea of what is coming down the pipe. There's still a stretch before you'll see all of these features appear in Wild Pockets, but we do intend to incrementally release pieces of the new architecture over the next few months, when it is appropriate and possible.

share