OK - do Mac devices (it's been a few years since I used one) have other 'click'-type functions that currently don't have a function in the existing UI - eg is there a shift-click or Alt-click or option-click) ?
I have been going though all my old feature requests on redmine looking for anything to do with menus. One I came across is to do with the Mage/cleric spell book. Im not sure if that has already been fixed as my pc is broken atm so i cant play games so sorry if its already in lol.
http://redmine.beamdog.com/issues/20957 [Feature Request] Right Clicking memorized Mage/Cleric spells should highlight corresponding spell in spell book showing its description Description
1. Start a new BG:EE game as the Mage Adelia pregen. 2. Press W to access spell book. 3. Right click on the memorised spell (not known spell) Magic Missile in the memorized spell list at the bottom.
Observed: Nothing happens.
Expected: When you right click the memorised spell it should then highlight the same spell (Magic Missile in this case) from the main left spell list. In turn showing its description on the right side of the page.
Notes: -This would help save time scrolling though the list to match up the icons with the spells whenever we are reorganizing them. -This would also help new players who might not be familiar with what icons each spell correspond to. -The change would effect cleric spells and also be applied to BG2:EE.
Edit: Cleaned up description, old text below: "In the Mage/Cleric book menus where the icons in the lower horizontal bar are displayed for the current chosen spells memorized. Could we get the ability to 'right click' the memorized spell icon to automatically make that spells name highlighted in the main left spell list which in turn would bring up the spell description?
This would help save time scrolling though the list to match up the icons with the spells whenever we are reorganizing them. As well as help new player who wont be familiar with what spells correspond to each icon know what they have memorized."
@Dee probably a silly question I assume the answer is yes, but are you guys also looking at the feature requests for some ideas ?
Not sure if this particular thread is still active, but speaking of the Mage/Cleric spell screen, I'd like to mention something.
The fact that the spells are alphabetical rather than in the order that you memorize them causes some issues w/ the Simulacrum spell (and level drain actually). I don't mind the grouping for organizational purposes, but since spells are lost from right to left, there are some spells it's really hard to pass on to your copy unless you plan ahead. You tend to get front loaded with the first half of the alphabet.
After playing SoD I went into BG2EE, and was totally thrown off by the UI. The UI in SoD looked really polished and in order. The new BG2EE UI looks sloppy. The buttons are not crisp and clear but look like they are bad images and some of them, like the clock, are offset and hanging off the UI. I have tried this in "scaled" and "unscaled" mode and it just looks like a poor mod.
Seems like you could just do BG2 like SoD and it would all look smoother.
@Baptor: During the road to v2.0 the devs switched the design for the UI for BG:EE/SoD based on user feedback but did not have enough time to tackle BG2:EE as well. So that UI is, as you correctly stated, in a sloppy state compared to the other two games.
It was suggested to me that I should post this concern in this thread.
Can something be done to tighten up how the map moves into position with the new patch?
Instead of snapping smartly to an overhead view of your current map as it did in ver. 1.3 it now kind of drags into position.
I used to love flipping back and forth to see where my party was on the map and where I wanted to go next. Now I dread it as I get this vertigo kind of feeling when I go to map view.
It was suggested to me that I should post this concern in this thread.
Can something be done to tighten up how the map moves into position with the new patch?
Instead of snapping smartly to an overhead view of your current map as it did in ver. 1.3 it now kind of drags into position.
I used to love flipping back and forth to see where my party was on the map and where I wanted to go next. Now I dread it as I get this vertigo kind of feeling when I go to map view.
For clarification, the issue you're describing is the effect of "zooming out" to the area map screen, rather than having it be more of a "change screens" effect.
Some people seem to like the effect, but other people don't. Might be worth a simple toggle to turn it on/off.
(The Area Map screen had a lot of new features pre-beta that ended up being made optional; this would be just one more.)
Another thing with the area map I noticed is that the green rectangle doesn't follow the cursor when dragged like in previous versions, but instead jumps to the final location of the cursor when un-dragged. While the functionality remains same, it feels a little less intuitive.
As I put in the other thread, the zooming effect is cute and reminds me of things like CSI when they zoom into/out of a photograph ... but it can feel a bit like this:
Warning! View at your own risk...
You were warned...
Another side-effect of the area map zoom, I think, is when using the area map to navigate across a map. If an NPC approaches you then the game reverts from the zoomed out area map to the standard game screen however it doesn't zoom to the characters. Resulting in the following screenshot. For me this is a different issue than the zooming one but equally frustrating.
Here I've just arrived in Nashkel and am walking across the map to go and recruit Minsc. However the first guard interrupts my journey:
So an 'off' toggle would be very much appreciated, as well as a more intelligent zoom where needed....
I also agree with @Pecca 's suggestion for a drag-able box in the area map.
Now that you mention that, I use keys to scroll around the map, because I tend to play in Maximized Window, rather than fullscreen. If I'm pressing the keys to scroll, when a dialogue pops up, it keeps on scrolling, so I'm looking at a piece of black, or earlier discovered terrain that is far from the dialogue in question.
Looking at the current discussions in this subforum, I would like to say the following.
UI design isn't just a matter of drawing a pretty picture, it's more than that. This is why @Dee has reiterated that one should aim to use a neutral aesthetic when discussing layout.
This subforum, this "workshop" includes lessons on how to iterate on design, how the UI design process works, how to effectively mock things up and discuss them without saying only "I don't like it because it's different". We all have started to learn these lessons already.
Of course, it's not a non-designer's job to explain why you don't like a design, but if you want your ideas to be actually accepted and considered, you need to start thinking as a designer.
Art, no matter how great it is, should not be the first thing to look at when thinking about a certain UI screen. Because if it is, then there can appear a situation when numbers inside icons stop matter and only art matters. Continue to think so, and voila, you get a design that is not functional. Which will kill the end result immediately.
Yes, adding colour can change how we perceive layout. But colour should not be the first thing to imagine, especially when you discuss UI - something that is destined to provide information for the player in the first place.
Concerning that, I'm gonna put @Adul 's post here, which I agree with:
It should also be considered that designing UI for, let's say, BG2, which is part of the "package" here, is not the same as designing UI for a new game. For a new game, yes, you want your layouts to be functionally sound first and then you want to build your visuals around that. And you can go in a lot of directions with it, as you have full artistic freedom.
When making new UI for BG2, you need to be more careful. BG2 already has an artistic style that needs to be adhered to, and frankly, you have less freedom there. Like a lot less. If you make your functional layout too mechanical, or too "rigid", it won't work well with the art style. You need to give primary consideration to both functionality and the visuals. Focusing on one first and having it override the needs of the other is not a good idea.
And not to point fingers, but I think the difficulties that I described above caused a lot of problems with the UI in version 2.0. Of course, it's not my decision how Beamdog will design their next UI going forward, but I want to warn them against committing the same mistake again.
When you're building a house, you're drawing a blueprint from scratch. You get to put every room exactly where you want it to be, you can move things around, you can make everything an octagon if you want.
When you're remodeling a house, you're taking an existing blueprint and making changes to it. You need that existing blueprint to guide you--you'll probably be drawing on a transparency over it as you make changes--and you'll want to have photos of how the house used to look so that you can keep some of its old character. But you're still starting with a blueprint, a sketch.
It's fine to work with full color drawings, but it's not what anyone would call Best Practices.
Soo, thinking about the earlier suggestions from (new or former) developers "asking" or "hinting" for making proposed designs in a neutral environment, it makes sense to follow it (even though I still have some reservations). Because they are likely telling us that this way it's going to be taken more seriously.
But I'd like to emphasize that I think it's very important to match the final neutral design with the final art and evaluate if the layout "fits", not just leave it to the artist to try to "make it look good" as was said. I strongly suspect this approach led to some inconsistencies and oddities we've seen in the EE GUI since launch (like the gap between backpack and ground in the inventory) that eventually devaluated the final product a bit when it made the unfitting elements look somewhat amateurish. And this was even more accented with the v2.0 UI, that introduced even more unfitting elements (such as the record screen being graphically inconsistent with the rest of the UI, or out-of-place red shading of selected spells in the spellbook screen, etc.). These things immediatelly didn't look right to me when I first saw them, if I worked at Beamdog I would have said "this doesn't look good, we need to find another solution". Such practice is what I would call Good Practice. Also in this specific case, when the art (and artistic style) is already made, I think the designer should keep in mind its specifics beforehand and adjust the layout a bit to it accordingly. Such thing he wouldn't have to worry about with a completely new interface.
Of course I'm just a meager amateur and I don't see behind the curtain of what are all the difficulties that need to be overcome to ship a game, so I, by no means, want to sound like I'm giving advices to the professionals about how to do their jobs. I just thought this point of view might be relevant.
After yesterdays discussions it begins to feel to me more like an attempt to justify what we will be getting in the future when they merge all three games. “Well it didn’t fit in all of the games so it was dropped/changed, whatever.”
This argument really makes no sense to me. Fans made mods years ago in order to use BGII’s UI in BG. They could have chosen the same approach, they chose not to. Instead they chose to remake BG into SoD’s image. Going forward, it is again their choice what direction they will take.
Diverting any discussions of what the fans want to see in the way of style and artwork is unnecessary unless they just want to continue on their current course as much as possible.
If they need to see it in grayscale it could certainly be made to look like that for a report, but they should be looking at what it is that people actually want to see as well. This constant effort to discourage any talk about the style of the game just feels like a diversion to me. Before everyone just dismisses that argument, yes, that is what companies do. They emphasize the areas that they want you to think about and constantly bring your attention back to where they want it to be.
To think that they won’t be able to make changes if they see the mockup in anything but grayscale is just silly. Appealing to a fans desire to “do it right” and “be more professional” is again diverting attention away from the style. Yes it is important to take the functionality into consideration. It should not be the only discussion.
When @Pecca made his mockup for the record screen he wasn’t told, “don’t do that, it has to be in grayscale.” It worked just fine.
SoD is marketed as a bridge between BG and BGII. Bridges tie two areas together, they don’t redesign both the other two areas to fit the bridge.
The example of building a house has been used here, so I will use it as well. In this case, I think a more appropriate example would be that you’re not building a house, you are adding a room to a historically significant building. This is much different then building a house from scratch. With different challenges.
There's no intention to merge all the three games. Since the first day of the EEs, each game had its own UI. The question here is not about total unification of all games, the question is that from a functional side, each UI should follow the same guideline (you want to see THAC0 in the same place in BGEE UI, in BG2EE UI and in SoD UI).
So, this argument doesn't exist and it's not a direction the company chooses.
Also, nobody is diverting discussions, discussions flow, and flow quickly, with 50+ comments each day.
The only thing Dee and I mentioned was that when proposing an idea you have to understand how a company looks at it. Nobody is discouraging a talk about the style of the game. Actually, you have been talking about the style of the game since the first day this subforum had been created. And this talk is still continuing. I'm sad to see disappointement is still strong in you, because you (and others) are sharing your views and opinions and they are being discussed in detail in these threads.
Dee and I just try to say that the style is not the only thing you should talk about.
they are likely telling us that this way it's going to be taken more seriously.
See, each idea will be looked at, even the one that is completely about the style and art. But the chances the team will better understand all the aspects of what is being proposed, the chances to see a certain change are much higher when attention is not only on the style.
The company only thinks about improving the game, it doesn't try to make you look somewhere in particular. No area is discouraged.
When Pecca made his mock-up of the Record screen--the final one--it was appropriate because the greyboxes had served their purpose in identifying the layout everyone wanted.
I'll break it down for you. Bear in mind I no longer work for Beamdog; I don't have a dog in this fight, I'm trying to help you all to understand how this process works, how it should work, and why it should work that way. [spoiler]
Step 1: Compile a List of Necessary Features
This work is already done for you; you're not adding a ton of new features, you're taking the features that are already there in v2.0 and shifting them so that they look more like v1.3. Anything beyond that is secondary to the goal of getting v2.0 to look less like a departure and more like an evolution.
Again--the goal of the discussion is to get v2.0 to bring back the elements that made v1.3 great, without losing the functionality that v2.0 added. On the Inventory screen, that means item comparisons.
Step 2: Create a blueprint of where the necessary features will be placed on the screen
This sketch shows placement and sizing. That's it.
And again, most of the work is done for you, because you're not changing the arrangement of the inventory slots; you're changing the layout of the text boxes on the right side of the screen. But it's important to get a sketch of what you have, so that you know what the context is. In the context of the house addition, you're putting together the blueprint of the house as it is now, and then modifying that blueprint so you can see where the walls are eventually going to go in your new room.
Step 3: Iterate the blueprint until everybody is happy with the design
This is where discussion happens. Put this over there, move that down a bit, shrink that box a few pixels. You want people in the discussion who can say, "Hey, we need to leave more space between these icons because it's going to limit the art if they're so close together."
At this stage you don't necessarily want artistic renderings, because (among other things) that makes it harder to iterate; it's a lot easier to move a rectangle than it is to move a collection of pixels and then paint over the space they left behind.
A lot of that depends on the tools you're using, of course--if you're not working with layered images, if you're just editing the raw pixels, then obviously you gain nothing by keeping everything plain, because every change you make is painted onto your blueprint.
At this point, once the design is finalized at this stage, if we were actually making the design and implementing it as a mod, we'd hand it over to programmers to implement the blueprint with just boxes--or in the case of BG, where the UI is already there and we're just changing things, implement the blueprint with just boxes for the elements that are changing.
Step 4: Have an artist put together an artistic rendering of the design
This is where art is important. It's important because now that everyone's happy with the blueprints, you need to see how an artist will interpret that blueprint. It's fine to pick one skin to work with (BGII:EE, for example), especially if one of the skins has more ornamentation than the others; that's absolutely right, and a good instinct.
At this stage, no one should be making changes to the blueprint itself; if something gets brought up that needs to be addressed, you freeze the artistic rendering and go back to the blueprint.
Here, again, it helps to work with layered images; and the artist should be able to "hide" the art in order to see the blueprint underneath (or use the blueprint as an overlay to make sure everything lines up).
At this point, if it helps everyone to work with renderings alongside the blueprints, that's fine. But the changes should always happen on the blueprint--if the artist becomes responsible for making changes without the guidance of that blueprint, that's where things fall apart.
The blueprint is important for everybody--it's important for the programmers because they need to know how many pixels tall and wide the text boxes should be, how large the stat icons should be, exactly where they should be in relation to the rest of the screen. It's also important for the artists, because they'll need to know exactly how things are spaced so they can build things that fit together.
Step 5: Build the final art assets and implement them with code
This is the last step! Once the artistic rendering has been approved (or in this case, agreed upon by the group), the artist puts together each of the individual art assets that will be used with the blueprint to create the final screen.
Of course, here you're just making a proposal. So as a proposal, for Step 5 I would say it's just putting together the final render (Pecca's Record screen, for example) and posting it together with the final blueprint so that the developers can see what the group has decided on. The final render should line up perfectly with the final blueprint so that it's useful to the development team both in terms of the layout and in terms of the art.[/spoiler]
And that's pretty much the whole process. Right now you're in Step 3. You're almost finished with Step 3, but while there's discussion about what the text box should contain and how the icons should be displayed (on top or to the left), posting art is going to get in the way.
Once you've decided everything and there's no more debate about how the blueprint should look, then it's appropriate--necessary, even!--to put it to art. At that point you'll have a solid blueprint that you can refer back to, which the artists can use as a reference, and which the developers can use to implement your design if it's accepted.
If you want to start with the artistic renders, that's okay too. I don't agree with that approach, but obviously some people are resistant to the other way. But if you start with the art, you still have to create a blueprint--the blueprint is what tells you whether or not things are actually aligned properly, it tells the developers exactly the dimensions of the elements and where they need to go, and it gives you a frame of reference whenever changes need to be made.
(The Record screen is still in Step 4, I'd say. The blueprint stopped being updated once the first artistic rendering was posted; in order to get to Step 5, that blueprint will need to be drawn up again--and I'd definitely recommend making the final render use the BGII:EE theme, for ornamentation's sake.)
It does make sense. Thanks Dee for the extensive description. In this context, these discussions are mostly merged steps 3 and 4. I still believe that in case of making UI changes for EEs that is a correct approach, because you can't easily work with just a blueprint when the art already exists and you need to take it into consideration. If you don't, you leave that artist in a very difficult position and he should be ideally able to tell you that the layout sometimes needs to be changed because of the artistic style that needs to be uphold. And that's basically steps 3 and 4 merged together.
It does make sense. Thanks Dee for the extensive description. In this context, these discussions are mostly merged steps 3 and 4. I still believe that in case of making UI changes for EEs that is a correct approach, because you can't easily work with just a blueprint when the art already exists and you need to take it into consideration. If you don't, you leave that artist in a very difficult position and he should be ideally able to tell you that the layout sometimes needs to be changed because of the artistic style that needs to be uphold. And that's basically steps 3 and 4 merged together.
That's legitimate. The only thing I would say is that if that's the approach you want to take, still post the wireframe blueprints. Include the renders as a reference point (especially if you don't mind doing the art), but the blueprints ensure that everyone's on the same page, and allows multiple artists to make their own interpretation if they so choose.
Comments
https://support.apple.com/kb/PH18768?locale=en_US
http://redmine.beamdog.com/issues/20957
[Feature Request] Right Clicking memorized Mage/Cleric spells should highlight corresponding spell in spell book showing its description
Description
1. Start a new BG:EE game as the Mage Adelia pregen.
2. Press W to access spell book.
3. Right click on the memorised spell (not known spell) Magic Missile in the memorized spell list at the bottom.
Observed:
Nothing happens.
Expected:
When you right click the memorised spell it should then highlight the same spell (Magic Missile in this case) from the main left spell list. In turn showing its description on the right side of the page.
Notes:
-This would help save time scrolling though the list to match up the icons with the spells whenever we are reorganizing them.
-This would also help new players who might not be familiar with what icons each spell correspond to.
-The change would effect cleric spells and also be applied to BG2:EE.
Edit:
Cleaned up description, old text below:
"In the Mage/Cleric book menus where the icons in the lower horizontal bar are displayed for the current chosen spells memorized. Could we get the ability to 'right click' the memorized spell icon to automatically make that spells name highlighted in the main left spell list which in turn would bring up the spell description?
This would help save time scrolling though the list to match up the icons with the spells whenever we are reorganizing them. As well as help new player who wont be familiar with what spells correspond to each icon know what they have memorized."
@Dee probably a silly question I assume the answer is yes, but are you guys also looking at the feature requests for some ideas
The fact that the spells are alphabetical rather than in the order that you memorize them causes some issues w/ the Simulacrum spell (and level drain actually). I don't mind the grouping for organizational purposes, but since spells are lost from right to left, there are some spells it's really hard to pass on to your copy unless you plan ahead. You tend to get front loaded with the first half of the alphabet.
After playing SoD I went into BG2EE, and was totally thrown off by the UI. The UI in SoD looked really polished and in order. The new BG2EE UI looks sloppy. The buttons are not crisp and clear but look like they are bad images and some of them, like the clock, are offset and hanging off the UI. I have tried this in "scaled" and "unscaled" mode and it just looks like a poor mod.
Seems like you could just do BG2 like SoD and it would all look smoother.
Can something be done to tighten up how the map moves into position with the new patch?
Instead of snapping smartly to an overhead view of your current map as it did in ver. 1.3 it now kind of drags into position.
I used to love flipping back and forth to see where my party was on the map and where I wanted to go next. Now I dread it as I get this vertigo kind of feeling when I go to map view.
Some people seem to like the effect, but other people don't. Might be worth a simple toggle to turn it on/off.
(The Area Map screen had a lot of new features pre-beta that ended up being made optional; this would be just one more.)
Warning! View at your own risk...
Another side-effect of the area map zoom, I think, is when using the area map to navigate across a map. If an NPC approaches you then the game reverts from the zoomed out area map to the standard game screen however it doesn't zoom to the characters. Resulting in the following screenshot. For me this is a different issue than the zooming one but equally frustrating.
Here I've just arrived in Nashkel and am walking across the map to go and recruit Minsc. However the first guard interrupts my journey:
So an 'off' toggle would be very much appreciated, as well as a more intelligent zoom where needed....
I also agree with @Pecca 's suggestion for a drag-able box in the area map.
UI design isn't just a matter of drawing a pretty picture, it's more than that. This is why @Dee has reiterated that one should aim to use a neutral aesthetic when discussing layout.
This subforum, this "workshop" includes lessons on how to iterate on design, how the UI design process works, how to effectively mock things up and discuss them without saying only "I don't like it because it's different". We all have started to learn these lessons already.
Of course, it's not a non-designer's job to explain why you don't like a design, but if you want your ideas to be actually accepted and considered, you need to start thinking as a designer.
Art, no matter how great it is, should not be the first thing to look at when thinking about a certain UI screen. Because if it is, then there can appear a situation when numbers inside icons stop matter and only art matters. Continue to think so, and voila, you get a design that is not functional. Which will kill the end result immediately.
Yes, adding colour can change how we perceive layout. But colour should not be the first thing to imagine, especially when you discuss UI - something that is destined to provide information for the player in the first place.
It should also be considered that designing UI for, let's say, BG2, which is part of the "package" here, is not the same as designing UI for a new game. For a new game, yes, you want your layouts to be functionally sound first and then you want to build your visuals around that. And you can go in a lot of directions with it, as you have full artistic freedom.
When making new UI for BG2, you need to be more careful. BG2 already has an artistic style that needs to be adhered to, and frankly, you have less freedom there. Like a lot less. If you make your functional layout too mechanical, or too "rigid", it won't work well with the art style. You need to give primary consideration to both functionality and the visuals. Focusing on one first and having it override the needs of the other is not a good idea.
And not to point fingers, but I think the difficulties that I described above caused a lot of problems with the UI in version 2.0. Of course, it's not my decision how Beamdog will design their next UI going forward, but I want to warn them against committing the same mistake again.
When you're building a house, you're drawing a blueprint from scratch. You get to put every room exactly where you want it to be, you can move things around, you can make everything an octagon if you want.
When you're remodeling a house, you're taking an existing blueprint and making changes to it. You need that existing blueprint to guide you--you'll probably be drawing on a transparency over it as you make changes--and you'll want to have photos of how the house used to look so that you can keep some of its old character. But you're still starting with a blueprint, a sketch.
It's fine to work with full color drawings, but it's not what anyone would call Best Practices.
just kidding please don't ban me
But I'd like to emphasize that I think it's very important to match the final neutral design with the final art and evaluate if the layout "fits", not just leave it to the artist to try to "make it look good" as was said. I strongly suspect this approach led to some inconsistencies and oddities we've seen in the EE GUI since launch (like the gap between backpack and ground in the inventory) that eventually devaluated the final product a bit when it made the unfitting elements look somewhat amateurish. And this was even more accented with the v2.0 UI, that introduced even more unfitting elements (such as the record screen being graphically inconsistent with the rest of the UI, or out-of-place red shading of selected spells in the spellbook screen, etc.). These things immediatelly didn't look right to me when I first saw them, if I worked at Beamdog I would have said "this doesn't look good, we need to find another solution". Such practice is what I would call Good Practice.
Also in this specific case, when the art (and artistic style) is already made, I think the designer should keep in mind its specifics beforehand and adjust the layout a bit to it accordingly. Such thing he wouldn't have to worry about with a completely new interface.
Of course I'm just a meager amateur and I don't see behind the curtain of what are all the difficulties that need to be overcome to ship a game, so I, by no means, want to sound like I'm giving advices to the professionals about how to do their jobs. I just thought this point of view might be relevant.
This argument really makes no sense to me. Fans made mods years ago in order to use BGII’s UI in BG. They could have chosen the same approach, they chose not to. Instead they chose to remake BG into SoD’s image. Going forward, it is again their choice what direction they will take.
Diverting any discussions of what the fans want to see in the way of style and artwork is unnecessary unless they just want to continue on their current course as much as possible.
If they need to see it in grayscale it could certainly be made to look like that for a report, but they should be looking at what it is that people actually want to see as well. This constant effort to discourage any talk about the style of the game just feels like a diversion to me. Before everyone just dismisses that argument, yes, that is what companies do. They emphasize the areas that they want you to think about and constantly bring your attention back to where they want it to be.
To think that they won’t be able to make changes if they see the mockup in anything but grayscale is just silly. Appealing to a fans desire to “do it right” and “be more professional” is again diverting attention away from the style. Yes it is important to take the functionality into consideration. It should not be the only discussion.
When @Pecca made his mockup for the record screen he wasn’t told, “don’t do that, it has to be in grayscale.” It worked just fine.
SoD is marketed as a bridge between BG and BGII. Bridges tie two areas together, they don’t redesign both the other two areas to fit the bridge.
The example of building a house has been used here, so I will use it as well. In this case, I think a more appropriate example would be that you’re not building a house, you are adding a room to a historically significant building. This is much different then building a house from scratch. With different challenges.
/ end of rank from one very disappointed fan
There's no intention to merge all the three games. Since the first day of the EEs, each game had its own UI. The question here is not about total unification of all games, the question is that from a functional side, each UI should follow the same guideline (you want to see THAC0 in the same place in BGEE UI, in BG2EE UI and in SoD UI).
So, this argument doesn't exist and it's not a direction the company chooses.
Also, nobody is diverting discussions, discussions flow, and flow quickly, with 50+ comments each day.
The only thing Dee and I mentioned was that when proposing an idea you have to understand how a company looks at it. Nobody is discouraging a talk about the style of the game. Actually, you have been talking about the style of the game since the first day this subforum had been created. And this talk is still continuing. I'm sad to see disappointement is still strong in you, because you (and others) are sharing your views and opinions and they are being discussed in detail in these threads.
Dee and I just try to say that the style is not the only thing you should talk about. See, each idea will be looked at, even the one that is completely about the style and art. But the chances the team will better understand all the aspects of what is being proposed, the chances to see a certain change are much higher when attention is not only on the style.
The company only thinks about improving the game, it doesn't try to make you look somewhere in particular. No area is discouraged.
I'll break it down for you. Bear in mind I no longer work for Beamdog; I don't have a dog in this fight, I'm trying to help you all to understand how this process works, how it should work, and why it should work that way.
[spoiler]
Step 1: Compile a List of Necessary Features
This work is already done for you; you're not adding a ton of new features, you're taking the features that are already there in v2.0 and shifting them so that they look more like v1.3. Anything beyond that is secondary to the goal of getting v2.0 to look less like a departure and more like an evolution.Again--the goal of the discussion is to get v2.0 to bring back the elements that made v1.3 great, without losing the functionality that v2.0 added. On the Inventory screen, that means item comparisons.
Step 2: Create a blueprint of where the necessary features will be placed on the screen
This sketch shows placement and sizing. That's it.And again, most of the work is done for you, because you're not changing the arrangement of the inventory slots; you're changing the layout of the text boxes on the right side of the screen. But it's important to get a sketch of what you have, so that you know what the context is. In the context of the house addition, you're putting together the blueprint of the house as it is now, and then modifying that blueprint so you can see where the walls are eventually going to go in your new room.
Step 3: Iterate the blueprint until everybody is happy with the design
This is where discussion happens. Put this over there, move that down a bit, shrink that box a few pixels. You want people in the discussion who can say, "Hey, we need to leave more space between these icons because it's going to limit the art if they're so close together."At this stage you don't necessarily want artistic renderings, because (among other things) that makes it harder to iterate; it's a lot easier to move a rectangle than it is to move a collection of pixels and then paint over the space they left behind.
A lot of that depends on the tools you're using, of course--if you're not working with layered images, if you're just editing the raw pixels, then obviously you gain nothing by keeping everything plain, because every change you make is painted onto your blueprint.
At this point, once the design is finalized at this stage, if we were actually making the design and implementing it as a mod, we'd hand it over to programmers to implement the blueprint with just boxes--or in the case of BG, where the UI is already there and we're just changing things, implement the blueprint with just boxes for the elements that are changing.
Step 4: Have an artist put together an artistic rendering of the design
This is where art is important. It's important because now that everyone's happy with the blueprints, you need to see how an artist will interpret that blueprint. It's fine to pick one skin to work with (BGII:EE, for example), especially if one of the skins has more ornamentation than the others; that's absolutely right, and a good instinct.At this stage, no one should be making changes to the blueprint itself; if something gets brought up that needs to be addressed, you freeze the artistic rendering and go back to the blueprint.
Here, again, it helps to work with layered images; and the artist should be able to "hide" the art in order to see the blueprint underneath (or use the blueprint as an overlay to make sure everything lines up).
At this point, if it helps everyone to work with renderings alongside the blueprints, that's fine. But the changes should always happen on the blueprint--if the artist becomes responsible for making changes without the guidance of that blueprint, that's where things fall apart.
The blueprint is important for everybody--it's important for the programmers because they need to know how many pixels tall and wide the text boxes should be, how large the stat icons should be, exactly where they should be in relation to the rest of the screen. It's also important for the artists, because they'll need to know exactly how things are spaced so they can build things that fit together.
Step 5: Build the final art assets and implement them with code
This is the last step! Once the artistic rendering has been approved (or in this case, agreed upon by the group), the artist puts together each of the individual art assets that will be used with the blueprint to create the final screen.Of course, here you're just making a proposal. So as a proposal, for Step 5 I would say it's just putting together the final render (Pecca's Record screen, for example) and posting it together with the final blueprint so that the developers can see what the group has decided on. The final render should line up perfectly with the final blueprint so that it's useful to the development team both in terms of the layout and in terms of the art.[/spoiler]
And that's pretty much the whole process. Right now you're in Step 3. You're almost finished with Step 3, but while there's discussion about what the text box should contain and how the icons should be displayed (on top or to the left), posting art is going to get in the way.
Once you've decided everything and there's no more debate about how the blueprint should look, then it's appropriate--necessary, even!--to put it to art. At that point you'll have a solid blueprint that you can refer back to, which the artists can use as a reference, and which the developers can use to implement your design if it's accepted.
If you want to start with the artistic renders, that's okay too. I don't agree with that approach, but obviously some people are resistant to the other way. But if you start with the art, you still have to create a blueprint--the blueprint is what tells you whether or not things are actually aligned properly, it tells the developers exactly the dimensions of the elements and where they need to go, and it gives you a frame of reference whenever changes need to be made.
That all make sense? No? Okay then.