Creating and attaching multiple sprites to an object

I'm starting work on a top-down run-n-gun game as an inexperienced user - visually and structurally 3D, but functionally 2D.

The plan was to use sprites for a lot of things, namely the actors, but I'm pretty confused as to how sprites actually function in Unity. In particular, I'm trying to vertically layer three sprites, with a short distance between them. A head, body, and legs:

------------
------------
------------

I'm assuming that I would make a 3D object and take off the Mesh Renderer (which I have), but I can't work out how to create or attach sprites in the fashion I want.

 

Use a SpriteRenderer.

No need to create a 3D object and then remove all the 3D boilerplate components either - you can simply drag/drop your sprite image from your Assets folder into the scene, and it will automatically create a GameObject with a SpriteRenderer component for your sprite.

Worth noting also that a GameObject cannot have more than one SpriteRenderer, so you would need to create separate GameObjects for each sprite you want to add, and group each GameObject under a common parent GameObject.

 

This is why I hate Unity. This is why Unity drives me around the bend.

This engine takes away the freedom to approach a task in multiple ways, complicates the sole remaining way, and then claims to have simplified the process.

 

?



What is the problem with this method?

 

As Vryken says, whats wrong with this method? I have used it several times for Turrets on Tanks, or other modular parts on an object. Allows you to control them seperately and also , in my case, damage them seperately

 

First and foremost let me be blunt here. Unity is a professional game engine aimed at professionals and while they like to talk about democratizing game development people who make games for giggles are not the target for this game engine.

There are many ways to approach this problem. In fact @Vryken never once stated that this was the only way to do it. You just assumed that and started a rant that only serves to make you look foolish to everyone.

SpriteRenderer exists for same reason as MeshRenderer. It's there to provide a simple way to render sprites. It's not the fastest approach. It's the simplest approach. That may seem like a waste to you but to a professional it's time saved from having to build and support their own system and a professional's time is very valuable.

One alternative method to drawing sprites to the screen is Graphics.DrawTexture but it comes with the caveat that since it doesn't rely on GameObjects it doesn't have a Transform and therefore the developer must work with the identity matrix themselves. You'll also have to set up the material for rendering yourself.

https://docs.unity3d.com/ScriptReference/Graphics.DrawTexture.html
https://docs.unity3d.com/ScriptReference/GL.html

A third method is to create a custom mesh with the sprite materials assigned to different sections of it through code and then rendered using either MeshRenderer or Graphics.DrawMeshInstanced. This is one of the fastest ways to do the job but it takes far more set up than the previous methods. For that reason it's best used when you have an enormous number of sprites to render (eg Terraria).

https://docs.unity3d.com/ScriptReference/Mesh.html
https://docs.unity3d.com/ScriptReference/MeshRenderer.html
https://docs.unity3d.com/ScriptReference/Graphics.DrawMeshInstanced.html

 

I know I probably look foolish, but you also have to understand I've had a hell of a time with this engine, and I wrote that post at breaking point. I've noticed that Unity doesn't really like to let people use raw assets as functional pieces, and it has a heavy reliance on building things from individual, 'Unity-specific' components, which definitely throws me off my methodology.
I often find myself frustrated from spending days on end trying to achieve fairly simple things, to no result; or trying to fix fairly straightforward bugs with no success - and I'm far from the only one that finds Unity to be strangely steep to learn and esoteric to use, compared to the marketing claims they've heard echoing on from those bygone salad days.

Onto Unity being a "professional game engine" - I've been aware of Unity for many years, and I'm still trying to erase my old perceptions from when Unity was strictly targeted towards novice developers. I appreciate that it's easier for professionals to use, but users like me have found our best choice for learning repurposed so that Unity Tech can better break into a more lucrative market.



Anyway, apologies for obliging you to read all that crap with your busy schedule. I appreciate you explaining sprite use in a little more depth; hopefully this'll save me many headaches and heartaches in the future.

 

Agreed, but in my opinion the only people who find it this way are the people who are actively fighting the way the engine was designed to be used. While I found it easy to adapt to thanks to a history with esoteric game creation systems (MegaZeux anyone?) I still somewhat know the feeling as I came to this engine from having worked with frameworks like Irrlicht and SDL.

It is completely possible to treat Unity as a framework and never create more than one game object (you need at least one to hook into the Awake(), Start(), and the other magic methods) but it's not at all documented. You will still need to use the editor to import assets but you can do a great deal from pure code.

If you want to continue down this road there are classes intended to provide raw access to certain subsystems.

https://docs.unity3d.com/ScriptReference/Graphics.html
https://docs.unity3d.com/ScriptReference/Physics.html

Some of the classes intended to be attached to objects have raw methods too. This one takes the name of an audio clip in your assets, a Vector3 to position it, and a volume. The only caveat is that you can't change anything once it starts playing.

https://docs.unity3d.com/ScriptReference/AudioSource.PlayClipAtPoint.html

There is an immediate mode UI system that can be called entirely from code.

https://docs.unity3d.com/Manual/GUIScriptingGuide.html

All that said though I don't regret forcing myself to unlearn the approaches I had picked up elsewhere and while I am capable of using the engine solely as a framework I can't see myself doing that at all. It's just way harder for what I see now as being very little benefit.