Elysian Shadows

I've been working on a game that implements a tron-esque like mode (not exactly the same) that requires leaving a wall/path behind the moving craft. The problem is that I'm not entirely sure the best way to go about it. As some already know, I'm working with C# in XNA so there's some functionality built in that I can take advantage of (working with primitives for examples). Right now, I kind of have two thoughts in mind:

1) Working with primitives - this would involve working with a bunch of vertices, including updating the most closely following vertices and laying permanent vertices every time the object turns (primitives can be a bitch to work out good algorithms for I've found - but it's doable).

2) Lay some model "piece" down every fraction of a second to give a nice long continuous path that looks smooth but is really just a bunch of little segments pieced together. I'd imagine that this could be very memory intensive (though if I properly load the model/models I'd use for the path and just reference those every time I place a new one then I suppose it wouldn't be that much... that's assuming that something like that would work).

I'm still kind of working this aspect out from a design perspective before going headfirst into it - any feedback or suggestions would be greatly appreciated. I don't necessarily need to use either of those approaches, they're just the ones that occurred to me.

EDIT: Here's a link to a youtube video showing Armagetron which is a game based upon lightcyles from Tron:
http://www.youtube.com/watch?v=AtG85KGfwYg

I like the single stretching primitive idea, seems like it'd be better than having a ton of vertices constantly being added.

The thing with the primitives is that it would involve manipulating a bunch of vertices. Every time you turn you need to set some static vertices to represent the turn point, then create a new primitive for the next length.

EccentricDuck wrote:The thing with the primitives is that it would involve manipulating a bunch of vertices.

It's only 4 vertices per wall (worst case), as opposed to hundreds? in your other idea.

EccentricDuck wrote:Every time you turn you need to set some static vertices to represent the turn point, then create a new primitive for the next length.

I don't understand what you mean here.

Now that I think of it, if you do it the other way you have a single static prim that you're drawing multiple times, instead a bunch of different prims. I really have no idea which way is better, but it seems like both would be perfectly reasonable solutions. Just give it a go and see what happens?

dandymcgee wrote:

EccentricDuck wrote:The thing with the primitives is that it would involve manipulating a bunch of vertices.

It's only 4 vertices per wall (worst case), as opposed to hundreds? in your other idea.

Good point actually - it really wouldn't take that many vertices. Sorry, I sometimes over-complicate things.

dandymcgee wrote:

EccentricDuck wrote:Every time you turn you need to set some static vertices to represent the turn point, then create a new primitive for the next length.

I don't understand what you mean here.

Every segment in a particular direction is its own piece. Primitives, or at least the ones I have access to, represent points, lines, or triangles. However, I can make single objects out of a whole bunch of them (eg. an icosahedron from a tutorial I did - 20 sided with 12 vertices (actually, 60 when you take into account that they're made up of triangles, but each vertice gets indexed 5 times by 5 different triangles in the icosahedron)). The difficulty comes in the update methods. I need to update the vertices that represent the leading edge of the wall (the one coming from the craft) as I go, but when I turn I need those points to lock (stop updating or become static in a sense) and form a corner of the wall, I need to create two new vertices for a new leading edge of the wall going in a different direction. The old vertices will stay in place since they represent the edge to the first segment of the wall and the new vertices will need to be passed onto the relevant update call (that updates them along with the craft's movement) so that the old points stay in place. If you didn't you'd end up getting a wall that is anchored on one side that rotates in whatever direction the ship goes.

Hmm... I suppose the simplest way would be to create new vertices and pass them to the update method each time the craft turns... then the old ones continue to get updated.