It would be nice to have a multiplayer mode/level where there are forts that can be captured. A level example would be:
===========================
15 capture points that start out neutral. Touching a fort that is neutral or belongs to the enemy will capture it for your team as long as an enemy unit is not within a certain distance. First team to capture 8 points wins. After X minutes, if neither team has 8 points the match ends in a tie.
However, there are several issues that would need to be solved to make a level like this work. I’ve been brain storming and I’ve come up with a few half-baked solutions:
A) Make a new type of Thang specifically to support this sort of level
B) Have three thangs (human, ogre, neutral) that all occupy the same space, but only one is set to visible at a time. Can we change the visibility of a Thang mid-level?
C) Mobile units have the Builds and Attacks components, but not the Attackable component. Capture points have Attackable. To capture a point, you destroy the existing Thang and instantly build a new one on the spot. How do we restrict it so you can only build in certain spots?
Other open questions:
How do the players get a list of capture point locations/statuses?
Can a match end in a tie under the current ladder system? It would be possible for two players to repeatedly recapture the same point back and forth and never get up to the required 8 for a win, so we’ll need a time limit.
Should capture point locations be randomized each time a match starts, or fixed?
Q: Should capture point locations be randomized each time a match starts, or fixed?
A: These point should be fixed, and it will take some good level design to balance out the position of these points, to figure out the perfect positions and the amound of points. This surely will require enough testing.
A good reference for this type of level is imho Team Fortress 2, so be sure to look at references like these when you’re designing a first level as a proof of concept for capture point multiplayer levels. Another good reference is Brink. They have made tools in house to capture all played games in multiplayer. All this data was used to finetune the level design even after release. I saw it with my own eyes when I visited their studios and it’s quite the amazing tool. This makes me quite confident to say that their level design is quite cool. They do have really different gameplay (same for team Fortress 2) so you can’t litterly take their genious level design and copycat it for CodeCombat, as it just wont work as good. There is a good talk about the level design of Brink to be found here. Sadly enough, I assume that you don’t have access to the vault, in that case, you can view the slides here for free, but they don’t really tell you that much without the talk itself.
Q: Can a match end in a tie under the current ladder system?
I’ll admit that the inspiration for the level type came from various FPS style games, but I’m not entirely sure there will be a close link between how FPS games have built these types of levels and how a game like Code Combat will deal with them.
In an FPS, units are semi-independent and directly controlled by humans. In Code Combat, the player is coding up AI routines
In an FPS, each unit has a lot of freedom of movement, and the environment and both allow and constrain many approaches to a capture point. In Code Combat, at least as things stand, a unit will probably approach a capture point in a straight line, unimpeded unless we make it a combat level.
A randomized level will provide a very different challenge to the player’s code than a predetermined level.
This is very cool! Yes, we can change the visibility of a Thang mid-level. We can just mess around with the display.Invisible to add methods to adjust the visibility. Then we can have already-tinted capture points fading in and out as control changes. It might be even easier to toggle the exists to true/false instead. We can add some methods for getting capture points, and then you could just see which capture points of each team exist.
For measuring capture, we have the Goal Trigger Thang Type that already does something like this, although we’d probably want a new one to count down control times.
Matches can end in ties, although hopefully levels are designed so that most matches won’t.
We already have a way of using pseudorandomness, since Math.random() is stubbed out by something deterministic that we control. We could either make it so that player code or code in the level asks for different numbers of random numbers which influences the unfolding of the level, like in Gold Rush and Greed, or if we want to randomize even the initial conditions, we can add something that changes the random seed seed based on the IDs of the two players.
But if we did randomize, then we would definitely want to make sure that the randomness didn’t favor one side over the other.