New coop types (idea)

[biell]

I need the communities help. I realized we can do a bunch of stuff, and I don't have time to make all the maps myself. I also don't know if all of the ideas will work, so I would like community input if people think some of them would just be destroyed by trolls. Also, they are a little anti-climactic, so people may just not like them.

On my server, I have all of xal's extensions. Most notably, I have his "setTime" extension, which allows me to end a timed game (except ball for some reason). This means that all I need is a trigger (any powerup, just like in my ball_flag type) to run "setTime 30000" (or whatever would end the game), and viola, we have a new coop. What is most interesting, is this will work for TDM and FFA!

Just imagine the difficulty of a coop where you have to avoid your fellow players, because you can damage them. Additonally, there are new aspects. For example, boosting your fellow player across a gap by shooting them with a missle!

Here is the extra cool part, we can make a single powerup complete the game, or we can make a map like coop_jack or coop_ace, but each powerup takes a certain amount of time off the timer. So, we could set the timer to 20 minutes, and make 4 paths, each which takes 5 minutes off the timer. We could set a minimum number of powerups which have to be found for the time to count as a record. Maybe you need all 4, maybe you just need 3.

This all came to me while I was working on a 1dm_coop map where you complete the game by killing the bot, who is sequestered in a room behind a turret of his own color for the first part of the game. That one is going to take a while, as it is a super mario theme where the final room is like fighing Bowser. I am planning on using the new carry key feature so only one player can get into the room with the Bowser Bot. This one isn't going to be ready for a while, because I am trying to make something different than I normally do. I feel like my coop maps always have too much space covered by walls. So, I haven't even settled on a layout for this one yet.

So, what do people think about the new modes, will the end be too boring? Will the ffa_coop be ruined by trolls? If these are valid ideas, I wouldn't mind some help in creating the first maps of these types. Because, beyond making the maps, I have to update the Alti+ server code to support all this.

So, what do you think? Anyone want to make a map? I imagine that an ffa_coop map which takes advantage of a number of the new possibiliites would be a challenge.

[estguy]

hehe timed coop in tbd would be nice and maybe it could be even set like that that you have something like 3 lives or "lives" overall then it could be pretty fun.
Not sure about FFA coop though since idk if you can add bases in ffa for each player. Though it would be quite cool if there were like 10 different teams and 10 different bases and you'd have to bomb hop other teams' bases.
Also i'm a nice tester :P though i can start testing more activly in 2 weeks for 2 weeks and the idea is definately worth implementing

[biell]

There would not be any bases. The game would be over when you find a special powerup. If we added a bomb and a base to the map, Altitude would automatically set the game mode to TBD.

[LewisH]

FFA coop sounds fantastic ^^

Does the client still detect maps as being TBD when you add bombs & bases to the xml directly, rather than using the map editor? Perhaps there are some interesting mechanics possible with that..

An aside, related to new coop mechanics, but not so much to this thread:

Altitude's fixed game modes are a little annoying, the server can't overwrite whatever game mode the client assumes from the map. I have found that you can spawn a plane with an arbitrary team for any player, regardless of which team that player is actually in. It's also possible to spawn planes for players which don't exist. So that should be fun to play with. I'm pretty confident about my estimate of having some sort of alpha of my server software in febuary, perhaps sooner.

A few interesting things which will be possible with libalt:

- Powerups which move along preset paths with a given speed (already working)
- Powerup spawners which trigger when the previously picked up powerup has been lost or used (not implemented, but simple enough)
- Turrets which shoot abritrary projectiles (bombs, emp, randa shots, etc.) (I'm working on projectile entitites today, they're a bit odd, you don't spawn them as actual entities but through an ability event, which then contains the entity creation event but with *separate* data for the position, velocity etc, so that data is seperate from the entity in the packet format, but I'd like it to be part of the entity in my internal representation of the world.. anyway...)
- Multiple turret shooting modes (always shooting straight, tracking the player, shooting in predefined patterns, etc) (It'll be rather difficult to even emulate altitude's turret behaviour, as I'm not actually simulating the physics yet, so my player tracking depends on the player's latency)
- Triggering game events (destroying turrets/bases, time changes, spawning powerups, etc) based on player actions.
____

@estguy Have you ever played with the map editor? More people making coop maps would always be a good thing

I envision many new and enjoyable mechanics in coop's future, I might have to write a map editor and start creating my own maps, though I don't think I'd be very good at it ^^

[biell]

