PlatformJumping: CastCollision Vs. Pick[Line/Rect] Vs. Triggers

#61 Heh, AI is so easy. Just think of how you play and simulate your own patterns.

#62 Thomas

That went over my head. :)

Maybe what you are saying is that instead of making them move with the keyboard, I script their movements or attach them to paths.

But how will I make them react to the player, say if a player reaches a particular distance near them and only then they start following him or shooting at him, if the player goes back and is n distance away from them , they again start following their predetermined path.

Have you tried something like this ?

#63 I just wanted to provide a bit of perspective on the differences in the TGB platformer tutorials, the Torque X platformer SDK, and Eric's (very accurate) comment about working within the boundaries.

In my personal opinion (and I'm not Thomas, who wrote the Platformer Starter Kit for Torque X), the fundamental difference between the two starting points is that the TGB tutorial attempts to work within the standard TGB swept poly collision mechanism, while the Torque X kit implements the collision aspects that are directly on target for platformer style game mechanics. In some ways it was "easier" to develop in Torque X because there weren't any major built in expectations to use a standardized (and therefore limited in certain ways) physics reaction system--he could simply over-ride/replace the stock physics component for one that accomplished what he needed.

That sounds like a bit of hot air, but if you take a half step back and think about the basics of platformer "physics", none of them really directly apply to the core reactions that are part of TGB's stock physics--and trying to twist them into reliable and genre expected game mechanics is a very difficult task.

If I were making a TGB platformer game (and I am assuming here that Thomas took the same approach with the Torque X PSK), I would personally turn off all built in physics responses, and simply put together a reactions model that interacts with collision detections.

My reactions model would be responsible for managing not only raw detections of collisions, but factoring in current game states, direction of travel vs collision detection (one way platforms for example), landing on platforms (none of the stock TGB collision reactions really apply when you think it through), and all other state and action based permutations of collisions.

I'm not really blowing hot air at all here by the way--the very first TGB Boot Camp labs were based on modifications of the (as it existed then) platformer mini-tutorial, and I found out myself quickly that stock physics reactions weren't going to meet all of my needs, and in some ways conflicted with my needs--so I built a basic system that did implement my needs (all in script in case you were wondering), and went from there.

I guess my short version of the above is: know the bounds and work within them when appropriate, but if what you want isn't in the bounds, don't try to stretch them to fit--just define and implement a new box :)

#64 Stephen

I clearly understand what you saying here but you have years of experience with the game engine.( much more then me)

Given my condition ( not knowing much of scripting) and pressure of making a game as fast as possible ( even if it does not make me money.) I wont be able to recreate a new box any time sooner.

Maybe after a year working with torque, I will reach a point where I can do plumbing with scripting and totally recreate a new physics model for my games.

But for now I will have to work within limits of the engine. So instead of stretching the engine to fit my needs, I can stretch my needs to fit the engine and thus as Eric mentioned maybe create a totally new genre of games. Thats what I am doing now, testing the engine for what I can do and cannot do and after I know A-Z of the engine, I will design my game accordingly.

I think that is what Indie game development is all about- innovation and improvisation and more intrinsic is to make a game which I will enjoy playing as a gamer rather then restricting myself to genres and types of games.

#65 Good points, except:

Quote:
I think that is what Indie game development is all about- innovation and improvisation and more intrinsic is to make a game which I will enjoy playing as a gamer rather then restricting myself to genres and types of games

The other thing that indie game development is all about is starting small, learning as you go, and selecting projects (for learning or profit) that are within your capabilities, or at least not far outside.

Myself, Thomas, Ben Garney, Adam Larson, even (all bow down) Melv May were all newbies once--and in fact, everyone in the mini-list here can have their posts traced back in this very web page to the day when we knew little to nothing about Torque, and were asking the very basic questions and taking small steps.

Today, we have Ben's Atlas and polysoup (an alternate 3D collision model for TGE) as a resource, Thomas and Adam Larson are lead devs on Torque X, Melv May is one of the founding developers of TGB itself, and I teach Torque Technology for a living.

And that's just a very small sample--there are dozens if not hundreds of people like that all throughout the forums--just start small, learn as you go...but it's important to know your bounds and capabilities, and strive to push them outwards slowly, instead of leaping to level 99 when you haven't been able to beat level 5 yet ;)

#66 @Wicked:

Quote:But how will I make them react to the player, say if a player reaches a particular distance near them and only then they start following him or shooting at him, if the player goes back and is n distance away from them , they again start following their predetermined path.

Pseudocode that statement:

if enemy near Player
     move enemy towards player
     fire at player
else
     cease fire
     Walk path

Turn that code into Torquescript with the appropriate function calls and toss it into an update loop and you're golden. You could also investigate triggers and such, associating a trigger with a character (onenter = attack player, onleave = reset to path walk). There's lots of options and that's the beauty of it all. Take a look around! Ask on the forums (that's what I did to start this [rather long] thread). I've found that the Torque community is full of really bright people who are very willing to help you out. Heck, even the devs are regulars in the forums!

