I’m jumping into Unity headfirst and swimming through as fast as possible, but my previous programming experience is rather old school, 80s BASIC and all that. As I’m watching tutorials and reviewing guides, it seems a lot of the Unity strategies involve using visual components. For example, the Roguelike tutorial is using raycasts to detect things on an 8x8 grid.
I can’t help but think, why not just drop the information into an array and have the graphics providing a visual representation of what the numbers are, ‘under the hood’. I saw this again in a Match-3 game, where all of the checks were done by looking at the tiles rather than just tracking array contents.
Is that just a difference in programming styles, or is there a reason not to have the numbers crunched underneath in scripts, and using Unity to present the visual components?
Unity can definitely be a jarring experience if you’ve never worked with visual development tools. I was fortunate to have had some experience with progressively more complex visual tools rather than making the leap straight from programming to Unity (QuickBASIC and C++ were my initial programming experiences).
Unity is designed to be used by more than simply programmers. Dropping the information into an array and processing it from there makes sense to us as programmers but it won’t necessarily make sense to someone else. It’s good then that you can do it exactly the way you want to.
It’s entirely possible to do everything in Unity solely from code. You only need a single scene with a single game object that has a single script attached to it. Just think of the Update() function in that script as your main game loop.
Assets have to be imported at design time using the editor but that’s just a minor step.
It’s just a difference in development styles. Unity’s tutorials are after all designed to teach Unity’s approach.
I think you misunderstood his question (he was asking about how the code checks tiles, not how things were linked up in the editor) but you gave the right answer anyway: it’s just coding styles, do what works for you.
What you describe doesn’t sound very OOP (storing all the information in an array rather than in the objects themselves) but that’s just how you choose to structure things.
They’ve ^^^ already provided some great detailed answers particularly @Ryiah .
I agree it does seem to be an odd way to handle such things (using raycasts to detect tiles) but that is likely because (haven’t taken a close look at the Roguelike tutorial) they don’t actually have any data structure backing things up.
Unity is designed to allow people to just plop things out there in the scene and detect them. So it is all a very generic approach to work with any scenario. In order to do that they provide the Overlap and Cast methods.
Obviously, a better way to do it (for a programmer anyway) would be to use a tilemap and simply look at the map cells to detect collisions.
That is actually what I am doing with my current game which is sort of kind of a bit like a roguelike. I use the SpriteTile map editor to build my levels.
The player, enemies and projectiles all move smoothly and are displayed in whole pixel positions but for collisions with the walls I check the map cells.
For collisions between sprites I simply use an overlapping rectangle method I wrote. So this game will be my first that I purged basically all Unity specific systems having finally replaced Physics2D Overlap and Cast methods with a call to my own collision routines.
I actually just did that part in tonight’s dev session when I added Magic Missiles for the player.
Bottom line is you can do things anyway you like basically. For me this procedural style just using the proven approaches makes development much more enjoyable and productive.
You may well like the Unity Way though if you give it a chance. If not, and you run into problems structuring your programs to do it the way you are used to feel free to PM me.