reshaping the arena, part II

[philippeqc]

Hi all

Just to tell you that I'm still working the multi-shaped maps. And making some progress. But now that I'm deep in it, I realise a bit more the extent of the work needed. And this post is to see if anyone would be interested to lend a hand.

I'm still hard at work with the engine part, how to make object move from one field to another.

I'd be interested if someone would like to tackle the rendering aspect. But I will not decline any other help offer.

-ph

[Tank Program]

Take your time, I know you're producing quality work. Alas though, that this level of work is beyond me...

[philippeqc]

Tank made the mistake of publicly declining rather than to cowardly not anser like the other 20 ppl who checked this post. So I went and reeled him in.

That said, like all of you, we dont have the knowledge, skill or time to do it, but we will welcome any help available. Feel free to join our merry adventure.

-ph

[philippeqc]

Some basic understanding for anyone interested in the problem of complex arenas and their rendering.

The current game has many shortcuts that need to be fixed.
a) camera makes many assumptions about shape
For the rendering, the whole concept is really around the grid being the sole element, bounded by the rim, and with player stuff inside. I think it draw the floor, the sky, clip them
with the rim, then do the bikes and traces.

Displaying complex world will need a very different technique. A very optional infinitely big sphere with a picture mapped (1) on it to bound the colliseum [remerber that you cant see out of a colliseum]. The the visible fields for all the arena present should be found. and after that, the game elements on them rendered. I dont know how much gl does by itself, and how much we need to do.

Cameras have a position. That position should be converted to be a point on a surface ??? Knowing the surface your on, you know the field, arena and colliseum, and that would allow it to get acces to all the info needed to display the colliseum.

b) Wrong associations of object
Many objects are owned by the wrong ones. The first to my mind is the cameras (plurial) owned by the grid. World element should not own them. The game should. But moving them is non trivial as it is a convenient association as the cam and grid exchange many info. This might be the good way to start. Just dissociate the camera from the grid and give it to the game. While in this convertion, keep an open eye and prepare for it to be made aware of worlds later.

Yes, its pretty ugly, but I think its _A_ way to start.

-ph

1) Could be like a sky filled with stars, or anything else. I think games like quake N uses that, some "very far away" texture. But It could also just be plain old black

Nota: I need to redefine some words to better present the details involved. I already presented surface, field, arena, colliseum and empire in a post at the beginning of the summer. I lack a word to describe the ensemble, the whole. Map cant be used for that (even if I did already, my bad). I think map should designate the static information to describe/build one structure.

I dont like grid because it is too generic. In the new model it can be applied equally to surface, field and arena. Should it be reseved only when talking about the old model?

Walls are too generic a term at the moment, meaning both rims and traces. So I try not to use them. Rim are the walls bounding parts or all of fields (ie; where a field is not connected to another). Traces is what is left behind a cycle (I say bike often, but that is my mistake).

[Tank Program]

So start by taking the camera from the grid and assigning it to the game then?

[philippeqc]

Yes tank.

[simcosmos]

Hello

I was one of those who “looked but cowardly did not answer”

For now I’m just lurking the forum, seeing old posts, ideas, etc so that I can be +/- inside the issues. (I’m particularly interested in textures and models)… It’s very probable that the second part of my post will not bring anything new to the discussion… but I still need to read some of the past threads/posts with more detail… sorry if the terms are not the most exact ones…


Part I

I think that the idea of arenas with other shapes is very good as well features like custom player skins visualization in online sessions, etc but I’m afraid that I can’t actually help in anything like that…

I mean, in the past I programmed in… BASIC (don’t laugh)… used BASIC as an introductory language (btw: did a nice graphical 2D representation of comet West tour around our Sun, with physical elements like speed, distance, etc dynamically changing with a funny orbit animation…).

Then I started using a more complex language - IDL - to model things like the Sun’s internal structure and the atmosphere of a T Tauri Star… Other than that I used IRAF to search for a galaxy cluster or to extract and analyse the spectrum of a star and from that know the star’s properties… (ok… IRAF is not actually programming)

The point is that I have no C++ experience as probably some others that had a look at this thread… I’m slowing studying c++ (also because it would be very handy for DLL making for Orbiter Space Flight Simulator addons): once we learn a language (Basic, IDL, Fortran, Pascal, etc) we know what are procedures, functions, algorithms, variables, etc… we just have to adapt what we know to the new language and learn some new tips and tricks (ok, it is not soooo easy)

What I want to write with all this is that I can’t help with the coding part of the process and because of that I “cowardly did not answer”… All what I can do is to read the work in progress posts, try to understand what you guys are talking about and if possible make suggestions… with the risk of writing things that make no sense at all for the programmer

[simcosmos]

Part II – About other shapes for Arenas

Ok here it goes “nothing”…