The server uses the same method as the map_editor. I have found no way to "trick" altitude into another game mode. I believe it cheks in the order listed in the map editor, and the first match is what the game mode is. That is why you can place a ball in 1de mode, but not in tbd. The server will see the ball and select a ball mode before it even checks for tbd. So, it isn't best match, it is first match.

Yesterday I wrapped your setTime command with map aware Alti+ code. So, now I can run "map::set_time(90)" or "map::set_time('1:30')" and it will set the timer to 1:30. Ending the game will be as easy as "map::set_time(0)". Implementing a specific powerup to end the game will be easy. If I implement something where each powerup removes a pre-defined amount of time, that will be a little harder. I tried doing something like that, but since there is no "getTime" command, it is a lot of math to keep up with, if you call "setTime" multiple times. It is doable if I keep track of clock time and what the map timer is set to when changes are made. But, I am not going to do that unless there is real interest.

I do think that a first ffa_coop map needs to take advantage of the new things you can do with ffa, if people are to accept it. Also, since players can ruin the game by killing each other, I think I will have to put these maps on Coop+ Advanced.

I was thinking that, to make the end a little more exciting, we could put high radius, low damage turrets behind walls around the winning powerup such that it looks like fireworks. When you grab the powerup. Also, if we made a trophy cup, a shield powerup could be placed such that it looks like it is resting in the cup. Other choices would be to reuse my flags from my ball_flag game type.

[estguy]

well i have played with the map editor and kind of understand how it works so it might be possible that i'll start producing maps in the next year

also biell could 1de_coop_trees be put into coop+ advanced? would be really nice to try to solo that map :P

[LewisH]

Originally Posted by biell

since there is no "getTime" command

Added.

/getTime
{"roundTimeTicks":12481,"port":27276,"time":23434,"type":"getTime"}

I did a little refactoring too, I didn't like the structure of having it split into many patches, it makes small changes like this a little more difficult than they should be, so now it's all a single patch -- everything is configurable in the config file, and with no config it should be no different to a vanilla server (with the exception of some extra details in the json logs). I've left the `mods` part of the JSON log entry there as an empty array, and added `version`.

I also added the `botPlaneSetup` and `botPlaneRandom` commands to the list in the readme.

[biell]

I was making use of the mods array, that was a bit of coding I wasn't expecting for yesterday. With your changes being so pervasive, my latest alti+ github code refuses to work against your older server patches. If your patches are in place, I require the "version" element in "serverPatches". If I don't see it, then I exit.

Thank you for documenting the plane setup commands, I didn't understand them, and so hadn't used them before. Now, they are in place, so maps like tdm_biplane also only have bip bots. I had to completely redo the way I accomplish plane restrictions. It now takes more memory and work up front, but checking if a plane configuration is OK is now supper fast (hash lookup).

An interesting note about setTime and getTime, setTime is increasing and getTime is decreasing. It took me a few minutes to figure out why my code didn't seem to be working at all. Also, getTime really should have a "source" element in the log file. Normally, a command like that, e.g. logPlanePositions has a json entry for a "source", which is the vaporId of the requester, or all 0's if it is the server. With all of that, I can now set the timer, or modify it.

I haven't figured out how I am going to code it exactly, but I might, for tdm and ffa, use the name as the clock set. 0:00 would end the game, -0:30 would make you 30 seconds closer to finishing, and +0:30 would increase the timer and make it longer until the timer runs out. This would be cool if you wanted to have poison powerups.

For ffa_coop, I also thought a good idea would be to set spawn health to 200%, and double the turret damage. Walls aren't affected by spawn health. So, this way it would take double the "friendly fire" to die, but turrets would affect you relatively normally. It will, however, take twice as long to reach 100% health if you use the Repair Drone green perk.

[LewisH]

> With your changes being so pervasive, my latest alti+ github code refuses to work against your older server patches.

Ah, I should have asked about that before changing it. I'm still not sure where I want to go with the project, but the overhead of making changes was much too high in the old system, it's a lot easier when I work on the assumption that all the files are modified, and to not have to think about how each patch interacts with the others. This way, I can make little changes (like adding the /getTime commad ^^) in a few minutes.

If I find the motivation for it, I'd like to spend a little time to clean the project up, and find some directed purpose for it. My current assumption is that your servers are the only ones using the patches (I'm not hosting servers anymore, the next time I do will be with altserv whenever that's ready). Which of the patches does alti+ use? It might be better to remove any which aren't being used -- that's just more clutter in the repo.

> An interesting note about setTime and getTime, setTime is increasing and getTime is decreasing.

Ah, that's an oversight on my part. The timer is a countdown timer, but I thought it was more natural to work forwards in time so I flipped it for /setTime -- then forgot to do the same for /getTime. I've change that such that they're the same (/setTime <value from /getTime> would be no change).

