Sprites as part of the UI?

Started by
2 comments, last by Guimo 19 years, 6 months ago
What i'm struggling with is should i have separate sprite and UI systems in a 2d game? It seems like there is alot of the UI system that sprites can take advantage of... input, messaging, rendering, parent/child relationships, z-order, states, animation. So it seems like a perfect fit... or is it? I don't think i've seen these two things combined in the past. Any thoughts or experience to share?
Tom Spilman Co-owner | Programmer www.sickheadgames.com
Advertisement
I think it's a perfectly good idea, it should keep your code cleaner as well if you don't have completely seperate sprite code. Of course the UI may require stuff you don't need for sprites but this can always be coded in as an extension to the base sprite system.

I, for example, use the same rendering function/graphics class for sprites and UI and I just have a little extra stuff required by only UI in the other classes. But basically they both use the same versions of functions, UI might just use a couple of extra functions.
I haven't encountered a single problem doing so, and neither will I.
I had the same revelation some time ago. I decided to remove all sprite clases from my engine but kept the animation classes (the ones that control the sprite sequences, times, etc). Now, when I need an sprite, I just create a KBitmap object and assign an appropiate animation to that. Then I add that to my GUI and I'm ready to go.

Even then, I dont mix my GUI with my sprites. I create a control container for the game controls, messages, etc (all the standar GUI layer). And another for the sprite layer. I render them with different z depths and I'm ready.

For me is a very nice architecture. And it can handle mouse events too... :)

Luck!
Guimo

This topic is closed to new replies.

Advertisement