I have heard of “Google’s Material Design” for a long time. At first, I thought it is for Android implementation only. However, I learned couple days ago, from the post below, that Fedora 30 also follows “Google’s Material Design specification”.
My question to you is whether “Google’s Material Design specification” is good for JMonkey 3.2.3 games?
Thank you.
Edit:
I was referring this section below.
Fedora 30 ships with GNOME 3.32, including all-new app icons using a new visual language reminiscent of Google’s Material Design guidelines, making those applications blend well with the Google Chrome icon, for example. Importantly, the new version of GNOME provides more robust support for HiDPI displays, including experimental non-integer scaling, allowing for applications to be drawn at 150% or 175%, when using Wayland. Likewise, backend improvements to GNOME resulted in “noticeable frame rate improvements,” according to the release announcement, resulting in “a faster, snappier feel to the animations, icons and top ‘shell’ panel.”
I’m not sure as to if one can say it is good for jme3 games, much less games themselves. It has more to do with what feel you want the game UI to have. My company uses many aspects of the material design philosophy on website and phone apps, but personally I have never used it in a game. It would depend on if the style would suit your game or not
Material Design is just a design specification for UI - it’s Google’s take on “Here’s what the ideal UI would look like.” There are plenty of other design guidelines out there (many of which I personally prefer over MD), and the one you choose for a jME game is entirely up to you. That said, game UI usually follows very different layout and paradigms than desktop/phone/web apps do, so I don’t see a great deal of applicability of MD and other design guidelines to game development. Do what looks best for your game, and don’t worry about whether or not it fits Google’s design spec.
If you’re using JavaFX or Lemur for your game UI, both of these have a sort of “preferred look” that they provide out of the box - so if using one of those you’ll probably want to lean in favor of doing things their way, unless you want to re-skin all the components completely.
I did not know there are other guide line. I hope you can share some of those. One day, I want to implement JMonkey game using Java Web Start, which I heard is deprecated soon.
Do you happen to know any guide line for Java game programming using Java Web Start?
Well, two other big ones are Microsoft’s Metro (Win 8) and Fluent (Win 10) design guidelines. You’d want to develop for those if you were writing native Windows applications, but like MD I don’t really view them as applicable to game dev except as possibly as a source of a few visual ideas.
Yep - don’t do it. It’s deprecated (as you said) and will be removed soon. Even in its prime it had a whole set of its own issues (just as an end user, I had about a 50/50 success/failure ratio running JWS applications). Also, keep in mind that it was just a distribution technology and had nothing to do with UI - the UI was typically in Swing (or more recently, JavaFx), and the application ran as a desktop application with a few extra security restrictions. Design guidelines and so forth are only as relevant to JWS as they are to the particular application you’re developing.
I’d suggest you start simple with a jME game, and not worry about how you will package it until you’re ready to distribute it.
One last question, please. Do you know what JMonkey team would be choosing to replace deprecated “Java Web Start”? I also hear that Java EE is soon to be free. Why JMonkey decided to go with AdoptedJDK?
There is already an open source Java EE implementation - Jakarta EE.
This is only for the SDK, and in no way limits where/how you distribute your game - it will still run on any OpenJDK based JRE (and others that are compatible with it). I don’t know if that’s even a final decision at this point - the guys developing the SDK needed a pre-built JDK for the SDK’s packaging tools. In any case, the AdoptOpenJDK build is just a build of OpenJDK to replace Oracle’s build (which in recent years was essentially just a plain OpenJDK build as well). Any other OpenJDK build (like Zulu) would work just as well. This will have no impact on the SDK users.
Returning back to the topic, a big plus of google’s material desgin is that they give you a ton if standardized icons that you can use for free. I’ve used those quite a couple of times in my ludum dare entries.
