-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CHill #178
Comments
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. |
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 For instance, create a |
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 likehillCaptureTime
(with a default value inrsrc/default.avarascript
that signals "this is not a KOTH level"), possibly ahillsAreContestable
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.
The text was updated successfully, but these errors were encountered: