Jump to content

Here is how bad the movement code actually is, and it's not just "pathfinding"


Recommended Posts

  • Replies 300
  • Created
  • Last Reply

Top Posters In This Topic

I am starting to work with an excellent program called Mathematica to do presentations for teaching and I and remembering all over again the joys of the misplaced comma. One wrong one turns a beautiful graphic that takes a hundred lines of high level code to generate into mush. I am getting much better at saving before EVERY SINGLE RUN of anything new. Given that CMSF is about a 100000 lines of code, just guessing. I am sure that it is all of the wrong kinds of "fun" to chase this stuff down.

Have you ever considered hiring Charles a helper or two, or maybe a whole room full of them in some eastern block country maybe. I would hate for BFC to disappear just because something happened to his jar. And I know it is a lot harder than it sounds to actually do, but still.

Link to comment
Share on other sites

It has been a long time that somebody told me I underestimate the complexity of a bug smile.gif . But good for everybody.

Originally posted by Bradley Dick:

It takes a certain tolerance for frustration, I think. If you're digging ditches, you can take out your frustrations on the dirt with your shovel. If you're programming, you just drink another portion of caffeine and power through.

Uh? What do you think interns are for? tongue.gif
Link to comment
Share on other sites

That's when you're lucky enough to have interns. smile.gif I tend to (being intern-less) deal with my frustrations by coming on gaming forums and reading about what pisses everyone else off.

Seriously, it's pretty tough to get me frustrated. Frustration avoidance is a survival skill in my industry (sub-hour deadlines -- for complete management-dev-QA turnaround of fresh applications and fixes alike -- are not uncommon). Just take a walk, clear your head, and go back to it. Otherwise there's a good chance you end up with bad code.

Link to comment
Share on other sites

Originally posted by Abbott:

</font><blockquote>quote:</font><hr />Originally posted by thewood:

There are interns in Peng? I'll be right back.

OK, just checked...bunch of smelly old guys, no interns.

And its nice to know that you are on your way to being an old guy. Enjoy the ride pilgrim. </font>
Link to comment
Share on other sites

All right, chaps.

I re-did it in "move" (not fast, not quick) and with a gazillion waypoints. You might notice that these are way more waypoints that you could possibly draw for each vehicle in RT.

Here's the path, all "move" speed:

path2_1.png

I spare you the fory detail, but the problems were the same as in fast. Not that I expected that, nahhhhh. Anyway...

Here's the worst "arse to enemy" turn, this is actually taken a split-second later than the worst position:

path2_2.png

In WEGO VCR replay we miss the path lines (why?) but this was the vehicle position.

path2_3.png

Now, this is actually worse(!) than the fast run. You see, with this huge number of waypoint and absolutely no non-smooth corners in there, and still producing arse-to-enemy movements, that is worse than in the case with fewer, not so smooth waypoints.

Worst, the vehicle comes to a complete halt all the time. I really don't see why that would be justified given path and speed. In a word: it's a code problem and it has nothing to do with speed and few to do with waypoints. It's broken.

Sorry, guys, but I told you so. Now that we are over with this, what will you make up now?

Link to comment
Share on other sites

I just read all 5 pages of this, and the only BFC comment I saw was a very general "we fix things and some bugs aren't as hard as you think".

Did I miss something? Has BFC actually acknowledged that Redwolf has a point here, acknowledged the finely presented problem report, and indicated that they think its' one they'll fix?

If so, I appologise for not seeing it.

If not, this is what pisses me off about BFC. So slow to acknowledge supportive efforts.

GaJ

Link to comment
Share on other sites

GaJ,

If not, this is what pisses me off about BFC. So slow to acknowledge supportive efforts.
I think the correct response I'm looking for here is "Dude, chill out!". When was this thread started? Less than 12 hours from the time I am typing this and 6 hours before my first response. If that is "slow", I wonder what you consider "fast" and what game developers you consider live up to your expectations. I'll time your answer and if it isn't within a few minutes I'll be pissed off at your slow acknowledge of my supportive efforts :D

You got to understand that when I see a thread with a title looks like yet another complaint session about problems we have already said we know about and are fixing... well, I'm not going to give that one high priority. Even still, I looked into it within 6 hours. Not bad considering I have to sleep and eat at some point during the day, not to mention actually work on fixing the problems.

Now, back to real issues instead of imagined ones...

To address the stuff in this thread is kinda pointless now. We've fixed a number of things that would cause these problems and you'll get a chance to see for yourselves how well we did very soon.

I will say, though, that Redwolf has a flaw in his logic. Any time a unit moves there is pathfinding involved. Why? Because any movement from a point to another point has to be "found" even if it is between two adjacent spaces of the same type. That's just the way computers need to think of things.

What is true is the TacAI should favor a straight line whenever it can, it should also not go out of its way to favor/avoid terrain based on some trival benefit/penalty. This has to do with "weights" that the pathing system uses to evaluate different possible course for the unit to take.

