Custom objlook graphics

[meadwarrior]

Hello!
Showing the custom objlook works brilliantly, however the data from the normal objlook is still rendered on top:



How could I get rid of this?

Thanks!

[Sophia]

It's designed to provide a custom background. You really shouldn't be using it to display text and such. Making all of those bitmaps is going to be immensely tedious for you, too!

I know that we haven't really nailed down the specifics but since we've already agreed that I'll do some programming work for your game as part of whatever deal we end up making, perhaps I could help out here, too? Making the renderer more flexible is of enough value to DSB that it's definitely something that I'd not mind doing.

So then the question becomes... what kind of things were you hoping to add to it?

[meadwarrior]

I appreciate it very much, and at the same time I feel like you won't like what I'm about to tell

To be honest, I haven't finalized the design for the objlook yet, so having the ability to just put graphics in there is awesome for testing purposes.

As for the bigger picture, speaking from an graphic artists perspective, customizing the objlook (or anything, really) with graphics is much, much more convenient for me. I'm just more used to dealing with large amounts of graphics, whereas working with long codelists is really quite cumbersome (and often stressful) for me in comparison.
That's also the reason why ESB is so great
Nothings against the code in DSB, of course, or against generally doing things in code. It's just a matter of personal preference and ability, I guess.

So, while I do have some useful additions planned for other parts of the game (at least I like to think so),
in this case it would be brilliant to just be able to make the overlaying elements invisible

Sorry...

[Sophia]

I'm not sure what you think is going to be cumbersome and stressful.

I'm offering to write the actual code for you, and the data used to generate that screen will be already needed by the game anyway: the item's name, its mass, its attack power, and so on. So I guess I just don't understand what kind of issue you're anticipating.

That said, it's your game. If you want to waste your time and your players' RAM on a bunch of fixed screens, it's not my place to stop you.

[meadwarrior]

I probably complicated the matter unnecessarily by showing a objlook that seemed like the final layout, but actually wasn't.
Here are examples of other designs I'm thinking about, which might even vary between different item categories (weapons having a different design than consumables etc.):





Since I use the objlook for storytelling, I'd have to test which approach works best first before being able to specify exactly how it would work.
For now, it's definitely easier for me to just put a picture in there, seeing as my first playable mini-teaser will only have a couple of items anyway

[Gambit37]

With my designer's hat on, I can totally understand the desire to have complete control over how these objlook screens should look, and why you want to do it that way: if you're not a coder, it just seems easier to do it all in PhotoShop, right? But with my developer's hat on, I really would listen to Sophia's advice on this: pre-drawing lots of these objlooks is a bad idea.

Firstly, every bitmap you load into DSB requires memory, and the more unique bitmaps you create, the more memory is required. Generally speaking, it's worth trying to keep memory consumption as low as possible: it's better for performance and means that older computers are more likely to be able to play your game.

Secondly, it's a ridiculous amount of work to pre-draw all these screens. I experimented with something similar years ago and after 10 or so unique objlooks, I gave it up as a bad idea. You're much better off designing a UI element that can be populated with data from the archetypes themselves, and let DSB draw/write that data over the top.

Third, what happens when you want to make some minor text changes to some of these objlooks? You'll have to edit your source files and export them all again. That's a horrible workflow (again, I know from experience). But if you have that data in code, it's much easier to edit it in code and let DSB do the work of updating the visual with those changes.

As Sophia is willing to help you with coding, I'd jump at the chance and recommend you take that option. It's your choice of course, but you'll really be missing out on the major benefits of how DSB works if you decide to pre-compose all this stuff as bitmaps.

[meadwarrior]

Thanks for the insight, Gambit!
Also, I have to apologize to you, Sophia, for my second post, as I realize it might come over as unthankful (which I'm not, I'm really thankful for all of your help).
I'd love to have help with the objlook, it's just not really a priority right now (and like I said, the design is far from being final). I wouldn't want you to code a specific design and then come back the next day with additions, changes or a total redesign.

My highest priority right now is the battle system, but more on this soon in another thread

One more question:

...the more unique bitmaps you create, the more memory is required.

I plan to create at least one unique bitmap per item anyway (the large view of the item icon). So this would be a bad idea as well?

Thanks!

[Sophia]

Don't worry, meadwarrior. The features and customization options I'll add (yes, including the option to make elements invisible) are all going to be in the form of a table that would aid in customization. I wouldn't want to hardcode any new changes.

[meadwarrior]

Sounds cool! Glad we were able to sort this out

Thanks!