I have one doubt: In some pictures I see a polygonal arena but with the cycle moving as usual (always in front, 90 degrees left/right turns)…

The question is: with the cycle moving always in front and changing direction with only 90 degrees turns, is it possible to grind and ride the outer walls of an arena with other shape than a simple rectangle?



II.a) Trying to develop a little more the question…

I think that the new arenas shapes should be based, at least in a first phase, only in polygons with the outer walls making internal angles of 90 or 270 degrees between them… that would perhaps simplify the collision procedures, the detection where the outer walls are, the ability to ride the outer walls… something like what was used in TRON2.0 Game Arenas… And with some death zones in the middle of such arena we would already have more variety.


For fields with other geometric shapes like triangles, hexagons and, later, circles (you can look at a circle as a “hexagon” with more sides)… perhaps the best would be to change the way the cycle moves in those fields where the outer walls do not have an internal angle of 90 or 270 degrees between them…



II.b) Concepts...

And here I enter with the concept of BIG ATRACTOR (BA) and PARALLELISM = Orbits…


Starting with a TRIANGULAR Field
… isosceles… base line with east / west direction, top vertice pointing north
top vertice = big atractor (BA)

IF cycle starts heading north / south it would follow a line that would take it into /away from the BA

If cycle starts heading east / west it would follow a path parallel to the wall opposite to the BA

Changing direction would be made with left / right turns but the angles would vary in order to make the light cycle follow the parallel (orbital) lines or the radial lines…


HEXAGONAL Field

To build a hexagonal field we would have to assemble triangles… in this case the BA would be in the very center of the hexagon and would be surrounded by a hexagonal internal wall …

The hexagonal arena brings something new: automatic changes of “parallel” directions as soon as the cycle crosses each one of the lines that connect the vertices of the hexagon to the BA (center of the hexagon)


Those changes would not be automatic when riding very near the outer walls… in that case the player would have to make a turn input command else it would crash (like it happens in rectangular arenas)… the turn command while at a vertice would make the player continue to grind the outer wall.


Then the same principles could be applied at octagonal, etc fields…

Please note that I’m assuming well behaved (symmetrical) polygonal forms or rectangular based ones for the fields…


II.c) Analogy

The main idea here is that the outer shape of the field and its relation with the BA would control the way the cycle moves…

Think in the BA as a star generating a gravitational field… if we had a circular arena, cycles would move away from or fall to the BA along the radial lines. Making left / right turn would make the cycle assume a circular orbital path… then, not pressing any key, would make the cycle continue that orbital path, maintaining the same radius (the equivalent to the automatic direction changes in octagonal fields)… Pressing right / left would make again the cycle follow the radial lines…



II.d) Now, putting it all together…

Finally all those fields (rectangular, polygonal rectangular based, triangular, triangular associations, hexagonal , octagonal, etc, circular) would be connected together to form the gamming arena…

When the player enters in one field, his/her cycle “orbital = parallel to BA” movement and “radial = perpendicular to BA” movement would be influenced by the field’s particular BIG attractor…

Ex: we could have an arena made up by a circle part glued together with a hexagon… the way cycles move would change when passing from the circle to the hexagon part of the arena…

But in each case we would have always only single left / right key presses tpo pass from an orbital path to a radial one. Connecting a third rectangular field to arena would make the light cycles move like usually… (Rectangular fields do not have BA associated)


Surrounding the arena would then be half of a sphere (the coliseum) with the sky texture and surrounding scenario textures… Coliseums would have then links to other coliseums (servers)…

From this point of view (BIG Atractor concept for non rectangular based fields) perhaps it would be better to maintain the camera relation to the grid of each field (?)…

Hummmm, I think that I tried to explain what was my idea but not sure if anyone will understand… I was hoping to make some pictures… perhaps will had some in a future occasion. Then some of what I wrote might be a little easier to understand… do not know…

What I wrote… does it make sense for anyone?

António

[klax]

In some pictures I see a polygonal arena but with the cycle moving as usual (always in front, 90 degrees left/right turns)…

The question is: with the cycle moving always in front and changing direction with only 90 degrees turns, is it possible to grind and ride the outer walls of an arena with other shape than a simple rectangle?

This is my main motivation of doing shaped arenas: trying to eliminate outer wall fights (very used strategy but nonesense IMHO) and force people to do more fights. It's more challenging for example playing in a triangular arena where none of the walls is orthogonal.

But as phillipeqc suggested somewhere he has in mind to change that behaviour of only turning in 90 degrees.

[philippeqc]

I have one doubt: In some pictures I see a polygonal arena but with the cycle moving as usual (always in front, 90 degrees left/right turns)…

I think you confuse camera view with freedom of motion in the game.

