The Recognizer Revisited

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
Post Reply
User avatar
Tank Program
Forum & Project Admin, PhD
Posts: 6711
Joined: Thu Dec 18, 2003 7:03 pm

The Recognizer Revisited

Post by Tank Program »

It occured to me that it might be possible to simply render supertards recognizer model in the middle of the deathzone, and leave it at that. The zone still circles around it, but no more code is needed to move it around or anything, as the zone code for that would take care of it. In map files you could specify object to be rendered in the middle of a zone, or if no object was to be rendered. It would fit in with zones becoming more customizable.
Image
User avatar
Tank Program
Forum & Project Admin, PhD
Posts: 6711
Joined: Thu Dec 18, 2003 7:03 pm

Post by Tank Program »

Any comments from anyone at all?
Image
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

And the MCP for fortress zones. Certainly not a bad idea.
User avatar
joda.bot
Match Winner
Posts: 421
Joined: Sun Jun 20, 2004 11:00 am
Location: Germany
Contact:

Post by joda.bot »

I guess the idea is good, but wouldn't it just mess code up more ?

If there is a good solid resource loading, I'd think that would be ok.
EDIT: Perhaps a basic Gameobject for Placed 3DModels should be available too ;)
User avatar
philippeqc
Long Poster - Project Developer - Sage
Posts: 1526
Joined: Mon Jul 12, 2004 8:55 am
Location: Stockholm
Contact:

Post by philippeqc »

