Jmtcw

#1 2. You can drag the image map to the trash can


I concur on all other points. :)

#2 Hi!

On 2., thanks for the tip!;)

I don't see it in the post, but in the email I received you have:


3. Alt + Return works for me


However, this is not the kind of max/min I was referring to. For max, I mean widening the "view port", not just making the image larger. For min, I mean iconize. The standard 3 boxes in Windows and in most UNIX/Linux window managing packages for "min", "max", and "close" would be nice and usually, you have to disable these to get the result displayed by T2D.exe. I guess I'm a little spoiled, being used to resizing windows to see more/less and being able to scroll around the view. I miss it terribly in T2D.exe!:-(

I'm sure to many these seem like nits to be picking, but when a user is used to certain behaviors, it's hard to adjust to their absence and to using workarounds.

thx,
Dave S.

#3 Exactly that's why i removed it from the post... :) At first i thought you had problems getting into fullscreen mode :P

#4 1. While not all .cs files can be recompiled while T2D.exe is running, if you put all your custom script file exec() statements inside your startGame function (in game.cs) it will recomplie it when you press the play button to test the level.

5. Everything in console.log can be viewed through the console while TGB is running. To view the log, press the key to the left of 1, which is normally ~.

6. The code the level builder generates is either in the managed folder (primarily datablocks.cs when adding images and animation to the create tab) or in the level file that you should be saving to data/levels (YourLevelName.t2d).

#5 Hi,

Thanks for your response here and elsewhere...:-)

1. All tutorials state (and my experience has been) that to get a change in scripting to take effect, you must quit T2D.exe and restart it. This is what is onerous to me. If you've been using TGB for some time (through more than one incarnation) you're probably used to this and it's "okay". To newbies, it's somewhat of a pain (especially at ~$200)

5. "... through the console... " ??? What console? I see it when I press the backtick key (left of '1') but how does one know about this feature?

6. nice info!:-)

I don't mean to seem rude, but you seem to be an "old timer", with a lot of "insider" info. My suggestions here are meant to be for improvements to TGB (as the premise of the forum states), not for current work arounds. And, yes I do truly appreciate your information. As I said, I'm not trying to be rude. I just don't want any input to fall by the wayside since insider workarounds already exist.

A better product would have these features well documented and up front and readily available even to newbies. Reliance on fora and experienced users to hold newbies hands is not making a better product.

Please, please, don't take any offense, I value your knowledge and input and info! I and many others would be lost without it!:-) As I said, I'm just trying to respond to the topic of the forum.

thx,
Dave S.

#6 /off topic
Dave, this is the second time you've mentioned $200. Where do you get that figure from? TGB is $100, or $80 if you already own TGE.
/on topic

#7 It took me 3 emails to GarageGames to discover how to purchase for the prices you mentioned. And "~" is mathematical (and other) shorthand for "approximately". To a lot of people $180 is approximately $200. Also, if you aren't tenacious about emailing and take the path of least resistance, you'll drop "exactly" $200. One hundred for each (TGE/TGB)

And, you're right, it is off topic, but how/what/when/where to purchase torque is rather nebulous (at least to dummies like me!;). In the final analysis, yes, you don't _have_ to buy TGE to use TGB, but look at all the references to it!:-( I'm often seeing "see TGE documentation for a further explanation". And, since you cannot get _any_ kind of support/documentation/access without purchasing, and, if you are a newbie and want to see how things work and how to get the most out of it, yes, you have to purchase both! And, that's "approximately" ~$200.

I know I'm stupid, but, if I'm an average user coming to GarageGames because of the advertised "write games without _any_ code!", I'm pretty well stuck with "hey, buy these 2 if you want access to us and our user community to see how it works and how to use it!"

I admit, my background is mostly C/UNIX in telecommunications, so I'm pretty dumb (ignorant, stupid, head up my...) about graphics and games, but I don't believe I'm alone and I do think GarageGames _is_ trying to widen its user base beyond the aficionados. And us ignoramuses need all the help we can get! So, the TGE/TGB bundle is kinda a must for dummies trying to get a handle on gaming software.

rant over!;)

So, anyway, improving the product to make it more worth the ~$200 is right on topic!;)

thx,
Bye,
Dave S.

#8 Very good feedback items, we'll be adding them to our workflow and usability review passes!

Quote:
I know I'm stupid, but, if I'm an average user coming to GarageGames because of the advertised "write games without _any_ code!",

Can you show me a link where this is advertised like that?

Thanks!

