[LE] Up- and Download

[Germanunkol]

I believe to make sure people use the level editor, we have to make up and download (i.e. sharing of the levels) as simple as possible. In my opinion, we need:

• Fields for levelname, description and author in the LE
• Upload button in LE
• Upload function
  • should run in background thread
  • should display progress (bar? percentage?)
  • should return possible errors (where to display them)?
  • should time out when there's no connection possible or upload takes too long.
• Online interface ("list" of all uploaded levels which we can access to download and then "approve" manually). It might also be nice if we could display them on the website if we ever make one for the game.
• "User levels" section in the main menu - where people can go to get a list of levels. All available levels should be displayed, sortable, searchable.
  • Unapproved maps could be displayed and available for download, but with a warning: Sort of like I do it for the trAInsported maps: http://trainsportedgame.no-ip.org/maps.php. Since we never execute the downloadable maps, I think this should be save. And it would make sure that maps are available for download even if neither you nor me have the time to review them at the moment.
  • We could display local statistics (number of times played, best time, least deaths...). By local I mean they just display information about this current computer and are not synchronized.
• Protocol: Http might be the best choice since that's running on the server anyway (and luasocket can handle it well). A Lua server might be a tint easier to program, but would need an additional program to run all day long, which we can avoid.

What's your opinion? Do you agree on the above, or is it too much? Do you want anything else added or do you have another idea of how to do it?

At least for testing purposes, I would use my server (germanunkol.de). If the application turns out light enough, we can leave it on there in the future as well, and maybe just buy a domain (bandana.org is free). Otherwise, we might need to rent a separate server. So we should definitely use http since root servers (which could run a Lua program) tend to be much more expensive...

[michalove]

This is a totally new field for me. I have not server/upload/download experience what so ever. So I am eager to learn!

I agree with what you wrote. The upload should be done in a separate thread, but the game should not let the user do anything in the meantime, maybe only show a waitbar and an option to abort.

Directly after approval, we could run a small test on the submitted file, if this is a proper map (from the technical point of view) and then have it in the "not approved" list. Final approval could be done by us by hand.

Additionally, I suggest, the players can rate the maps they download on two scales: fun and difficulty (in stars 1-5).

And we should try to make the concept future-proof. By that I mean, if we hard-code the server/domain where the maps are, and we decided to move, then the players cannot use this functionality anymore. Maybe have one fixed and definite place to go first (germanunkol.de). The map data do not have to be there, but the info, where to find the map data. So we can move the map data, if we need to.

[Germanunkol]

The rating system is important, you're right!

The URL could be hard-coded if it was something we can be sure we'll stick with (like bandana.org). But there should be some way of falling back as well... (maybe entering a manual URL if nothing is found under the hard-coded URLs?)

[Germanunkol]

Another thing came to mind: How should we store "meta"-data (ratings, number of downloads, file location etc.)? I can think of two methods:

1. We create a mySQL database. This is pretty straight forward and allows for the maximum flexibility (for example, a simple field "file name" could hold the name and path to the corresponding level file). It would be easy to sort and php has direct bindings. Also, we'd need a minimum level of string-parsing here: All different data types (file name, rating etc) would be in a column in the table, so retrieving single bits of that data would be a piece of cake.
2. We store meta-data in a seperate file. In this file, rating, number of downloads etc would be stored, with a line per level. This approach comes with the huge benefit that moving servers would only involve moving the levels folder and the metadata file (mySQL databases can be moved, too, but I've never done it and think it's a little more involved). Sorting would be much more difficult here, but I think we can do sorting client-side (simply always send the full list of available levels and then let the client sort and move levels). If the client then wants to download the corresponding file, he can easily piece together the URL because the file path is written in the file he just downloaded. This way, the effort for downloading files would be minimal on the server side - since it's just http requests, which the running apache server would handle anyway. Upload would be simple, too: Parse the file, if it's fine add it to the download folder and then add a line to the metadata file.

You might be able to tell that I'm leaning towards the second option - but I'm open to suggestion. If you want to do sorting on the server's side, for example, we should consider databases - they're quite nice...

[michalove]

I have to say, this is totally outside my knowledge. But from what you are writing SQL would be a readily available solution, but probably a bit overkill, since we only have very few data fields. In the second option we have more control over the whole thing, since it is only one file.

I think, sorting can be done locally in the game, unless we get really many level submissions. Then we could still let the server sort the levels (e.g. by name) once a day or even after each new submission.

So, I cannot contribute much to this discussion and I am open to whatever you prefer.

[Germanunkol]

Actually, you already DID contribute a lot: That idea about sorting once a day is really good. As so many things, though, it requires that we have a server we can run programs on - so more than a very simple web server.

I also noticed another thing we need to consider: We need to manually "approve" levels (or delete them) - so we somehow need to edit the metafile or the database. Editing the metafile might be easier - we can just log in and then manipulate the file using nano or vim. Editing a mysql database works, too, though: For this, we can even use graphical interfaces. Using a file reduces work on the download side, but might increase it on the upload, because we need to search through the file for a level with the same name, for example (which is very simple in mySQL). Using mySQL increases work on the download side, but decreases it on upload.

Few. Let me sleep over this... I'll also take a look at some php file functions - if there's a simply way to serialize tables then I think the metafile-method would be the way to go.

[Germanunkol]

All right, I did some more reading. It seems that writing arrays in php to file and retreiving them is a 2-line thing - with the huge benefit that it can be written in human-readable form. This means we could simply edit that metafile manually when we want to administrate (approve or delete levels) and the php would then load the new file. Since sorting arrays in php works as well, I think we should use the file method as its the easiest to program (and, in my opinion, ends up in much cleaner code since we can avoid mixing SQL and php syntax). In case we do want a proper administration interface later on, we can always still add that later.

[Germanunkol]

Another thing: Since we don't require a log in for downloading levels, how do we make sure people don't rate levels multiple times? Should we just save it locally? And should we ever notice abuse, we can still add some sort of security system... What do you think?

[Germanunkol]

For downloading levels, should we simply add another entry to the main menu? And then a list of levels (similar to the level selection screen we currently have), where players can select a level to play. But how do we let the user sort? Maybe by pressing something on the keyboard? So first it's sorted by rating, when the user presses "space" then it changes to sorting by name, space again -> sort by author and so on? Also, we'll need two "categories", authorized and un-authorized. The latter could be below the screen ("underground"). Also, each level might have: Name, author, description, rating (fun), rating (difficulty). Do you have the time to brainstorm this level-selection screen and could you maybe come up with some sort of mockup?

[Germanunkol]

P.S. I'd also be happy about icons that I can display on what I call the "upload status panel", the panel that displays at the bottom when uploading levels. For example: we could display some sort of "idle" or "waiting" image while the process is running, a checkmark when it's done and a red cross when it failed?

[Germanunkol]

Well, up- and download is done. There's some minor things to sort with deleting levels and currently users can still rate a level multiple times. But the main functionality is done, I'll make seperate issues when we need them