@Stephen:

Quote:I'm not really blowing hot air at all here by the way--the very first TGB Boot Camp labs were based on modifications of the (as it existed then) platformer mini-tutorial, and I found out myself quickly that stock physics reactions weren't going to meet all of my needs, and in some ways conflicted with my needs--so I built a basic system that did implement my needs (all in script in case you were wondering), and went from there.

Agreed. The original Platformer Tutorial was troublesome. I never got it to work well and fought with the interactions for good. I saw that something was possible, however, and that was enough to convince me that TGB would be a viable base for my project. Then, while I was in Design-mode, the Mini Platformer Tutorial came out and completely simplified the interactions. I found some bugs and was able to work around some (updating the tutorial as I went) but, in the end, it still isn't what I needed. I got it to work for a prototype to show off what I wanted to do and then figured that I'd overhaul the interactions method in much the way you claim above when it came time to move forward with a beta design. I've learned a ton through the process, though, and have loved every second of it (except when I found that bug that crashed my OS. That wasn't fun).

@Wicked:

Quote:But for now I will have to work within limits of the engine. So instead of stretching the engine to fit my needs, I can stretch my needs to fit the engine and thus as Eric mentioned maybe create a totally new genre of games. Thats what I am doing now, testing the engine for what I can do and cannot do and after I know A-Z of the engine, I will design my game accordingly.

I actually started thinking about exactly this and came up with a game design that would work really well given very simple elastic collisions (supported in Torque). Back in High School I played a game called Diamonds on my HP48G graphing calculator. In that game you played as a ball that constantly bounced up and down where horizontal movement was based on player input. The ball would break blocks a-la Arkanoid and I believe you would lose a life by hitting a certain type of brick. Well, you could take that bouncing mechanic and implement it in TGB easily. Except that you could turn it into an exploration game where you do platform-style things: grab keys, kill enemies (bursts or lasers from the ball?), etc. Want to make it even neater? Allow the player to hit certain items that rotate the level (or even the direction the ball moves) by 90 degrees. Increase/decrease the players speed for variance. There's tons you can do and this style game would be a cinch to implement.

Heck, maybe I'll just do that!

Whatever, that's an example of working in the bounds. Create something simple to start and see if you can't add stuff. My first demo level was terrible but it allowed me play around with interactions and such much as you have been in your use of the mini platformer as a starting point. Good stuff!

@Stephen:

Quote:Myself, Thomas, Ben Garney, Adam Larson, even (all bow down) Melv May were all newbies once--and in fact, everyone in the mini-list here can have their posts traced back in this very web page to the day when we knew little to nothing about Torque, and were asking the very basic questions and taking small steps.

True. This thread was started for exactly that reason. I had no idea what would work for what I was attempting. In looking through the documents I came up with three separate ideas and asked for input on them. I actually tested all three of them and decided upon a combination of two of them for my final implementation (which is still buggy but I see ways to fix things... by mainly shutting off collision responses like CLAMP or BOUNCE). You can actually track my progress through this thread and the others that I linked in it. Eventually I learned enough to write a rather informative
TDN article on Fading (Wicked: I recommend giving that a read-through. I discuss various script-based functions, callback implementation, optimization strategies, etc. It's pretty clear and a very simple; the final function is something like 10 lines of actual code).

That all being said, if someone does figure out a way to get the platformer physics to work without all the customized coding then by all means share the knowledge! I like making use of built-in tech as much as possible and that would be really nice.

#67 Wicked: I made some AI for my enemy in a space shooter and when in game, it appeared to be a very complicated foe which predicted movement patterns and did some complicated thought processes. In reality, I randomly set "i" nodes up around the player, each node set "j" distance around, at "k" angle. The nodes were in the players local coordinates, which caused them to rotate and move along with the player. The Enemy had a few attack patterns - slim cut, it consisted of moving towards a node, then running away at a random speed. It ran away to a random node which faced to the rear of the player. That node was set once a node was reached by the player, and was in world coordinates. He touches the new escape node, then goes after the next node around the player. Once all nodes have been touched he performs a special move randomly selected, and sets new nodes. Also, whenever he was not running away, he would be firing his weapon at a predicted movement vector of the player. If he gets too close to the player, he automatically backs away.

It sounds complicated, but it is really simple. I made that simply AI in about 1 hour, and the results were much better than I expected. Just think of how you play and turn that into script. That is all I did.

#68 @Stephen

Agreed, that is exactly in my mind, to make a small sweet game, but exceptionally funny and enjoyable. I have given myself a deadline, till end of July I will try to learn whatever I can in torque and then utilize it to make a small game by September or max October.

Meanwhile I can learn and outline my design and graphics( at least the character).

The only thing which might slow me down is creating particles.It is the only thing I was not able to create efficiently even after going through the documentation again and again.


@Eric

That is the exact idea I am working on, but a bit different then the arkanoid and yes on par with a platformer. :) Thanks for that link. That will help.

#69 @Thomas

Thanks for that, I think I just need to give more time to scripting and I will be able to catch up fast.