Features I would like to see

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
gnorty
Core Dumper
Posts: 187
Joined: Wed Nov 02, 2005 2:45 am

Features I would like to see

Post by gnorty »

I understand phillipe may be working on some of this stuff, so really this is to see what is happening, what is possible and what is just not possible. Most of spring from ideas I have for various maps which use slightly different gameplay to the usual.

Discriminative kill/win zones - is it possible that a kill/winzone is active for one team only? preferably clients would not show zones that are not active for their team. Could this also allow us to specifically allocate a fortress to an arbitrary team instead of just the nearest?

Spawn points allocated to specific teams - say one team spawns in wingman format in the center, and the other team spawns from the rim in 2 battle groups. the key is that the ownership can be specified in the xml for the map.

Different maps for each team- say I have maps gnorty1a.xml and gnorty1b.xml. How easy to get blue team to use 1a and gold to use 1b? Of course the differences would be minor, but would allow gold players to appear to travel through walls to the blue team etc.

Teams staying where they start - Say I have a 1 fortress map where 1 team attacks and the other defends. I would like the roles to stay static and not switch from time to time.

team names and colours to be specifiable in config.

some cycle attributes to be varied according to team. ie maybe blue has long walls and high speed, and gold has more rubber and short walls.

User avatar
Z-Man
God & Project Admin
Posts: 11291
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne, Jabber: [email protected]
Contact:

Post by Z-Man »

A good collection overall.

Better spawnpoint and zone ownership control, as well as more interesting zones, are indeed part of Philippe's spec.

The "different maps for different teams" idea would be an extremely ugly hack and wouldn't always work. What if two players on one PC are on different teams? It would be better to add the desired game elements, walls passable by/visible for only one team, directly.

gnorty
Core Dumper
Posts: 187
Joined: Wed Nov 02, 2005 2:45 am

Post by gnorty »

z-man wrote:walls passable by/visible for only one team, directly.
That would be cool also :)

User avatar
philippeqc
Long Poster - Project Developer - Sage
Posts: 1526
Joined: Mon Jul 12, 2004 8:55 am
Location: Stockholm
Contact:

Re: Features I would like to see

Post by philippeqc »

Wow, you have quite a list. And as a compliment, of all the "I have an idea" post, yours is well structured, well thought. It show that you did your homework.

gnorty wrote:Discriminative kill/win zones - is it possible that a kill/winzone is active for one team only?
This is defenitively coming. I have working code that already support this. The map format is drafted. What is missing is the glue between the description on the map and the actual team or player in the game.
As for the discrimination, i'm aiming for more complex scenarios, but the "only the owner can" will still be there.
gnorty wrote:Could this also allow us to specifically allocate a fortress to an arbitrary team instead of just the nearest?
Yes. To an arbitrary team or teams and/or to an arbitrary player or players. So you could define a death zone that only kills the team leaders, or a fortress that appear over the enemy start location (the opposite of the classical fortress), or that only the 2 player on the tip of the wingman formation (1) migth defend the team's zone and that only the players of team red and green can conquer that zone (and not the players of blue and yellow). If you are curious and armed with
gnorty wrote:preferably clients would not show zones that are not active for their team.
I'm not going in that direction. Or rather, I didnt consider it before, but I think to fully support the ownershipt model that I want, it would be overly complex to try to do that.
gnorty wrote:Spawn points allocated to specific teams - say one team spawns in wingman format in the center, and the other team spawns from the rim in 2 battle groups. the key is that the ownership can be specified in the xml for the map.
At the map level, what associate a player to a zone is the same mecanism that associate it to a spawn point. So that part will be there. Mecanisms to sort out how to assigne a player to a spawn point is needed and also a good system when multiple are possible are to be designed (ask the user is one way, what are the other?). Check the spawn point document for more details. But it is now a bit old, so it really doesnt consider "formation".
gnorty wrote:Different maps for each team- say I have maps gnorty1a.xml and gnorty1b.xml. How easy to get blue team to use 1a and gold to use 1b? Of course the differences would be minor, but would allow gold players to appear to travel through walls to the blue team etc.
Not on my roadmap. As z-man pointed out, technically complex to implement. I'd guess you will find an easier solution with zones when they can other shapes than circle.
gnorty wrote:Teams staying where they start - Say I have a 1 fortress map where 1 team attacks and the other defends. I would like the roles to stay static and not switch from time to time.
I'd say it falls into Joda's area, ie: player and team assignment.
gnorty wrote:some cycle attributes to be varied according to team. ie maybe blue has long walls and high speed, and gold has more rubber and short walls.
Very good idea. Extremly good idea. I'd guess the first work of that type will be to allow walls to have different textures. But this would fit very well in the map/css model we have. So I'd give it a good chance, but much further down the line.
gnorty wrote:team names and colours to be specifiable in config.

