• edited August 2016
    I'm trying to acomplish an exact Diablo game click to move element with Isometric camera.
    Well I'm using free unity version, because I don't want to pay about 130 euro monthly for Unity Pro or any other paid version while my project isn't even in alpha stage.

    I can explain really in exact details. For example, after main menu, then character selection, it goes into a first scene, 'Graveyard' where my character starts. I've managed to create Isometric camera position using ORK, but haven't found out how the camera can follow the character yet. Edit: Solved the camera with using the basic control controls, as it's much easier.
    https://postimg.org/image/uk7cs8155/

    Keldryn said: You don't need to know any C# to build a game with ORK, nor do you need to use any custom components in order to make a functional game. Some things are only possible with custom scripting, but you can always design your game around that if you aren't a programmer or if you don't have access to a programmer.
    I believe that, it's why I bought ORK, but since scripting is my weakness, I'm doing everything to improve it.

    Anyway, I've put the Nav Mesh agent in game controls, the player gets spawned and moves according the nav mesh, but I have to click it exactly 3 times to move character somewhere. So don't know if that helps as a little bit of info. Edit:Solved the 3 times click to normal 1 time by puting None Input Origin to 'None' in Input Keys. It was previously set to Mouse.

    Now I have to find out, why my character isn't using any Animation from ORK. Just the one set in 'Animation' default in the prefab. Edit: Fixed it with enabling 'Use Position Change' in Movement setting.

    So basically with this I could say that I'm all set in moving terms. I actually switched to using the Character controller due to it's "instant rotation turns" because I don't like sloppy Nav Mesh agent turns. And the Char controller actually uses same nav mesh coordinations? Like he understands elevation and so on. Was there any change in this controller recently? lol
    Post edited by Machal on
  • Best way for having diablo style player/camera controls with ORK's built-in controls is:
    - use the Mouse player controls, which also supports NavMesh for pathfinding
    - use the Top Down Border camera controls, for the isometric look you just need change the camera in your scene to use Orthographic projection.
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • Yes, you are right, thanks for tips. Also found out that Character controller supports my Nav mesh (thought it's only possibly with Nav mesh agent).

    Getting slowly into this and finding ORK pretty amazing.

    Consider this topic solved, I just have question besides this topic. And It would be great if someone has experience with this:

    I want to have skeleton enemies. And on their death animation, I would like their bones to do the "explosion", so their bones go all around to get a bit realistic physics. I saw somewhere that ORK is able to trigger the explosion thing. My skeleton is a one big mesh consisting of some separated bones that I will want to go out during the explosion.

    But do I need to separate all of them as individual child objects for the effect to work or can I leave them separated but under one mesh?

    I guess the explosion gravity applies only on child objects within the prefab...
  • Yes, I see that the slope feature works when generating a grid via the battle component. A few more questions then.

    -Can a grid attached to combatants be generated as a battle start event and destroyed afterward? (and how stable would that be? I noticed a few errant cells around the perimeter generating grids in a scene.

    -Is it possible to setup features on a map so that auto generated grids will paint occupying cells accordingly. I.e. features like trees, shrubs and walls will paint the cells touching them as blocked and other terrain, such as grass or roads, can paint their own cell types.

    -Are grids dormant during play until activated? Placing a couple of 50x50 grids in different locations uses a lot of processing power--I'm assuming because ray-casting is continually running on every cell--but a running game should ignore that until the grid is in use.

    -You've said that grids cannot be linked but, assuming that generating them on the fly via an attached component isn't feasible, the boarder issue will likely cause problems in a game with free roaming enemies where battles are set to occur on the spot. If the combatants are straddling two or more grids, how do they select which grid to battle on? Could a battle start event ordering them to automatically move to the nearest free cell lead them to occupy multiple grids, and can our universe handle such a of paradox if said were to occur?

    -There appear to be secondary toolkits, like Grids Pro by GameLogic or the Terrain Grid System by Kronnect, that are dedicated to building map-wide grids overlaying a terrain. Are any of these compatible with ORK?
  • I think you've posted in the wrong thread :)

    Anyway:

    1) Generating a grid in-game should be possible, although I've never tried it. The code for this is part of the gameplay code, so it's accessible while playing. Call BattleGridGenerator.Generate(BattleGridComponent gridComponent) to generate a grid on the passed on grid component.
    The performance depends on the size of the grid, e.g. a 50x50 grid causes 2500 raycasts. You could hide that from the player by doing this while having the screen faded out :)

    2) Auto generated grids can paint cells as empty if the raycast didn't find anything, or as blocked depending on the slope of the ground. You could use this system by e.g. setting up planes on an extra layer to be hit by the grid generation raycast.

    3) Grids actually don't do anything on their own, activated or not. They're just game objects in the scene and shouldn't cost any performance while playing. What's costly is stuff like grid highlights or pathfinding, especially when using large areas.
    When showing the grid in the editor it's a bit demanding due to showing the handles for all cells.

    4) Usually the nearest grid, but that depends on your setup. You can set up your combatant spawners to use the nearest battle and set up battle components throughout the scene to define which grid to use. Also, setting up multiple grids that overlap each other might be a good idea to prevent having too obvious edges.

    5) No, at least not out of the box. I guess you could use them with some custom scripting to add ORK's grid/cell components to them, but replacing ORK's internal grid logic would be a lot more work :)
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
Sign In or Register to comment.