Plan for Ben Garney

#1 Oh yeah - I forgot. The console UI is better, there's a nice console error tracker at the bottom of it, and the GuiInspector control has been totally revamped and MUCH improved. Also a couple of new GUI controls for building GUIs with.

And a neat object field update tracking value!

Anyway, it seems to build and run fine with VC7. Just a matter of updating makefiles for the other platforms and we're set. Please post your updated makefiles if you get to it before we do. :)

#2 You finally tell me about your little project! I wonder where you got the name from, it seems so original, :).

SO, when can we see the Torque Developer Network?

http://www.garagegames.com/mg/forums/result.thread.php?qt=26844 (Private SDK)

#3 When it's done! (TM)

Maybe when I get back from my vacation I'll have a screenshot or something to show off.

#4 @Ben:
Your GGs own John Carmack, :)

EDIT: Time to set up my CVS client, hehe.
EDIT2: Checked out! Time to attempt to compile with no changes.
EDIT3: Well, seems VC6 files don't work, time to fix em!

#5

Quote:I think there are still some improvements left in it, but it's getting closer to a point where we can release it without being ashamed of ourselves.

Oh, get over it. You know everyone here will worship you for releasing the terrain weither its a bit flawed currently or not. :P

#6 Robert, just relink the files of the /gui dir. They are now in subdir. And also link the files that are missing and it will compile in VC6.

#7 Woohoo!

Note: I'll be checking in the OS X changes for the 1.4 release next week.

Have a great trip Ben and good work pushing so hard to get this thing out to people before you leave. :)

#8 Mmmmm, new Torque.

#9 What I did to get the VC6 project to work:
-- /gui is now subdirectories
-- Add the new location of frameAllocator.cc|.h of /core/frameAllocator.cc|h
-- Add badWordFilter.cc|.h of /game/badWordFilter.cc|.h
-- Add gDynamicTexture.cc|.h of /dgl/gDynamicTexture.cc|.h

I think that is all I did, :).

