As a beginner, what is your biggest hurdle so far?

#21 Finding an artist willing to undertake the project, that artsy fartsy stuff is just beyond me for some reason...

What's really odd is I come from an art background, it's in my blood and most of my relatives have Art actually
hanging in museums, sculptures citing in front of city libraries, music published, or films they have acted in, but couldn't run a computer to save their lives :)

#22 Time, or lack of it. Thats my biggest issue. It takes me awhile to get into coding mode when I sit down at the pc, and having only a few hours a week to work doesnt help.

The other major issue has to do with figuring out what torque can't do. Or doesn't do very well. And then either deciding not to use that feature, or find a way to implement it. So far the only real problems we had to either work around or really dig in to fix were vehicle collisions and vertex buffers. So far so good tho!

#23 I'd say that my absolute biggest hurdle isn't motivation, time (though this is a bit of a problem), being overwhelmed by the engine, or any of that stuff.

My problem is that I have so many things I want to do, I can't friggin' figure out which one to start with.

#24 Motivation in general, and BattleField 2 in specific.

#25 I have developed quite a few games and also worked on other stuff, so I'm experienced in C++ and the development process. What I'm missing most is an easy and orderly entry point. I have the feeling most tutorials and helps are assuming they have to help a newbie getting into modifying a preset emtpy world to their liking. But I am used to a systematic approach.

I would like to know how to startup the system from my C++ program, how to program a mainloop, which important init functions do what and what can I modify to make it work the way I need it. A Hello World approach would be nice. I dont care so much about terrain editor or whatnot at this stage. I want to compile a simple program and start from there.

I have ordered this 3D programing book thats praised so much and hope that this will help me find this approach.

#26

Quote:
I would like to know how to startup the system from my C++ program, how to program a mainloop

Torque is a game engine not a library. You don't use it in this way...ever.

#27 The artistic pipeline... definately. It's unbelievably difficult to do something as simple as model and insert a drivable car into Torque (Assuming that one has never done it before).

It would be great if one could simplify the exporting process.

I even tried opening player.max and re-exporting it (Not touching a thing). I got it into TGE, but the mount points were screwed up and some of the faces were backwards. None of the animations played, either.

#28 My biggest hurdle is having a problem with my debugger, for some reason no one in this whole Earth has the same problem and I cant fix it. Whats the next step? Buy a new PC and hope it wasent my Copy of windows been scratched. Works in Linux. Acually Ill wait untill Longhorn comes out when I build my new system, and then I should be able to Debug.

NOTE: Seriosly what I mean is that problems sometime happen and money is the only way to fix it. Meaning im going to have to pay over 2k just to fix my problem. Im pretty sure this counts as a hurdle to a begginer.

#29

Quote:Are you unable to find the docs? are the docs not organized well enough?

Damn right!.. I have been working on this for AGES now.. and I still dont get where things are on this site.. Where ARE the docs? Look in the menus to the side NOW.. is there a sensible link to them? Nope.. no FIRST you have to click on Torque Game Engine, then look for a link on this page.. Yes, its not in the menu on this page either.. and THEN to the main menu of the docs... frankly thats crap... there is NO need to use mor than 2 clicks to get ANYWHERE on a site if it arranged ok...

But mostly the main thing I've had (am having) problems with is that I still dont undertand the "structure" of TGE. What are the files FOR... sometimes (to me anyway- - cos I dont know any better) It looks like code is strewn about the place.. a line here in blah.cs and line here in doobie.cs etc.. I want a "Site Map", some doc that says:
main.cs ------ here is where you put code for dum di dum...
player.cs ---- here is where you put code for dum di dum...

