Beta2 Editor Scripts

#21 I don't think that we can talk about how this decision will affect productivity until we can evaluate the editor SDK and what we can achieve with it. I believe that the GG staff will not underestimate it's importance, so I'm not worried about that.
The only real problem that I see in not releasing the editor's source is that the community will not be able to help when bugs will be found, leaving us without any other choice than wait for a patch. The community has proven itself to be very helpful in the past.
Another thing that I'm concerned about is that the source can be a valuable learning tool. Since the TGB interface and editors are evolving in a very powerful instrument (I really like how TGB evolved from the initial release), I think that we could learn a lot just reading the source.
Said that, I will respect the decision that GG will make because I respect their work, but I will surely be happier if we can get those source! :-)


Bye,
Jacopo

#22 To reiterate the point on code changes making the editors useless ...

Everything I am doing with T2D is so far from stock that every single line of stock T2D script code is completely and utterly useless for me. This includes all the editors except for the GUI editor. I havent even bothered looking at stock script code since alpha 3 or 4 aside from a quick glance to disable the level builder when I needed a really quick and dirty test app for something on a stock codebase.

It has always been my intention to write a map editor that will allow Nauris (and eventually, modders) to paint terrain. When the time comes I can get the basic thing running inside of a day. If I were to base the editor on the level builder, regardless of how cool and shiny it is by then, it would take me a lot longer to get it hacked to do what I need it to do simply because my code structure is so different to stock.

It's just another one of those things that is completely game specific. There's no point in fretting over it. What will be will be and GG have always been reasonable. At the end of the day, it's better to to just get on with making games.

T.

#23 I'd just like to say that I have the same concerns as Jon do about not having the "full source" as we were promised when we bought a t2d license.

It's almost like a slap in the face. "Full source, except for all the editors which you would use to build everything ingame"

#24 To be fair -- you were buying a license to the engine source, not the tools. I know this may rub people the wrong way, but that's what you bought. You can go back and read the fine print if you like. I have to agree with Tom on this one. My game projects have been 100% custom Torque Script and my own engine mods. The Level Builder is only useful to me for really quick and dirty experiments with collision, physics, and properties. I cannot forsee myself using the Level Builder to actually build one of my games. Again, that's my POV and yours may vary. There's nothing stopping you from building your own tools and you can do so against the same engine sources the rest of us have.

#25 I feel I should clarify my original post a little more as it may be based on reading more into Justins post than I should. If the source is simply withheld until such a time as GG are happy with the bugfree ness of the level editors and that the final version of TGB ships with editor source then I have no problem what so ever.

To answer the analogy with constructor, that is a none issue imo. We will know up front that constructor does or does not come with source.

Maya and Max don't come with source, that doesn't mean people won't use them, because the tools are flexible enough to be modified to handle most situations. With maya or max the concern would be more "does the dts exporter come with source". Since you may make engine changes to the DTS structure and need to slightly tweak the exporter, I've had to do this once so far, it was a minor change just a few lines, but without the exporter source, I'd have had to recreate all the work the original auther put in to create a compleatly new exporter from scratch just to accomodate what was really a small change.

Now this can be contrasted to showtool pro. This is a tool where having source access would be beneficially. There could be engine changes made or extra things you'd like to have showtool do. At which time you cannot do so and instead have to reinvent the wheel again based on say the show tool that ship with TGE. Again its not the end of the world and a serious developer will work past the issue. But in this case it was enough to make me hold off from buying ShowToolPro (that and the lack of a linux build), since I didn't want to be left with a product that I couldn't use in the future because of changes I'd made to the engine or because I wanted to display extra information.

Jason: I feel the "buying the engine source not script source" is playing semantics. It may be technically correct, but in the spirit of things it isn't. Although I do agree fully that TGB even without editors is still worth the money.

I agree there is nothing stopping people building their own tools. But is this beneficial to indies? I know this is a "what if" and we can create these all day, but bear with me. Assume a developer changed the engine such that the current level editor tool set needs extending to still be usable to build off. If the extensibility built in didn't allow this specific type of extention then the developer can no longer use those tools. So they have to re-invent the wheel, duplicating all the effort GG has put into building a toolset, in order to make the changes they require. Now if the developer is serious about making games, they'll make new editors without question. But what we need to consider is, how beneficial was it having developers partially duplicate the work GG has put in over the past months on creating editors?

Sure there may be an instances where the engine changes are so drastic that it would be easier (even with editor source) to create new editors from scratch. But at least the developer has the choice. They can concentrate on making their game with tweaks to the editors when possible rather than duplicating effort.

Still, if source becomes available at a later date then this is all a none-issue imo. TGB is still EA and if editor script was closed source all the way up until final release I wouldnt' mind, so long as eventually the editors are released.

So to summerise I agree we can build our own editors and in many cases this may be the ideal way to go for that particular project. But in many other cases this could just end up wasting many weeks of development time re-inventing the wheel (I think I've used that term too much in this post :P)

In closing though I do want to say once more that I love the new editors :)

#26 Hey all,

Sorry for the delay in getting back to this thread; I've been out of town and preoccupied over the last few days. I've got to say that I'm a bit surprised by the overall reaction to this thread. You guys need to understand that this is a huge project and is still in a great state of flux. Because our community has been so great at helping us 'eat our dogfood' over the course of development we wanted to get you guys the newest goodies to use that we were going to be showing off at GDC.

