Game: Track implementation

[ISAWHIM]

I vote for the tile approach also... Hehe...

For that same reason... quickness of design... (And available code.)

I am going to force a full demand of my idea being shelved... (Not a demand on your half, on mine... or I will keep rambling.)

[Michael Hartlef]

Oh well :-\ I would have loved to see this in action, if it would result in a nice detailed track with a nice variaty.

[ISAWHIM]

LOL... I would much rather see a completed game submitted, than a half complete concept. (I have not stopped thinking about it... just stopped trying to explain it badly.)

I have access to the GL help files now... so I can study what you guys already know. (My knowledge is all based on direct creation, since I never had an editor, beside the ones for Quake and Unreal, and Need for speed. I don't even know how to use CAD or blender or any other complex editor. I have lived off script-created geometry and SketchUp for years.)

Yours will do the same... only faster... (But it still needs to create a few outputs. Map_Object, Map_Attributes, AI_Path, and Fill_Objects.)

I will enjoy making suggestions on that, as that develops. (It will help me learn how or if it is possible to implement my old idea.)

Might be safe to lock this topic, since no other suggestions have been made. Create an area for it in the CODE section, so we can throw some ideas at you.

[Michael Hartlef]

I will enjoy making suggestions on that, as that develops. (It will help me learn how or if it is possible to implement my old idea.)

And I enjoy them comming, even it they make my head spin. What idea is that? Care to share?

[ISAWHIM]

Old idea = The one about the track building off itself.

I am playing with some formula attributes, trying to give the crafts some physics. Once we have a collision set of code to play with, we should be able to drop them inside your map for testing.

[ISAWHIM]

Ok, sort-of ignore this post, I am just writing this to get it out of my head... but place it in an appropriate area.

Here we go again... Hehe...

If the "Points" of the track actually defined the track itself, the AI and us, can be confined to that loop. No matter what the shape.

If some attributes of the "Points", were... (LOL, this will sound similar to my above posts.)
- Width (Defines the connecting outer limits "Joints".)
- Height (Defines the position off the "Base".)
- Bank (Defines that outer edge/s sweep-up.)
- Covered (Forces a roof, which is required for any "Overpass".)
- Mapped (Uses a M15 file for construction. Otherwise it is a simple walled structure.)
- ID_Type (Normally 0 "null", but specific "types", would be used for programming/editing/play.)
- - (0) = Generic (No special attributes.)
- - (1) = Start/Finish (Acts as a lap-counter and performs the initial launch/ending.)
- - (2) = Wide Bend (Bank is more subtle, larger flat, limited length min/max.)
- - (3) = Tight Bend (Bank is high, inner is folded and locked "post", limited length min/max.)
- - (4) = Crowd bleachers (Fenced bleachers, limited length min/max.)
- - (5) = Overpass (This would be the under side, that allows a (0) track to cross over it.)
- - (6) = Tunnel wall (Provides a cement/roof to intersect a building or mountain, to pass through.)
- - (7) = Tunnel ground (Similar to wall version, but with ground slice, like a subway.)
- - (8 - 255) = User defined. Not available for now...

Separate of the "ID_Type", there would be a style... (Profile or Structured.) So a "Tight bend", would simply tell you the shape, while the style would determine what that shape is constructed of. A "generic" style would be default also. Just a track, and walls. While a custom profile or a fixed structure M15, would replace the generic shape, or add to it. The type would be the same for both. EG, limits, functions, effects...

The ID_Type would be used by the program, similar to a script. It determines what reactions, limitations, sounds, objects, etc... will suit the length of track.

From point to point, is a "Length". However, with the above options, a point can have points in its length. Since the points have a width, and in a "Track", paths with walls don't cross one another, you can connect the round points with edges to form the track visually and for the AI at the same time, using the same points, or overlap them to stop walls from drawing.

Further "Map" traits could also respond to the points.

If there were mountain terrain created from a BMP for height, the BMP could be modified with the track points level and width values, to raise or lower the terrain to form around the track.

If there were generic objects, like trees and bushes, and buildings... they could pull-up to the edge of the map, or near it, while avoiding overlapping. (As opposed to placing trees or making a special "Tree section track". Just define a box as woods, or city section. The limitations would be in the file for the map, not the track.)

Since this is specifically a "hovercraft" track, it would be safe to assume that the entire track has walls of some sort, but the walls don't have to be on all inside edges. EG, two flat generic tracks overlap like an 8 but the joint in the center is not a CROSS, the two tracks just touch enough, and no wall is drawn. There is a "Chance" that if you overshoot your turn, you will fly into head-on racers that were behind you! That is always fun. That can be a good thing for the track, to give it a more open feel. The surrounding objects would fill-in, up to the edges of the track... This would be cool if it sliced into a mountain terrain, looking like joining valleys around two towering plateaus.

A sample of a custom section of track, would include the "limitations" for placement, size, etc... as well as, containing an M15, or multiple M15's. Objects inside could be collision objects, or scenery, or scripted. Scripted objects would be simple pre-made scripts that exist in the game itself. A value would indicate the CASE, and hold any parameters.

Sample scripts would be...
- (0) FxSparks(X,Y,Z,Size,Type)
- (1) FxLaunch(X,Y,Z,Width,Length,XYAngle,Power)
- (2) FxSound(Name,Loop,VolIN,VolOUT)
- (3) FxLeaves(X,Y,Z,Size,Type)
- (4) FxSand(X,Y,Z,Size,Type)

etc... (Particle effects, shared functions, shared attributes.)

So you could make a desert track, have jumps, put sand on sections that blows around as you pass over that area, add oil-pump sound effects, and use your own geometry, or others geometry...

Ok, I am done... I am going to finish learning TBGL now... (Yea, like I am almost done. LOL.)

You might be able to use some of that for the track editor... (I have not played with it yet, but I am guessing it only outputs the map, in this early stage.)

[Michael Hartlef]

Boy, I think we can better discuss 3rd world child suffering with all these dicussions. :

To Petr and anyone else who think is able to provide usefull code to the game. Please come up with a describtion how you want the track implemented so we can start putting a sample track together, with or without an editor.
And before someone comes out with a major science paper over 30 or more pages. Remember, we have to deliver something in january and it would be great to have some dummy artwork by the end of this month.