OSMT Discussion & Ideas

[SuperApe]

I'm working on the implementation of Monster Teams and Player Team Integration. These are related, but separate issues, as far as the code is concerned. Monster teams are not the same as player teams.

First, you can set a TeamTag in ScriptedMonsters (AI->TeamTag) and you can set one of the Team members to be the leader (AI->bTeamLeader). At this point, if there is a team set up this way, ScriptedMonsters recognize the team and will do two things:

1) if they are considering various enemies, they will recognize Team members and consider them a "friendly". (in theory)
2) if they are thinking of attacking anyone, they will "ask" their Team leader for orders of how to attack. Right now, this just sets them to Charge, which may result in either a long range attack or actual charing action. When the leader gives the order, it will turn to it's team member and speak (give an Aquire sound). (in theory)

This should allow for monster Teams to act in a more coordinated way. At least they shouldn't be fighting amonst themselves, but also they should be able to (in theory) set up more complex combat tactics, like stay back and fire ranged weapons or charge all at once, etc.

Second, if monsters have been assigned to a player Team, they will also see their Team members as a "friendly" and not attack. (in theory) At the moment, I do not have a mechanism for monsters to Join a player team. I'm thinking some trigger device could do the job, perhaps a ScriptedAction of some kind.

Once on a player Team, the monster should make use of the AttitudeToPlayer setting, ATTITUDE_Follow, which was never implemented in this toolset or in the original UT99 stuff. This would just make them act a little more like team mate bots, although I hesitate to say that you could give them bot orders. For that, I'm thinking that's what another AttitudeToPlayer setting was for; ATTITUDE_Max. That setting was never even described in the code, but my suspicion is that this was meant to represent a full "player-like" member of the team, able to take orders, play the game, reach game objectives, score Team points, etc. This might be a little too difficult to implement at this time, but it's worth keeping in mind for later. (Imagine a Krall carrying a flag or defending a DOMPoint)

I will need to do some specific tests, like in a TeamDeathmatch setting, to see how this plays out for player Teams.

For monster Teams, I'm going to do lots of testing as well. I was trying to think of other things monster teams need to do. There is no other code that I could find in the old ScriptedPawn that defines team behavior, but my suspicion is that monster Teams traveled in packs, if no other Orders were in effect. This would be similar to the ATTITUDE_Follow stuff I need to implement for player Teams, but here the TeamLeader is the one that wanders or hunts and the rest of the team follows the leader.

[outpt.co.uk]

Originally Posted by SuperApe

I'd pick one, right-click, select the Select All Krall item, and make my edit.

[SuperApe]

Okay. More good news than bad, but here the skinny.

