Grid12 Tank Designer (an Idea)

[osx]

Rob has previously stated that in the future he would like there to be 200+ tanks in Grid12. Because of this, I thought that there could be a Tank Designer that would allow us to design our own tanks. This would work similarly to the way the rotmg pixel editor works, meaning that the tanks designed could be viewed by everyone, and that rob could possibly implement any tanks that caught his eye into the game.

[raidonx]

200+ ?

Seems a bit excessive, but it's a fun concept.
A tank designer would be nice to allow us to help Rob & Friends to further the development and variation within the game.

[gingerbear]

p.s.: Rob has his own tank designer. It's not published 'cause it is not user friendly.

p.s. p.s: Since the database is public, and you can build up your tank from there (see amitp's site with all the units), there is nothing stopping you from doing it the other way around, and build your own tank designer kit. Look for a friend who has time and skills to do so, I think the devs have more pressing issues to fix then a tank maker.

[amitp]

Yes, it seems entirely possible for some of us to make a tank designer ourselves, and then export the data so that Rob can use it. I wrote some code to decode the database tables and draw tanks: www.redblobgames.com/x/jetbolt/viewer/ ; the javascript code is in www.redblobgames.com/x/jetbolt/viewer/index.js. I didn't make an editor.

I've used Rob's tank editor and have some ideas on how to make it better. I can confirm that it's not user friendly. It's also not a separate tool but integrated into the devel process that (I think) it's not easy to make it something everyone has permission to use. If I remember right you need to run your own mysql and game instance on your own machine, which means Rob has to give you the game server too. I think it'd be better as a standalone tool instead of one that is tied to mysql and the game server.

The other problem is that designing tanks seems to be such a small amount of overall development time that if I were Rob I wouldn't spend any time making it better. It might be a fun project for one of the players to work on.

I'm happy to help anyone who does figure out the database tables to make a standalone tank editor. And who knows? Maybe one day I'll want to work on it too.

[rob]

Last month or so I successfully pulled the tank editor out of the game client. To run it, you just need the editor swf, a mysql server, and the data.

There are 2 obstacles that are preventing me from releasing the editor:

1) It's not friendly. I'd describe it as user-hostile.

2) New entities in the database need ids. Currently, the editor uses ids starting at one million, and we run a "compactdb" program to choose smaller ids just before we check in the new "grid12staticdata.sql" file. This scheme allows more than one person to build things at a time, without id collisions. But it is error-prone and fiddly, and the consequences of making an error can be large (eg, bye-bye, two days' work).

We can probably live with problem 1. I could open-source the editor and let others improve it.

Problem 2 is deeper. Any ideas?

[Duco]

Jul 3, 2013 6:52:20 GMT -5 rob said:

Last month or so I successfully pulled the tank editor out of the game client. To run it, you just need the editor swf, a mysql server, and the data.

There are 2 obstacles that are preventing me from releasing the editor:

1) It's not friendly. I'd describe it as user-hostile.

2) New entities in the database need ids. Currently, the editor uses ids starting at one million, and we run a "compactdb" program to choose smaller ids just before we check in the new "grid12staticdata.sql" file. This scheme allows more than one person to build things at a time, without id collisions. But it is error-prone and fiddly, and the consequences of making an error can be large (eg, bye-bye, two days' work).

We can probably live with problem 1. I could open-source the editor and let others improve it.

Problem 2 is deeper. Any ideas?

Open soure would be really cool.

As for problem #2, I don't really understand what you mean there.

EDIT: ''bye bye 2 days' work'' can be solved by autosaving to a tempory file every 2 minutes or so.

[osx]

First off, thanks rob and amitp for your feedback.

Jul 3, 2013 6:52:20 GMT -5 rob said:

Last month or so I successfully pulled the tank editor out of the game client. To run it, you just need the editor swf, a mysql server, and the data.

There are 2 obstacles that are preventing me from releasing the editor:

1) It's not friendly. I'd describe it as user-hostile.

2) New entities in the database need ids. Currently, the editor uses ids starting at one million, and we run a "compactdb" program to choose smaller ids just before we check in the new "grid12staticdata.sql" file. This scheme allows more than one person to build things at a time, without id collisions. But it is error-prone and fiddly, and the consequences of making an error can be large (eg, bye-bye, two days' work).

We can probably live with problem 1. I could open-source the editor and let others improve it.

Problem 2 is deeper. Any ideas?

Problem 1: I like the idea of open-sourcing the editor, as problem 1 would be the lowest priority because the editor still works fine.

Problem 2: I don't quite understand why the id scheme is prone to errors. If the problem cannot be pinpointed, maybe there could be a different way of choosing ideas? This would be helpful in the future if grid12 becomes very popular, and the limit of 1 million tank id's (keep in mind that not all of these would be implemented into the game) would not suffice.

[amitp]

Rob, do you mean id collisions are a problem on each individual's mysql server, or do you mean the merge process makes them problematic? If each instance of mysql had its own start-id (other than 1,000,000), would that minimize collisions? In a 64-bit address space you could reserve 48 bits for a unique id per user. This wouldn't allow collaboration but at least each individual's creations would be separate.

I don't have a good sense of the use case though. Do you want people to build shapes that are shared with others, and then those shapes get built up into full tanks? It might be easier to support copy/paste than to have proper sharing. You can eliminate duplicates during the build process if necessary but I suspect the sharing aspect hurts the usability of the editor.

[gingerbear]

Simple and possibly worst solution:

Step 1:

To be able to make tanks, you have to register somewhere. Everyone registered is allowed to make about 10-30 tanks, with 10-30 unique ID-s.

Step 2:

Create a new table called "temporary tanks", which has the ID column matching the IDs the players have been given, the other columns match regular tank columns. There is no need for built-in autoincrement, uniqueness is provided by the way ids are distributed. Then all you have to do is to add this table to the tank queries.

Also:
- messing up anything in this temp table won't ruin anything on the main database
- tanks can be tracked back, so best tank makers could be exalted
- multiple people working on tanks is possible, no collosions
- easy to move a tank to the main database, in case it gets "approved".

---

If you want to share turrets, hulls, etc. just make a temporary table for those too. Let's say everyone is entitled to make as many different hulls as tanks, and 2x or maximum 3x turrets as tanks.