Thought Experiment: Material Design and MUing
-
I don't know how many people have read the Material Design documentation (I'm almost done), but I keep thinking: How can this be applied to MUing?
I feel like there's a way, like it's on the tip of my tongue. I think that we should scratch our heads and think of ways, even if it might seem like nonsense, that we could learn from Material Design, even if in some abstract or esoteric way!
I thought about putting this in the code section (and there might even be code applicable ideas), but Material Design is a design language and not necessarily strictly code oriented.
Any ideas?
-
I haven't read the material.io design manifesto, but it's a design manifesto, so as far as I think that it'd be applicable to a MU... well, it's essentially a design document.
I think it would most evidently be applied in the clarity of the grid, the rooms, the help files and so on. I think most games strive for this by having Room Parents to enforce coherent and cohesive theme, and they standardize all code output to have lines and so on. This is pretty common.
I am anal as a coder, and so when I build out a game, I have a structured document that I upload to build out the first 100 objects so that anything with a dbref of #100 or less is a game-owned object, usually OOC grid and Master Room objects.
Oh, and I guess that my ansi color schemes, while the player can recolor the entire game's primary and secondary colors with preferences on themselves, are very MD in that they are 'flat'?
-
@Rook I haven't read it, but from what you're describing I get the general idea.
And I'm kinda giggling over here because I'm kinda doing the same thing, re: design.
I color-code things like whoa, and cringe when something falls outside of the standard header/display format that's set up. I'm still working on unifying all of that.
Also, people can pick their own colors; colorblindness is a thing and some people do use white backgrounds/etc. so the ability to customize this stuff is, IMHO, a useful thing.
The colors come in two sets: one set of four IC colors, one set of four OOC colors. This color-codes the data as it is presented in a way that subconsciously reinforces whether that information is IC or OOC info. Commands, help/news files, OOC talk, OOC notifications, even the headers and such for OOC areas all use the OOC colors. IC areas and notifications? Use the IC colors. (OOC talk and commands still show up in the OOC colors from an IC space, since they're still OOC info.)
It's subtle. It's super anal-retentive of me and I know it. I also know it's a handy subconscious cue/reminder about what's what.
-
@HelloProject said in Thought Experiment: Material Design and MUing:
I don't know how many people have read the Material Design documentation (I'm almost done), but I keep thinking: How can this be applied to MUing?
I feel like there's a way, like it's on the tip of my tongue. I think that we should scratch our heads and think of ways, even if it might seem like nonsense, that we could learn from Material Design, even if in some abstract or esoteric way!
We can learn that there is benefit to a well-thought off design document. Notice how almost nothing in it explains why these things are; there is undoubtedly a deeper design document that is used between members of this design team, or the document used to explain to management why this works. Probably during classes for the curious at Google's I/O.
This document is for informing people how to design a consistent experience. You'll notice that the most core of concepts are explained and illustrated before getting to the meat of the matter, and each layer of complexity (movement, color, etc.) does the same thing.
Though all I can think of now is how Google hired a graphic designer who quit out of frustration at the Google engineers arguing over which color of blue to use for a project.
