How create my own app ?

#1 1) What do you mean by "normal application"?
2) Also, there are many docs, manuals, tutorials, resources, and forums about this process--spend some time reading before posting.
3) What do you mean by "normal way to integrate with user data"?
4) See 2)

#2 As I say we spend one day with exploring code and forums and docs, and did not find manual about how to create application form very beginning.

Tutorial shows only how to use functionality in prepared workspace, and we need doc about preparing this workspace.

#3 .

#4 The closest thing is the minapp tutorials. But they only cover creating your scripts from scratch, using the pre-compiled executable.

But, seriously, Torque is a complex beast. A very complex one. It would NOT be simple to write a tutorial that teachs you how to re-create the Demo app from scratch, using only the basic generic classes provided with the engine.

The Torque SDK avaliable for download is actually a demo game made with Torque. There is no bare-bones version. While a bare-bones version would be very interesting, it would be frustating to 90% of the license owners, since it would take a long time to get a player running around the screen. Not to mention the massive amount of extra documentation required. If you to remember how much you paid for the Torque SDK, then I think you'd figure out this logic does make sense.

Our company is in the middle of our first Torque game, and maybe I can share some things.

I strongly advice you NOT doing the next be-all-end-everything game straight into Torque in the first try, specially if that game differs too much, in features, from the current Torque, and if your team/company isn't experienced enough in working with radically different technologies.

Our company has many big games in our schedule, but in order to learn Torque and gain enough experience to build our games without any surprises and major mid-project researchs we are building a small budget game, taking in account Torque's features. We planned the game to be done with as little modifications as possible, but with enough changes so we could get to learn about the engine's many subsystems.

We're also not removing any features for this project. This keeps us from unintentionally breaking the engine during devlopment. We're just adding things were we need them, with heavy comments so we can easily locate (and maybe undo, if needed) all changes we did to the engine.

We also checked all avaliable resources on the site before staring the project, so we could check which ones could save us some time.

In our next project, we'll make heavier chances, actually remove unused features, and maybe rewrite some specifics for our needs (like the Player and AiPlayer classes) anew, using the existing ones only as usefull reference.

But you're right when you say that there should be some extra documentation explaining the demo app, since some classes and features in there *are* supposed to be just that: demo features. It's hard at first to figure out what's essential to the core engine, and what's demo-specific source (I think the player and vehicle classes fit into the demo-specific content, even if they are awesome examples on how to handle such things).

#5 If I ever get some extra free time, I'll try building something simple from scratch (like a 3D pac-man or tetris), removing all demo-specific stuff, and make a tutorial out of it. It's such an undertaking (writing the tutorial, that is), so I have no idea when I can do such thing.

#6 .

#7 What's the point of removing what is already built?

#8 .

#9 I understand your point but it does not relate to the engine. It relates to how you wish to learn the engine. Those are two different things.

Any modern professional AAA quality game engine works this way. You get a pile of source and a single monolithic game (torque test app, quake 3, doom 3, unreal, etc...) to see how it all fits together.

Some people prefer to learn by building somethign "bottom up" or "from scratch". Nothing wrong with that. This is not the preferred method when dealing with a game engine. The method there is start with something that works...and modify it to what you want. This is the approach I have taken in both learning the game engine and working with it.

I have had great success with this method...but then I also have years of experience dealing with large code bases that I did not write.

Good luck in your journey to learn Torque! Indie game dev rocks!

#10 I highly recommend getting the Game 3D Programming All-In-One book as it has ground-up examples that build up from a simple "hello world" print statement to having a character running around world terrain. This book will save you alot of time.

I just bought Torque a week ago and was confused about how to go about creating an app but this book explains it pretty well. The version of Torque that comes with the book has some differing folder names but I believe that if you study from the book's version of torque you'll understand how to create/modify projects with the commercial version.

#11 Torque is a hard beast to strip down. For sure we could ship a version that was very very bare bones, but that would leave out a LOT on how you might implement a working FPS. A lot of the code in the starter.fps had its genesis with Tribes 1 and 2, both AAA, technologically ground-breaking game titles. It's an INCREDIBLY valuable resource, with a lot of hard-learned lessons in it.

There are some resources out there that show you how you can run Torque in a stripped down mode, but it's much much more valuable to understand the entirety of what is there rather than the simple situations a little toy demo application might show off. Starter.fps isn't very polished but it is industrial strength.

It's like getting a jet fighter in the mail, and immediately ripping out all the fancy flight control electronics, jet engines, etc, and fitting it with a propeller, so that you "understand the basics." Sure, you'll learn a lot, but you'd have gotten a lot further by reading the manual and using it as it was meant to be used...

We have, are, and will continue to put a lot of work into making Torque easy to use. Don't read this as being hostile towards people that like to learn things from a simple starting point or via ground-up examples - we have things in the works that will definitely appeal to those types of people. But at the same time, Torque is complex, because it solves extremely complex problems. It is appropriate that it takes more than a day to learn. In the right situations, I think it is completely reasonable for people to do some neat things with it quickly - but to really master Torque takes months and years, not days and hours.

I have several man-years of Torque experience, and I'm still learning new things about it. Even when we have the very best possible documentation and examples set up on an easy to navigate website with helpful hints and powerful searching, it's still going to take a significant amount of time for people to master the engine. You don't have to master the engine to start creating cool games with it, but it helps if you want to finish them. :)

#12 .