> Also, getTime really should have a "source" element in the log file.

So it is written, so it shall be done -- one line changes are the best

{"roundTimeTicks":364,"port":27276,"source":"a896ce74-4802-468b-bff6-d2326b211c4c","time":28246,"type":"getTime"}

[biell]

Originally Posted by LewisH

>If I find the motivation for it, I'd like to spend a little time to clean the project up, and find some directed purpose for it. My current assumption is that your servers are the only ones using the patches (I'm not hosting servers anymore, the next time I do will be with altserv whenever that's ready). Which of the patches does alti+ use? It might be better to remove any which aren't being used -- that's just more clutter in the repo.

I don't use the whitelist functionality, but I could easilly enough if someone wanted it. So, I think you should keep it.

I also don't currently use periodic logPlanePositions (even though I requested it). I sometimes call logPlanePositions, and I need the fact that there is a gaurenteed delay from the event I am on until it is called. So, I need to know when I asked for it vs. it being run automatically. I haven't figured out how to handle that yet, so I haven't started using it for the original reasons I wanted it. But, I think it is still good to stay around, in case I figure that out.

I now have most of the plumbing for ffa_coop and tdm_coop, but you and esty are the only two to respond. So, I am not sure how much interest there is.

[Loquacious Bum]

you and esty are the only two to respond. So, I am not sure how much interest there is.

FFA Coop sounds fun, but I don't see how it would be all that much different then normal coop. I think the idea is cool, but I guess I don't understand the benefits of FFA coop.

[biell]

Originally Posted by Loquacious Bum

FFA Coop sounds fun, but I don't see how it would be all that much different then normal coop. I think the idea is cool, but I guess I don't understand the benefits of FFA coop.

ffa_coop would be harder, have additional game play challenges, and be more subject to ruin by trolls and newbies.

harder

• Players can kill each other, even though they don't want to. This will make the game more challenging.
• You have to be careful about weapon selection not to pick one which tracks your fellow coop teammates, more coordination will be needed
• The free-for-all associated with whale remote mine hops can't be done, as you can affect your other players
• Walls are a very important part of map design, but what happens when you fellow players can't go through it, more strategy is needed.
• Randas will hurt their fellow players when they jump
• Emp-ing in a tight space will affect your fellow players

game play

• You can send a missle at your fellow player to boost them across a turret infested area, right now you need to mine hop for this kind of manuver.
• Think about the original tbd_coop_better_together, the bot is placed in a location such that a group of powerup missles key in on him and destroy a turret. Now, your fellow player can be lure on the other side of the wall.
• Missle powerups aren't the only tracking weapon, how about luring a loopy tracker missle towards a turret
• Bomber suppressor may become really helpful for arcing over your fellow players

I am sure there are plenty more, I just haven't thought of them yet. That is part of why I was seeking community feedback.

issues

• Since players can kill each other, a troll could join the game and start killing everyone.
• Additionally a newbie could come onto the map, not realizing what coop was all about, and start killing players because they think that is what they are supposed to do.
• Also, one player might believe another player is purposely killing them when that isn't actually the case. This could lead to in-fighting and make everyone miserable.

[Loquacious Bum]

Thanks for explaining biell. It definitely sounds fun with a group of mature players who know how to work together. Maps like para false use a similar concept that requires both team's cooperation without letting the teams get in the way of each other. If the FFA coop maps were similar to para false (where the players are totally separated) the troll issue would not be a problem.

[estguy]

For FFA coop there needs to be a level requirement of 60 for sure since anybody lower has usually played it for week, 2 at the most

[Mango777]

For sure a FFA coop would require setting health to 999 or something high, to reduce risk of injury?

[estguy]

well that would most certainly ruin the point of FFA coop since you have to not try hit your team mates and that's probably the most challenging part

[Oyster]

I'd be willing to make any maps you guys want, just let me know.

Happy New Years!

[Oyster]

We could do a level like this where you have to catch the batteries as you race to keep the timer going so you can reach the end

[biell]

Originally Posted by Oyster

We could do a level like this where you have to catch the batteries as you race to keep the timer going so you can reach the end

I don't know if it is done exactly the way it should be, I might make changes. But, I have this coded. Right now, you need to set the spawn time on the "battery" powerups, because each time you collect one, the timer will be increased. I can tweak the methodology if you need me to. I haven't uploaded the code to github yet, but it is running to test on Map QA.

If you want to make a map like this, just let me know. And, we can work out the details. As before, I can help you finish it and add the plus.txt file to the altx archive.