Good news:
- I've got a ScriptedAction called ACTION_AssignMonsterToTeam which will allow you to define the monster's Tag and a TeamIndex (0=red, 1=blue). Upon execution of the ScriptedAction, via ScriptedTrigger, the creature will be given a PlayerReplicationInfo, a team RosterEntry and be added to the player team.
- The Team monsters will immeditately ignore their original Orders, AlarmTags, etc. and become servants to that Team.
- If previously on another Team, they will be removed from that one and added to this one.
- If they see a Team member player, they may make an Aquisition sound. They may even play a Greeting animation, if available.
- If they see a player from another Team, they will attack as normal, hunt and chase as normal, etc. They will not follow AlarmTag behaviors, as those would have already been removed from their Orders.
- Bots will generally ignore Team monsters, however, some more Aggressive bots like to kill them. So, I've got a "Hey, same team!" function in the monsters, to attempt to get them to stop. Again, more Aggressive Bots won't stop (and some humans won't stop either, I suspect). So, likewise, more Aggressive monsters will eventually break off from the Team themselves, if injured by Team Members. At that point, they will attack the player/bot who injured them and continue as a normal monster.

Bad News:
- They will not recieve Bot Orders. I tried for a long time to mimic what Bots do to handle orders from players and, in the end of working on it today, I decided there's a stop-gap measure on the player's end, where if the creature you're trying to talk to isn't a Bot, it doesn't give the order.
- I also had problems getting them to simply follow a Team Member, like SquadLeader, or to guard a Team Objective.
- The result is, although they are on a Team, monsters do not do anything other than Wander after being added to the Team.

? News:
- I haven't tested enough regarding Monster Teams yet, but that is probably set up in it's basic form, as described earlier.
- The following (or moving as a pack) probably isn't working yet, based on the problems I had with following player Team Members.

[SuperApe]

Player Team stuff looks pretty good now. Monsters can join a player team (via ScriptedAction), show up on a roster, attack opponents, etc. They will follow the bot squad leader, first human team mate, visible human teammate, or they will defend the team base, depending on what's available to them. They will do a fairly good job of attacking other monsters. The exceptions to that are when the opponent is the same species of monster or if the opponent not associated with a team at all. But against bots or other humans, they'll do just fine. We'll need to do extensive testing, I'm sure.

However, they will not be taking any Bot Orders. After a lot of research, I see that Team's SquadAI is exclusively made for Bot Controllers. So, that is a feature for another release, after the public release, if at all.

On the plus side, I have made a couple new ScriptedMonsterController states to help with Team handling: FollowTeamLeader and HoldPostion. So, it should be no problem to include a couple more ScriptedActions to set orders for Team monsters, like ACTION_MonsterFollow or ACTION_MonsterDefend, which should be a good substitue for bot Orders, if handled properly by the mapper.

I still haven't gotten to testing the monster Team stuff, but that's next. While working on that, I found some extra properties and functions that I thought I would have to omit (as part of the conversion from UT99's ScriptedPawn to UT200x's Pawn & Controller scheme). But with these extra script goodies, I should be able to tweak the combat AI a little more and get even better tactics out of these monsters.

I have successfully cleaned up the code in ScriptedMonsterController and ScriptedMonster and gained a good 50k back in file size. I've been wanting to clean that code up for a long time.

I'll have to eat something, take a quick nap and get back to testing, but I hope to release a new version later today.

Here's a few screenies that document the progress. This map was originally set up to work on Team Doors, but it worked well for this testing too.

[Lord_Simeon]

Do you ever sleep.....lol

[SuperApe]

You have to read between the lines:

Originally Posted by SuperApe

...for a long time. I'll have to eat something, take a quick nap and get back to testing, but I hope to release a new version later...

I'm just trying to keep up the pace so I can release this with plenty of time before the baby takes it all out of me.

[SuperApe]

The new team stuff is working pretty good now. I wish I knew how monster teams behaved in UT99; beyond what I can see in ScriptedPawn. The main thing I added to that was following the TeamLeader by default. This seemed logical, but I could not find nothing like that in the old code.

The result is you can set the TeamLeader to do things like Patrol, Ambush, etc. and the rest of the Team will follow the same route without setting those Orders on the members explicitly. In theory (I haven't tested), you could set up the team members with different AlarmTags, so they would follow the leader, but when an Enemy showed up, they would "scatter" to their Alarm assignments.

If you don't want the monster team members to follow the leader, you can set bIgnoreFriends and they will go it alone. (I'm not sure of the advantage to this, but it was specified in the documents of the old code.)

Also with this code, I can use it to implement something the old UT99 ScriptedPawn planned to, but never did: AttitudeToPlayer ATTITUDE_Follow. I still need to test this a bit, but it should make a friendly creature that will greet the player, then follow, as if it were joined on a team, whether it's a TeamGame or not.

[SuperApe]

All this Team stuff seems to be working pretty good, including the new AttitudeToPlayer ATTITUDE_Follow, which essentially makes the creature the player's ally. I've seen some very cool behavior so far in testing this stuf. Once you've seen a pack of Skaarj running through the hallways, you'll know fear. There's much more to test: friendly creatures leading you to a neat goodie via AlarmTag, escort missions, sidekick characters.

/me rubs hands together

[SuperApe]

Originally Posted by outpt.co.uk

Is it possible to drop the time limit completely?

Originally Posted by Lord_Simeon

Is there a way to disable the time limit alltogether?
Every now and then, i'll be in a matinee and i'll hear "5 minutes remaining" which is a bit annoying.

Originally Posted by SuperApe

After a little thought, I'm thinking that if we did take the game config Timelimit out of the options menu very few Players would complain (that's just my guess). And if mappers wanted to have a timelimit, as their adventure requires it, they can use the Objective timelimits or not or in some Objectives and not others; however they want.