#13 I concur with the sentiment expressed here.
As torque is meant to be - sold as - a SDK it should be possible, in if not encouraged, to compile it without ANY of the demo or console code from the ground up.
Although the indie licence states that you have to include the garagegames logo and credit, it should still be possible to compile without such references. There executable should be able to be named anything the developer wants. INDIE does NOT mean chained to a proprietory brand such as the DEMO app. There must be someonr amongst those of use who have purchased this software as a SDK who has successfully managed to strip out the non essential.

It should also be possible to compile custom documentation into a distribution platform for the finished product. this also seems to be very awkward to integrate to a porper level.

#14 @Thc:

3DGPAI1 uses a pretty standard version of Torque. Anything you learn from the book is going to be directly applicable to the version you can download from the site.

The whole point of Torque is to make it so you don't need to know how to start a totally new project from scratch. As part of my duties as the Torque Technologies Director, I inspect the source code behind a lot of the shipped Torque games, looking for fixes and improvements that can go into the mainline version. No one starts from scratch. Not in any of the current generation of shipped games, not in any of the last generation of shipped games, not even in the generation before that. Some of those codebases are pretty heavily modified from "stock" Torque, but they all have a clear and direct lineage to what was the stock Torque code of the time. If you want to have something where you can start from absolutely nothing and slowly build up, you might want to look elsewhere. Torque is all about giving you maximum power and flexibility to build your game, and it's been proven over and over again that that is something it does extremely well.

@Edward:

You surely can do this. You have to spend about a day ripping things out, at which point you end up with a binary that can't do anything. :) There are several lightweight Torques out there - check the resources - which let you do this from various perspectives.

You don't have to compile it with the logo or credit. The license says that you must distribute your PRODUCT with such references. If you have a build you want to use for internal learning or testing or what have you, not for public distribution, you're welcome to treat it however you like. If you're making a resource for the community, and it doesn't even have a GUI because it's simple, then you're also probably exempt. All we want is to have a tiny bit of credit for having provided you with useful technology. Stick a little blurb in your about box! I think that for the value we provide, this is a very, very reasonable request. If you look at most commercial games, you'll find a significant collection of little icons for different middlewares they've used - and mosts of those middlewares are demanding per-platform fees and revenue sharing.

You can name the executable anything you want, and I would encourage you to do so. The Lore executable is named Lore.exe, as I recall, and the ThinkTanks exe is named ttanks.exe or something similar. Tribes2 had an executable named tribes2.exe. It usually makes sense to have the binary's name reflect the name of your product.

We do not force you to tie your brand to us (except for a small mention somewhere in your game), we don't require you to look like anything, we don't restrict the content in your game, and we don't require you to distribute with us (and in fact, we even turn people down if their game isn't up to snuff).

I don't understand what "It should also be possible to compile custom documentation into a distribution platform for the finished product. this also seems to be very awkward to integrate to a porper level." means. It seems like this is something you'd want to do if you were redistributing the source code?

Just to be clear - when I refer to the demo code, I mean everything in engine/game, and in example/common, as well as the various mods that build on those bodies of code.

#15 .

#16 Did you try using echo instead of printf? It might be that 3dgpai1 has a little bit of helper script they use. Those other functions are part of the mission loading framework in the demo app - pretty useful if you want to have a networked game. Somewhere Ken ought to describe any changes he made to the binary.

No, I don't believe it's a splashscreen. Have you read the EULA? It explains this in some detail.

#17 .

#18 I guess my point is that the mods Ken did should be very minor, and not affect your ability to quickly move code back and forth from stock Torque to his version and back...

Thanks for citing the license. There you are, do that in your game. Obviously that only applies to publicly released things; if you're doing internal testing or development, don't worry about us suing you. :)

#19 .

#20 To any people who read this and are angry because they feel they are "tied" to an FPS using TGE, please consider what exactly an engine does :

-It renders a 3D scene, given the viewers camera. This includes handling 3D and 2D rendering, animated models, and these days, for outdoors scenes, often height maps. It is responsible for culling unseen geometry, using some or other scheme.

-It handles input from the user, mapping it to function calls/ state changes in the engine.

-It handles time based functions, processing events every "tick"

-It handles sound.

-It handles loading and managing resources, such as textures and meshes.

-It handles collision between objects, mostly using bounding objects (such as boxes). And physics.

-It generally has some type of scripting system.

(I've no doubt missed some points, but you get the idea)

These are all common tasks which are performed in almost EVERY game, irrespective of game type or setting. The warcraft engine does this. The morrowind engine does this. Mario brothers engine does this. Resident evil engine does this. etc

What does the demo FPS do?

Everything I mentioned above, plus some scripting to map player movement to the model, position the camera out his eyes, and create a projectile when you click the mouse. Also a little bit of game logic that keeps score ( and loads a stage). This is a relatively thin layer that is quite easy to modify. TGE is just a general ... simulation engine, thats the best term I can think of. A small bit of code turns it into an FPS (and its small just because FPS rules are incredibly simple, not because Torque is an "FPS" engine). All an FPS is is a few assumptions about camera position, input-player model mapping, and a scoring system. People seem to get the idea that because you're advised to modify the demo app, you're forced to "hack" an FPS to get your non-FPS idea working. This isn't the case. The demo just shows you the best place to insert your code to get YOUR type of gameplay. Its really just your game logic code that will make your game look like one of a certain genre.

I think thats why the GG guys get tired of hearing every Noob wanting to tear all the demo script out and start again from scratch. This game your making, its going to have stages right? Its going to load them right? Its going to perform actions when you click the mouse/press a key right? World objects are going to interact right? Probably gonna be some animations happening? You're more than likely going to want to edit your stage right? Play sounds? Trigger some events when the player does something maybe?

Why do all that work, when its already been done for you? Don't be so quick to dismiss the Demo app guys, please.