While you all are accustomed to full source access to everything, we're just not comfortable releasing something that we may change drastically in the upcoming months. We've had quite a bit changing in TGB over the last few months and it's become a burden for some of our users to update to new versions because they had modified something in a previous version. We're aiming to change that. By holding the source of this tool during development we can ensure that any updates will be quick and painless to add in as we roll them out.

I hope this helps clear some stuff up-bear with us, we've got your best interests in mind.

Cheers,

-Justin

#27 Justin: I think the "overall reaction" is due to uncertainty in whether the scripts will eventually be released. Holding off on releasing them during development is perfectly understandable and I'm sure the majority would accept that (if not I'm sure they'll let you know :P). But I think the wording in the original post left enough doubt as to your intentions to cause a little concern over where this may be heading.

For example stating that you'll be releasing an sdk to extend the editors leads us to assume (perhaps totally wrongly) that you no longer plan to release the script in the final product. As Ray points out, the updated sales page stating "Full C++ source" again leads the same assumption. Now this may be a totally wrong assumption on our part, you may actully have updated the sales page to just make it clear that "Yes you really do get the full c++ source, hard to beleive but its true".

So I hope you'll realise that people are just unsure where you're going with this and may be its really nothing to be concerned about at all.

#28 I don't really see anything wrong with a SDK to extend the level editor. However, as others have pointed out, it would be nice to have the script sources. The more code to browse through and learn from, the better.

I am with Jason, though. I don't see myself using the level editors to actually build my game. I'd rather do it from scripts. However, I could see myself modifying the editors to make a level editor specific to my game. If the SDK makes this easier to do, I'm all for that. However, it still would be nice to have the source code...

#29 Having had a chance to play with the level editor, and having seen my graphic designer's reaction to them I can say that much of the value in T2D is in the editors. Consider this skin in my game:

http://www.mrjoy.com/alpha7_vn.png

That skin consists of 30 separate animated sprites that do nothing but sit in one place and look pretty. I've got two options: 1) I can write all the imagemap datablocks, animation datablocks, translate the coordinate spaces (pixels with x,y at upper-left corner) into the virtual screen coordinates used in the game, write the code to display them, with proper z arrangement and blending (including figuring out what blending mode to use for each sprite). 2) I can let my graphic designer put the whole thing together to her liking in the level editor and figure out how to make my game use the output of the level editor. The total labor exterted for #2 turns out to be DRAMATICALLY less than the total labor for #1, AND my designer can go back and easily tweak and adjust things.

I understand the natural tendency for programmers to be skeptical about a tool like this, and if you're not working with an artist or all you need form your artist is a few simple sprites, then sure ya don't need it, but if you wanna let your artists roam free and you don't wanna spend a lot of time being their UI to the engine, the level editor is a life saver. Could I make my own level editor? Maybe. Could I make my own level editor, particle editor, and put that kinda smile on my artists' face? Err, not in any kinda practical timeframe -- and I'd rather just make *games*, not game development tools. Modifying someone else's level editor to meet my needs is a whole heck of a lot easier than building one from scratch.

-JF

#30 Not trying to keep flames burning, but I think it was this line that stuck out the most from Justins original post:
"Outside of the beta the scripts will still be closed"

*confused*

#31 As an artist jsut having spent an evening with the Level Editor I have to say that I like it if from no other position than What Jon mentioned above:

Yes, I can do it all 'by hand' in my scripts, but this tool makes placing, mounting, setting auto-rotation, making collision (Oh man alive, what a great, great function that is! Bless you!) and all the other tidbits of just getting something in place to work with a very easy task.

I am at a bit of a dead end as to how to take and use that data from the .t2d file in my current game, since I've become so used to my present workflow. However, the time savings from the setup gets me to a point where I'm treading new ground anyway (in terms of implementing designed functionality) and so it's not a huge deal to me.

That said, I am curious how the engine is going to handle my taking objects with predefined scene IDs and mixing them in with what I have already that gets IDs at runtime. I.e. my world gets started, objects get created, then at some point I call the datablocks from the .t2d file - if there are clashing IDs, how does the game handle it? Especially with mounted objects where the Level Editor generated datablocks' IDs are all 'hard coded'.

- Don

#32 The Level Builder doesn't hardcode IDs :) If you look at your .t2d file you'll notice its all basically just script, it recreates those objects with thsoe values when the level gets loaded so the IDs won't conflict.

Also we completely agree with you on the usability of the Level Builder, we've been using it extensively with MightyFist. Right now I can set up a ll the script classes ahead of time and then load of Mighty Fist and drop enemies and a player wherever I want with linkage to those classes, test the level and can run around in it just fine :)

#33 Matt, I started a new thread since I had a follow up question.

http://www.garagegames.com/mg/forums/result.thread.php?qt=42155

#34 As long as we get the source eventually, I'm happy. But if we don't, I won't be able to adapt the editor to work with my OOP resources paradigm / idiom / interface. The TGE editor works great with my OOP stuff with only a few changes. Hate to see T2D not be able to do that.

But like I said, as long as we eventually get the source, I have no complaints. A bit nervous, yes, but no complaints :)

#35 The leveleditor already has fields for class, superclass etc in the edit tab ...
Do you mean that by OO?

#36 There's a little more to it than that when it comes to using the OOP resource with object serialization, but it's relatively trivial stuff. Basically I like to be able to do a little more with the editors than what is allowed and using my OO resource I can.