I will upload the project file (torque demo.dsp) onto my webspace incase I forgot something (This isn't against the license because no source is released, right? If it is, I am very sorry).

http://uberrealgames.com/Torque Demo.dsp

Robert

EDIT: I just saw Gilles post about the /gui folder, hehe

#10 Glad your taking a vacation Ben! You definately deserve it... wanted to shake your hand at GDC (respect the work yoru doing) but each time you were swamped by multiple people who were gawking in awe at your terrain ! ... can't wait for 1.4 ( might sneak in some time and give my first non-official build a try ) ... the TDN sounds amazing! I really am looking forward to this and I'm sure it will help the new (and old) users of Torque (any of em) a whole lot!

Quote:
much to my delight, offering to improve them themselves.

count me in on that list.



btw amazing terrain already, even more tweak and optimized will be even more gorgeous, it is really impressive where Torque is going (from 2D to 1.4 to TSE)

#11 although it would be nice if the terrain was released now for people to try out a bit so we wouldn't have to wait extra long and dyin with anticipation. ;)

#12 Have a great trip man and get some well-earned relaxation time in!

#13 Thanks for the update Ben! Downloading HEAD now from the Garage...
Have a great time on your vacation!

Nick

#14 That terrain is just . . . freaking . . . wow.

I am definitely interested in hearing info about how (approximately) the new terrain, new water and vegetation fx all trade off against each other, performance-wise.

Also, forgive my ignorance of this, but are waterblocks generally occluded by terrain the same way that other objects are in Torque? (even 'infinite' waterblocks). Or would that actually be more of a performance hit than a gain . . .

Because from a mapper's pov, if that water is a noticeable performance hit, it'd be nice to be able to hide the water most of the time by sinking it down in canyons, etc, and then use higher-detail terrain as the water is occluded most of the time (and most of the terrain would be occluded when the water is visible to the player, as they'd be below the level of most of the terrain and their viewable distance could be restricted.

Until now it's been sort of difficult to squeeze, for instance, a really long sequential map into one Torque terrain, but that seems to be so far beyond "thing of the past" that most people will probably have no idea what to do with all of this extra capability. Where the hell do you get enough content to fill a 20k square map?!?

(I guess you generate its placement dynamically . . . hehehe . . . geez this is so cool).

#15 Just like TGE, water really doesn't matter in terms of its actual size. It's just how muh water is visible in the scene. Doing advanced occluding usually isn't a big deal, as modern water is very pixel bound. :)

Good question for the content issue. I'm interested to see how people handle that myself. Of course, we're working on some stuff at GG, but it's all hush hush. ;)

#16 I can't speak for any other projects, but when one of your primary game mechanics is control of territory in a MMOG, lots of empty terrain for players to occupy is quite important!

#17 Ooh, you sneaky devil.

I assume you're talking about things like boulders and trees? That kind of thing seems a much better fit for random geometry creation.

I will say that, holy crap, you guys would have a MASSIVE foot up on other engines if you came out with something that was basically melv's fx stuff on steroids -- a way to manage creation/placement of dynamic content that allows the coders to plug in and create their own content generators, swap out algorithms for choosing placement and methods of determining seed and methods of synching w/server

Yes, I'm mostly talking out of my ass here, heh; I don't know that much and/or have that much to contribute to these kinds of high-level discussions, so all I can contribute is awed gawking. I'm still learning so much about hacking in general, check out one of my old plans for instance -- I said there, in 2001, that it would probably be 5-10 years before I'd be able to really start making ideas practical, and so far it's just starting to be true -- for instance, I recently did some scripting for BlockLand that let me write generators for shapes by addition/subtraction of basic 3D solids; I think I used a clever/elegant/inefficient method heh, basically set up a generic "draw-point-and-return-to-center-coordinate" function, and then just a bunch of functions that test for collision within an arbitrary implicit sphere/cube/pyramid, and then the single drawing function would accept a stacked set of additions/subtractions and finally only attempt to lay down the blocks, bottom-up, that pass all of the hit tests, so with something like 3 drawing functions and a set of functions to test for collision within an implicit/explicit shape, I could do boolean operations on arbitrary geometric solids for automatic construction scripts in BlockLand . . . once again . . . it has to be a pointless waste or I don't feel like I'm learning anything . . .

And I'm torn because I'm at a point right now, working with a small enough company, where I can actually code "for fun" and make money at it, without doing it for games; I have only 1 other person to work with, the person who owns the business, and he and I are going over all kinds of take-over-the-world projects that we can do, just having a blast -- so right now most of what I'm learning and have been learning has NOT been of the type that would benefit hardcore limits-pushing game development, but more the type that might benefit, say, a really pragmatic attempt to use the Torque engine as a really low-cost way to accomplish simulation-type requirements in an application. Games in general seem to be constructed as specialty applications, and the emphasis on reusability/modularity/abstraction is mostly assumed to be the responsibility of the engine, whereas in most (err, I should say 'most well-written') commercial software, the goal is a lot more the creation of well-abstracted frameworks for working in a problem domain, and an absolutely minimal codebase for dealing SPECIFICALLY with the client problem the application is built to solve. (Or at least that's how we, as contract software guys, tend to approach it -- we want to make code that mostly addresses a CLASS of problems, so that when we move on to the next job, we may only have to write a few hundred lines of code and tweak the UI to have a finished product).

And in most of my free time, I'm studying languages and techniques that, aside from Python, don't seem to have a lot of direct applicability to anything other than, I guess, AI -- but really, Lisp is mostly a language created for doing things as elegantly as possible, bottom-up, and obviously no one would seriously put forward the idea of doing a game engine in Lisp, even though it should be possible to do one that works about 70% as speedily, just because of the enormous amount of work involved, both in starting from scratch and in being unable to reuse almost anything except bare algorithms, because the nature of a truly Lispy game-engine would make it completely unlike anything that came before it.

So if I keep on learning Lisp, while it will strengthen my skills in the "pure applications development" part of developing innovative web apps, I have to accept that about the only thing I should consider using it for in Torque will be, perhaps initially, to help manage AI.

I will say that I believe Jax&Daxter uses Lisp to manage not only its AI but its dynamic content and object properties, as well as tools for character animation etc, and they've had enormous success (and everyone on their team apparently loves it since it makes creating game objects much easier), but again that's not the kind of thing I'll be able to consider doing in Torque unless I undstand Torque as well a any of the GG guys -- in other words, forget it.

Short-term, I don't know that I'll be able to mess around with TGE as much as I'd love to, but I think it would be fun for some side-projects to at least try to do some basic call-outs to Lisp from TorqueScript, and see if (for instance) I could put together a simple Eliza for talking to bots, etc . . . maybe that would be a good starting point . . .

Egads. How the hell did I get started on this from talking about Terrain? It's Sunday and I just woke up, I guess . . . and what a glorious bloody day it is! Excuse the ramblings of a newbie, GG, but this is one of the few places where I still feel it's ok -- nay, a duty -- to think about castles in the sky . . . . :D

#18 @Luc: Yes, I do think that when you have the ability to use this type of terrain size (basically unlimited), you really need to focus on procedural generation for a lot of things--not just the terrain itself, but the geographical features (such as mineral resources, soil type, water tables, climate, etc.) as well.

If you take the presence of absolutely huge terrain as if it were simply that much more area level designers need to edit to create all content from scratch, then I think that you are setting yourself up for a long road. But if it's simply "uncharted virigin territory" for your players to explore, and then build upon (as well as NPC's, never forget them!), instead of having to hand craft every single portion of content you provide to the players, you are just giving them a very large stage for development at their discretion.

Think of the Civilization games here, and how resources were randomly generated each game, but consistent to internal generation rules based on the terrain geography. Obviously it's more complex in 3-D, but that's a benefit, not a disadvantage in my book!

#19 Hi there, I've just finished hacking up a patch to fix the Linux build process.

There are also three images that need to be replaced with the versions from TGE 1.3 as they're corrupt for some reason and result in PNG CRC errors which prevent the demo missions from loading.

example/demo/data/environment/lightning1frame1.png
example/demo/data/environment/lightning1frame2.png
example/demo/data/environment/lightning1frame3.png


I'm really looking forward merging my codebase with this when it is finally released. Cheers on some great work, the demo looks great!

#20 Are the console and gui changes going to be merged into T2D and TSE?