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

[RELEASED] TopDown Engine by More Mountains [new v3.0 : damage types, damage resistance, and more!]

Discussion in 'Assets and Asset Store' started by reuno, Oct 9, 2018.

  1. Koodetat

    Koodetat

    Joined:
    Apr 11, 2014
    Posts:
    14
    @reuno

    Hello, I intend to buy this asset very soon. I looked at your roadmap, about the multiplayer, are you considering a local multiplayer or online?


    A quest system would be great, with rewards, experience gains, enemy spawn based on the quest ...


    Thank you for your work, again fantastic.
     
    pushingpandas likes this.
  2. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Hello,
    considering buying that asset, I see that there is a weapon system but no magic.

    Would the ranged weapon system be the way to go to create spells or it would be a bit complicated to adapt? I'm not really a coder so I prefer to know if this is something that could be implemented in the future or if this is something already doable.

    Also, I'm using currently Cinemachine for my project, and configured it to my liking. Every time the character turn in a direction, the camera angle will also turn slowly to that direction (meaning the camera is rotating). Is it something that can be achieved in Top-Down Engine as well?

    Last question: I have many melee attack animations (if not all) that are root motion based. Is that an issue? If I've read correctly, the Engine has its own Character Controller, I was using a 3rd party character controller, but wouldn't mind switching if the engine covers my need

    Thanks, anyway that asset looks awesome
     
    MHolmstrom likes this.
  3. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Doud8ou > Multiplayer will be local only, for now.
    @Necka_ > Yes, spells would have to be weapons (I mean you could use something else, but it's designed to handle all sorts of "weapons", including spells (depends on the spell I guess).
    Regarding the camera, the TopDown Engine uses Cinemachine, so yes.
    As for animation, you'll have to try, I never use root motion based anims so I'm not sure of the implications. I'm not super optimistic.
     
    Koodetat likes this.
  4. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Thanks for those answers, I'm sorry about the question with the Camera, I was reading the documentation and then saw the Camera doc... and answered the question for me.

    Regarding root motion, all the other features are appealing me and will save me a lot of time. I'd say it worth the shot and I can always figure out a way to handle that part with in-place animations I guess.

    Also I've seen the Corgi Engine changelog (I was well aware that Corgi is a monster asset with great reputation) and saw all the features you've added over time, if Top-Down Engine is going to follow that kind of support/updates/new features, I think I won't regret it.

    I do not know if your community built some custom abilities for that Corgi Engine in the past years, but from the documentation I saw on Top-Down, I believe that custom abilities sharing could be thing. Is there any place for such thing? like a Discord server or a hub of some sort?
     
  5. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Necka_ > It was still a good question :)
    If the root motion thing doesn't work, please contact me about it, I'd love to hear your feedback on this.
    The TopDown Engine will follow the Corgi in terms of updates and features :)
    There are indeed custom abilities for Corgi available for free on a Github repo, I plan on having the same thing for TopDown as soon as I collect enough to kickstart the repo.
     
    Necka_ likes this.
  6. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Great :)

    you got yourself a new customer ;)
     
  7. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Hey there,

    So I played with the engine for the past hours, honestly it's really great. Didn't encounter much issues (that can't be solved by a bit of reading)

    One small feedback though: The asset import phase overwrite (in case of an existing project) many things. Which is fine as it is required to be as efficient and simple as possible. But one setting I didn't like to see changed is the Scripting version (I'm working on Net 4.X and the asset change it to Net 3) that created a huge amount of errors but again that was fixed easily and apparently there are no conflicts with Net 4.

    I'm not sure that there are actually required Player settings that the Engine requires, if not, it might be good to not include that file in the asset import.

    Ok now for a few questions :)

    1-I've read the documentation and I'm still confused, it's probably just me because of the way I'm working so far with my character Animator.

    For weapons: You can set animator parameters when using it (and for many other cases apparently)

    What I don't get: Is it only for the weapon animator, or can you use the animator parameter on the character? In the documentation on creating a weapon, it's an example with the Character animator.

    When it comes to a Rifle for example, in the demo (Loft) the animator is on the weapon for recoil.

    If I need the character to do some specific shooting animation + the weapon to actually have recoin, how could I manage that? I can reference multiple animators in the Weapon script, but I'm not sure how this works. Would I have to create for example an animator bool called "shooting" on both the weapon animator and character animator and it would trigger both?

    2-Staying on the Animator topic: Can the system handle substates (I.E: referencing "base layer.substate.state") or does everything needs to be flat?
    Same question about Blend Trees, can the Engine handle those?

    I'm asking that because I'm not sure if the base engine is super simple but ultra flexible to include flexibility like those (without scripting in case of the animator states) or if it's meant to stay simple

    3-I'm having an issue and I think you commented you scripts quite deeply so it might be a bug on my side. I do not see any tooltip in the editor when I move my mouse over a setting. For example on the weapon script none of the settings seem to have a tooltip help. I checked in "Tool > more mountain > Enable help in the inspector" it's greyed out, so supposedly active

    Thanks a lot, so far it's really a pleasure to go through the whole asset, everything is so neat and very well thought.
     
  8. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Necka_ > The asset is what the Asset Store considers a "complete project", it's only meant to be imported in a blank project, as explained in the asset's page, the readme, the doc, etc. Unfortunately there's no other ways to do things on the asset store right now. If you want to see that changed I'd suggest talking to Unity directly.
    As for your questions :

    1. By default the animation parameters you set on a weapon will only affect the character. You can bind other animators to it (the weapon's, anything you want) using the Animator array just above the parameter names fields. And yes you'll need a bool of that same name(s) on each animator.

    2. Regarding animation in general, the Engine is agnostic. All it does is send/update parameters. What you do with them is standard Unity and entirely up to you. So sure, go ahead and use blend trees.

    3. There are no tooltips, so it's definitely not a bug.
     
  9. Muppo

    Muppo

    Joined:
    Sep 28, 2016
    Posts:
    242
    Two linked questions about this.

    I was thinking on how it will be and AI Brain comes to my mind. Will it work in a similar way, with a modular scheme? If so, Will this be able to be port to Corgi Engine?

    Thanks.
     
  10. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Muppo > That would be nice. I think the first iteration will be close to what's in Corgi for now. Just a bit improved, but nothing that radical. Always the same idea of focusing on nailing the core features first.
     
  11. Muppo

    Muppo

    Joined:
    Sep 28, 2016
    Posts:
    242
    Sounds logical, as dialog system works nice on Corgi already.
    Will wait to see what path does this feature takes until getting myself into it again.
     
    reuno likes this.
  12. uberwiggett

    uberwiggett

    Joined:
    Jun 26, 2015
    Posts:
    105
    Was going to ask about multiplayer but looks like there is a roadmap somewhere that explains it so I will look for that.

    My other question is would this system work for the 2018.3 isometric tilemaps? I have used other 2d top down systems with it and needed a little tweaking but ai assume it wouldn't be too hard to implement something along the lines of bastion's control mechanics?
     
  13. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
  14. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Edit: Please ignore my message - I actually found it in the animation part of the documentation

    upload_2018-10-25_20-30-13.png

    Bad me! didn't read enough :)

    ---old message---

    I couldn't find in the documentation about this (on Weapon and projectile weapon script)

    upload_2018-10-25_20-0-17.png

    Sorry if I didn't search properly.

    What does it do? is it an free animator parameter that we can add with an Integer (which could be to state: ID0 = Pistol / ID1 = Rifle)?
     
    Last edited: Oct 25, 2018
  15. Muppo

    Muppo

    Joined:
    Sep 28, 2016
    Posts:
    242
    Haven't tested it yet but there's something similar on Corgi for different states as idle, stop, in use, reload, etc. Maybe it's like this.
     
  16. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Yes those animator parameters are there too, those are fine. It's just that in the documentation this parameter doesn't appear on the screenshots, it's probably something added later, I'm going step by step and try to get the meaning of everything :)
     
  17. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Necka_ > Yup, as explained in the doc, this gives you the ID of the weapon, as specified on the weapon. So at all times your animator knows what weapon is equipped and you can use that info in your transitions.
     
  18. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    I know you won't help (like actually doing) with such thing, but I'm asking just for a general guideline here
    TopDown Engine is meant to be agnostic, I got that and tried by myself multiple things (especially in animation) and that's entirely true, which is great.

    One thing though, while there is an inventory shipped with the Engine, I'm lacking some features I was used to (such as filtering inventory by item types, simple crafting and other things like that)

    Those things are already working on my side with my own inventory solution

    Would you be able to tell me (again, I just need direction) how I'd tell the Engine that a weapon is actually equipped from an inventory which isn't the one built-in?

    I mean equipping a weapon is at the end just attaching the weapon to a bone or attachement point. But how do the engine would actually acknowledge that and update the Animator accordingly? Is there some sort of events going on?
     
  19. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Necka_> It's hard to answer that question without knowing the new inventory system.
    Really it's a problem that is on this inventory's side, not the engine's.
    On the engine side it's extremely simple, all you have to do is put a Weapon in the CharacterHandleWeapon's CurrentWeapon slot, that's all, just one line.

    How you get it there though really depends on your inventory solution. The Corgi Engine comes with examples of how to do that with a ScriptableObject based solution (the InventoryEngine), you can take inspiration from that to adapt it to another system. You can learn more about the details of how all that works by looking at the inventory classes in the engine for reference, and in the documentation of course.
     
  20. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Thanks for the answer,

    I can probably start working around with a Wrapper (a weapon equipped on my inventory set the one line you mentionned)

    It’s probably not the cleanest but at start, that will do.

    Thank you
     
  21. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Necka_ > Not sure what you mean with wrapper in that context.
    As I said, if you look at the InventoryEngine specific classes that are included in Corgi (and there's only a handful : CharacterInventory, WeaponItem, WeaponAmmo, you'll get a good idea of how to plug any inventory system to the engine.
     
  22. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    I meant more like a bridge, I’m not a great coder but I can understand the logic and build around that. I’ll check it out and made some tests

    I never used Corgi but I can of course check its documentation. From what I’ve read so far in the top down engine classes doc, it should be quite easy to manage as the weapon handler just need a weapon item to know that it is equipped.

    Don’t want to annoy you before trying all my best first, your guidelines so far should be good enough, thanks for that

    Btw, completely off topic and I don’t want to offend you with that question :) but I kind of hear a slight French accent in your voice on the tutorials, are you? (I’m French, but it’s totally out of curiosity that I’m asking ^^)
     
  23. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Necka_ > I meant TopDown, not Corgi, my bad. Both work exactly the same, no need to check the Corgi's doc :)
     
  24. DiscoFever

    DiscoFever

    Joined:
    Nov 16, 2014
    Posts:
    286
    quick question before (hopefully) purchase:
    I see in the 3D demo that it doesn't use root motion; is it 'hard' to implement ?
    Also regarding aiming, would it be hard to change so that there's no mouse aiming (I mean always aiming forward) ?

    Thanks !
     
  25. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @DiscoFever > How hard something is depends on your skills, not mine, I can't answer that.
    As for aiming, there are currently 3 main aiming modes built into the engine : main movement (forward), secondary movement (second stick on a gamepad for example), and mouse.
     
  26. weberdls

    weberdls

    Joined:
    Dec 24, 2017
    Posts:
    7
    Hey @reuno!

    Does this engine have physics implemented? I mean: character jumping over higher places & climbing, throwing things that bounces on the floor, collisions on the air, etc?

    Great work!
     
  27. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @weberdls > I'm not sure what collisions on the air mean, but yes, there are physics collisions, and jumps. As for the exact feature list, you can see it on the asset's page.
     
  28. Koodetat

    Koodetat

    Joined:
    Apr 11, 2014
    Posts:
    14
    @reuno
    Is it possible to fire on an enemy located lower or higher than the player ?

    Thank you !
     
  29. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Doud8ou > No, not by default, but it'd be easy to implement.
     
  30. nixter

    nixter

    Joined:
    Mar 17, 2012
    Posts:
    320
    Hi there, reuno!

    Just got this and I'm enjoying playing around with it. Great job!

    Got a question about allies. I set one of the Ninja Sword Masters in the demo as Tag: Ally and Layer:Ally. Then I changed his AIDecisionDetectTargetRadius2D:TargetLayer to Enemies. I placed another NSM near him and changed it's AIDecisionDetectTargetRadius2D:TargetLayer to Characters and Allies.

    This does work, but only for 1-2 hits. Then they stand still without attacking. According to the AI Brain:CurrentState, they are both still in Attacking State, but the Time In State meter keeps running up without them attacking.

    Any idea what I'm doing wrong here?
     
  31. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @nixter > You need to change the brain's structure to have it do what you want. After attack have it reevaluate conditions and decide what to do next.
     
    nixter likes this.
  32. nixter

    nixter

    Joined:
    Mar 17, 2012
    Posts:
    320
    Hey, thanks for the tip! That indeed got it working. Here is the code if anyone else is trying to do the same.

    Code (CSharp):
    1.  
    2. // From AIBrain.Update
    3. //Nixter: Adding some resetting to allow attacking to continue
    4.             if (CurrentState.StateName == "Attacking" && TimeInThisState >= 1.0f)
    5.             {
    6.                 CurrentState = States[0];
    7.                 return;
    8.             }
    9.  
    Also: don't forget to change the Weapons' Damaged Caused:Target Layer Mask to include the Ally Layer.

    UPDATE: As pointed out below, changing the AIBrain itself is not a hot idea. better to modify the the AI scripts directly.
     
    Last edited: Nov 1, 2018
    Frog_Milk likes this.
  33. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Hi,
    After playing a while with the demo scene, I've decided to jump in my own scene.

    1-I have a big issue with movements. The character doesn't rotate at all. It just move in all direction without rotating at all

    Having already Cinemachine configured to my liking, I've just added the necessary component copied from a demo scene.
    For the character, I used the "wizard" to auto build the 3D character. set the Ground and obstacle layer, and I think that was it for this part.

    I've copied the managers from a demo scene and the only thing I'm not doing, is spawning the Player character as it is already in the scene. Is that an issue? My scene start with a timeline cut-scene and I need the Player to be already in the scene for that to work properly

    2-The second thing I'm afraid off now, is that I discovered there is apparently no built-in way to have the character to move following the camera direction. And if it is the case you might tell me that I have to extend that by myself but I just can't with my coding knowledge (I build my game mechanics using visual scripting and that is why I counted on this framework to do the heavy lifting)
    Having the player move in the camera direction is very common in top-down game (especially RPG, such as Divinity original sin for example) and it helps a lot for level design too. I do not know how difficult this option would be to implement though.
    In my project I'm having a freelook vCam that the player can rotate using the middle mouse button (otherwise the camera very slowly rotate as the player rotate too) and the mouse wheel can zoom-in/out. Nothing crazy, it's basic Cinemachine stuff here.

    Hope you can help me a bit here for those two points

    thank you

    Edit: Still have the rotation problem (#1)
    For the virtual camera even if it's not related to the issue of not having the player to move/turn in Camera direction, I did find an issue:

    For people like me who use Cinemachine extensively, there are more than one vCam in a scene. Which create an issue with the Camera Shaker script at line 58 because of the "Find object of type".
    Couldn't it be better to have something like:

    Code (CSharp):
    1. _virtualCamera = this.gameObject.GetComponent<Cinemachine.CinemachineVirtualCamera>();
    As the Camera Shaker component is anyway supposed to be on the main game Camera?

    Also I noticed that unfortunately TDE isn't compatible with the Freelook camera (which sound like a 3rd person Camera I know, but is also great for having a top-down rotation + zoom in and out). The orbital transposer from a vCam doesn't allow for a nice gradual zoom-in.

    I believe it's a limitation from the current Shaker which use the perlin noise. And a freelook camera would have 3 perlin noise.

    As Unity 2018+ is a requirement for TDE, why not using the Impulse listener component which is made for Shaking? I mean, maybe in a future update :)
     
    Last edited: Oct 30, 2018
  34. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @nixter > I wouldn't recommend modifying the AIBrain class. Instead, these changes should be made in its inspector directly. Look at the documentation for more info on how the brain works.
    @Necka_ > Please use the support email for support, thanks. I don't know why your character doesn't rotate. If all the demo characters do, and if you've read the documentation correctly, then I'm guessing you've done something wrong, but it's impossible to guess what without details. I'd suggest comparing with the demo characters for differences in setup.
    And no, there's no built in way to have the player move in the camera direction. I wouldn't go as far as saying it's "very common" in top down games though, as I'm not sure what you mean actually. You mean click somewhere and the player goes there? So in the direction of the click? There's a demo in the 3D folder that does exactly that if that's what you're after. If not, then I can add it to the todo list and if more people request it, it'll make it into the engine.
     
  35. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Ok, I will send a mail for the support, I'm sorry to annoy you; but let's not be too harsh here. I didn't know as many dev use the forum for support management and I guess you did have a lot of experience with users asking questions that were obvious.

    On my side I spent the past 8 hours troubleshooting this issue (which made me a little "nervous" too, with no result and of course I compared component by component, side by side with demo assets and read the documentation especially the setup part.

    I'm 99% sure the issue is on my side, but I didn't build the whole engine, I really appreciate that it is neat and well documented, but as you would guess, such framework will attract people like me, who are not so great dev. I'm a good reader though, but again, missing something is easy.

    Ok so for the other points:

    -You didn't mention it, but I do think the "Find component vCam" is an issue as a scene can start with a cut-scene that could involve let say 5 vCam. I updated the code myself but it will be reversed at each update on the store. Just hope you can figure something for this use case

    -For the camera rotation: no, nothing to do with a click to move, it's something that is common in top-down RPG (not action-rpg like Diablo). Like DOS:1 and 2, Pillars of Eternity 2 and others. It's keyboard or gamepad controlled, it is just that the facing direction isn't based on the movement but on the camera forward (like a 3rd person view). It's very convenient and I would really love to see that as a feature. I know for 2D it's absolutely not required, but for 3D it's a neat feature to have

    An example in video in DOS:1 played with Gamepad: youtu.be/7TNjTEKe3OQ?t=41 (edit: removed the https:// to avoid the big thumbnail)

    It's just that environment wise in 3D based on the art style, it does make sense :)

    Hope my arguments are valid enough, if of course that feature isn't too crazy to implement (that would be, movement based on movement or weapon direction or camera forward I guess)

    Thanks again, will send you an e-mail with details and screenshot of my actual setup.
     
  36. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Necka_ > I didn't say anything harsh, just pointed you at the right place politely.
    If you decide to add more cameras, then it's up to you to handle it. The system is built to be extended, you won't lose anything at each update if you extend the code correctly, as is recommended.
    I see what you mean about the PoE2 camera. It's very specific. I'll add that to the list, if more people request it, it'll make it into a release, thanks for the suggestion.
     
  37. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Thank you, for your answer,

    Cinemachine sell point is the Virtual CameraS system. There are to my knowledge no single Unity video that doesn't show a scene with only 1 vCam and you made a good point stating you want to use Unity good practices. That's what makes it so powerful.
    I get it, any feature is meant to be extended by the customer, that's something I didn't understand and make TDE a wrong choice for me. I know basic C# but can't extend stuff that are made by a 30 years old experienced dev like you, I'm humble, I assume that and it's fine.
    The Find Component is in Awake, I would have no clue how to extend from that without changing your core files (because of my knowledge). So I'll stick at the moment updating that single line to use the component in "Self" whenever you make an update to TDE, it's not a big deal ;)

    Thanks for taking into account the Camera idea. I do not know your Background for game making, I just saw on the asset side it's a lot about 2D. For 3D it's just that a Top-Down view is nothing less than a 3rd person Camera moved up and rotated down to a certain angle. So, many Third person controller on the market have that feature to move in the camera direction (or rotate the camera with the movement direction) to be as flexible as possible.

    I'll then wait and hope that feature is requested by more people :)
     
  38. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Necka_ > Multiple cameras is one of Cinemachine's selling points (and it's by far my favorite package). I've used it in tons of projects since its first release. I can assure you it's also really good for single camera games, and it's absolutely not against good practices to do so. Furthermore, top down games are traditionnally single camera (Hotline Miami, Helldivers, Legend of Zelda, Alien Swarm, Binding of Isaac, etc.). This goes for beat em all as well (Castle Crashers, Final Fight, etc). And these are the games the engine is built for. As I said, extending makes it very easy to handle different setups that the engine can't predict. In this case, the LevelManager's Awake method is all you have to override for it to work. You can learn more about extending managers in the dedicated section of the documentation by the way, there's even a code example there (and in Unity's documentation of course, it's nothing specific to the engine). That said, I can for sure add that to the todo list.
    As for your second point, this is not meant to be a third person controller, it's built for top down games, not generic third person games (one would argue that top down games are indeed a sub genre of third person games). I don't plan on adding features that wouldn't be commonly found in this genre.
    But again, if more people request these, who knows :)
     
  39. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    Oki, Thanks for your explanation. I'll have a look at how to extend things like that (I absolutely didn't know it would have something to do with the level manager as the issue was for me on the Cinemachine controller script)

    I might have mispoke about the multiple cameras though: I am of course using only one vCam for my character to be tracked and so on. But as soon as a Cutscene appears, I'm using the power of Cinemachine to change a bit the sequence point of view. Just vCams, no other Main Cameras of course

    One thing to fix that easily actually would kind of having the game vCam using a tag (or even the Main Camera Layer) so any other vCam tagged/layered as default/default would not impact the script in Awake that find the vCam component, it would just search it by this tag or this layer. But I'm not an expert, it's just an idea :)

    And yeah, in 3D it's definitely a Sub-genre, out of twin stick shooters and A-RPG a lot of games (RPG) have an actual rotating camera (even passive and subtle sometime) that the player direction follows. It helps a lot to deal with Level Design too!

    Thank you!
     
  40. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Necka_ > It could very well be on the controller :) Not sure why I mentioned the LevelManager, must have confused with something else. The method is the same though :) Let me know if you have trouble with it.
     
    Necka_ likes this.
  41. Regularry

    Regularry

    Joined:
    Aug 9, 2008
    Posts:
    161
    It would be a much more desirable asset if there were options to have the camera swing around and stay behind the character player. Not having that really limits the types of games you could make with it.
     
  42. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Regularry > But then it wouldn't really a top down solution anymore, would it?
    There's nothing preventing you to do it right now by the way. It's just not something I plan on focusing on. But it's doable, without much code, it's just Cinemachine setup at this point.
     
    M0ti likes this.
  43. Regularry

    Regularry

    Joined:
    Aug 9, 2008
    Posts:
    161
    That's kind of a puzzling response because the 3D example scenes that come with the asset are not exactly "top down" either. The camera is tilted down at sort of a 45 degree angle. Having the camera swing around when the player turns would not make it any more or less "top down" one way or the other.

    I'm also confused because when Necka_ requested the exact same thing yesterday you said "I'll add that to the list, if more people request it, it'll make it into a release". Now someone else is requesting it but you seem to be now rejecting the idea outright.
     
  44. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Regularry > I'm not rejecting the idea, I said it's not something I plan on focusing on. The idea is in the pile, but so far only two people have requested it. We'll see if it gets more votes.

    And I also think that one the forces of my assets is that they are opinionated. I try to avoid feature creep, and provide the right tool for the right job. Feel free to have a different opinion, but I don't think a "rotating camera" TPS and a top down action game share the same core mechanics. If you change 2 of the 3 Cs, then it's not the same genre anymore.

    And so my opinion is that I'd prefer having a strong, "perfect" top down engine than something that tries to do everything and is just average. Again, in its current state, it's entirely doable to do a rotating camera / behind the shoulders setup if you want.

    I hope this clarifies things! :)
     
  45. Regularry

    Regularry

    Joined:
    Aug 9, 2008
    Posts:
    161
    OK, thanks for the clarification.

    Let's try it a different way: Please change my previous suggestion to a request for a new More Mountains product called "Third-Person Shooter Engine". It would be an easy new product to make because it would be almost the same as TopDown Engine but with a few additional camera options.

    However, I guess then melee combat would not be allowed because because that wouldn't technically be a "shooter".

    Oh well, thanks for your time. I'll keep an eye on your product line for future consideration.
     
    Stevepunk likes this.
  46. Necka_

    Necka_

    Joined:
    Jan 22, 2018
    Posts:
    488
    I think this topic is all a matter of point of view. At the end it's the dev's baby so it's his call. But from what I've seen he's listening to his community and eventually features makes it to later updates, but there are obviously focusing priorities (like cleaning out any bugs after D1 release, if there are any)

    To me Top-Down Engine as it is today (for 3D) covers only a style of A-RPG (hack and slash) and Shooters/Fast paced action (twin stick?).

    That statement is only true for the core engine. Anyone can extend it up to their imagination!

    But it could cover all three kind of defined types that are mostly about what the Camera does and not a game genre definition as a RTS is also top-down view:

    -Top-Down: the pure one where you basically only see the top of the head of your character
    -Angled or Isometric: that boomed in the 90s with 3D being more and more present (Diablo anyone?)
    -Rotated: that existed both in 2D and 3D in retro games and of course today (One 2D Contra game had what seemed a rotating Camera but in fact it's the whole environment that was rotating :D )

    Top-Down Engine covers the 2 firsts, no questions.

    A Third Person view has way more work involved as it requires to also manage aiming (both melee and projectiles) with the Camera.

    And maybe at some point MoreMountain will consider creating Third Person controller and why not First Person.

    I think what we are speaking about here is only a top-down (angled or not) camera rotation with player movements synced.

    It's easy to have camera rotation right now. But that means some core changes will need to happen to have the character follow the camera rotation otherwise the inputs become all messed up.

    What is sure to me, is that no actual Character controllers covers what Top Down engine covers if you want to work with a Top-Down view. I worked a lot with 2 other famous Third person controllers and while they are brilliant for a TPS, they are bad for a Top-Down view as you do not need the 3D aiming part in the later.

    And mostly, TDE is not just a Character Controller, that's why I love it, it offers so much features that really fits a top-down view genre that it's just incredible.

    Some features are missing (I plan on doing a feedback post when I will have played enough with it to give some ideas) and everything can be extended if you are a coder. For those like me who aren't, I'm sure MoreMountain will add more and more as the updates goes.

    The asset is featured on the Asset Store since day one, so hopefully it will be a success like Corgi Engine.

    It's all I wish for :)

    To summarize my personal experience: I have used Third person controllers to build my project and so far it was great for the movements and camera but not at all for the Top-Down specifics. Now I'm quite in the opposite situation, but I'm confident because at least I can cover way more grounds on the gameplay part (which is obviously not only about camera and walking around)
     
  47. CHOPJZL

    CHOPJZL

    Joined:
    Dec 5, 2016
    Posts:
    55
    Hello,
    About the 2D part, I found that although the character can flip left and right by code, but 4/8 dir sprites assign and flip seems not supported. Or did I miss something?
     
  48. reuno

    reuno

    Joined:
    Sep 22, 2014
    Posts:
    4,914
    @Regularry > A separate asset would make more sense, yes.
    @Necka_ > You get it :)
    @CHOPJZL > There's no example of that, but you get the direction info in the animator, so it's entirely doable without adding a single line of code. It's just a matter of setting up the right animation transitions based on your character and that direction.
     
  49. Muppo

    Muppo

    Joined:
    Sep 28, 2016
    Posts:
    242
    I like the camera suggestion like DOS @Necka_ said a few post before. It's not I find current one incomplete but a bit more of freedom on the movement could add dynamism (and help when player have to go behind stage elements)
    This and the fading elements as seen in the same video are two things which have my vote for sure in future releases.
     
    reuno and Necka_ like this.
  50. CHOPJZL

    CHOPJZL

    Joined:
    Dec 5, 2016
    Posts:
    55
    Oh, I forgot that, never looked into animation before....then how about melee weapon combo?

    Take the koalaSword as an example. Let's say I want to have act1-left, act2-up, act3-down. From my understanding now, I would keep the 3 weapon components, add animation into the koala_Sword(animator), and add damage area of each direction. Is this enough?