Game tools

About the actual programming of the game.

Re: Game tools

Postby S0lll0s » Thu Oct 31, 2013 5:37 pm

I'd make the server in python, nodejs or sinatrarb. All of those are easy to use, multiplatform and it's easy to make RESTful APIs with them.
S0lll0s
 
Posts: 58
Joined: Fri Sep 20, 2013 9:13 pm

Re: Game tools

Postby DarkSpartan » Thu Oct 31, 2013 6:30 pm

This seems like a reasonable way to do the job, regardless. Pseudo, let me know what you prefer as far as languages and implementation details, and I'll see if I can get it together.
DarkSpartan
Lead Designer
 
Posts: 100
Joined: Mon Aug 12, 2013 10:45 pm

Re: Game tools

Postby wrongu » Sat Nov 02, 2013 10:15 pm

I've already started working on this in Java. After about a week of wrestling with container/server configurations, I think I have one that will work, so development will start gaining momentum. Here's what I'm using:

Container: Grizzly 2.3
REST Api: Jersey
Database: MongoDB
Team: JGit (maybe. open to suggestions.)

I'm working out Swagger now. Once it gets to a presentable and minimally functional state, I'll publish the repo. Earlier than that (Monday?) I'll publish the first draft of the REST api that I had in mind.
wrongu
 
Posts: 46
Joined: Sun Sep 08, 2013 6:15 pm

Re: Game tools

Postby wrongu » Mon Nov 04, 2013 3:13 pm

Quick-and-dirty first draft of the API is available here
wrongu
 
Posts: 46
Joined: Sun Sep 08, 2013 6:15 pm

Re: Game tools

Postby S0lll0s » Wed Nov 06, 2013 6:16 pm

Mmmh i'm not sure whether java is the right choice here. Still /tu for starting on this.

Edit: may I suggest that the GET HTTP-Verb is only used in "Read-Only" contexts (i.e. /git-* and /create with POST or PUT)?
Code: Select all
[img]http://localhost:8080/create[/img]
adding fake files etc. is no fun.

Also a RESTful API should look like this, no?
Code: Select all
POST /register
POST /documents              [new file]
PUT   /documents/<id>      [undo]  "edit": "undo"
PUT   /documents/<id>      [redo]   "edit": "redo"
PUT   /documents/<id>      [edit]    "edit": "data", "data": {...}
GET   /documents/<id>      [refresh]
GET   /documents              [list of all documents]

(where id could be the full path too)

I wouldn't include git commands via JSON either, those should just go with the standard git http protocol - thats what it's made for (/.git as repo path)

Maybe the server should be structured with projects or something like that (repos):
Code: Select all
POST /projects       [new project]
POST /projects/<name>/documents etc.
git: /project/<name>.git
S0lll0s
 
Posts: 58
Joined: Fri Sep 20, 2013 9:13 pm

Re: Game tools

Postby wrongu » Wed Nov 06, 2013 11:08 pm

You're absolutely right about GET for /create. oops.

To be honest, this is the first RESTful API I've built, so you tell me what the proper format should be. Is it considered best-practice to use fewer paths and rely more on content (like how you use /documents for many functions)? And I do like keeping id as a relative file path, where the user chooses a local root directory when the server is first launched.

As for git, I'm putting that off until later regardless. Part of me wants to abstract away "commit" as a `GET /documents/id [save]`. It sounds crazy, I know.. but I would like to remove one of the many layers of editing. At the moment, we're looking at DeltaJSON --> the full JSON document in the database --> a JSON file on disk --> the central git repo.

Then again, maybe we skip the full-document-in-database step and write to local files for every change.

As for the decision to use Java.. partly selfish. But JAR files are also very easy to distribute with no per-system customization, and it has all the features we need.
wrongu
 
Posts: 46
Joined: Sun Sep 08, 2013 6:15 pm

Re: Game tools

Postby S0lll0s » Thu Nov 07, 2013 3:54 pm

wrongu wrote:You're absolutely right about GET for /create. oops.

To be honest, this is the first RESTful API I've built, so you tell me what the proper format should be. Is it considered best-practice to use fewer paths and rely more on content (like how you use /documents for many functions)? And I do like keeping id as a relative file path, where the user chooses a local root directory when the server is first launched.

As for git, I'm putting that off until later regardless. Part of me wants to abstract away "commit" as a `GET /documents/id [save]`. It sounds crazy, I know.. but I would like to remove one of the many layers of editing. At the moment, we're looking at DeltaJSON --> the full JSON document in the database --> a JSON file on disk --> the central git repo.

Then again, maybe we skip the full-document-in-database step and write to local files for every change.

As for the decision to use Java.. partly selfish. But JAR files are also very easy to distribute with no per-system customization, and it has all the features we need.


REST APIs have a strict syntax:
From http://www.restapitutorial.com/lessons/httpmethods.html :
Code: Select all
Examples:

GET http://www.example.com/customers/12345
GET http://www.example.com/customers/12345/orders
GET http://www.example.com/buckets/sample

PUT http://www.example.com/customers/12345
PUT http://www.example.com/customers/12345/orders/98765
PUT http://www.example.com/buckets/secret_stuff

POST http://www.example.com/customers
POST http://www.example.com/customers/12345/orders


basically in a REST api you always have a {kind} of thing you want to view / create / edit / delete and that is done with the verbs
GET (view), POST (new), PUT (edit) and DELETE (delete) to the URL /path/to/{kind} (for POST) and /path/to/{kind}/id (everything else).

with /path/to/{kind} I mean that its either {kind} or /{parent_kind}/id/{kind} etc.

And python is easier to run IMO.
S0lll0s
 
Posts: 58
Joined: Fri Sep 20, 2013 9:13 pm

Re: Game tools

Postby wrongu » Thu Nov 07, 2013 6:03 pm

Thanks for that tutorial.

At the moment, we're keeping the discussion to the API only. If we share a common spec, there's nothing keeping us from writing both a java implementation and a python implementation!
wrongu
 
Posts: 46
Joined: Sun Sep 08, 2013 6:15 pm

Re: Game tools

Postby S0lll0s » Tue Nov 12, 2013 1:35 pm

I was also thinking of better versioning support... shouldn't there be projects or something?
I mean we don't want to ship every change so there should be at least a stable and a development version, + everyone wants their own state obviously.

As we get to that point, we really approach git: files are files, undo/redo points are commits, user states are branches.
The question is do we stick to our REST api and just add a /projects/{name} in front of every URL or shouldn't we switch to git bindings completely? I'm not sure how much better we can get than git.
S0lll0s
 
Posts: 58
Joined: Fri Sep 20, 2013 9:13 pm

Re: Game tools

Postby wrongu » Thu Nov 14, 2013 2:09 pm

Good point. This really depends on the shape of the designers' workflow.

Personally, when I use git, there is a lot of trial and error that goes in to a single commit. So I do think we can do better than git in at least one sense: file size and granularity of edits. Every git-commit is a full snapshot, which is too cumbersome for small changes.

If the designers want to prioritize synchronization, then pure git is probably the way to go. This tool server is about more than just synchronization, though.

Insomniac Games Blog Post wrote:The Insomniac LunaServer architecture was started about two years ago. It seemed like a good idea at the time. I don’t think that anyone involved realized back then, how good the idea really was. The server side document storage, the simple synchronization between instances, the centralized undo/redo system and disk access have made our tools more robust, more flexible, easier to use, and their development much simpler.
wrongu
 
Posts: 46
Joined: Sun Sep 08, 2013 6:15 pm

PreviousNext

Return to Code

Who is online

Users browsing this forum: No registered users and 1 guest

cron