(Most probably, the following comes from english not being our first language) The bike is in "front" because the camera is "behind", and its easier for our monkey-decendent brains. Maybe you havent had the chance yet to play with the different cameras offered in the game. In "player setup" "first player" "camera configuration" remember what key is assigned to "change camera" or something similar. Then go in game and experiment. A few cameras need you to move the mouse to change their position and orientation.

As klax mentionned, I proposed to change that "90 degree only". You will find this detail in http://guru3.sytes.net/viewtopic.php?t=986 at the end of the FIRST message. Search for "direction" in that message.

Also, the picture come must come from a "simpler" change that only affect the shape of one arena. My proposed changes are somewhat more complex. I appologize if I wasnt able to convey this easily in my post.

I think that the new arenas shapes should be based, at least in a first phase, only in polygons with the outer walls making internal angles of 90 or 270 degrees between them… that would perhaps simplify the collision procedures, the detection where the outer walls are, the ability to ride the outer walls… something like what was used in TRON2.0 Game Arenas… And with some death zones in the middle of such arena we would already have more variety.

I havent seen any collision code yet in aa, but I dont think that the world shape would improve/worsen it.

As for the ability to ride outer wall. I'm not for or against it. I just want to make code that support MANY thing, and let it to map designer to decide if they want it in their map or not.

As for any internal angles, the game REALLY doesnt like that at the moment. Get the code, go to src/game/gArena.cpp, go to the method "PrepareGrid" and set the points as you like them. You will see what I mean. One bug has been found there. On the first Insert, the point should be scaled like the other ie: *sizeMultiplier.

There is already code for a "arena description" downloader and a parser (not it is hard coded in the game). Except for internal angles, the problem of "having the rim in shape X instead of a square" is nearly fixed. I'm more on the problem of 3D shaped world.

Starting with a TRIANGULAR Field

... snip...

If cycle starts heading east / west it would follow a path parallel to the wall opposite to the BA

Changing direction would be made with left / right turns but the angles would vary in order to make the light cycle follow the parallel (orbital) lines or the radial lines…

Wouldn't you get a similar behavior with direction = 6 and triangular arena in my proposed model?

If I understand you hexagonal model properly, except for some different behavior if you are "near" or "far" from the rim, its one case that could be covered with my model. You also see the need for many fields, each with their own set of direction and some mechanism to deal with the passage from set of direction to another as you change fields. Good! Good! You should join the team

Overall, you present a case of regular polygon with orbital trajectories. I'm quite sure that it wouldn't be that hard to write a map that define a world behaving exactly like you described. What I hoped with my model was that it could allow for many new interesting ideas, like the one you proposed.

The difference is that you add the notion of Big Attractor, while I think that just setting the direction for each field in the map would be
a) simple to code
b) allow more flexibility with scenario such as"what if an hexagon has an attractor at each corner" OR "what if you stretch the hexagon in one direction and place 2 attractors inside" being at the reach of anyone with a text editor willing to write the maps instead of needing a engine re-write.

Surrounding the arena would then be half of a sphere (the coliseum) with the sky texture and surrounding scenario textures… Coliseums would have then links to other coliseums (servers)…

NOOOOOOOOOOOOOOOOOOO!

Colliseum are NOT server!!!! They CAN be, but they are NOT automatically! It is a POSSIBILITY in the model. I've taken great care to allow for it.

Sorry, it had to be said. People seem TOO entousiat at the idea of changing servers and seem to forget that it could be on the same machine.

From this point of view (BIG Atractor concept for non rectangular based fields) perhaps it would be better to maintain the camera relation to the grid of each field (?)…

Depends on what cam is used. If you think of the smart cam, that could make for a very jumpy camera. Imagine passing between 2 fields located at right angle. Probably for the smart cam a smooth trajectory similar to the current one would be much more easy to follow on the eye.

I think you need to play a bit with the cameras to see how they behave. Some of them would probably pass to the field where the cycle is instantly, like the incam. Its on a case basis.

Overall you propose a new idea that I didnt think of, but can be covered by my proposed model. You use many of the concepts such as multiple fields and set of direction for each. I sure hope that will make you accept my model, and make you join the team. The more the merrier. And what if you are not a C++ coder, you can still read and understand it, and after a short time, you could feel at ease and help with your own contribution

-ph

[philippeqc]

Starting with a TRIANGULAR Field
… isosceles… base line with east / west direction, top vertice pointing north
top vertice = big atractor (BA)

IF cycle starts heading north / south it would follow a line that would take it into /away from the BA

If cycle starts heading east / west it would follow a path parallel to the wall opposite to the BA

Humm, I've re-read you post.

One thing that bothered me but just couldnt understand was the motion toward/away from the BA. Now I understand it. You dont want paralle motion, you want all motion to be exactly toward the BA, all the lines pointing toward a point.

May I note that you seemed insistant to preserve griding, and that this behavior would make it dificult for motion toward/away from the BA.

