Game tools

About the actual programming of the game.

Re: Game tools

Postby wrongu » Wed Jan 15, 2014 10:34 pm

A few days ago I had the lucky opportunity to ask Chris Edwards a few questions. He is the engineer at Insomniac Games who invented Luna :D

Here is what I asked:
1. Do you think a Luna-like game tools server makes sense for an open-source project? It requires that all editors/tools use it, which may be more difficult when tools are written by the anonymous masses.
2. Why do you use git/perforce rather than running a central (remote) instance of Luna? Do you provide git hooks to the editors as part of Luna's API?

And here are his responses:
1. Yes, I think that a Luna-like game tools server can work for an open-source project. I would suggest that in addition to providing the server for tools to be written against, you provide the basic interface for working with the server, at least for a few languages that you anticipated using for the tools. We have a JavaScript interface that wraps all calls that can be made to the server and the UI is written against that. We also have some Perl floating around that funnels all server interaction through a single module. We’ve found this a little easier to manage since even changes in the server can be slightly insulated in the tools by keeping the JavaScript api stable. But at a certain point, you may make changes so drastic that even that is not possible. At that point, you could version the the server’s URLs and interface module as well, and maybe even keep both versions going for a while. I think that could be important depending on how many different developers are out there creating tools that rely on the server.

2. We use Perforce to manage revisions of our assets simply because that was already in place in our previous tools and we use it for our code. We already have a lot of infrastructure to make sure that the Perforce server is working well and backed up. So we chose to leverage that. Also, we had a lot of concerns about latency when dealing with a remote server and shuttling around large amounts of data. With the Perforce arrangement, the data is all on the local machine and the server is also on the local machine. We don’t have to worry about concurrent users (though there’s nothing that really precludes that). LunaServer does provide a fairly raw interface to Perforce: open (which will do an add or check out as appropriate), changelist creation and management, fstat, and submit. For us, the data in Perforce is the definitive information, and we chuck it all into a database to make it faster to query and edit. But any change to a file on disk stomps whatever is in the database. However, we could certainly move in a direction where the database is the authority and try centralizing that.
Posts: 46
Joined: Sun Sep 08, 2013 6:15 pm


Return to Code

Who is online

Users browsing this forum: No registered users and 1 guest