Originally Posted by Blitz

How about this? Remove the TimeLimit as it is now and replace it with a percentage. Let them go from something like 25% up to 500% and then "scale" the objective times based on this number. That way the user can still control the pace of the game, but the time limits that were chosen by the mappers are preserved.

Originally Posted by outpt.co.uk

...sounds excellent. The mapper would have his default time limits for objectives. If the player finds the game too paced or slow, he can bump them up a bit.

At first, this idea about the Timelimit percentages option sounded good to me. Now, I'm havnig second thoughts about it. First, it doesn't quite solve the problem brought up by Lord_Simeon and outpt; the timelimit can still be in effect and can frustrate Players in terms of "interrupting" their adventure with a countdown that's essentially irrelevant to the story. Second if there is an Objective timelimit, chances seem pretty good that the mapper will have thought that timelimit through pretty well. Maybe they've even counted on it being close, both to increase the difficulty and to add tension. If the Players can arbitrarily change this design, that seems like that can defeat the mapper's efforts.

Timelimit in Multiplayer serves a important function, but I'm not so sure the same function is necessary or warranted in Singleplayer unless designed by the mapper.

[SuperApe]

Originally Posted by Blitz

EDIT: Option 2 would be a "difficulty" setting that would let mappers adjust the time limits based on difficulty (as well as other things, like number of creatures, pickups, etc).

Originally Posted by outpt.co.uk

(That) forces a little additional work for the mapper - he'll have to test his objectives more to match the difficulty levels.

I like this idea a little more. While looking on the wiki for old UT stuff that's similar, I ran across an old property group that I should probably move OddsOfAppearing into anyway: Filter. Here there are only four Difficulty switches, but that could easily translate to the seven settings UT200x has.

On another topic (slightly related), CoOp play and mapping is discussed on this page. I am still thinking about implementing CoOp play. And since we've moved the public release date, I may actually have some time to work on this before then.

[SuperApe]

So, I had a chance to see Fraghouse's SinglePlayer Framework in action yesterday. I believe they just released a new version (v2) late last month and I've been reading their forums on BUF as well to get an idea of what their mod can do. Although they do offer all the old Unreal creatures and a Save/Load game feature (allegedly, I didn't see that part), I think this toolset will show some improvement over that project. I'm not doing this for one-upsmanship, but their project has been sticking in the back of my mind this whole time, as I would rather see this toolset stand apart from other monster or singleplayer mods/mutators available.

I would like to work on the Save/Load game feature, or at least look into the issue before release. The idea is that Players could Save a game at any point and could Load the game back up to return to their last completed Objective, with all their points, ammo, inventory, etc. Optionally, I would also like to see the map they're in be set the same way: basically all actors and settings returned to the state at the point of the Save. This extra feature would ensure that critical switches or conditions are preserved in the Save game.

After release, I would also like to look into getting a hold of the other Unreal creatures (their animations, textures and sounds) so that they can be released as individual add-ons to the toolset. One of the problems I see with Fraghouse's SP Framework is the 13+MB it adds to the size of the released SP map using it. This is entirely due to the extra mesh animations of these creatures. By allowing mappers to selectively include only the creatures they use, we give the mappers the option to use these creature without the unused overhead.

In addition, I have plans for some of my own custom creatures to release as optional add-ons, perhaps as embedded creatures in a map.

[SuperApe]

Sorta Off Topic:
Anyone have a suggestion as to how I should mark the Atari Forum thread when I announce the toolset's release? I see about four or five that could apply to this announcement.

[Lord_Simeon]

Gametype?

[SuperApe]

Sorta still off topic:
Yeah, here's the ones that it *could* represent:

- Utility (in a strictly literal sense, although most of these seem to be server addons for security,etc)
- TC Mod (sorta)
- Mutator (not really)
- Map Pack
- Gametype

[MortalPlague]

I think "Gametype" is the most appropriate. You're not doing a total conversion, yet this is far more advanced than a simple mutator or map pack. Also, "Gametype" would likely grab a few more hits than any of those (other than TC Mod).