#9 Okay, "_any_" was an exaggeration. I should have said minimal and no previous programming language needed. Since everything can be done within the builder and/or Torque Script, you don't really have to have "_any_" previous code knowledge (altho' it helps, and thank you, I do have prior experience!;)

What I searched for on the web was 2d game graphics packages that generated games without, necessarily, requiring previous coding knowledge. The idea being you could concentrate on the game instead of code. GarageGames' TGB was one that came up in the search.

So far, I'm "satisfied" with it, although I don't believe it's a finished product (are there any of those?), but then, it does say "beta" (but beta usually doesn't have a price tag!;)

Things I'd like to see in a "finished" product are:

1. Complete conformance to UI standards of the platform it's sold for (i.e., max/min/close/resize and other UI niceties)

2. No documentation of the type "oh, btw, you needed to copy these files before you did this". And distributed documentation that matches the code. No, "oh, well to get the latest that actually matches what you've got, you've got to go to this website..." If you sell a package, make sure its documentation matches. It's what used to be called when I was actively in the business, a "code freeze". For something as pricey as this is and something that even has a purchase price, it's a bit too "bleeding edge" to be credible.

3. Complete access to all generated code in one easy to find, easy to follow location. The code seems to reflect the fact that it's built by different folks at different times. This could be avoided by using what used to be called when I was active "coding and development environment standards". That way, when all the pieces are put together, it's a bit less "crazy quilt".

4. A more automated development cycle. Not so much "okay, move this here, rename that, delete this, overwrite that...".

I think it's a dynamite brain-stormed idea, but can we calm down the storm a bit when distribution time comes?

thx,
Dave S.

#10 Dave,

Don't worry, I didn't take your post as rude. I was just trying to help by giving you ways now that can help solve some of your issues. That's of course not to say that these things shouldn't be improved upon to make the new user experience better. And yes, I guess I am an "old timer" now having played around with TGB for over a year in it's various early adopter forms. I did buy the product without any programming experience whatsoever though, so I'd like to think GarageGames isn't totally off in marketing their product. (Although to be fair, the level builder is only a couple months old, before that nearly everything had to be done in script. So that's one way to be forced to learn it. ;)

Back to your comments:

For recompiling script to get changes to take effect - I'm used to the quit and restart so it's not a huge deal for me. But perhaps a new default function in game.cs where other custom made script files are initializedfrom can be made. Then in the project menu, a "Compile all scripts" selection which calls that function.

For the console - you're right, newer tutorials don't mention anything about it. I probably learned about it from one of the older, script only, tutorials. It's something that should be added to new user tutorials as a way to check if any script code you type is wrong. The only other issue is that the level builder spits out non critical errors from time to time which might confuse beginners.

Regarding documentation - could you give specific examples where this "oh, btw" stuff is? If it's on TDN, myself or someone else from the communtiy can probably fix that up if it's a big issue. And for the final release you can be sure that the distributed documentation will match the game engine. Right now, part of early adopter is simply accepting the fact that the documentation lags a bit behind the latest builds. This is a direct result of a community request, we wanted to get our hands on the latest builds as soon as possible. :)

Code locations - technically there shouldn't be a need to look at that in script, especially for beginners. Unless there is some bug in the level builder itself, the code the level builder generates is correct. It's simply a matter of using the scripting or dynamic fields rollouts to hook level builder generated stuff into your custom scripts. As for the folder layout itself, what is non-intutive about it?

As for the price, I guess everyone is going to have different viewpoints on that. :) Considering most people have no problem paying 50-60 dollars for a finished game, 100 for a game engine that you can make your own games with is a really good deal. And yes, you are paying for an unfinished product, but you need to look at it from the viewpoint that you are paying for early access to give yourself a headstart in either professional or hobby game making.

#11

Quote:5. "... through the console... " ??? What console? I see it when I press the backtick key (left of '1') but how does one know about this feature?

That has been a "standard" feature in (mostly FPS) games for years. Thus, given that TGB's descended from TGE I would have thought it was a fairly obvious feature to anyone who's cheated in PC games in the last few years. In fact, when I got TGE it was one of the first things I looked for the very first time I ran it.

As far as docs go, pretty much everyone takes the console for granted and thus it's easily overlooked.

T.

#12 Yes, I think we're both on the same page;)

As an example of a "btw" instruction. They usually start with:

Important Step - Go back to the games folder