I recall seing something to this egard recently on the forum. Part of it might be relating to the config/map rotator, or it was z-man telling how a server admin could change the default name of the teams and default color from the config file.
As for a better implementation, I'd say it migth also fall into the map/css model.

So I hope this gave you at least some answers to your question.

Hope you got hooked!

-ph

The spawn document can be found here
http://forums.armagetronad.net/viewtopi ... 3911#33911

(1) No plan to support exactly this at the moment (the two player on the tip of the wingman formation), but it must be possible. And it makes for a relatively easy example.
Canis meus id comedit.

gnorty
Core Dumper
Posts: 187
Joined: Wed Nov 02, 2005 2:45 am

Post by gnorty »

Thanks for the replies. sounds like I will be able to have some fun with the new stuff :)

another ideas I thought of (and forgot about when I posted) :-

a configurable object similar to the zombies in pigs hack. something that can move around the grid, influenced by the players around it. If this object could be used to trigger another object in the same way a player would, thaty would be great. ie, a fortress triggered not by the players, but by the presence of a mobile object. Does this make sense? it is kinda hard to explain

Teleports - zone at point a respawns player to point b. simple!

User avatar
philippeqc
Long Poster - Project Developer - Sage
Posts: 1526
Joined: Mon Jul 12, 2004 8:55 am
Location: Stockholm
Contact:

Post by philippeqc »

gnorty wrote:Thanks for the replies. sounds like I will be able to have some fun with the new stuff :)
No problems. Its always fun to have someone interested in the work your are doing. I just hope I'll be able to deliver it soon enough so you dont lose interest.
a configurable object similar to the zombies in pigs hack. something that can move around the grid, influenced by the players around it. If this object could be used to trigger another object in the same way a player would, thaty would be great. ie, a fortress triggered not by the players, but by the presence of a mobile object. Does this make sense? it is kinda hard to explain
this has come a few times in different form.

First of all, zones will support some motion. Nothing as complex as that, but some basic capacity.

Second of all, for more advanced capacities, I'll ask you to wait until scripting is implemented.
Teleports - zone at point a respawns player to point b. simple!
On my list too. It is actually on many of my lists ;) I want that for zones like you describe, for cycle special power (I dont personnaly like it, but it is always in demand), and mostly, it will be required for my over promised "multi-field" arenas. But the teleport capacity will involve quite some engine medling, and will/should be quite an effort.

-ph
Canis meus id comedit.

User avatar
Self_Destructo
Round Winner
Posts: 317
Joined: Tue Jun 07, 2005 1:24 am
Location: HillBilly Country
Contact:

Post by Self_Destructo »

What about the ability to specify _conquest and _defence for a specific fortress? Kinda like an easy conquered zone inside a big sumo zone. The big zone has a different setting than the small ones.

User avatar
ed
Match Winner
Posts: 613
Joined: Mon Feb 13, 2006 12:34 pm
Location: UK

Post by ed »

Some great new features on the horizon there.
I'll just throw in a few idea's that may/may not have been considered:
philippeqc wrote:I want that for zones like you describe, for cycle special power
By this do you mean a zone you can assign special cycle attributes to, ie:

For a speed boost zone:

Code: Select all

   
<Zone effect="special">
    <ShapeCircle radius="40">
     <Point x="128" y="64"/>
     <Setting name="CYCLE_SPEED" value="100" />
    </ShapeCircle>
   </Zone>
maybe one to replenish your brake/turbo:

Code: Select all

   
<Zone effect="special">
    <ShapeCircle radius="40">
     <Point x="128" y="64"/>
     <Setting name="CYCLE_BRAKE_REFILL" value="1" />
    </ShapeCircle>
   </Zone>
Where those attributes are changed only whilst inside the zones.