For example: Where EXACTLY should I put code for NPC's? Now I have implemented a few resources pertaining to NPC's, I have gotten a few of the little buggers into my game... but EACH ONE IS DONE DIFFERENTLY!!! One is in the Resources added file, one has been pasted into AIPlayer, (or is that the original Kork Orc? If so.. Garage Games put him there.. so is THAT the right place to launch him? But should I use this file for launchin ALL NPC's)

Now I ve been asking these questions for a long time now, and I got alot of great help, theres some fantastic people here willing to help an idiot like me... but somehow the focus has been slightly wrong...

Hope this helps... I dont want to critisise, as there no doubt that TGE rocks...

m

#30 Biggest hurdle was coming to the realization that I didn't have to learn TGE. If I simply sat down with the engine and a predefined goal, I could achieve that goal rather quickly. The complxity of learning the engine is an illusion brought on by fear of not understanding it.

You don't need to understand TGE. You simply need to understand the small part you're working with for the duration you work with it.

#31 Actually... i'm going to have to disagree with Chris for the most part... please don't hit me :)

i really feel that the hardest part of learning TGE is coming to grips with several key concepts... concepts which, if not understood, will prevent anyone from doing anything except the most trivial modding with the engine...

the lack of cohesive structured programmers reference type docs is certainly a wall which those who come from traditional programming environments are going to have to deal with... and i can empathize with that... after all, you wanna make a game, not search the forums or search through pages of code...

but hey... reality does bite sometimes... and, like i've said before... while they are doing their best, the staff is a limited and finite resource... doing things in Torque is a lil different than many of us are used to... myself included... and i used to get paid good money to chase down logic and code bugs in large distributed applications... but hey, this is what we've got right now, so...


ok... getting back to those key concepts... if you intend to do anything in Torque, you will need to have a firm, if not complete understand of...

(i'm working primarily in scripting TGE, so keep in mind that the following is from that perspective)


1- a basic understanding of the application as an entity on the disk... the directory tree, and why it is the way it is... without this you have no idea why certain files are where they are, and no idea of where to put your stuff...

2- the torque implementation of it's client/server architecture... it pervades the whole thing... you've gotta understand client/server model TGE uses... no matter what type game you plan to make...

3- along with this, the concept of client/server communications and ghost objects, on the client and the server... how to create them on the server, how to proliferate them on the clients, the implications of various networking issues that these objects incur, and how to communicate the different states of each server object between client and server...


without this basic knowledge, you can forget doing anything outside of the trivial with TGE...


to a lesser degree, it would be nice to know a little about the relationships between the scripting code and engine code...

also, and i think this is important, you've gotta get a good editor... one that lets you see the various files you are editing as a total application... not just a disparate bunch of files.

your editor must allow you to see the events raised by the engine that the code is responding to... so that you can start thinking in the context of event handling... which will aid you in knowing where to code your functionality...

ok... where do you get all this stuff...

the editor... i use tribalide... i think you can still find links to it around the forum

the client server stuff... you need to read this doc... torque_scripting_basics021103.pdf the last place i saw it was as part of the total torque docs compilation... read and understand that for some scripting basics as well as a good introduction to the client/server stuff...

the rest is on the forums, but you are gonna have to search for it... but at least now you will have some direction to your search...

the ken Finney book, 3D Game Programming All In One... it's centered around Torque... it more than touches on modeling, skinning, etc... it's an easy read, and it's a great place to start with TGE... it'll save you weeks of frustration... and, no... i'm not getting any commisions :)

finally... don't try and do too much at one time... take one aspect, get an idea of what you wanna do, model it, code it, test it, then build upon that...

it's not gonna happen overnight... but each lil step is like a revalation... motivating you on the the next step...


good luck all...




--Mike

#32 I think a big hurdle for a lot of people is learning game development.

Now this may seem obvious, though I see it quite often. In an example of a person with no other experience relating to game dev (whether art or programming), its picking up a lot of the general concepts... like programming, creating art assets, etc.

then for those that do have previous experience in related fields its the game dev specific aspects... for art being creating low poly models that work well enough, working under the limitation game dev usually demands (like not using Physique in Max). Also the idea of exporting. Sure exporting to Torque seems hard, but for those usually who haven't tried exporting to other AAA engines. Going from exporting to Unreal to exporting to Torque I really don't see where people can even begin to say the art pipeline is so bad.

With programmers with previous application development (and those with amatuer experience - not an insult just another direction people come from) they have to adapt to game dev programming...

yes, programming is programming... but application programming is not game programming/scripting. Application development is not game development either. It takes adaptations, changes, and learning. Sometimes those people are too proud and to stuck in their own ways to adapt to the most efficient way for game programming (or game art). I've seem a fair share of animators who hate adapting to the restrictions for game dev modelling... on the flip side of the same token I've seen more than a fair share of professional app programmers who don't want to adapt to game programming, they want to force game programming into the same lines of app programming.

Now of course I've seen the opposite too. Animators with previous experience who have a lot of talent and pick up low poly modelling techniques easily and learn new methods rapidly due to their experience. The same goes for App programmers, sometimes the professional experience gives their code a polish, there knowledge and experience puts them leaps and bounds over those new to the game.


In my personal opinion you need to be completely open when approaching game development. In programming you can't be stuck on doing things your way. For one you often work with others, two game programming is different. The concepts behind it is different. Sure it shares the same language and some of the same calls, but making calls to OpenGL and Direct 3D is almost like learning a new language... just like learning the way Torque does it.

In my opinion artists need to be just as open minded, they need to learn what the most efficient way for them to develop game models, not force it down their path. Exporting is a pain, but it makes sense, you need to specify certain things.

I've recently seen a slew of Unreal Moders switch over to only using Torque. At first they thought they would start with Unreal since they had heard it was easier than Torque... when they got there hands on Torque, exported static shapes, then animated characters now, they even say its easier than Unreal.

A lot of people really need to open themselves to learn game dev before they can critize Torque. A lot of people are too proud.

#33 I feel I should say something, as this thread is QUITE related to my current work.

As of earlier this month, Im the new manager for the Torque Developer Network. For those of you who don't know, TDN is a Torque wiki which will be the home of all documentation once it launches. I personally am currently creating the framework for it as well as rewriting the DTS exporter docs. Sometime in the future Im also going to be rewriting the mission editor docs and possibly the DIF docs as well.

I wont make any promises here, but I can say that the direction we're going with the new documentation (at least as far as the art pipeline is concerned) is one of in-depth getting started lessons; tutorials that walk you through setting up your workspace, modeling, unwrapping, etc, and then getting your shape into the engine with all animations and whatnots working. And for those of you that just need a quick reference, theres still going to be documetation similar to what exists now (an encyclopedia of the exporter, if you will).

It's all pretty awesome and I, for one, am super pumped to be working on it.

I know the documentation can be a little hard to wade through. Just wanted to let all you good Torquers out there that GarageGames has heard you and is taking some serious steps to make the learning curve significantly smaller. Help is on the way, folks. :)

#34 Thanks Adam... encouraging news for sure...

all the best in your new position as TDN Manager... from what i gathered from your post above, it looks to me as if they've got the right guy at the helm there...

--Mike

#35 @Michael Hense -

Quote:
the lack of cohesive structured programmers reference type docs is certainly a wall which those who come from traditional programming environments are going to have to deal with

I come from a traditional programming environment. Having taken it in university.

Quote:
doing things in Torque is a lil different than many of us are used to

Code is code is code.

Quote:
if you intend to do anything in Torque, you will need to have a firm, if not complete understand of...

I don't have a complete, or even anywhere close to firm understanding, and my game is almost finished.

Quote:
2- the torque implementation of it's client/server architecture

I don't know how the client / server architecture works. Yet, my game is almost finished.

Quote:
to a lesser degree, it would be nice to know a little about the relationships between the scripting code and engine code...

You can find this in the docs.

@Mathew Langley -

Quote:
In my personal opinion you need to be completely open when approaching game development

I agree entirely. The best developers are those who can adapt to whatever situation gets thrown at them. And the way to do that is researching and then trying any task they have to. If you don't give it a shot, regardless of whether you have done, or know how to do the task, you will never be felxible enough to bring a game where it needs to be brought.

#36 @ Chris Labombard-

Quote:I don't have a complete, or even anywhere close to firm understanding, and my game is almost finished.

Quote:I don't know how the client / server architecture works. Yet, my game is almost finished.

Quote: Code is code is code.

you forgot a few Chris...

ignorance is bliss...

don't worry, be happy...

at any rate, all the best to you, and good luck with your game...


@ everyone else-

to those who need to have some idea what's going on, the stuff is out there, and if you are having trouble finding any of the docs and references i mentioned above, feel free to post here and i will do all i can to get you the info...


--Mike

#37 Michael - That made me laugh. :)

My point was that you don't need to understand what you aren't going to use. My game is single player, so I don't care about client / server stuff, so I haven't learned it. I don't have a firm understanding of the engine because there are a lot of areas that I havent needed to look into. Why would I learn things I dont need to know and wont use ?

I don't need to learn TGE. I choose a task to complete, research it, and do it. Works great! I learn about hte area I am working with. The more areas I work with, the firmer my understanding of TGE becomes.

One thing you don't realize is that NO ONE has a complete understanding of Torque. It is too large. Some people have a much better understanding then others, but noone understands it all.

And thank you, so far my game is quite unique and fun to play. Or at least, that's what I'm told. I tend not to judge my own work if I can help it.

#38 Hey Chris... i really don't wanna turn this into a one-for-one tit-for-tat clash of opinions or personalities...

there is really too much more useful exchange to be had by avoiding this, which interests me much more than wasting time going round for round with you on this...

like i said above... be happy...

whatever spins your prop...

if you feel that you don't need to learn TGE, then hey... who am i to try and convince you otherwise...

i'm sure your game will be quite unique... like you said.



--Mike

#39 My biggest hurdle is maintainig development momentum when there are so many real life issues tugging at me for my time.
I'd love to be able to take a couple of weeks out from work and work soley on my game... OOooo that'd be lovely...

But unfortunately, I have to fit it in around everything else including, Job, Missus, family... etc...

The second biggest hurdle was fitting my idea to what the engine can do with minimum engine modifications. Sometimes I find something the engine doesn't do too well, but often, a quick search on the forums yields the results and/or modifications I need.

When I started a year or so ago, some of the tools were less mature than they could be (notably the Milkshape exporter) but they've come on leaps and bounds now and seem to be as capible as the exporters for other more industry standard tools.

Scripting was an issue, I'm a developer by trade, I have C++, Delphi, VB even assembler experience... but Torque script is taking some getting used to... not the syntax mind you, there's a few concepts that need to be learned before you can really get into the scripting.


As long as you follow a few basic rules, you'll be fine.

Here are the rules I'm trying to keep to.


#1 Make a design document and stick to it. Otherwise, you'll get bogged down in code and have flashes of inspiration and add features and never get the game written.

#2 Don't worry too much about the art (yet!) get the game structure written. The real Art can be made later... and you'll get far more satisfaction from putting the real art into the already solid game structure..

#3 Keep at it. It's soooooo easy to give up. To hit a stumbling block and bang your head against it until it hurts and you don't want to work on the game anymore... if something is too hard, back track.. take a different route. But keep moving.



I've already abandoned one game project due to scope creep and not enough design work... I don't plan on making the same mistake again.

#40 Michael - Oh. Sorry, didn't mean to take a shot at you or anything. Your ignorance is bliss comment really did make me laugh and smile. Last thing I want is to ruin a good thread witha trivial argument.

I just don't understand why you would learn something you are never going to use. But maybe I will never know.