@Kirlim Thanks for the feedback, let me respond.
49 minutes ago, Kirlim said:
Each tile needing it's own set of data does not imply that every tile should be a MonoBehavior, or even have it's own GameObject. As you mentioned, you can use a common class (or even struct, to enforce value type) on some type of organized containers. Then you can process it anytime and any way you need, without the memory overhead of managing lots of behaviors (or even the memory overhead).
I absolutely agree with that and my original post was trying to explain that as my general original idea (I used bad wording in using behaviour to mean general functionality and not MonoBehaviour).
Also thinking about this more, I am going to need to be able to have destructible tiles that don't have colliders on them too so something like this I think is going to be needed no matter what.
49 minutes ago, Kirlim said:
About the collision detection, I've got really bad experiences trying to make Unity's one working the way I wanted on 2D games. It felt like using Unity against itself. I've ended up rolling my own collisions systems (one was based on simple bounding box - unity already have most of the code for this, and other was a Sweep SAT). Took more time, but overall, felt better than fighting the engine - I believe it's collision detection is better fit for real time and/or realistic simulations.
I have not had much issue with using colliders but then again I might be using it in a non-standard way. I am not using it for physics or anything like that as all movement is just manual position manipulation. What I am using colliders to be able to raycast to detect what objects are in a particular location.
I would like to avoid creating my own collision system unless 100% needed. I am using Unity in order to not have to create those lower / mid level game engine systems that I don't have an interest in building nor do I believe I have the technical knowledge required to build them in any meaningful or efficient way.
49 minutes ago, Kirlim said:
Are the colliders really needed, or that is an assumption? Assumptions will tend to lead to premature optimization or pessimization of something that you actually don't ever need! Since it is a turn-based rogue like, having colliders on map feels weird. Maybe there is a simpler solution, without troublesome collision systems?
While I can't say for sure, I think they are (and by needed, I mean they are much easier to work with that other alternatives). For one, the path finding solution I am using makes it calculations based on colliders to know where impassable areas are.
Another case where I think they are very useful is for tracking enemies. Without colliders I would have to have an array of all enemies and where they are and such but seems like a bit of data to manage manually (not to mention they are accounted for in the path finding).
I am making a number of assumptions and I am willing to consider other ideas however one thing I don't want to do is reinvent solutions in which I don't need a unique solution.
Building a custom collision system seems like a bit of work and I can't imagine any custom work I would need that Unity's collision system does not have. It also seems like building a custom collision system before the Unity's collision system is giving me problems might be a bit premature.
Building a path finding solution is pretty much the same. The path finding I am going to need for this game is relatively basic in comparison to what other game might need to have.
I hoped I am not coming off as "I don't want to do any programming and just have a create game button for me" too much but I am using Unity because I don't want to deal with all the lower level stuff and be able to focus the unique parts of my game as much as possible. I understand there are going to be some lower level stuff I might have to build but I don't think the collision system is really giving me any issue right now.