Hello,
I’m building a game similar to Ogre Battle (SNES) in 3D. For those unfamiliar with the game, it’s a real-time strategy game where you control squads of typical rpg-classes on a large scale map. The objective is to take control of the enemy’s main base and there are cities in between that, when captured, can provide you with goodies. Capturing is straight-forward, you just need your unit to be fully within the bounds of the city with no enemy units present.
Here’s a ‘Let’s Play’ to showcase the original game:
The sequel was released for the N64 with an attempt at 3D environments.
Ogre Battle 64
I’m sure this was impressive 20 years ago, but I think we can do better.
I would like to stick with a low-poly art style. I’m envisioning something like this:
What could be?
There are two core mechanics to Ogre Battle:
- Capturing cities
- Fighting enemy units
I’m going to ignore “Fighting enemy units” and focus on “Capturing cities” because it involves maneuvering the current scenario’s map and is the source of my troubles. The mechanics at play here involve movement penalties for various terrain types and how a specific unit moves about them. For example, flying units can simply ignore any terrain penalties while a grounded unit may suffer severe penalties over water and mountains.
I’ve played around with Unity’s NavMesh and Aron Granberg’s A* Pathfinding plugin, but they all seem to have issues traversing mountains. Aron’s GridGraph implementation seemed to work well, but the examples use a CharacterController to move around which often results in the GameObject becoming stuck on mountain geometry. I could probably get around this by implementing my own controller, but that leads me to concerns over fundamental game play.
On a 2D field (or low mesh like in the N64 version) applying a movement penalty to “mountain” tiles makes sense. The distance is basically the same so to compensate it should take longer to traverse. In a more robust 3D mesh (like in “What could be?”) you’re already penalized by the additional vertical space necessary to climb over the mountain.
This gets me thinking - should I even bother applying a penalty? Should I normalize the travel time and then apply a penalty? This adds a lot more complexity because now I need to make sure the cost in pathfinding accurately reflects the actual movement time. Now I’m back-peddling, thinking maybe I should treat mountains instead as obstacles for non-flying units. Now this limits game play and devalues having a cost associated with various terrain types. I’d basically just have water and forest penalties and water movement is already rare.
I could keep going here. Maybe it makes sense for each mountain to have a tunnel that cuts straight through or units dig their own way through the base. I could add roads through and around mountains. I could compromise on the art direction and make low resolution versions like in N64, but that makes me sad.
I sort of like the idea of ground units digging tunnels through the base of mountains. This keeps everything on the same plane basically and would probably simplify a lot of my issues. I could always turn mountains transparent so the little guys are viewable underneath. It would be consistent with how I plan to implement movement through forests where units disappear until they exit. I’d have to plan for abuse cases so the player can’t just hide an injured unit within a mountain.
Anyways I really value any advice or input. I know I can be a bit long winded, but I generally only post things like this when something is keeping me up at night. I’d love to hear what you all think would be fun or interesting. Thanks for reading.
). It’s not too hard.