How about moving walls, this must have been considered, where you can have doors opening and closing between parts of the arena.
Maybe even doors opening whilst you're inside a zone to let your partner through, or to leave just enough time to get through yourself.
If zones could have attributes, maybe they could be used only once then they're gone.
It would be like tomb raider for tron.

With this funtionality, not only could you make some wild fortress maps, but you could quite easily make a 1 player puzzle game based in the tron arena.
Or a 2 player online puzzle that takes 2 players cooperation to complete.



Or am I getting carrried away?

User avatar
philippeqc
Long Poster - Project Developer - Sage
Posts: 1526
Joined: Mon Jul 12, 2004 8:55 am
Location: Stockholm
Contact:

Post by philippeqc »

Self_Destructo wrote:What about the ability to specify _conquest and _defence for a specific fortress?
Yes, zones will be assigned properties individually.
ed wrote:By this do you mean a zone you can assign special cycle attributes to, ie:
Well, it is high in demand, and I while I dont actively work on for this, I feel it would be very easy to implement. Starting with wrt's callback mecanism, a zone has a deep reach into all the corner of the game.

How about moving walls, this must have been considered, where you can have doors opening and closing between parts of the arena.

Maybe even doors opening whilst you're inside a zone to let your partner through, or to leave just enough time to get through yourself.
If zones could have attributes, maybe they could be used only once then they're gone.
It would be like tomb raider for tron.
Zone will move, and I'm looking how to have effect like counters, or triggers. So if you combine both, one zone could make another move. Walls dont move (unless there was some big change in the core) sadly.
Or am I getting carrried away?
Not by much actually.

-ph
Canis meus id comedit.

User avatar
ed
Match Winner
Posts: 613
Joined: Mon Feb 13, 2006 12:34 pm
Location: UK

Post by ed »

okay, walls don't move.
But you could have a dz blocking a doorway which could move back and forth, this would have a similar effect. And if that movement could also be triggered by another zone a lot of fun could be had inventing and playing these maps.

gnorty
Core Dumper
Posts: 187
Joined: Wed Nov 02, 2005 2:45 am

Post by gnorty »

philippeqc wrote: Walls dont move (unless there was some big change in the core) sadly.
-ph
Have a word with the guys behind Merkurium. I was playing there earlier, and the cycle trails were moving all over the place. Maybe you could modify whatever hack caused that

;)

User avatar
Self_Destructo
Round Winner
Posts: 317
Joined: Tue Jun 07, 2005 1:24 am
Location: HillBilly Country
Contact:

Post by Self_Destructo »

philippeqc wrote:
Self_Destructo wrote:What about the ability to specify _conquest and _defence for a specific fortress?
Yes, zones will be assigned properties individually.
Ah, I shoulda asked if they could be in groups, and the set settings for that group. Like: <Zones><Settings... /></Zones>

User avatar
kyle
Reverse Outside Corner Grinder
Posts: 1850
Joined: Thu Jun 08, 2006 3:33 pm
Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
Contact:

Post by kyle »

What about being able to control the shape of the zones

Also being able to say which team has which zones in fortress mode

Another thing having different sets of axes for each team

User avatar
Z-Man
God & Project Admin
Posts: 11291
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne, Jabber: [email protected]
Contact:

Post by Z-Man »

The zone things are in philippe's specs of future plans. I don't know about the axes thing. Could be fun to turn them by 45 degrees relative to each other :)

User avatar
philippeqc
Long Poster - Project Developer - Sage
Posts: 1526
Joined: Mon Jul 12, 2004 8:55 am
Location: Stockholm
Contact:

Post by philippeqc »

Hi,

Thanks for your interests for the zones. I'm sorry that I havent delivered them yet. Let just say there has been lots of learning, the need of many iterations of what I had planned as a small component, and I now have to put my hands deep in the guts of the standard template library of C++ to make it do what I want (the default behavior is not to be blamed, but I just want that little extra ;) )

So, with all of that, I still need to talk in the conditional, as I havent tuggled these topics.
-ct-kyle wrote:What about being able to control the shape of the zones
That is planned. Some of it might be planned to a more basic level than what you expect (like only support for circles and basic polygones), and some of it might be planned to a much higher level than expected (Imagine a single zone that exist as 2 circle, each on an opposing corner of the grid. Being inside either would make you "in the zone".)

