Xevious — Positions and Waypoints
Xevious has two main sets of enemies, ground and air based. Enemies attack the player from, mostly, specific points on the map.
These pictures show a typical location of the map with examples of the different variants of the enemies. The picture on the left is the game view, whereas the picture on the right shows the level design including spawn and goal/waypoints for:
- Two moving ground-based enemies that move along the roads on the map aiming for the green diamond waypoints.
- Two airborne enemies that have fixed starting positions but then move depending on their specific rules, in this case we can see two Zohsi who in this example will eventually both end up aiming for the same gold diamond waypoint at the bottom of the screen.
- Two stationary ground objects (see big blue arrows) that have spawned into their correct positions but do not independently move, however, they must move along with the background.
Please read, How the enemies are spawned, if you want to know more about the specifics.
This mechanism poses a couple of problems for Unity. Consider the basic requirements of the stationary enemy. The background is moving at a steady speed to give the illusion of flight. If we spawn the ground enemy in world space the enemy would also have to maintain the same vector as the background. I suspect the real game is doing something similar. If you examine the real game frame-by-frame you can see the enemy is almost 1 frame behind the background. As much as I want to be faithful to the original, I do not want to introduce the same…I shall be generous and call it…a feature. So I have two choices:
- The enemy has a script that maintains the same speed as background.
- Place the enemy as a local child to the background.
I do not like (1) because this requires introducing movement logic for each ground enemy which seems like an unnecessary overhead. Whereas (2) means I can just place them at the position and it will automatically just be moved with its parent. However, using local-position comes with its own set of problems. Consider the moving ground enemy, a Domogram, that is seemingly moving on the road. It is using a system of waypoints (green diamonds) to move along.
The problem is that when you use local-position all relative movement must also use local-positions. Not only that but it must, typically, be within the same ‘local container’. This is a problem when you want to use the standard pattern of Spawning Containers. A Spawning container is a ‘good housekeeping’ method where you group all the spawned items into the same container, e.g. Spawn Manager -> Spawned Object -> Ground Enemy -> {Domogram (clone 1), Domogram (clone2)}. However, there might be a lot of different scales and relative positions between the newly spawned Domogram and the waypoint it is trying to travel to. In my experience it very quickly becomes very complicated to calculate. So I just spawn them in the same hierarchical position as the waypoints.
The airborne enemy can be treated differently as their rules of engagement are often more about a timeout, e.g. spin away after 0.5 second, fire and turn back after 1 second. But others, such as the spinning Zoshi have their own waypoints, which again requires them to be spawned using a local-position.
Takeaways
- When you need something to move relative to something else, consider using local-positions.
- When you use local-position and vector calculations consider keeping all the actors in the same container.
Where Next?
Next up, Sprites and Animations
