I should also say that in case of the record screen, I created both SoD and BG2EE versions, that are not 100% match layout-wise. Each screen needed to be tweaked a little to match the art (most visible change is thebottom buttons). I'm not sure if you suggest that the blueprint and thus all the final screens in all games should be exactly 100% same (layout-wise), but I wouldn't recommend that, even if it's mostly the same, a different art takes a different space.
I should also say that in case of the record screen, I created both SoD and BG2EE versions, that are not 100% match layout-wise. Each screen needed to be tweaked a little to match the art (most visible change is thebottom buttons). I'm not sure if you suggest that the blueprint and thus all the final screens in all games should be exactly 100% same (layout-wise), but I wouldn't recommend that, even if it's mostly the same, a different art takes a different space.
My recommendation would be that the blueprint should match BGII:EE since that's the screen that needs the most space between elements. (That's something that you'd want to see addressed in Step 3, assuming you have someone familiar with the BGII:EE theme who can say "Hey we need more room for ornamentation here.")
The adjacent bonus, then, is that it allows the other themes to add more ornamentation if it's appropriate. The blueprint should be the same, and it should befit all three games; if it doesn't fit one of them (and, again, BGII:EE is probably the best litmus test), then it probably ought to be changed for the other two as well.
The reason for that is scalability. If you start with the assumption that every IE game will use the same layout 1:1, then that means creating new themes (or tweaking existing ones) is only a matter of changing art, which means that the cost of doing so is much lower, which means that it's more likely to be approved. It also means that any new theme that gets introduced will only differ in terms of its art from the player's perspective, meaning that a player wanting to choose between Dragonskin and Blue Stone can make that call based on which art style they prefer, rather than which skin has the better usability.
I feel that if it helps us to visualize how those boxes and text will actually look and work in game as we are trying to find solutions to problems it shouldn't be discouraged.
If we need to be reminded of why this or that doesn’t really work well from a technical point of view, I think @Pecca does a good job of that. For example, his insistence on talking about the font scaling issue.
If there is something important that we are failing to consider, then I can see a dev stepping in and letting us know that we are overlooking something. But constantly jumping in and saying “forget about the art, forget about whether it feels appropriate for a Baldur’s Gate Game” is just distracting from the progress we are making.
I do realize that it’s not the developers way of doing things, but it’s not the only way.
If, once we have something that feels right it needs to be put in a format that the developers can understand, that can be done too. I suspect Pecca would be willing to do that.
If the developers are at all interested in getting feedback about what is also important to the fans concerning the style, they can get that by looking at these threads as well. The constant interruptions to those discussions with “forget about the style” feels like they are not a bit interested.
I should also say that in case of the record screen, I created both SoD and BG2EE versions, that are not 100% match layout-wise. Each screen needed to be tweaked a little to match the art (most visible change is thebottom buttons). I'm not sure if you suggest that the blueprint and thus all the final screens in all games should be exactly 100% same (layout-wise), but I wouldn't recommend that, even if it's mostly the same, a different art takes a different space.
My recommendation would be that the blueprint should match BGII:EE since that's the screen that needs the most space between elements. (That's something that you'd want to see addressed in Step 3, assuming you have someone familiar with the BGII:EE theme who can say "Hey we need more room for ornamentation here.")
The adjacent bonus, then, is that it allows the other themes to add more ornamentation if it's appropriate. The blueprint should be the same, and it should befit all three games; if it doesn't fit one of them (and, again, BGII:EE is probably the best litmus test), then it probably ought to be changed for the other two as well.
The reason for that is scalability. If you start with the assumption that every IE game will use the same layout 1:1, then that means creating new themes (or tweaking existing ones) is only a matter of changing art, which means that the cost of doing so is much lower, which means that it's more likely to be approved. It also means that any new theme that gets introduced will only differ in terms of its art from the player's perspective, meaning that a player wanting to choose between Dragonskin and Blue Stone can make that call based on which art style they prefer, rather than which skin has the better usability.
Thanks for the recommendation. This is really insightful.
I should also say that in case of the record screen, I created both SoD and BG2EE versions, that are not 100% match layout-wise. Each screen needed to be tweaked a little to match the art (most visible change is thebottom buttons). I'm not sure if you suggest that the blueprint and thus all the final screens in all games should be exactly 100% same (layout-wise), but I wouldn't recommend that, even if it's mostly the same, a different art takes a different space.
My recommendation would be that the blueprint should match BGII:EE since that's the screen that needs the most space between elements. (That's something that you'd want to see addressed in Step 3, assuming you have someone familiar with the BGII:EE theme who can say "Hey we need more room for ornamentation here.")
The adjacent bonus, then, is that it allows the other themes to add more ornamentation if it's appropriate. The blueprint should be the same, and it should befit all three games; if it doesn't fit one of them (and, again, BGII:EE is probably the best litmus test), then it probably ought to be changed for the other two as well.
The reason for that is scalability. If you start with the assumption that every IE game will use the same layout 1:1, then that means creating new themes (or tweaking existing ones) is only a matter of changing art, which means that the cost of doing so is much lower, which means that it's more likely to be approved. It also means that any new theme that gets introduced will only differ in terms of its art from the player's perspective, meaning that a player wanting to choose between Dragonskin and Blue Stone can make that call based on which art style they prefer, rather than which skin has the better usability.
This makes sense to me. Using BGII style as a base and then trying to find a way to have more uniformity between the games.
Look, I feel like I need to issue a disclaimer. At this point, none of this really matters. Speaking of the inventory, it seems that most of the iterating we'll do with it is done. Not a lot of new ideas come up and most people seem to be mostly happy with the current layout(s) that we have over there. This is a small, technical disagreement about part of an old game's ongoing patch development process. Us arguing about this is like two countries going to war over the region dispute of an outhouse.
So, with that said... here we go!
I think we understand that's the process by which Beamdog does things, it just happens that we take issue with the process itself. I realize Beamdog is unlikely to reexamine and change the process by which they do things just because some keyboard warriors on the internet told them they think it sucks, but I think we're free to voice our grievances regardless. And hey, sometimes criticism leads to change. It doesn't happen often, but it probably happened at some point, right? Presumably?
Anyway, what I personally have a slight problem with is this part:
Step 3: Iterate the blueprint until everybody is happy with the design Step 4: Have an artist put together an artistic rendering of the design
See, step 3 doesn't really work all that great if you show everyone only part of the design. In this case, the functional layout part.
All those boxes sure look great and everyone's happy, so you send it off to step 4, you play Angry Birds for a bit, then it comes back and suddenly not everyone is happy anymore. And that's not necessarily the artist's fault, it's just a matter of some layouts looking great on paper and weird in practice. That's because for humans, it's easier to imagine playing a game with a certain UI layout by actually seeing the game in front of them—or at least something that resembles the game more than some nondescript grey blocks do.
What I think could improve of your process there is to introduce a periodic, semi-realistic rendering of the layout (using one or more of the art styles it's going to employ) during step 3. Does this make iteration take longer? Yes. Does it lower the chances of a fecal hurricane hitting you after the full implementation and publication of your new UI? Also yes.
Am I proud of myself? No. Do I love arguing about inconsequential things instead of doing work? Yes.
@Adul read the subsequent posts from Pecca and myself. I explain why it's important, but also how you could include some artistic renderings as well--as long as you don't completely omit the wireframe layouts.
Some other times when it's important to have a plan before you build the final product:
When you're rehearsing a play, you don't immediately go onto the stage with a fully completed set. When you're building a house, you don't paint the walls before you lay the foundation. When you're baking a pie, you don't put the pan in the oven before you've made the filling. When you're practicing a gymnastics routine for the Olympics, you don't go to Rio before you've decided your choreography. When you're revising a book, you don't write the second draft before you've figured out what was wrong with the first. When you're drawing a comic book, you don't ink the lines before you've drawn them in pencil.
When you're designing (or changing) a user interface, you don't add art before you know what the functionality is going to be.
No, but an architect can look at the blueprints of a modern home and see how the rooms are laid out, and therefore how a new room will need to be built in order to fit with the rest of the house.
Yes they can. But they try to make that addition fit with the rest of the house. They look at what is already there and work within the confines of the current style. If they tacked on a log cabin room onto their customers modern home they would have an unhappy customer.
An architect will do conceptual drawings first, using various inspirations, which are then given to a draftsman to draw up the blueprint. One is artistic, the other technical.
While I think we're going into metaphor overdose, I understand what you're saying @Dee, and I do see the value in wireframes and blueprints and grey boxes. But I also like seeing what we'll get before committing to the final layout. I don't think there's a fundamental disagreement about this between us.
And here are some metaphors so I can fit in too:
When you're building a monitor, you don't put on the casing before putting in the display. When you're blowing glass, you don't start blowing before heating up the glass. When you're having pasta for lunch, you don't wash the dishes before you finish eating the spaghetti. When you're taking a stroll, you don't go out the door before putting on clothes. When you're demolishing a house, you don't start the engine before the family moves out.
Inspired by this talk, I've found this: User Interface design is the design of software or websites with the focus on the user's experience and interaction. The goal of user interface design is to make the user's interaction as simple and efficient as possible. Good user interface design puts emphasis on goals and completing tasks, and good UI design never draws more attention to itself than enforcing user goals.
"The design process must balance technical functionality and visual elements to create a system that is not only operational but also usable and adaptable to changing user needs."
Then I've gone to http://ui-designer.net/interface_design.htm, and found out that Visual design of interface is only the 4th step, after, especially, structurnal and compositional designs.
Also, I can't help but feel like we're going in circles. The next step in our little dance is me describing how I think the current scenario we're dealing with, which is basically suggesting some improvements to a somewhat flawed redesign of an old iconic UI, is different from designing a new UI from scratch. I think that was on the previous page.
Do any of those articles speak specifically to the challenges of fitting new design into a 15+ year old iconic game?
I am already confident that the developers know how things should work when building a game from the ground up.
I am only suggesting that a different approach may be needed in this case. I don’t think it is helpful to disregard the fact that there are factors out of the norm to be considered here.
I am really getting tired of people talking about "what the fans want." Please speak for yourselves and not for "the fans." I too am just as much a fan, and a lot of what some people are talking about on these forums re. the UI I don't want and instead prefer things the way they currently are.
I have to admit, with these discussions I do sometimes wonder if we're just going to end up with what the most vocal section of fans wants and people who like the current UI or just aren't on the forums are going to wonder what the heck happened. But I'm not sure if there's a way to avoid that.
That said, have we discussed the journal yet? Personally, I found the new one unusable until @Mr2150 made his mod and that's pretty much exactly what I'd want. But there may be different opinions.
Here would be my list of issues with the journal @Ratatoskr589 - some solved by my mod, but a list of annoyances with the journal and the journal 'textflash' pop-up (TPU) nonetheless.
My list may be a bit more critical as I've played with it at length (even playing a run through of BG1EE + 1/2 of SOD solely to look at how the journal and TPU work in tandem).
- Cannot filter by completed / active / all quests - Hard to work out which quests are done because the font colouring is poor - 'NO OBJECTIVE TEXT' issue for BGEE and BG2EE (this is jointly a UI issue and an engine issue) - Conceptually it's a brilliant idea (small journal that you can have on screen at the same time as you are still 'live' in the game) but it can introduce a major bug that causes slowdown of the game. - Some people may prefer a larger journal that fills the screen (and pauses the game). - The graphics used for the 'background' of the journal feel completely out of place with the game. - Quest chains can be marked completed before subsequent elements are done - Cannot filter/search quest entries, only journal entries and user notes - Cannot easily delete user notes, you have to go in and manually delete all the text - I think. - The parchment colour is too “white”, it needs to be brought more in line with the tones of the original games. - Ability to go into the journal from the inventory screen. - TPU doesn't find quests and journal entries - TPU sometimes presents entries that don't exist (this is more an engine issue) - TPU doesn't occur for some entries (this is more an engine issue) - ..... BUT, TPU status 'Journal Updated' is sometimes misleading if any of the previous two issues occur - TPU sometimes occurs too quickly to read / click on - TPU updates can often be sequential (eg if a quest is given and updated in the same conversation) - example talking to the mayor of Nashkel for the first time produces two updates. - TPU position is often in the way / takes up too much space - TPU position squeezes text and makes it unreadable.
I'm happy to start a new thread. Are there any other issues that people have with the journal? May as well get them all down here first...
I have to admit, with these discussions I do sometimes wonder if we're just going to end up with what the most vocal section of fans wants and people who like the current UI or just aren't on the forums are going to wonder what the heck happened. But I'm not sure if there's a way to avoid that.
We're providing feedback, not making demands. I expect that our suggestions will only appear in the official release if developers like them or agree with them, not because they were shouted out.
It wasn't meant to your post @Mr2150. I was responding to: " I do sometimes wonder if we're just going to end up with what the most vocal section of fans wants and people who like the current UI or just aren't on the forums are going to wonder what the heck happened." Added a quote to the above.
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.
The current state of the area map is a big step forward compared to the previous version which used a static image and therefore wasn't always showing the actual state of the map. However, it still has a lot of potential for improvement.
I'll just throw in my personal wish list for the area map for discussion:
As already pointed out in various places of this forum, the map is partially covered by the UI elements (side bars and the top element).
The zoom effect may cause slowdowns on less powerful systems. It's also causing this "vertigo kind of feeling" as Ravenslight has described it, or a slight disorientation for a moment.
The directional keys of the keyboard don't work correctly. When used they instantly move the viewport to a fixed point on the map. It appears to be a different point on each map. I would count that as a bug.
The behavior of dragging the viewport with the mouse should be reimplemented. Currently it is only repositioned to the point where you release the mouse button.
The fog of war effect should be removed from explored regions of the map while the area map is displayed. The fog of war makes it difficult to make out structures on the map, especially on dark maps (e.g. at night time or on dungeon maps). Creatures normally hidden by the fog of war should stay hidden, however.
Add a toggle button in the map controls or a separate option that allows us to decide whether to show map markers with or without labels. Currently you have to hover over each map marker to show the associated text.
I “think” I agree with most of this. But as I’m not sure I understand it all as stated, I’ll add that I like how the fog of war works in ver. 1.3 It is only uncovered on the area map view in the areas that you have already traveled.
I don’t know what that white filmy view was supposed to be for, I just know that it was the first thing that I tried to get rid of.
I'm referring to the darkened area outside of the visual range of characters when I'm talking about "fog of war". The black regions are unexplored areas.
To visualize the differences I have created a mockup screenshot where fog of war is disabled in comparison to the current state (brightness and contrast are identical in both screenshots).
I would also like the option to disable the new fog weather affect without disabling the rest of the weather affects. Neat idea, but in practice it just obscures what I want to see.
Comments
The adjacent bonus, then, is that it allows the other themes to add more ornamentation if it's appropriate. The blueprint should be the same, and it should befit all three games; if it doesn't fit one of them (and, again, BGII:EE is probably the best litmus test), then it probably ought to be changed for the other two as well.
The reason for that is scalability. If you start with the assumption that every IE game will use the same layout 1:1, then that means creating new themes (or tweaking existing ones) is only a matter of changing art, which means that the cost of doing so is much lower, which means that it's more likely to be approved. It also means that any new theme that gets introduced will only differ in terms of its art from the player's perspective, meaning that a player wanting to choose between Dragonskin and Blue Stone can make that call based on which art style they prefer, rather than which skin has the better usability.
If we need to be reminded of why this or that doesn’t really work well from a technical point of view, I think @Pecca does a good job of that. For example, his insistence on talking about the font scaling issue.
If there is something important that we are failing to consider, then I can see a dev stepping in and letting us know that we are overlooking something. But constantly jumping in and saying “forget about the art, forget about whether it feels appropriate for a Baldur’s Gate Game” is just distracting from the progress we are making.
I do realize that it’s not the developers way of doing things, but it’s not the only way.
If, once we have something that feels right it needs to be put in a format that the developers can understand, that can be done too. I suspect Pecca would be willing to do that.
If the developers are at all interested in getting feedback about what is also important to the fans concerning the style, they can get that by looking at these threads as well. The constant interruptions to those discussions with “forget about the style” feels like they are not a bit interested.
This makes sense to me. Using BGII style as a base and then trying to find a way to have more uniformity between the games.
So, with that said... here we go!
I think we understand that's the process by which Beamdog does things, it just happens that we take issue with the process itself. I realize Beamdog is unlikely to reexamine and change the process by which they do things just because some keyboard warriors on the internet told them they think it sucks, but I think we're free to voice our grievances regardless. And hey, sometimes criticism leads to change. It doesn't happen often, but it probably happened at some point, right? Presumably?
Anyway, what I personally have a slight problem with is this part:
Step 4: Have an artist put together an artistic rendering of the design
See, step 3 doesn't really work all that great if you show everyone only part of the design. In this case, the functional layout part.
All those boxes sure look great and everyone's happy, so you send it off to step 4, you play Angry Birds for a bit, then it comes back and suddenly not everyone is happy anymore. And that's not necessarily the artist's fault, it's just a matter of some layouts looking great on paper and weird in practice. That's because for humans, it's easier to imagine playing a game with a certain UI layout by actually seeing the game in front of them—or at least something that resembles the game more than some nondescript grey blocks do.
What I think could improve of your process there is to introduce a periodic, semi-realistic rendering of the layout (using one or more of the art styles it's going to employ) during step 3. Does this make iteration take longer? Yes. Does it lower the chances of a fecal hurricane hitting you after the full implementation and publication of your new UI? Also yes.
Am I proud of myself? No. Do I love arguing about inconsequential things instead of doing work? Yes.
Some other times when it's important to have a plan before you build the final product:
When you're rehearsing a play, you don't immediately go onto the stage with a fully completed set.
When you're building a house, you don't paint the walls before you lay the foundation.
When you're baking a pie, you don't put the pan in the oven before you've made the filling.
When you're practicing a gymnastics routine for the Olympics, you don't go to Rio before you've decided your choreography.
When you're revising a book, you don't write the second draft before you've figured out what was wrong with the first.
When you're drawing a comic book, you don't ink the lines before you've drawn them in pencil.
When you're designing (or changing) a user interface, you don't add art before you know what the functionality is going to be.
Architects don’t design blueprints for a modern home if they want to end up with plans for a log cabin.
And here are some metaphors so I can fit in too:
When you're building a monitor, you don't put on the casing before putting in the display.
When you're blowing glass, you don't start blowing before heating up the glass.
When you're having pasta for lunch, you don't wash the dishes before you finish eating the spaghetti.
When you're taking a stroll, you don't go out the door before putting on clothes.
When you're demolishing a house, you don't start the engine before the family moves out.
... I suck at metaphors.
"The design process must balance technical functionality and visual elements to create a system that is not only operational but also usable and adaptable to changing user needs."
Then I've gone to http://ui-designer.net/interface_design.htm, and found out that Visual design of interface is only the 4th step, after, especially, structurnal and compositional designs.
Also, I can't help but feel like we're going in circles. The next step in our little dance is me describing how I think the current scenario we're dealing with, which is basically suggesting some improvements to a somewhat flawed redesign of an old iconic UI, is different from designing a new UI from scratch. I think that was on the previous page.
I am already confident that the developers know how things should work when building a game from the ground up.
I am only suggesting that a different approach may be needed in this case. I don’t think it is helpful to disregard the fact that there are factors out of the norm to be considered here.
That said, have we discussed the journal yet? Personally, I found the new one unusable until @Mr2150 made his mod and that's pretty much exactly what I'd want. But there may be different opinions.
My list may be a bit more critical as I've played with it at length (even playing a run through of BG1EE + 1/2 of SOD solely to look at how the journal and TPU work in tandem).
- Cannot filter by completed / active / all quests
- Hard to work out which quests are done because the font colouring is poor
- 'NO OBJECTIVE TEXT' issue for BGEE and BG2EE (this is jointly a UI issue and an engine issue)
- Conceptually it's a brilliant idea (small journal that you can have on screen at the same time as you are still 'live' in the game) but it can introduce a major bug that causes slowdown of the game.
- Some people may prefer a larger journal that fills the screen (and pauses the game).
- The graphics used for the 'background' of the journal feel completely out of place with the game.
- Quest chains can be marked completed before subsequent elements are done
- Cannot filter/search quest entries, only journal entries and user notes
- Cannot easily delete user notes, you have to go in and manually delete all the text - I think.
- The parchment colour is too “white”, it needs to be brought more in line with the tones of the original games.
- Ability to go into the journal from the inventory screen.
- TPU doesn't find quests and journal entries
- TPU sometimes presents entries that don't exist (this is more an engine issue)
- TPU doesn't occur for some entries (this is more an engine issue)
- ..... BUT, TPU status 'Journal Updated' is sometimes misleading if any of the previous two issues occur
- TPU sometimes occurs too quickly to read / click on
- TPU updates can often be sequential (eg if a quest is given and updated in the same conversation) - example talking to the mayor of Nashkel for the first time produces two updates.
- TPU position is often in the way / takes up too much space
- TPU position squeezes text and makes it unreadable.
I'm happy to start a new thread. Are there any other issues that people have with the journal? May as well get them all down here first...
Edit:quote added.
Added a quote to the above.
I'll just throw in my personal wish list for the area map for discussion:
I don’t know what that white filmy view was supposed to be for, I just know that it was the first thing that I tried to get rid of.
To visualize the differences I have created a mockup screenshot where fog of war is disabled in comparison to the current state (brightness and contrast are identical in both screenshots).
Current state with active fog of war:
Desired state with disabled fog of war: