CHill

[rherriman]

In the classic version of the game, KOTH levels were possible but involved a lot of scripting including Fields, WallDoors, logic, and Text objects. It was also required, if memory serves, to duplicate this logic for every team that you wanted to support, typically three or four different teams.

It would be nice to be able to simply place a first-class Hill object in a map and have it work out of the box. We have had numerous discussions about this sort of thing in the past on Avaraline, but I've been giving it some thought over the last couple weeks and wanted to document my thoughts.

CHill should be similar to a Field or Area object, to start with. I would like hill areas to be either box or sphere shaped at the discretion of the level designer. I thought Field would be a good starting point, as the ALD manual states that if you specify a shape parameter it is supposed to use that shape for the collision detection. Unfortunately, my tests have not proven that out. (This is possibly a bug with the port, however.) In any case, being able to specify a "height" for the hill separate from the normal collision area would be valuable as well, with an infinite height being the preferred default.

I also believe that the time tracking component should not be a property of the hill object itself, but stored in the scorekeeper. For one thing, this enables us to display times on the in-game/post-game scoreboard. But it also enables us to have a moving hill, by using events to disable a Hill object and enable another one someplace else. Maybe even have multiple hill areas active at the same time.

This also means, though, that certain game type configuration settings will have to be placed in "global" variables rather than as properties of the hill objects. This isn't totally unprecedented, with the existence of things like defaultLives. So something like hillCaptureTime (with a default value in rsrc/default.avarascript that signals "this is not a KOTH level"), possibly a hillsAreContestable boolean var that controls whether the timer continues to tick when multiple players from different teams are on a hill, etc. Another possibility for variables would be the formatting strings for progress notifications in the messages area, e.g. "%s team has %d seconds!", or the rate at which those messages are sent. It's also possible that we just don't do messages, since all this stuff would be going to scorekeeper and checkable in-game.

CHill objects (and scorekeeper) should also support all possible teams.

That's all I can think of for now. Please feel free to provide feedback on these ideas.

[rherriman]

I knew I was going to forget at least one thing. Another thing I wanted to point out is that we'll need a way to trigger the end of the game/win teleporter once one team accumulates enough time, and ideally only mark that team as the winner. I'm not exactly sure what is going to be involved there.

[iksbob]

While it would certainly take the headache out of KOTH levels, a monolithic object seems to go against the simple-but-flexible approach of OG Avara scripting. Rather than one black-box, how about a script class of more complex behaviors that rely on underlying logic constructs? That way new functionality can be used elsewhere by intrepid designers.

For instance, create a logic complexTimer which tracks cumulative running time and kicks out messages at specified instants. It could further be tagged as belonging to a team, and given a text label for scorekeeping purposes.