Does the server support...

[Lucifer]

There's a couple of things that have occurred to me and I thought I'd ask. My opinion on these is that if there isn't support for it, it would be well worth it to hold off the 0.2.8 release for as long as a month to get it.

1. Can a map control the winzone?

If the map can control both the timing and placement of the winzone, we can have race maps. Very simple, just set the brake to a mild accelerator, put one spawn point at the beginning of the track and the winzone at the end of the track, and only give points for winning the round, but none for dying, none for core dumping, possibly -1 for suicide. This also makes for a "solve the maze fast" map where everyone starts at different places in a maze, and the one who reaches the winzone first (by solving the maze) wins.

2. Can the map control team spawn points?

Something like:

<team>
<spawn>
</team>

This leads into...

3. Can the client support more than 1 winzone at a time?

Which includes...

4. Can a winzone be configured to only allow working on a team member?

I'm thinking capture the flag here. You'd set in the map how many teams are allowed, set up their "flag" to be a winzone that starts immediately, or maybe not, but has a set location on the map. Then your team members can't win by going through it, but if anyone of the other team passes through it, then you do one of several things:

A. The team wins!
B. All winzone have to be passed before a winner can be announced, the winner is the one with the most!

[philippeqc]

Excellent ideas. I would put a fifth in there too:

5. Can the map control the growth rate of the winzone(s).
For the same race in maze maps, a map designer could place a winzone using a classical growth that appears after a certain time, and grows until it gobs up all the players. But controling the growth, it could be set to 0, ie: the winzone just appears at a specific location at a specific time and specific size and stays there until the end of the game.

