1
\$\begingroup\$

First of all: I'm not sure if my question is worded well, I just can't think of any better way. I'm also a beginner both at Monogame and programming in general, so my question might miss the actual issue or be based on incorrect assumptions / understanding regarding the topic.

Assuming the following simplified example: a 2D-game in Monogame with a base class Object, derived classes StaticObject and MobileObject and derived from the later the classes Human and Orc.

What is a good way of handling graphics (in the form of several sprite sheets) in this construct? What I can come up with:

a) non-static Texture2D => every instance carries around it's own copy of the sprite sheet, which sounds like a huge waste of resources if, e.g. i have a sprite sheet for 100 different StaticObjects, and a screen with 10 stones and 15 logs on it then has the memory footprint of 25 full sprite sheets, when either one sheet or even just 2% of one sheet would be enough.

b) static Texture2D => all draws from just one sprite sheet, but I don't know how I would deal with having different sprite sheets (after all, they are all the same reference now), and I would rather not put all graphics for all different object classes into just one sprite sheet

c) have a separate (static?) class that houses all the graphics and have all my objects get their graphics from that class => ??

Could anybody point me in the right direction? (Or tell me if I'm going the wrong way all together) Maybe this is also a quite common subject and I just google for the wrong terms, in which case just telling me what to look for would also be great.

Thanks!

\$\endgroup\$
  • \$\begingroup\$ " base class Object, derived classes StaticObject and MobileObject and derived from the later the classes Human and Orc." this is a way to shoot yourself in the foot; what if 1 year from now you want an OrcStatue? Do you inherit from StaticObject or from Orc? You will not want to change your hierarchy so you'll find a way to make it work, but you'll end up with spaghetti code. Take a look at "composition over inheritance", that might give you a couple of ideas. \$\endgroup\$ – Alexandre Vaillancourt May 5 '17 at 21:00
  • \$\begingroup\$ Thanks for the response, I'll look into it. I understood inheritance to be an important concept in OOP, is that incorrect / outdated? Also: am I correct in concluding that "composition over inheritance" would point towards option c) - having an extra class to deal with the graphics? \$\endgroup\$ – Flo May 5 '17 at 22:55
  • \$\begingroup\$ OOP is not outdated. It's just that you should probably not base all of your game on a single hierarchy. Unfortunately, where to inherit and use OOP and where to use composition over inheritance is not black and white, and devs generally base on their experience and gut feeling to decide. \$\endgroup\$ – Alexandre Vaillancourt May 6 '17 at 0:33
  • \$\begingroup\$ As for your question, I'd probably go with c), have a manager that loads and unloads data as required, and all the entities that need the graphics will use the same reference. So you'll have only one instance of each spritesheet loaded in memory. \$\endgroup\$ – Alexandre Vaillancourt May 6 '17 at 0:35
  • \$\begingroup\$ Monogame is smart and will not load in a texture twice. So if you load the same image into tex1 and tex2 then they will hold the same reference. You can load an image of a circle all over your program and they all point back to the same image. A lot of people miss this about Monogame. \$\endgroup\$ – Andrew Wilson Aug 15 '17 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.