Howdy,
I’ve started designing the first phase of a content creation app.
I would like to call it jME Studio (JS) if there are no objections.
JS will start out as a modeler with the goal of evolving into a full blown game content creation system.
I am writing requirements, use cases, etc., pretty much going through a full blown development process for creating it. I’m doing this because it appears that my day job is going to require it of me and I need to get some experience doing it. I also believe that if properly applied, a software development process can make a huge difference in the overall quality of a system.
JS needs a rich UI to accomplish what I want it to do and jME provides a robust architecture and strong foundation on which to build JS, thus my motivation for creating a GUI for jME.
I have decided to let the development of JS drive the development of Widgets for the jME GUI. Widget development for JS will also set the priority for which Widgets I work on first. So far, I expect all of the requested Widgets to eventually show up in JS and be available to jME developers. It just takes time to build them.
I need to work on JS to stay motivated. Developing a GUI in and of itself doesn’t do it for me. I will be happy to advise anyone who wants to try developing their own Widget.
Also, I have a question, should JS be part of the jME project or should I make it a project of its own? I’m fine doing it either way and I don’t want to presume either way. Does anyone have an opinion?
Thanks,
Gregg
Hi Gregg,
That sounds pretty exciting and very cool. I have no objection with the name, in fact you could do something cool to use the logo as well. Say a wireframe version of the monkey. Something to tie the app with the API. 
I think driving GUI creation with the app is a good idea because it will insure that the widgets are debugged and optimized properly, as you’ll be using them a great deal. So, that will work just fine.
As far as being part of the API or apart, I’m thinking make the widgets part but the app seperate. However, we will tie the app into the API via the webpage. Renanse is also making a great Particle Engine Editor that could be done similarly. We could then have a seperate webpage of utilities and applications. I’d be more than happy to give you a directory on CVS under the src directory. js or something.
In other words, I want very much for your work to be part of jME but I’m not sure if the code itself belong in the jME API source tree. So, by having it as it’s own package under src will tie it with jME as it’s part of the jME project, but give it it’s own space with it’s own package. Does that sound agreeable?
Anyways, I’m excited to see what you come up with. Let us know what features are needed to make the app complete.
Thanks,
mark
Hi Mark,
I agree that it seems appropriate to keep application code seperate from the jME API source. I intend to keep putting the Widget/GUI code I develop in the jME API source tree.
I’ll consult with you when I’m ready to commit some JS code so I can get it set up properly.
Thanks,
Gregg
This sounds like an excellent idea. It’ll be a great - and useful! - addition to the jME platorm. I’m also looking forward to the improvements in the GUI. I like the name, too!
(On a somewhat unrelated note, I just thought I’d mention that Unreal Tournament 2004 has an excellent in-game GUI. This is exactly the type of thing I would like to be able to do with the jME GUI. If you’re curious, you can download the demo and check it out firsthand. [It’s a great game! :)])