For the current form of zones (like death/win/fortress at the moment, as an opposition to a shape drawn on the floor like detailed here http://forums.armagetronad.net/viewtopi ... 9751#39751), I'd like to see a bit more information presented.

From the top of my head, the following attributes are quite important to advertise for a Zone:
- Who is the owner of the zone
- Who is the user (*1)
- Who is the target (*2)
- What is the effect

This is quite a lot of information to present in the blink of an eye.

What I thought was first to affect the pattern of the zone itself. Now we only use a dashed pattern on the circle, but nothing prevent us for making other similar, simple patterns. A pattern could be replacing the rectangles by equilateral triangles pointing upward. Another would have the triangles pointing downward. Another could, instead of having all the rectangles be all full size, alternate between one that is only the bottom half, one that is only the top half. It would be important to keep to simple pattern so as to not impair on the rendering performance, and also, so the pattern used can be identified in the blink of an eye in gaming condition.

The pattern would be use to display the effect of the zone: rectangles for win, upward triangles for teleport, downward triangle for fortress, etc.

To display the remaining information, 3 colored bands could be drawn horizontally on the zone. The top one would be the color of the owner. The game color of the cycle if it is of a single player, some computation(average, median, official, etc) on the color of all the member of the team owning it otherwise.

The middle band would be who is the category of the user. Some assignment between easy to distinguish color and possible values for user would be determined. It would give us something like blue=owning team, purple=anyone but owning team, green=all players, etc.

The bottom band would be the target of the effect. Again, a color mapping between different easy to distinguish color and possible values for target would need to be determined.

As the "user" is probably the second most important information to deliver after the effect, it might be possible to give is more space on the pattern. Something like 3/5 could acheive this.

While the owner of a zone is really easy to determine, the effect shouldn't cause too much of a problem as it would rely on simple patterns of a limited number, the other 2 details are more complex. First and foremost because they are relational. The user express something in relation to the owner. Attempting to color it according to the cycle colors of the players who qualifies as users will often deliver shades of grey when many are concerned, or a single color that might be close to the true color of many players when only one is the valid user, hemptering any reading of information. Alternatively, dividing the band and giving the color of all the valid users will provide an overflow of information in many cases. While color coding the different values of the middle and low band forces some effort on the part of the player, it also enable for deterministic information, and a chance to learn them.

When multiple value would need to be expressed, for example if the zone have different combined effects, the first one would be used. While this might allow to "hide" an effect by exposing one that is configured not to affect the game (example: advertised effect is "give points" and the amount is "0"), it has never been my intention to limit action by imposing restriction, but rather to encourage interesting and intelligent behavior. In other words, abusing this will displease the players, which will leave the map unplayed, and carefull usage will amuse them, when done properly.

Because of the coming model, I feel that we should promote a display mechanism in the fashion of the one documented before. The idea of a model over the zone can be quite complementary to the proposed idea. For example, a zone that would be configured to kill anyone entering it (no owner, user:everybody, target:person who triggers it) could have a recogniser over it. A zone that would kill all the players of the team owning it (owner: team blue, user:anyone not from team blue, target: team blue) could have a skull floating over it. The model would gain to be much simpler, to avoid penalising players with slower hardware. Also, the floating shape around the center of the zone with its bands might be removed when the model can provide the full information required by the players.

The appeal of the model is even greater when the zone is not enwraped in a shape, but rather drawn on the floor (like detailed here http://forums.armagetronad.net/viewtopi ... 9751#39751), and the zones are used in simpler configuration, such as "everybody" or "only once", and provide simple effects, for example the kind that is normally assigned as bonus in racing games.

So there is some place for models over zones, but I think we should be carefull not to add them only for a decorative purpose, but rather invest them with the capacity of displaying vital game information.

-ph

Quick reminders:
*1 : the user is not necessarly the owner. A user is someone who can trigger a zone. If the zone is owned by "team red", the user could be "any enemy of the owner", which would be all players of team blue, green and yellow for example.
*2 : the target can be also different than the user and the owner. It could be "any single dead player from the team of the user". So if a blue player would take the zone, then he could affect a dead player on his team, and yellow could also do the same.
Canis meus id comedit.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

I admit I didn't read your whole post because I'm troubleshooting my wireless card right now, but I'd like to see the zone rendered as it was before, only with a ring the same color as the dashes, placed right on the floor. Possibly another ring above it about two heights of a cycle, touching the dashed pattern we have now.

I like the mcp idea z-man had, I'm concerned that while it would look really cool, it would also result in the boundary of the mcp being an obstacle to game play, much like silly and I have both observed the existing dashed pattern can be from time to time. (Only happened once for me, though, it's not a big problem)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
philippeqc
Long Poster - Project Developer - Sage
Posts: 1526
Joined: Mon Jul 12, 2004 8:55 am
Location: Stockholm
Contact:

Post by philippeqc »

Lucifer wrote:I admit I didn't read your whole post because I'm troubleshooting my wireless card right now, but I'd like to see the zone rendered as it was before, only with a ring the same color as the dashes, placed right on the floor. Possibly another ring above it about two heights of a cycle, touching the dashed pattern we have now.
There are many variations. could be "colored filled band" + "colored pattern band" + "colored filled band" (make all the combinaisions where you remove one or 2). I'm concern that will all new capacities of zone coming, players will want to know what they are facing, so I've been looking at a way to provide it.

The "pattern" idea was inspired of a mod someone (I forget who) did where the win/death zone on his client where a full circle except for a single opening. This qualifies as a simple pattern for me.

I'll stop now and wait till you read it.

-ph
Canis meus id comedit.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

Haha. Am I losing my mind? I had concluded that there was a nuclear blast nearby that took out my wife (who was at the school taking a test, she's starting school this semester), and consequently also my wireless connection. It just started working as mysteriously as it had stopped.

Ok, zones. I think you're missing some other important visual aids we can use to communicate what we're trying to communicate. Currently, the fortress zones show one excellent way of doing that, they spin! So, the motion of a zone, one way or another, can be tapped as another channel of communication.

I'm not a big fan of colorcoding, but I'll happily concede the base polys should be color-coded. Then we need to layer on textures that do a better job. For example. the zone we have right now, but grey, and with a skull and cross-bones on each dash. What does that mean to you? Means poison to me.

We can also pull shapes from road signs, and other signs that appear. The nuke symbol is universal (insofar as this planet is the entire universe). What does it mean when the zone has a series of nuke-symbol-shaped meshes rotating in a circle? I'd take it as a radiation hazard, and if you're in the effected area too long, kaput. If we had a health rating, then being in it would drain your health.

There are a few more considerations. Height being one of them. A fortress zone rendered as the MCP would really rock, but it would also be really freaking tall. That's cool! But when we get multi-layered maps, the effect could be the wrong effect wanted by the mapmaker. Maybe the mapmaker wants to hide the fortress in a cave. Other effects need to be capable of being seen from lots of places, such as a winzone. (OT: calling a winzone a "gayzone" is no different than calling it a "jewzone" or a "nig gerzone". It's still bigoted, no matter how you put it) Still, I could see a map where you're being "dropped" in a test of survival. After being dropped, you're required to proceed to the center of the map, evading numerous localized threats. When you reach the center, you have to wait for the pickup, which will be a winzone that appears at timed intervals. You should only be able to see this winzone when you're near the center. If you get lost, and you're stuck far out, tough cookies hookie.

All this points to something else I've mentioned, phil. :) Presentation directives should be separate from the map. ;) We should follow the xhtml model and make stylesheets that provide both visual and audio information for the map elements. Then a server admin can make his own stylesheet for his server, and the stylesheet for the map will inherit that. Mapmakers should be encouraged to only use styles they absolutely need in their maps. Some will need all of them, some will only need a few. That way, server admins can have their own personality stuck into each map they serve up. And all maps we ship by default should allow completely customization by the server stylesheet. :)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
philippeqc
Long Poster - Project Developer - Sage
Posts: 1526
Joined: Mon Jul 12, 2004 8:55 am
Location: Stockholm
Contact:

Post by philippeqc »

Quick reminder, the 4 details I'm talking about are:
- owner: the zone is given to a player or a team or no one.
- user: Who can trigger the zone in question. The zone can be limited to its owners, but can also be restricted to players that are not its owner. A winzone that you own but can only be used by your enemies is a form of capture the flag. you cant win by passing in it, but need to protect it from all the enemies.
- target: Who receive the effect of the zone. Often it will be the player who triggers the zone, or it's team. But it could be "another player not in the user's team", sending a nasty effect to one of your enemy.
- effect: this describe what happens once the zone is triggered. It could be "give points to the target", "make target win the round" (winzone), "make target lose the round" (deathzone) or "teleport the target to a random new location"

You can find more information in this document http://forums.armagetronad.net/viewtopi ... 3881#33881
---------------------------------------------------------------------------------

I like the idea of rotation as an indication of the "time left" for the zone. The faster it turns, the closer it is to dissapear. I your pick-up example, the winzone needed to escape would appear nearly non rotating in the place of the pick-up and slowly accelerate. From the side of the eye, a player can evaluate if she/he has time to reach it before it dissapear again.

The hickup wiht texture is that not everybody uses them. They can be a great tool to display one of the 4 details I've mentionned in a secondary, hopefully easy way to decypher, but I would not make them the sole bearer of one of the 4 details. They could also be used to display combined information, like you say

Separation of information and presentation: Neat idea. In the map, a map desinger only detail the properties of the zone. Even in a pattern, owner color and dual color coding scheme, the presentation directive could easily be specified in an outside file, and hold the for effect x use pattern y, for user of type z use color c. This also has a positive side effect that the development team doesnt need to debate if spades or clovers make a better pattern for teleport ;), We can provide a resonnable default, and anyone can change it as desired. (*)