If you see the need for some shapes, or some types of support, dont hesitate .
Also being able to say which team has which zones (in fortress mode)
Yes.
There are 3 parts to that:
a) the map will be able to describe some owning information to the zones. Example: A map designer would make a map, and associate the zones included to 6 different teams, namely 1,2,3,4,5 and 6.
b) a logic that would associate the map information to the game information. Some of it might be quite direct, such as saying "all the items described in the map for team 1 are owned by the game team BLUE", 2 to RED, 3 to YELLOW, etc.
In some case, there might be different ways to associate the items described in the map to the team currently in play. What if there are 3 teams, and the map describe resources for 6 teams! Do you give one set of resource to each team and let the rest unused, or do you give 2 to each teams. And if so, which are left unused, or wich 2 get to a certain team.
The same logic is well placed to stir and control new "game types". Some one could try and implement a new game mode "everybody agains the winner (of the last round)". Maybe that new game mode would consider the winner a one-man-team, and give him the items described for a single team in the map, and give all the remaining items to the other players. Or it might just do the opposite, to give an edge to the poor single player.
c) What does it mean to "own" a zone? Or rather, what is the effect of being the owner?
For the current fortress zones, this concept is already there, but at a much more condesded form. If you own a zone, you can defend it, otherwise, you can capture it. In a 2 team configuration, it is quite appropriate, but what happen when you want to have 3 teams fortress? Can both teams decide to gang up on yours and capture your zone early, eliminating your team, or could it be that BLUE can only capture RED's zone, but has to defent agains YELLOW's attackers? (In a BLUE attack RED attack YELLOW attack BLUE and cant capture the other zone?)

The way I'm fixing this goes a bit like this
I) Define who owns a zone. This information comes from the map and is affected by the logic in b to find what in-game player and/or in-game team is to be considered the owner.
II) Who can use the zone. Traditionnally, this has always been "anybody". A win zone appear, it is used by the first player who enters it. A fortress zone stand, it is usable equally by players of both team (one conquers and the other defends, but both can "use" it). A valid user will more often be defined by comparing to the owners. The comparing means pretty much any expression one could dream up of is or is-not an owner or a member of the team owning the zone. Example: A win zone could exist, owned by you, and configured so that only the owner can use it (In wich case you migth find all the other players trying very hard to forbid you to enter it), or it could be set that anybody but the owner (you) can use it to win the game (In wich case, you might find yourself fighting hard to keep anybody from entering it).
III) Finally, who get to receive the effect, in other words, who is the target of the zone.
For the classical win and death zone, it has always been the user, ie: the player entering it, that was the target of the effect. In fortress, if you capture the enemi's zone, while you get the points, there are settings where the defending team was all killed. In this case, they where the target of the killing action, not the player who actually captured the zone.
So the target gets to be determined using the information of "who is the owner" and "who is the user". The target can be determined using again nearly any combinaison of is or is-not, for the owner and/or the user, and can include wheter the target has to be or cant be a member of their team. Yes, quite complex. Lets break down in examples:
-A zone could give a bonus to a teammate of the user, as long as its not the user itself. This could be quite a beneficial team tactic. Fortify your teammates, and hope they do the same to you.
-A zone could give out a malus to a random player, as long as its not a member of your team. A zone in the middle of the field that would kill an enemy would be highly fought for.
-A zone could give a malus to the owning team. Like in the previous example, a random player could be killed, but this time he would be selected from the team that owns the zone.
While both examples appears similar in a 2 team configuration, they take a new meaning when more teams are involved. In the first case, when 3 teams are fighting, if BLUE uses the zone, RED and YELLOW have equal chances of loosing a teammate and might think it an acceptable risk and ignore the zone for other objectives. But if the zone is like the last case, and RED owns it, while YELLOW will be happy to leave it alone, RED will surely try their best so nobody can come and use it, penalising them from a teammate.

To recapitulate, zones have an owners, who simple posess the zone. The users, the players that can trigger the zone to produce an effect, can be described as being or not being the owners, and a target can be described as being or not being an owner and or the user.

Now that you are totally confused, just remember this
- The old behavior will still be available,
- It SHOULD allow to describe pretty much any combo of who-can-use and who-get-the-effect desirable
- It wont be as complex at that, because map designer will actually pick mixes that make sence for the game at hand, rather than my abstract examples
Another thing having different sets of axes for each team
This idea is really starting to pop up recently. I think it would be realitively easy to do. I'll have a good look at it.


-ph
Canis meus id comedit.

Post Reply