By itself, this feels like something you assumed in your proposal (or something that I just didn't read). But having worked as a tester in the past 8 months told me that if its not clearly specified, then it doesnt really exist. ;)

Moreover, while I understand that such simple change could bring lots of new game play into the game in this release, we should consider just holding the idea until the python scripting or risk the race of "just one more hard-coded feature".

Overall some good ideas.

-ph

[Lucifer]

Moreover, while I understand that such simple change could bring lots of new game play into the game in this release, we should consider just holding the idea until the python scripting or risk the race of "just one more hard-coded feature".

Yeah, I know. My reasoning is that maps add so much more to the game, and they're certainly making an impression on my server, but they really only hint at new stuff without quite providing it.

Here's a problem (for lack of a better word). You've been playing awhile and you can clear the grid all the time, and there's not really much left to do, but you love playing the game. You've learned all this cool stuff about how to move and have all these cool tricks, but they're useless unless you're just killing, and that's boring because there aren't many players as good as you. (That's a little off, there are lots of players in this situation, but they don't play often because, well, they're in this situation)

So what do you do?

Capture the flag gives you a different objective than just killing. It also makes a team server that much more....different...than a regular server.

Racing is everything you want, depending on the map. You get to use all your fancy moves, your fancy aim, and all that, to get around the inevitable obstacle course (nobody's seriously going to make a square/spiral race track, are they?).

While maze fighting is fun, maze solving is its own entertainment. It would be nice to be rewarded in a competitive fashion for doing that. (It would also make Jonathan's maze program that much more interesting, imagine having a random maze generated every round, which is a capability we already have to some degree)

As far as adding these things to the map, I can't see it being that hard to add it to the format itself. Just create new entities, right? Adding it to the game logic might be a little harder, how much harder? If the client doesn't support multiple winzones, and it's not going to be too easy to add, then that would probably be better to wait for. But simply controlling team spawn points and the winzone are both things that strike me as somewhat trivial to add.

When it's all said and done, 0.2.8 winds up being a much bigger release than just "oh, we have maps, and we get our old gameplay back". It also gets some primitives for making entire new games that people want to play. Hell, people already play these games to some extent, the game just doesn't support them.

So, like I say, I'm willing to delay the release to get it (but not having time to do it). I'm not willing to wait too long, simply because the new release already has stuff we badly need back on the grid. (I've been getting nothing but compliments on the settings on The Crack Pipe, even from newer players that never played pre-0.2.7.1) But any/all of these things would add so much to the game, and if I'm estimating correctly how much work they'd be, then it would be better all around to add them, even if it's stuff that has to get factored a bit for the next release.

As far as how to add it to the map format, I'd suggest treating it as "substitue the winzone for this planned feature". So if you had already intended to make a "flag" entity and the associated feature, add the "flag" entity and substitute it with the winzone for now, later add the actual flag stuff. Same with the finish line. Call it what you'd intended to call the feature of the same functionality, then substitute a winzone into it for now, later implement the actual thing you wanted. We'll be happy if our flags are floating meters above us in thin air.

[philippeqc]

Your plea has moved my hearth. ;)

I'll whip out some specs (maybe) and a new dtd during the week end.

-ph

[Z-Man]

The client should support multiple win zones; the zones are game objects that can be spawned at will. Of course, they'll look all alike.
I'd suggest to implement the features in a branch-branch of b_0_2_8; this allows us to test whether I'm right about the support for the win zones and merge it to the trunk or b_0_2_8 for 0.2.8.0 or 0.2.8.1. I'm already very careful about complicated bugfixes in the branch and try hard not to break anything; I'd have a bad feeling about rushing in these features.
The difficult part about the CTF hack would be to make sure the teams get spawned close to their own flag (actually, the best way probably is to let the flag determine what team it belongs to after it's spawned, this keeps the code nicely local), the flag logic itself is almost trivial. I can take care of it.

Philippe: We could simply allow the map to override arbitrary settings, like

Code: Select all

<console command="CYCLE_SPEED=100" />

, this would take away some work for the admin who wants to use a map. Of course, this would only be fully useful if the configuration system was any good.

[Jonathan]

While maze fighting is fun, maze solving is its own entertainment. It would be nice to be rewarded in a competitive fashion for doing that. (It would also make Jonathan's maze program that much more interesting, imagine having a random maze generated every round, which is a capability we already have to some degree)

FYI: I haven't done much with mazes. I only made a program that turns a string like

Code: Select all

+-+-+
| | |
+ + +
|   |
+-+-+

into

Code: Select all

<ObstacleWall><Point x="0" y="0"/><Point x="2" y="0"/></ObstacleWall>
<ObstacleWall><Point x="0" y="-2"/><Point x="2" y="-2"/></ObstacleWall>
<ObstacleWall><Point x="0" y="0"/><Point x="0" y="-2"/></ObstacleWall>
<ObstacleWall><Point x="1" y="0"/><Point x="1" y="-1"/></ObstacleWall>
<ObstacleWall><Point x="2" y="0"/><Point x="2" y="-2"/></ObstacleWall>

with a <Wall> around it.

[Lucifer]

I'll make some maps. I'll put placeholder tags for this stuff and post them, and scan the original drawing, and you can modify them however you need.

After I study some chemistry, do my trig homework, a couple of sections of precal, etc.

[philippeqc]

Lucifer: I'm about to type my first draft for the dtd and documentation to support your request. I'll let it simmer over night and revise it in the morning before posting it. What I can say is that it presents zones as some sort of events "holders".

Philippe: We could simply allow the map to override arbitrary settings, like

Code: Select all

<console command="CYCLE_SPEED=100" />

, this would take away some work for the admin who wants to use a map. Of course, this would only be fully useful if the configuration system was any good.

I was keeping it for Bacchus, but I've solved the problem for settings. I have some code that allow any settings to be defined at the map level, and only my infrequent visits to the forums prevented me to hear about lucifer's trouble with rotating maps. The code shouldn't break anything, but its exposing settings to map-designers that might need a bit more study.

As a positive side effect, the map can control the cycle's model, texture, and trace texture. But it is currently impossible to affect any other resource items from the map, as they are instantiated way before the map is loaded. I was looking at fixing this, but haven't come that far, but it is nothing critical to the game experience.

Now the question is, should we break our feature freeze? I would put my vote on Lucifer's argument that it would greatly improve the gameplay as these are hinted, nearly expected features.

-ph

[Luke-Jr]

There's a couple of things that have occurred to me and I thought I'd ask. My opinion on these is that if there isn't support for it, it would be well worth it to hold off the 0.2.8 release for as long as a month to get it.

These features are not part of the 028 plan by design. 028 is feature frozen and no feature can be added even if it is ready in time for the release. We could, however, add a 0.6 between 0.4 and 1.0...

1. Can a map control the winzone?

Useful also for some kind of advanced pac-map, which is what made me think of it originally. We'd want to control not only location and growth, but also movement.
Anyway, this is more of an advanced map thing, along with borders and such...

2. Can the map control team spawn points?

Don't teams share the same spawn point?

4. Can a winzone be configured to only allow working on a team member?

Interesting idea, though would this really be a winzone or a score-zone? For a real CTF, we'd probably need a new object that moves with the player and a goal-zone to bring it back to...

The client should support multiple win zones; the zones are game objects that can be spawned at will. Of course, they'll look all alike.

Not necessarily... The server can specify the zone colour starting some time before the 028 branch.

Now the question is, should we break our feature freeze? I would put my vote on Lucifer's argument that it would greatly improve the gameplay as these are hinted, nearly expected features.

We're trying to speed up new releases anyway, right? We've already agreed on a feature freeze and it wasn't even recent, so I don't see any good excuse for violating it. The bigger 0.4-planned features can be put off to a 0.6, if needed to get 0.4 out the door sooner...

[philippeqc]

There's a couple of things that have occurred to me and I thought I'd ask. My opinion on these is that if there isn't support for it, it would be well worth it to hold off the 0.2.8 release for as long as a month to get it.

These features are not part of the 028 plan by design. 028 is feature frozen and no feature can be added even if it is ready in time for the release. We could, however, add a 0.6 between 0.4 and 1.0...

1. Can a map control the winzone?

Useful also for some kind of advanced pac-map, which is what made me think of it originally. We'd want to control not only location and growth, but also movement.
Anyway, this is more of an advanced map thing, along with borders and such...

I dont think this discussion is about who presented the idea first, but about inserting a simple item that will greatly impact gameplay.While I'm spec'ing the whole shabang, it is to ensure a good transition between versions. The implementation for 2.8 (Arthemis) would be very simple.

2. Can the map control team spawn points?

Don't teams share the same spawn point?

Yes, as long as the map designer want all the players of a team to start together in a wingman configuration. I could imagine a map like HexaTRON where team members are spread in opposite rooms.

-ph

[philippeqc]

Sprinkles:
Some people dont like sprinkles on their cake. None at all. They will go at great lenght to remove them.
Some people think sprinkles can be fun on a cake if used appropriatly. Maybe you wont put sprinkles on a cake to your boss if your boss is the VP of a big company, but you would if your boss is the director of a summer camp for kids.
Finally some people think cake are only good as load bearer for sprinkles and icing as morter.

Sprinkles are neither good nor bad. It's all about knowing the taste of your public.

Zones are like sprinkles!

Now you can read what I have spec'ed about Zones. Should we go for a quick fix in Arthemis, it will be easy to downsize it to the relevant parts.

Team spawn spec's will come in a few hours,

-ph 7.0

[Lucifer]

Looks like you've got it all covered. I'd respond to the ambiguities like this:

A zone can affect dead players. That would allow respawning dead players as an effect of the zone, but there's a little more to it. You're building primitives here, that will be used to construct a larger game. The more primitives available, the more game types can be created.

A zone should be capable of instantiating many times. I can think of a map where the win zone appears only at certain intervals, sort of a basic survival game. Stay alive (in a hostile environment!) until the drop zone appears, at which point you will be picked up--if you're there to be picked up. Then the round proceeds until all are dead or all are picked up. In that case, you want the zone to award points and remove the player from the round, but not kill the player. (A map maker might choose "kill player" as the effect of the zone, since that's the primitive that's there, and that's fine, so long as there's a point award to say that that player made it)

Also, with these primitives, would it be possible to kill the player, then re-spawn that exact player? Then the zone becomes like hyperspace in Asteroids. Hit it and be randomly sent to a spawn point. Of course, it's up to the map maker to provide enough spawn points to make it truly random.

My only remaining comment is that it's not clear how the AIs are to be treated. Are they to be treated as always equal to players? Or are there conditions under which an AI can be treated differently?

Otherwise, it looks like you've nailed it dead on.

[Lucifer]

Yes, as long as the map designer want all the players of a team to start together in a wingman configuration. I could imagine a map like HexaTRON where team members are spread in opposite rooms.

I could imagine a map where team members are not only sprinkled around the grid, but then they're all required to achieve the same location to win, and they have to go through the other teams to do so. Kind of an inverse capture the flag scenario.

[philippeqc]

A zone can affect dead players. ....... You're building primitives here, that will be used to construct a larger game. The more primitives available, the more game types can be created.

The reason I've wrote the spec like this is to avoid dead players to get points while being dead. Also, in many combinaison of targets, the effect could be wasted on a dead player. This can be quite frustrating if the player that triggered it had to fight hard for the Zone, and was hoping to use it to help himself in the battle, only to end up on a dead player.

The only alternative I managed to imagine is to add a series of target such as teammateDead and anotherDead. The paragraph about not affecting dead players would be rephrased to say "not dead player, unless specified by the target". Still not sure about it all.

A zone should be capable of instantiating many times.

very temporary text.
reInstantiateAfterCreation: after this amount of time has elapsed since the last creation of this Zone, a new one is created. Any instance still present is kept. For the purpose of the new instance, the moment the new instance is created is to be considered as the time of creation. Items such as growth would use this time as their time 0.
reInstantiateAfterDestruction: after this amount of time has elapsed since the destruction by any mean, such as time of removal, persistence failing to 0 or any other factor, a new instance is created. The moment at whitch this occurs is to be considered the original time of creation for the new Zone.

Also, with these primitives, would it be possible to kill the player, then re-spawn that exact player? Then the zone becomes like hyperspace in Asteroids. Hit it and be randomly sent to a spawn point. Of course, it's up to the map maker to provide enough spawn points to make it truly random. :)

It it was me, I'd teleport them instead. ;)

Code: Select all

Teleport: The calculated target is transported to a random, valid
position in the world, irrevelantly of the field, arena or
colliseum where the target was. The trace has a terminating point
at the old position, and new starting point at the new location of
the player. No trace segment goes from the pre-teleportation to
the post-teleportation point. Otherwise, the trace behaves as if a
hole had been blown in it throught an explosion.

No, its not my best bit of writing, so no need to appologyze. That exact mechanism is needed for multi-field. Therefore teleport will be possible simple because that is how I will have the game engine treat the transition from one field to another. As the source field and the destination field will be side by side, the user will never notice a thing.

To take another aspect of your question, will it be possible to combine primitives. The short answer is that you can juxtapose Zones as long as they dont conflict. If they need an order of execution, then I'd guess the effect is always uncertain. I feel this would be otherwise better left to scripting.

... it's not clear how the AIs are to be treated. Are they to be treated as always equal to players? Or are there conditions under which an AI can be treated differently?

I've written the whole thing assuming players where both humans and AI. I didn't consider nor study giving a special behavior to AI's. Maybe I'm wrong?

Otherwise, it looks like you've nailed it dead on.

Thanks

[Z-Man]

Philippe: Looks quite good. One addition: The action of a zone should not always be triggered when an authorized player enters; the player needs to be inside the zone for N seconds. This would make it possible to make the zones in CTF so big that they can't be protected by camping, but the defender has to stay inside the zone and kill or expel all enemies that enter fast enough.

Edit about the dead player respawn: this could be an effect on a Team: spawn one dead player from your team/the enemy team/whatever team the effect targets.

Luke: without respawning, what we call CTF here is more similar to symmetric counterstrike; the flag zone of the enemy is the place where you have to drop the bomb. This could be a lot of fun, won't require too many additions and be compatible with old clients (you're right, the color is transmitted with the zone creation message; I somehow thought it was a setting item). My current favorite handling of this would be: release 0.2.8 without CTF code and push out the first development release 0.3.0 with basic zone code as Philippe designed shortly afterwards. So shortly after 0.2.8 and with all bugfixes merged back into the trunk, 0.3.0's stability is likely to be extraordinarily high for a development release, so we can recommend it to server admins who want a new game mode without getting bad karma.