What you propose would be some kind of hybrid system, a bit radial (toward/away the center), a bit regular (paralelle to the outerwall in this case). So only 4 direction possible (away/toward the center counting just as 2 rather than infinite).

At the moment, my proposed system CANT support that. Sorry, I misread your message, and my example then doesnt cover your special case. One element that I didnt mention before that could allow for it would be to compress dimensions. Take a rectangle that is higher than large. Lets distord it so that the base is shrunk, making it looks like a triangle with the tip in the ground. All lines that run on the height now point to the imaginary tip of the triangle. 6 of them side by side would make an hexagon. It must be possible to compensate for "speed loss" so that you cover more distance on the horizontal line closer to the ground so that your speed over compressed territory doesnt change. That would fit exactly your case.

The problem is that I'm far from having my model implemented. And I dont have the distortion math ready.

On another slightly related note, I thought, some time in a late future, to add fields where motion would be radial, ie one set goes to/away from a point, all other go on circles around that point. Of course the shape would be free, ie: could be convenient for radial motion such as having an inner radius, outer radius and angle of the field (from >0 for very small angle to 360 for full circle). [Personnally, I would implement that with a rectangle distorted around a point, but that's just me.] Also, it could be a "any shape" field with its direction system set around a point.

It will probably be at similar time as there is work on all the sphere/cylinder shapes. Check the old post for discussion on that. There was QUITE a lot on that topic. (I'm not the only one on that idea)

All help is welcome. I hope these different pointers will make you curious and try to jump in the code. Pick something that you want to fix and try to fix it. In the worst case, you'll get to learn a LOT about armagetronad and C++.

-ph

[philippeqc]

So start by taking the camera from the grid and assigning it to the game then?

Then you will realise that this is QUITE a job

You have to remove the cameras from the eGrid, and then the cameras have a pointer to the grid in them, or get it passed quite loosely.

AT this point an analysis is required to figure out what goes in the scene and how to get it.

On the WHAT
let pretend that the camera know on which grid it is, what ever that may mean (1). What other structures must be drawn. From the current grid, you should get the arena. From the arena you get all other fields that build it, and the colliseum. From the colliseum, you get all the other arenas and so forth. I guess that should be me who fixes that code.

On the HOW
Even if the arena only has 2 fields sitting on the same plane, side by side, one probably must be draw before the other (fartest first, then closest). I think you should read about opengl and general 3D rendering to figure how to do this. Much later we will inclide them differently, and later after that play with closed (inside of a cube) and open (surface of a cube) arenas. And after that, we will check about rendering neighboor arenas.

-ph

(1) think of the smart cam floating behind, vs the in-cam, vs some of the free cams

[Lucifer]

Does the camera have to be owned by anything?

Let's say the camera has a pointer to what it's watching (weak casted). And it otherwise floats freely. To determine *how* to watch whatever it's watching, it could do:

mSubject->GetMethod()

Then the thing it's watching can be anything, but you'd probably want to start by making the thing a cycle object.

The grid should own the cycles, walls, obstacles, whatever, and define its shape and so forth. The Subject I just invented needs an interface to get the arena, so a cycle would return it's owner's ->GetArena (assuming the owner is a grid) while the grid would return its owner's ->GetArena, and the Arena would return itself. This problem, at least, inheritance can solve. (I'm a big fan of not using inheritance to solve every single little problem that comes along)

I don't actually know how much work any of that would be. Maybe the camera should be owned by a viewport instead, and the viewport would own a camera instance for each kind, but it would only use the current camera? (Current camera being defined by the player) Since the cameras would all store pointers to the rest of the arena, well. Um, hm. Maybe I should actually look at the code?

that's my armchair recommendation, anyway.

[Your_mom]

Hope you guys can get this to work.

[philippeqc]

Does the camera have to be owned by anything?

Sorta kindish yeah.

For sure not any world structure. Not even the empire. (1)

Either is the game (the object) or the game (the application, some kind of static thingy).

But cameras are called often to re-display the scene at every increment of all the status. So they should be easily accessible from there.

Let's say the camera has a pointer to what it's watching (weak casted). And it otherwise floats freely. To determine *how* to watch whatever it's watching, it could do:

mSubject->GetMethod()

yes yes. but I'm having trouble having classes a, b, c, d, e in a hirearcal fashion (a owns some b's. b own somes c's) and having them query about their owners owners.

Then the thing it's watching can be anything, but you'd probably want to start by making the thing a cycle object.

yes, but the cycle has a pos and the cam has pos. But what grid gets picked?

-ph

Take me drunk, I'm home!

1) I've got an extreme case to justify this. 2 players on a computer playing on the net. One so so, the other a pro. Somebody notice the pro and invite her/him to join a select server for those very good players that you never hear again from. So now the client has to deal with 2 empires....

told ya it was an extreme case. But it shows that empire can own the cameras.