And frequently, it's after you've been told to do something already. One in particular I can think of is when the tutorial said to copy all your images (that right there is onerous. If they need copying, why aren't they just distributed that way?) then import. It give a list of images to import. Then, after you're all done the next step (a paragraph or 2 down) is of the "Important Step..." variety that says to btw change from "Full" to "Cell" on some of them... oops!:-( If they're different, they should be listed separately and/or the instruction should come before, not after the instruct to import.

I must admit, tho', that after getting bitten a couple of times, I've come to tutorialize defensively... I skim ahead to make sure there isn't a "btw" instruction. However, in the interest of a good product with good documentation, it should be changed so that this defensive maneuvering isn't necessary.

I guess you can just chalk me up to not too bright and ornery enough to complain about it.

thx,
Dave S.

#13 Quote:

--------------------------------------------------------------------------------
5. "... through the console... " ??? What console? I see it when I press the backtick key (left of '1') but how does one know about this feature?
--------------------------------------------------------------------------------



That has been a "standard" feature in (mostly FPS) games for years. Thus, given that TGB's descended from TGE I would have thought it was a fairly obvious feature to anyone who's cheated in PC games in the last few years. In fact, when I got TGE it was one of the first things I looked for the very first time I ran it.

As far as docs go, pretty much everyone takes the console for granted and thus it's easily overlooked.

T.


***************************

Just my point. These things may be obvious to "aficionados" but to us more casual folks (a market GarageGames seems to be aiming at) this kind of "insider" knowledge about things that have been defacto undocumented standards doesn't quit cut it. Like I've been saying, a dummy like me needs all the help he can get. And it should be noted that many newbies will be among the uninitiated and deserve a break.

Lots of things are "standard" in lots of areas in computers. That doesn't keep the software suppliers from assuming that everyone is totally ignorant of all these things and informing them over and over again of these "obvious" points. "F1" has been "Help" almost since day one, but that doesn't mean that software suppliers (including opsys suppliers) leave this information out of their documentation. Believe it or not, there are some people out there that don't know that this is the convention. Some are even accomplished programmers who assign other functions to "F1"...:-O

I'm a firm believer in the adage: " 'Assume' makes an 'ass' of 'u' and 'me'..." So, I try never to assume because I don't like being an ass nor do I like making one of others...;)

I do understand where you're coming from, tho'. Long time users of any system frequently become impatient with newbies. It's just human nature (for them both).

thx,
Dave S.

#14

Quote:
Now that you know how to import images, repeat this process to import the rest of the images we will need for this tutorial: bg_blank_sky, bg_cloud_1, bg_cloud_2, bg_cloud_3a, bg_cloud_3b, enemyMissile, enemyShip1, particles1, particles2, particles3, particles5, particles6, and playerMissile.

One thing to note, when you import your particles into the level, change their Image Mode to Cell.

Ok, I understand. If I read the first paragraph there and stopped reading, I would import the particles wrong. I guess I also "read ahead" so it was never a problem for me. Usually I read an entire section of a tutorial first, then go back and actually do it. But not everyone is like me, so you do have a valid criticism. :)

As for:

Quote:
Important Step - Go back to the games folder. Now go to the spacescroller/data/images folder, and copy everything in there (a bunch of pictures) over to our yourProjectName/data/images folder....

This comes before trying to load any images in the level builder. But if I understand you correctly you would like the images to already be there, thus saving the tutorial reader the hassle of doing it?

Two things. The empty game template is always going to give you a blank slate. So a shooter template could be added or there is a Resources utility (Project Menu>Resources) now available (as of beta 3) which easily pre-loads art assets into the level builder. It would no doubt be better for a beginner to simply do that as it only takes a few clicks.

Another point of view is that when you finally get around to making your own game and have unique art assets, you are going to have to learn to copy your art into the correct folder and import it one by one into the level builder. So why not learn about it from the start?

Anyway, good discussion so far.

#15 @Dave,

Quote:Just my point. These things may be obvious to "aficionados" but to us more casual folks (a market GarageGames seems to be aiming at) this kind of "insider" knowledge about things that have been defacto undocumented standards doesn't quit cut it. Like I've been saying, a dummy like me needs all the help he can get. And it should be noted that many newbies will be among the uninitiated and deserve a break.

Either you completely missed my point or you hit it spot on, I'm not sure which :)

Quote:I do understand where you're coming from, tho'. Long time users of any system frequently become impatient with newbies. It's just human nature (for them both).

Although that's totally accurate, it's not what's going on here nor what I was getting at. I was just pointing out why it might have gotten overlooked in the docs. I am fairly sure that the console is mentioned in them in places, but that may be in passing as assumed knowledge. It could be that you came across it before and assumed it meant the console.log - which would be correct, but as you now know is only half the story.