The problem that need to be addressed to remove color coding is the sheer number of possible combinaisons of types:
user: all, owner, ownerTeam, allButOwner, allButTeamOwner, anotherTeammate.
target: self, teammate, team, all, allButSelf, allButTeam, another, anotherTeam, anotherTeammate, anotherNotTeammate, owner, ownerTeam, anyDead, allDead, AnotherTeammateDead and anotherNotTeammateDead.
effect: win, death, event, clearTrace, teleport, spawnPlayer and none.

Roughly: user (6) x target (16) x effect (7) = 672

I know if feels bad to rely on color coding as it would force a memory exercise on the part of the players, but it would be one of 6+16+7=29 types. Trying to find a single appropriate representation, even for the most common combinaison, will surely be of higher magnitune than this.

In other words, while it may feel bad to rely on such mecanism, I'm quite positive that this is the method that will hold the best results in game.

-ph

* I just remember a good management example. The only one I know. Lets say you have a fleet of trucks for your employes, and need to update them. Should you consult your employes about it?
-If you only have budget for a few vehicule, choose and buy them, then let the employes decide how to reassign the trucks among themself. Maybe they will pick a "most senior get newest truck" or a "most people are happy with their own truck and dont want to change, so instead give the new truck to the drivers who have the wrost ones". This will make them happy as they have a say and an influence in the matter.
-If you have budget to update the whole fleet, do not consult them on which model to get. No two person will agree on which is the one to get, so every body will be unhappy that they their opinion wheren't listen to. Instead pick the model, buy them, and give everybody a new truck.
Canis meus id comedit.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

Aha, the idea behind coloring the polys according to whatever scheme you dream up is that a well-thought texture will use them (via alpha channels) to make it part of the texture. :) So say you have 4 bands that go across, and a skull and cross-bones as the base graphic. Then you lay on patterns of alpha'd pixels in the texture to turn the color-code into a design of some sort, where each band gets its own special design. So you get both, color-code and pattern, the same information presented two different ways simultaneously, and a decent shot at the system being discoverable, eliminating the need to memorize. :)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
philippeqc
Long Poster - Project Developer - Sage
Posts: 1526
Joined: Mon Jul 12, 2004 8:55 am
Location: Stockholm
Contact:

Post by philippeqc »

neat

-ph
Canis meus id comedit.
User avatar
Tank Program
Forum & Project Admin, PhD
Posts: 6711
Joined: Thu Dec 18, 2003 7:03 pm

Post by Tank Program »

I just thought it'd look cool :?.
Image
User avatar
SuPeRTaRD
Round Winner
Posts: 300
Joined: Fri Nov 05, 2004 11:53 pm
Location: bedlam
Contact:

Post by SuPeRTaRD »

be nice if you could put semi-transparent texture on it..

but you cant! ;p

i still need to make a new one with better chestplate & put the "grip" at the bottom.. so if it grows it doesnt grow into the floor..


i'll try to get around to that next week
ŠüþéRTàRÐ
User avatar
SuPeRTaRD
Round Winner
Posts: 300
Joined: Fri Nov 05, 2004 11:53 pm
Location: bedlam
Contact:

Post by SuPeRTaRD »

i got around to it! the chestplate now glows the color of the trails & so do teh edges of the mesh.. i had mapped the chestplate a funky way & it looked cool on my computer, but i noticed on someones laptop, some graphcis cards made the chestplate invisible,.. so i changed it,.

I also changed the axis/grip point of the model even with the feet of the thing, so if'n it ever needs to grow/rotate, fly above ppl, ppl will know where the grip is now.. & if it grows, it wont grow into the floor, it will grow twoards teh sky.. blah..

if'n y'all want bloody razorblades in a circle around the bottom for a killzone, ;p or one that floats higher above the grid like in the movie lemme know..
picture:
http://forums.armagetronad.net/download.php?id=807
Attachments
recfin2.zip
new chestplate & axis/grip
(33.73 KiB) Downloaded 433 times
ŠüþéRTàRÐ
Post Reply