Remember that unlike CMx1, acceleration and turning radiuses are taken into account. So yes, speed does matter as does the path itself. The TacAI probably needs to be smarter about adjusting speed to keep to one's waypoints, but this is an extremely difficult thing to have the TacAI do. Anticipation is never easy to program. So yes, even with some fixes and tweaks people that use ridiculous Commands for the conditions will likely get suboptimal results. However, there are definitely bugs in the current system so it's hard to tell what is just suboptimal user input and what is suboptimal coding. Elmar put it quite well a couple of pages ago:

But it's not turning it's rear to the enemy. It has no clue where the enemy is. What's happening is that it misses it's intended path because of a too high a speed and too sharp a turn. In an effort to get back on track it may do just about anything, which sadly includes some totally bizarre things. That's the real problem: Not that it can't follow the path, but that the corrections to undo the user induced swerve (or whatever you call it) can have some bizarre and counter productive results.
We definitely fixed something that should solve the overshooting problem, which is indeed the issue that is currently causing the ass pointing in the wrong direction problem. Therefore, this particular problem should be fixed.

Steve

Link to comment
Share on other sites

tc237,

I'm guessing it is not possible to implement a "Follow Road" command somehow?
Good guess smile.gif Having the pathing code strongly favor roads when already on roads is just about the best it can do. However, it has a LOT to do with the terrain surrounding the road. The more unfriendly the more likely the vehicle will stay on the road. The less difference between the road and the terrain around it the more likely it will drive straight. A friend of mine who was offloading ships in Bahrain during OIF commented on how nobody uses roads... they just drive wherever they want because it is pretty flat and hard. Probably better driving conditions than roads in Boston!

Steve

Link to comment
Share on other sites

Well, this is probably not relevant to the main point, but the problem of the "disappearing" waypoints is easily explained as being due to the 8 x 8 m grid abstraction, and is not a problem at all.

When the vehicle reaches the outer edge of the 8 x 8 m grid containing a waypoint, the program thinks it has reached the waypoint, shown in the center of the grid, and takes it off the display. When the path line is redrawn, the line is drawn from the vehicle to the next waypoint, and since the vehicle is at the edge of the 8x8m grid, it looks like the line or waypoint has shifted.

Again, all this behaviour is just the code operating within the 8x8 m grid abstraction.

I wish BF would add the feature to toggle the display of this grid as an overly to the map, also showing the center point of each grid square, since this is such an important part of the game.

Link to comment
Share on other sites

Originally posted by Battlefront.com:

A friend of mine who was offloading ships in Bahrain during OIF commented on how nobody uses roads... they just drive wherever they want because it is pretty flat and hard. Probably better driving conditions than roads in Boston!

Steve [/QB]

And also, the IED's tend to be on the roads. It's not very effective to stash them in the middle of the desert.
Link to comment
Share on other sites

Originally posted by Steiner14:

</font><blockquote>quote:</font><hr />Originally posted by thelmia:

Oh God, I would never program. I'd rather dig ditches. I'm not kidding.

If you would ever get in touch with Object Oriented Programming, you would probably change your mind. </font>
Link to comment
Share on other sites

One exciting aspect seems to be, that it's not just programming spaghetti-code with dry algorithms and calling subroutines, but it's about modelling the real world into classes and objects (you create indeed the object "tank", or "soldier"). Then you give the objects attributes and capabilities, they send messages, do something and receive messages from other objects.

And if you need a more specified object, they can inherit their capabilities.

Another very shining aspect is a technique called encapsulation. In OOP you do not always set values of variables and then get confused, what was set and how often in the program that variable is set. In good style OOP the changing of variables is done via the capabilities an object has. Imagine you have an object "bicycle". You do not change it's gear variable from ouside, but you give the bicycle the capability to change its gear, you define what it needs as input data, to change the gear (i.e. the number of the new gear). And then, if you want to change the gear of that bicycle from the outside, you simply call the specific bicycle and it's capability (the function) to change the gear: bicycle.changeGear(3).

Good OOP programming can be almost read as normal text.

The dry and hard to understand algorithms are buried within the functions of the objects. But once defined, you only call the function's name of a certain object with the input data and receive the result back from the object.

[ August 25, 2007, 01:32 PM: Message edited by: Steiner14 ]

Link to comment
Share on other sites

Originally posted by Redwolf:

All right, chaps.

I re-did it in "move" (not fast, not quick) and with a gazillion waypoints. You might notice that these are way more waypoints that you could possibly draw for each vehicle in RT.

Sorry, guys, but I told you so. Now that we are over with this, what will you make up now?

Dial down the attitude, Redwolf. Did you miss where I told you MOVE would be doing this sort of thing too? Not as often as FAST and QUICK under the same circumstance, maybe you seeing it more is because you changed the test. Have you tried SLOW? Oh gee wizz, I wonder why not?

Anyway, I'm done 'debating' this as I am pretty happy how vehicles move in 1.03.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...