In general, I have found that the TGB docs and tutorials hold the hand of the inexperienced reader so much that for someone like me, out of a 10 page tutorial maybe only 1 paragraph is relevant. OK so maybe that's an exaggeration, but my point is that they hand-hold so much that it gets in the way if you are an experienced programmer familiar with TGE. There's nothing wrong with that, of course. As you said, GG seem to be aiming at the casual market, and besides, experienced programmers have other ways of finding out what they need to know ;-)

T.

#16 I hear you. However, for me, it's not that it's overly hand-holding, but overly chatty!;) It's nice to try to be personable and friendly, but it goes a bit overboard, imho. And actually "imho" is the kind of thing I'm talking about... You don't know how long I labored in the dark before I learned that 'imho' is "In My Humble Opinion" [tho' usually not so humble!;)] Not to mention how long I spent wondering why so many of my coworkers were putting colon-right-paren at the end of their interoffice email! And I was in the thick of the internet (pre-WWW days) in telecommunications. So, I was no uninitiated newbie, just ignorant. Now I know about smileys and abbreviations and acronyms. The benefit thereof, having the knowledge that is, is somewhat dubious.

Anyway, the point is, especially in tutorials, explain to a fault. Let the overly knowledgeable deal with it for the sake of the overly ignorant!;) But don't include too much convivial dross, its overbearing and burdensome to both the knowledgeable and those who become lost in the friendly chatter trying to find the relevant thread of knowledge. Unlike me, a tutorial should say what it means, completely and in detail, and come to the point as quickly as possilbe. No mean task. That's why so many programmers/designers/implementers despise the documentation portion of their job!;)

'Nuf said... tah...
Dave S.

#17 I agree with you about the tutorials being overly chatty. The problem with those tutorials are they're not written by professional writers, rather well meaning individuals. It would be nice if someone with some professional writing experience could go over them and tidy them up, but I think on the whole it's better they're chatty then non-existent.

T.

#18 Dave, great feedback. Thanks.

So you know, we have all of the same issues you brought up on our big to-do list for TGB as well. :) It's good to know we're not off in the weeds on what we think we need to do from here.

However, we won't be able to get all of these issues cleared out before release. For example, reloading scripts at run-time in a guaranteed safe and well-behaved manner is a deep architectural issue with the Torque application core itself, and we won't have time to do a pass on this before our official release. Likewise for some of the platform issues you brought up.

These are excellent concerns, and they are high on our priority lists. We will forge ahead on them as soon as possible after release.

We will be addressing the documentation issues as best we can before release, however. We haven't kept the documentation up to date with the beta releases of TGB 1.1, because it would've been an insane amount of overhead to update them all for every interstitial update release we've done to TGB. This is the cost of having lots of docs. :)

Now that we're pushing toward the official 1.1 release though, we have been focusing on docs primarily for the past 3 weeks, and will continue to do so for the coming weeks until release. We've made great progress so far, and believe me when I say that we will not ship without clearing up the documentation issues you've mentioned so far, or cutting the docs that don't make the grade (and adding them back in in a later release, once they are fixed up).

Thanks again Dave. I hope its nice to know at least that we *totally* agree with your comments, and are going to get to them as quickly as we can. There's lots of other stuff we feel we want to improve as well, so it's a constant balancing act. But once the docs are all in ship shape, I think TGB 1.1 will have surpassed any goals we had for it early on, and hopefully any customer expectations we are reasonably setting for it.

#19 ...

7. Save and Quit (a single choice) under File in the menu.

...

#20 ...

8. Allow access to files anywhere on the local disk instead of just the current TGB sub-hierarchy. Moving, copying files from here and there gets quite tedious. Understood that all files need to be in the subhierarchy for packaging purposes, but couldn't that be postponed until actual packaging? At that time, resolve which files are not in the local sub-hierarchy and import them as the user requests. Up until then, why not just allow using files that reside anywhere. This would avoid large development areas which eat up disk space.

A possible mechanism would be to use soft links (.lnk on Windows, symbolic links on UNIX) during development, then, upon packaging, copy any soft links that still exist (possibly by user approval mechanism) to the local area and effect the package. This could also be used for any local files copied by the level builder.

There's an old dp ("data processing") adage "Thou shalt not duplicate thy data".

I understand that duplication is quick and dirty and easy to implement, but it's also quite wasteful and a maintenance headache for you customers.

...