Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Looking for advice on core mechanics for my game

Discussion in 'Game Design' started by glangho, Aug 1, 2017.

  1. glangho

    glangho

    Joined:
    Aug 1, 2017
    Posts:
    3
    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.

    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:

    The geography is a little bumpy, but close to my ideal vision. Taken from Google - not mine.

    There are two core mechanics to Ogre Battle:
    1. Capturing cities
    2. 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.
     
  2. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    OK, you've mixed implementation questions with game design questions, so I'm going to do the same with my answers. :)

    First, don't let implementation issues drive your design. Those issues are solvable. You should not be using character controllers or any form of physics on a game like this. You do of course need a path-finding solution, but if you can't find one that doesn't require physics, you can make your own (or hire me to do it ;) ). It's not too hard.

    So that leaves the game design issues: how do you want your game to work? I have to confess, I'm not crazy about units tunneling under mountains as a matter of routine. It's cool if certain units can do that, but it should be a major project — orders of magnitude harder/slower than traversing the pass.

    And I also think it's quite reasonable to assume that your low-poly style (which is cool) doesn't show all the little rugged bits of the terrain that make passing it difficult. Thus, terrain traversal speeds are about more than just the local slope. And they vary not only with the terrain type, but with the unit type too — units on foot should not be slowed down by rugged terrain nearly as much as wheeled units (and flying units, of course, not at all).

    I hope any of this is helpful... it looks like a cool project!
     
  3. glangho

    glangho

    Joined:
    Aug 1, 2017
    Posts:
    3
    Thanks for your reply! Maybe I'll save the tunneling trick for a special class of saboteurs. I think the A* plugin I found will work once I implement my own movement controllers (sans the physics). It's a bit hard for me to picture climbing over mountains, but if it's a mechanic I want perhaps I should worry after I implement it and replace my programmer art.
     
  4. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    6,492
    Joe is right, get teh mechanics done first then think later about "presentation", because it's not a technical problem it's a presentation layer (how to show the cost of movement), THEN once presentation is chosen it become an implementation (technical) problem.
     
  5. glangho

    glangho

    Joined:
    Aug 1, 2017
    Posts:
    3
    Thank you! I'll be keeping that in mind.
     
  6. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    From a game design point of view, mountains will probably give the most bang for buck if they are completely impassable to all units. Check out the Civilization series.

    Tunnels that exist by default under mountains doesn't sit right with me. Its basically the same as saying 'this mountain doesn't exist'. So you might as well make it an open field.

    Spending resources to dig under mountains might work, if properly controlled.
     
    Martin_H likes this.