Programming in general
by Bryan Knouse · in Technical Issues · 12/15/2004 (4:13 pm) · 18 replies
About how much programming do you need to know to make a good game with torque? Does the 3D Game Programming All In One cover basically all of what you need to know?
About the author
#2
I never read the book, just repeating things I heard (mostly on Amazon). In fact I'm still thinking about getting it, so if anyone disagrees with any of these points I'm eager to hear why.
12/15/2004 (5:54 pm)
I've heard that the book has many coding mistakes, that its examples don't work on the stock version of TGE, and that its coverage of script is too basic for someone who already knows c++. The vast majority of people seem to love the book, but these three problems seem quite serious.I never read the book, just repeating things I heard (mostly on Amazon). In fact I'm still thinking about getting it, so if anyone disagrees with any of these points I'm eager to hear why.
#3
12/15/2004 (5:59 pm)
Hrmmm I've got the book coming from Amazon, I bought it off everyone's recommendation, as everyone seemed to say it was "the goods".
#4
1. Yes. There are some errors in the book. However, Ken Finney, the author frequents these forums and there is a forum devoted to the book and its issues. Help is there for the asking.
2. Hmm, I have the stock TGE v1.3 compiled under mingw and haven't had any problems whatsoever.
3. Scripting in the TGE is not C++. It has similarities but it is different. The TGE is HUGE and practically ever aspect of it can be controlled using the scripting system. So it make good sense to get a leg up and learn it. The book covers the important modules and from there you can work out the rest, IMO.
I think that people who buy the TGE without really knowing what it is have a hard time understanding that it is a complete game engine. Modding the source can be done if one wishes to, but it's not at all necessary. The scripting system takes care of 99.9% of what you want to do. Hence the rap about "too basic for someone who already knows C++".
12/15/2004 (6:05 pm)
I'll take up that gauntlet!1. Yes. There are some errors in the book. However, Ken Finney, the author frequents these forums and there is a forum devoted to the book and its issues. Help is there for the asking.
2. Hmm, I have the stock TGE v1.3 compiled under mingw and haven't had any problems whatsoever.
3. Scripting in the TGE is not C++. It has similarities but it is different. The TGE is HUGE and practically ever aspect of it can be controlled using the scripting system. So it make good sense to get a leg up and learn it. The book covers the important modules and from there you can work out the rest, IMO.
I think that people who buy the TGE without really knowing what it is have a hard time understanding that it is a complete game engine. Modding the source can be done if one wishes to, but it's not at all necessary. The scripting system takes care of 99.9% of what you want to do. Hence the rap about "too basic for someone who already knows C++".
#5
Can someone confirm that please ? If that's the case, then scripting's the way ...
One thing that ppl also might want to do is create an executable of the game engine with their icon rather than the torque icon, along with the other properties that are stored in EXE files. I smell a tutorial ;)
12/15/2004 (10:33 pm)
I think that most ppl might be turned off scripting because it is so exposed to anyone and everyone, however I think I read on the forums the other day that the DSO files that are created from the script files are compiled versions and you only need to distribute those.Can someone confirm that please ? If that's the case, then scripting's the way ...
One thing that ppl also might want to do is create an executable of the game engine with their icon rather than the torque icon, along with the other properties that are stored in EXE files. I smell a tutorial ;)
#6
12/16/2004 (2:36 am)
What are scripts? I know the C++ deal, but i hear a lotta different talk about that and coding...
#7
Right. Scripts are compiled when the program runs. They are essentially text that you can edit with any good text editor (I use Context).
This is one area that I think confuses people new to TGE. TGE is a complete game engine. Scripts are what you work with primarily to configure and "program" the engine. There are different "classes" within the TGE that have already been designed by the TGE crew that describe things such as vehicles, objects, terrain, etc. You don't have to re-code the source to make things change or work. You change aspects of the scripts. If you need a new function, you can create new script classes that access existing TGE functions. All in all, a very cool and flexible system.
IMO, using the scripting facilities of the TGE will take you a long way in your game development before you might even *think* about altering the source.
Hmm, I can't comment on the icon 'cause I haven't done one yet.
12/16/2004 (4:30 am)
Quote:Can someone confirm that please ? If that's the case, then scripting's the way ...
Right. Scripts are compiled when the program runs. They are essentially text that you can edit with any good text editor (I use Context).
This is one area that I think confuses people new to TGE. TGE is a complete game engine. Scripts are what you work with primarily to configure and "program" the engine. There are different "classes" within the TGE that have already been designed by the TGE crew that describe things such as vehicles, objects, terrain, etc. You don't have to re-code the source to make things change or work. You change aspects of the scripts. If you need a new function, you can create new script classes that access existing TGE functions. All in all, a very cool and flexible system.
IMO, using the scripting facilities of the TGE will take you a long way in your game development before you might even *think* about altering the source.
Hmm, I can't comment on the icon 'cause I haven't done one yet.
#8
12/16/2004 (10:52 am)
About how long did it take you to learn enough programming to make a game? It seems like whenever I look at files for Torque Im bombarded with a bunch of different numbers and words that I dont understand - albeit im still learning C++, but Im nowhere near close enough to write large scripts how does that affect me?
#9
Back up, and write some programs from scratch first. Code up some real simple games in console mode, like number guessing. Work up to number guessing.
Introduce yourself to graphics with something like Tetris or PacMan from scratch.
If you get a good solid grounding in the fundamentals before tackling something as complex as a 3D game engine, you will find yourself spending a lot less time scratching your head.
Everyone learns at different rates. I've seen students go from zero to 3D renderers in anywhere from 3 months to 3 years. Depends on the person.
12/16/2004 (11:11 am)
Sounds like you're taking on too much at once.Back up, and write some programs from scratch first. Code up some real simple games in console mode, like number guessing. Work up to number guessing.
Introduce yourself to graphics with something like Tetris or PacMan from scratch.
If you get a good solid grounding in the fundamentals before tackling something as complex as a 3D game engine, you will find yourself spending a lot less time scratching your head.
Everyone learns at different rates. I've seen students go from zero to 3D renderers in anywhere from 3 months to 3 years. Depends on the person.
#10
I agree with Mark entirely. You need to start small and get a firm grip on coding smaller, more focussed applications. If you don't spend time learning the fundamentals up front, you'll get frustrated and probably give up no matter how badly you want to code a game. BTW, I'm a professional programmer with 15+ years of C/C++ behind me and I still find game coding to be one the most challenging aspects of the art.
Why? Because you've got a lot going on in a game world. And you have to code for all of it. AI, graphics, file loading, user input,sound, everything. Even though the TGE takes care of a lot of it for you, you gotta have your game on...
Remember this we're all noobs starting out and we all "pay our dues" learning. Don't let yourself get in a rush. The gaming industry is going to be around for long time. Before you can fly with the eagles, you're gonna be on the ground with the turkeys... metaphorically speaking. 8^)
If it helps, download the Dev-C++ IDE with the bundled mingw compiler off the 'net and mess around with it. It's not perfect, but it's free and you can really learn some things.
12/16/2004 (11:43 am)
Quote:Im nowhere near close enough to write large scripts how does that affect me?
I agree with Mark entirely. You need to start small and get a firm grip on coding smaller, more focussed applications. If you don't spend time learning the fundamentals up front, you'll get frustrated and probably give up no matter how badly you want to code a game. BTW, I'm a professional programmer with 15+ years of C/C++ behind me and I still find game coding to be one the most challenging aspects of the art.
Why? Because you've got a lot going on in a game world. And you have to code for all of it. AI, graphics, file loading, user input,sound, everything. Even though the TGE takes care of a lot of it for you, you gotta have your game on...
Remember this we're all noobs starting out and we all "pay our dues" learning. Don't let yourself get in a rush. The gaming industry is going to be around for long time. Before you can fly with the eagles, you're gonna be on the ground with the turkeys... metaphorically speaking. 8^)
If it helps, download the Dev-C++ IDE with the bundled mingw compiler off the 'net and mess around with it. It's not perfect, but it's free and you can really learn some things.
#11
12/16/2004 (4:56 pm)
Have dev, have visual C++, and I have two books. Basically I started coding a celsius converter (works!!!!!) and im gonna try pac man with a friend soon. Hopefully thats not above my ability, I just have no idea as of right now.
#12
Take Pacman, for example. What is it? A ball with a mouth chomping on dots while running away from wandering ghosts in a maze.
Where do you start? You can't really test any of that running around unless you have a world to run in (else you just fall into the void), so start with that. How do you make the maze? It could be simple terrain. You saw the FPS demo right? You could raise hills to make that terrain into a maze. Simple to do with the terrain editor. Just play with it a bit.
Then you need Pacman. Remember that orc that so happens to be in the FPS demo as well? Well, he runs around. Sure, you don't know exactly how, but if you turn him into a ball with a mouth, you can basically ignore the details till you need them.
Then you need dots to chomp on. Remember those medic kits and ammo on the ground that the orc picks up? Well, they disappear when you step over them, not too different from being chomped is it?
Then you need ghosts.... Remember that other orc that runs around on his own? How does he do that? You already know how to turn him into a ghost, since you turned the first orc into a ball with a mouth. Getting it to run around intelligently is another matter though, and probably something that needs a bit of thinking and research.
At this point, you not only have Pacman.... you have 3D Pacman! Then comes the refinements.... You probably want a GUI to display a score that you calculate somehow. Perhaps modify the main menu and splash screen to be more pacmanish. Perhaps, replace the terrain walls with DIFs. Maybe even make the whole thing indoors within one huge DIF.
And after sorting out the details... guess what! You're Done!
Sure, I made it sound easy, but building the thought processes is important. That way, you can break big problems down into little ones and tackle them piecemeal. Much easier to learn working on a specific project, rather than learning generally from books and lectures and tutorials.
I have this resource for you if you need more tips on staying on track.
Have fun!
12/17/2004 (5:31 am)
Don't let it overawe you Bryan, just take things one small piece at a time. There's often too much flying about that it is difficult to focus on what you really need to get the job done. The art of programming is merely the act of thinking logically and systematically as opposed to normally.Take Pacman, for example. What is it? A ball with a mouth chomping on dots while running away from wandering ghosts in a maze.
Where do you start? You can't really test any of that running around unless you have a world to run in (else you just fall into the void), so start with that. How do you make the maze? It could be simple terrain. You saw the FPS demo right? You could raise hills to make that terrain into a maze. Simple to do with the terrain editor. Just play with it a bit.
Then you need Pacman. Remember that orc that so happens to be in the FPS demo as well? Well, he runs around. Sure, you don't know exactly how, but if you turn him into a ball with a mouth, you can basically ignore the details till you need them.
Then you need dots to chomp on. Remember those medic kits and ammo on the ground that the orc picks up? Well, they disappear when you step over them, not too different from being chomped is it?
Then you need ghosts.... Remember that other orc that runs around on his own? How does he do that? You already know how to turn him into a ghost, since you turned the first orc into a ball with a mouth. Getting it to run around intelligently is another matter though, and probably something that needs a bit of thinking and research.
At this point, you not only have Pacman.... you have 3D Pacman! Then comes the refinements.... You probably want a GUI to display a score that you calculate somehow. Perhaps modify the main menu and splash screen to be more pacmanish. Perhaps, replace the terrain walls with DIFs. Maybe even make the whole thing indoors within one huge DIF.
And after sorting out the details... guess what! You're Done!
Sure, I made it sound easy, but building the thought processes is important. That way, you can break big problems down into little ones and tackle them piecemeal. Much easier to learn working on a specific project, rather than learning generally from books and lectures and tutorials.
I have this resource for you if you need more tips on staying on track.
Have fun!
#13
Don't try to do things from scratch the first time..modify something small--something that already exists. Review what you did, and how it affected the game, and then take notes. Rinse and repeat for another major area of your "game".
By the end of this first "cycle", you'll have increased your knowledge of how TGE works incredibly, and should be ready to go back to the beginning and "refactor" the changes you made by either making them in a much more educated way, or introducing new things to your engine that you wrote yourself. Either way, the second (and third, and fourth) time around, you are much better prepared to not only understand why it works in the first place, but how to change/add to make it work the way you want.
12/17/2004 (5:42 am)
@Eugene: That's an amazingly simple, and extremely accurate way to describe how people should "get to know" Torque!Don't try to do things from scratch the first time..modify something small--something that already exists. Review what you did, and how it affected the game, and then take notes. Rinse and repeat for another major area of your "game".
By the end of this first "cycle", you'll have increased your knowledge of how TGE works incredibly, and should be ready to go back to the beginning and "refactor" the changes you made by either making them in a much more educated way, or introducing new things to your engine that you wrote yourself. Either way, the second (and third, and fourth) time around, you are much better prepared to not only understand why it works in the first place, but how to change/add to make it work the way you want.
#14
As for scripting, I'd actually suggest downloading the Flash MX trial, and make some simple games using its Actionscript. It is about the Simplest scripting language there is with loads of documentation and toturials.
And in essence it is identical to what you would do with Torque. Flash is an engine, a complete program, a virtual machine,and you modify its behavior with scripts. Same thing.
You can produce flash apps very quicky and its Action script will introduce you to scripting/programming quickly.
Spend one month with it and you'll be ready to move on, and the transition will not be very difficult. Plus you'll be able to make Flash Apps like a pro, it only takes about a month to master.
One other suggestion, don't get caught up on graphics and art assets. Just make the visuals functional and don't pay any attention to how pretty they are, all the art can be replaced when you get some structure and a semi working game in place..
If you do get interested in programming I'd say go striaght for C++. Not only is it the primary languange you will need to know, but it also has crap tons of documentation, tutorials, examples, open source software (including game engines) and a thousand user communities, all over the internet.
12/17/2004 (9:36 pm)
I'd agree with everyone who siad you need to start small. It is not only easier but you can get some very quick satisfaction. Once you get the rush of seeeing something you made work, no matter how small or crappy, you'll probably be hooked. And you'll need that hook to finish larger projects.As for scripting, I'd actually suggest downloading the Flash MX trial, and make some simple games using its Actionscript. It is about the Simplest scripting language there is with loads of documentation and toturials.
And in essence it is identical to what you would do with Torque. Flash is an engine, a complete program, a virtual machine,and you modify its behavior with scripts. Same thing.
You can produce flash apps very quicky and its Action script will introduce you to scripting/programming quickly.
Spend one month with it and you'll be ready to move on, and the transition will not be very difficult. Plus you'll be able to make Flash Apps like a pro, it only takes about a month to master.
One other suggestion, don't get caught up on graphics and art assets. Just make the visuals functional and don't pay any attention to how pretty they are, all the art can be replaced when you get some structure and a semi working game in place..
If you do get interested in programming I'd say go striaght for C++. Not only is it the primary languange you will need to know, but it also has crap tons of documentation, tutorials, examples, open source software (including game engines) and a thousand user communities, all over the internet.
#15
12/18/2004 (2:15 pm)
I know scripting is meant to be powerful, but it seems that everytime I want to add a feature (even features I would call basic) to the game I'm working on - it's not scripting, it's C++ code. ie. HUD, Forcefield or Reactive Regions.
#16
The power of TScript comes when you properly expose that functionality back to the console so your script developers can use it!
12/18/2004 (2:24 pm)
When you add new functionality that isn't part of stock TGE, almost by nature it requires underlying C++ handlers to be able to implement the functionality. This isn't always the case (IIRC, someone wrote an entire IRC chat lobby fully in script), but in general if it's truly "new", it needs engine implementation so the scripts can manipulate it.The power of TScript comes when you properly expose that functionality back to the console so your script developers can use it!
#17
12/19/2004 (2:53 pm)
Do you guys agree I could do pacman, being that i know very little C++, but just assume im starting from nothing, and using the 3d game programming all in one.
#18
12/19/2004 (3:40 pm)
I would seriously in your position simply run through each and every tutorial in the book. By the time you get to the last chapter, you'll know for yourself!
Torque Owner Jeff Houck
However, know this; you can go a long, long way with Torque by just utilizing the scripting system.