TAML for T3D

Friendly conversations, and everything that doesn't fit into the other forums.
32 posts Page 1 of 4
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Mon Feb 23, 2015 5:30 am
TAML is a persistence layer (and markup language) in use by T2D for saving resources like levels and animations. This page from the T2D wiki has a really good overview. I want to make it extra clear that TAML refers to both the persistence system itself, as well as a particular backend that looks like XML (Torque Application Markup Language, AFAIR). But the TAML persistence system is apparently able to persist via JSON and binary backends as well.

@ LukasPJ has already implemented TAML in T3D in some form, which I'm not too familiar with but I'm sure he can elaborate on. @ Hutch recently expressed some opinions on the use of TAML, which prompted me to create this thread. We should have a bit of a discussion about how we want to carry forward in this direction.

I'll write in more detail later, but I want to kick off the discussion by saying I'm very much in favour of separating code and data. Which means, TAML for data, and TorqueScript for code. At the moment, our .gui and .mis files, for example, are actually code, which is executed like code. I think separating them would allow for better editing and tooling. I'll finish for now by quoting Rene Damm, from some private correspondence we had a while ago which I've asked for his permission to share:
Torque’s serialization/loading system again is basically absent. Melv did some work here for T2D based on the work he did for T4, but in good old T3D that odd idea of serialization by generating script code still is the de-facto persistence mechanism (if that hasn’t changed in the MIT version). This leads to so many problems. Object references need to be by name and can only be resolved after loading. The script VM is dead slow so loading is extremely slow. And so on.

...

This, however, leads me to another issue. I always liked how “alive” things were in the Torque editor – your game is really running while you edit it. It’s fun. However, in the end, it’s not a good thing. It makes much more sense to separate play testing from editing and while Unity has some issues of its own here, it does this much better.

...

Finally, there’s the build pipeline – another concept that is sorely missing in Torque. In Torque, neither importing nor building is well-defined. Importing is sort of a per-asset-type kind of thing without any architectural backbone. And building basically equates to you somehow packaging your executable with the scripts and data. In Unity, building is essentially a final compile step with its own pipeline and processors. This allows targeting a metric ton of platforms from the same project data and again makes for a fully automated, deterministic, and repeatable process.
LukasPJ
Site Admin
Posts: 388
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Mon Feb 23, 2015 7:39 am
I love TAML, I think almost every aspect of TAML is great, and T3D already has something similar with the "TorqueScript"-serializer.. If someone wanted to, we could port that serializer to TAML and make TAML output TorqueScript instead for some reason that does not make sense!

But from what I can gather T3D community hates TAML :( That's just how the cookie crumbles!

Edit: I should mention that the PR in question has both XML, JSON and binary support. So at the very least, it's very good for sending SimObjects to e.g. webserver and back.

Edit: Should also mention that this does not affect current code at all... There's no disabled or changed features outside of the TAML stuff, so you can keep scripting as always without worrying about it.
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Mon Feb 23, 2015 9:43 am
Maybe if we renamed it, they wouldn't notice! Seriously though, I do think a rename is a good idea, so as not to confuse the persistence system with the file format. And, really, .taml should probably just be .xml. Maybe the system should be TASL (Torque Application Serialisation Layer) or TAS (Torque Asset Serialisation)?
LukasPJ
Site Admin
Posts: 388
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Mon Feb 23, 2015 10:08 am
I agree, the whole TAML vs TAML thing has only served to confuse people so far.

I like TASL, but that's probably because I've gotten used to calling it TAML :P
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Mon Feb 23, 2015 10:47 am
So, I was originally quite on board with the idea of doing stuff like storing levels in TAML because of the separation - you could open a TAML file, read it into memory, view it, edit it, operate on it, without creating any actual objects. This seems like it would be a win for editors - but on second thoughts, wouldn't it make it difficult to write editors? Say you open a 3D scene in the editor, which is represented as a TAML file that describes a list of (nested?) objects. What do you do now? You've got to create graphical representations of all those objects, of course, and lay them out in 3D space in the way they're represented in the file, the same way they'll be created when you play the level. But how do those representations get created, without actually instantiating objects anyway? Do you have to write separate rendering logic to render a TAML scene, before actually creating the real scene? isn't that a ton of code duplication?

The obvious answer, of course, is that you load up a TAML file, create all the objects it describes, then edit them like we do currently, and same them all back out to TAML afterwards. But then what benefit does TAML have?
LukasPJ
Site Admin
Posts: 388
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Mon Feb 23, 2015 3:09 pm
Okay here's the thing.. Torque3D already has a persistence layer, it can be found here. So what does TAML do differently? It generalizes that persistence layer. As described in the thread you linked initially, using e.g. XML is MUCH faster than executing a script file. Furthermore, you can now use serialize from/to any file format, which makes it easy to work with 3rd party apps (the main motivation behind TAML for T2D).

Lastly, having the missions in e.g. XML makes it easier for some world designers to understand the scene structure without having to learn TorqueScript, and you can validate an XML file without having to run the engine.

TAML and the existing persistence layer in essence works the same way. Save a SimObject to a file, read a SimObject from a file.
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Mon Feb 23, 2015 3:14 pm
The obvious answer, of course, is that you load up a TAML file, create all the objects it describes, then edit them like we do currently, and same them all back out to TAML afterwards. But then what benefit does TAML have?
The not-so-obvious answer is something like this: You have an object that is spread across several levels. With TAML you can create an XML visitor to walk the level files and update parameters after changing a single instance. Did it in Three Step Studio. Was glorious.
LukasPJ
Site Admin
Posts: 388
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Mon Feb 23, 2015 3:18 pm
The not-so-obvious answer is something like this: You have an object that is spread across several levels. With TAML you can create an XML visitor to walk the level files and update parameters after changing a single instance. Did it in Three Step Studio. Was glorious.
Could you elaborate on that? I don't quite understand what happened but it sounds intriguing :P
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Feb 23, 2015 3:56 pm
The not-so-obvious answer is something like this: You have an object that is spread across several levels. With TAML you can create an XML visitor to walk the level files and update parameters after changing a single instance. Did it in Three Step Studio. Was glorious.
Could you elaborate on that? I don't quite understand what happened but it sounds intriguing :P
Sounds like they had it where if you had an object like, say, a car for the player to drive, and you tweaked the parameters for it in one scene, you could have it go through the other levels and update it similarly there without having to edit each level yourself.

On a similar line, TAML/TASL would be useful for Prefabs. I'm not a fan of how they are currently(a glorified script file that contains a simgroup). It's an inefficient way to store stuff and requires you to generate additional simObjects, namely the simgroup, so that you can move stuff over to the prefab after load.
Having it in a TASL file means the prefab points to that file, and can just parse and create straight into it's internal list rather than needing to juggle around simgroups, and makes other convenience features around that easier.

I was looking at testing that out in the near future, as I feel it'd be a large step up for prefabs.
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Mon Feb 23, 2015 8:05 pm
The "physics launcher" template had many physics-enabled objects in the scene like enemies and obstacles. If you wanted all obstacles of type "crate01" to have a lower damage threshold you would have to update every instance of that object in each scene file - this is best done with a "visitor" pattern object that can iterate over and modify entities by their type.
32 posts Page 1 of 4

Who is online

Users browsing this forum: Hodo33 and 2 guests