(deprecated) jMonkeyPlatform (GDE) – idea thread

First, as a member of the NetBeans Dreamteam I’d like to offer my support. Not that I’m especially knowledgeable but I got to know some clever guys … :slight_smile:



Second, I’d like to discuss how a GDE can bridge the gap between a dev environment and a particular game/game engine that uses to setup a scenegraph on its very own rules and additional infrastructure?



Otherwise a GDE would be limited to resource management (which already is a big deal though…)


  • J
Herkules said:

First, as a member of the NetBeans Dreamteam I'd like to offer my support. Not that I'm especially knowledgeable but I got to know some clever guys ... :)

Second, I'd like to discuss how a GDE can bridge the gap between a dev environment and a particular game/game engine that uses to setup a scenegraph on its very own rules and additional infrastructure?

Otherwise a GDE would be limited to resource management (which already is a big deal though...)

- J
Herkules said:

First, as a member of the NetBeans Dreamteam I'd like to offer my support. Not that I'm especially knowledgeable but I got to know some clever guys ... :)
Awesome! The jME GDE is acquiring quite a following of adversely talented professionals. [In (great) spite of Normen's abnormally agile responsetime, I'll reiterate this anyways] Our very own technical writing expert Ruth 'Zathras' works with the likes of Wielenga Geertjan. If those interested really stick around then this project should see a lot of positive buzz coming out left and right.
Herkules@Web wrote:
(...) The Dream Team should write articles about other things [than tutorials] like real world projects thereby mentioning that NetBeans is the best and natural choice. This will increase believability and trust.
Sounds good! A nice read that interview. Also added JAX to my little list of Java events worth noting.

I think maybe it's time to consider a more complete 'channel' for jME GDE discussion, like a board or Group. Please discuss.
Normen:
About the second thing. Its something that I was thinking about as well. General scenegraph manipulation is something that will be similar in all games because the scenegraph is the same, the jme3 one Wink But advanced game characters for example will be something that differs from game to game as you already pointed out. Still, there could be some basic character entities in a jme3 library that have functions like bullet physics, pathfinding etc. built in already.
Another possibility would be basic game characters and then specialized libraries with FPS or strategy game entities that can be exchanged based on needs.


This is a really interesting point you mention. That's exactly what I thought some time ago (I know everybody could just say that ;) )
In the end you could have several patterns for different game types. And these patterns determine the genre specific things. But they should not be seen as a frame of your work but as a beginning. So you will be able to setup your first pre-alpha after about an hour of work using one fitting pattern. After this hour you've got the basic features of your game working without troubling and going through the forums searching for answers to already solved problems.....
this is really about motivation and could help a lot of people to develop their game further then without these patterns!

So please, get this done. (that's not a command just an appeal)
Custom said:
(...)
In the end you could have several patterns for different game types. And these patterns determine the genre specific things. But they should not be seen as a frame of your work but as a beginning. So you will be able to setup your first pre-alpha after about an hour of work using one fitting pattern
(...)
I am a big fan of this concept myself, and it has come up before as a lower priority extension request for jME3, looking at implementations such as 'input handler for strategy games' and 'drata-driven game development' for initial ideas. Whether such 'genre skeletons' (wouldn't that be a cool name for it!? :D ) and 'ready game components' would fit best as extensions of jME3 or the GDE platform I don't know though.
Custom said:

Normen:
About the second thing. Its something that I was thinking about as well. General scenegraph manipulation is something that will be similar in all games because the scenegraph is the same, the jme3 one Wink But advanced game characters for example will be something that differs from game to game as you already pointed out. Still, there could be some basic character entities in a jme3 library that have functions like bullet physics, pathfinding etc. built in already.
Another possibility would be basic game characters and then specialized libraries with FPS or strategy game entities that can be exchanged based on needs.


This is a really interesting point you mention. That's exactly what I thought some time ago (I know everybody could just say that ;) )
In the end you could have several patterns for different game types. And these patterns determine the genre specific things. But they should not be seen as a frame of your work but as a beginning. So you will be able to setup your first pre-alpha after about an hour of work using one fitting pattern. After this hour you've got the basic features of your game working without troubling and going through the forums searching for answers to already solved problems.....
this is really about motivation and could help a lot of people to develop their game further then without these patterns!

So please, get this done. (that's not a command just an appeal)


This is something I should be able to help weigh in on with some expertise.  Beyond building different games in different engines and editors I've had the unenviable task of porting games from one engine to another.  I started to get an idea about what was a must-have feature, what was acceptable via scripting, and what was implemented in a totally half-assed way.  *glares at the Torque editor*
erlend_sh said:

Whether such 'genre skeletons' (wouldn't that be a cool name for it!? :D ) and 'ready game components' would fit best as extensions of jME3 or the GDE platform I don't know though.

It would be both, so the library can be used without the gde. Of course the gde plugin would include the library to add it to the game project.

And within the GDE you could have a wizard that guides you through the setup of your game based on a spedific genre. After the setup ypu will have this pre-alpha I was talking about. As a programmer you will code some kick-ass-features that represent your game concept best subsequently and use the outcoming alpha version to hire some graphic artists etc.

Don't you think that this would be a good workflow that can be integrated in the gde?



And if you don't wanna use gde you get the libraries that give you some classes for e.g. players of your game that can be extended by yourself.



PS: There's a lot of potential behind wizards. Maybe at a later stage of gde there could be a GUI-design-wizard.

Custom said:

PS: There's a lot of potential behind wizards. Maybe at a later stage of gde there could be a GUI-design-wizard.

Each type of project (simplegame, physicsgame, fpsgame or whatever) will have a template and a wizard that can customize the template at startup. All the basic hooks and preparations (asset import, library initialization) are done in a transparent manner in the template so that they already work and can easily be modified. GDE plugins and wizards care about modifying/creating data that is specific to the library they belong to (e.g. GUI creation and saving of the layout templates).

Well, I didn't know that you already planned to use wizards. But thats great news! :wink:

Custom said:

Well, I didn't know that you already planned to use wizards. But thats great news! ;)

Actually I hate wizards, they let you do things "easily" and afterwards you always feel you have to run the wizard again to do the same thing because its not transparent enough what it did. In my opinion a good software has all functions available and accessible without the need for wizards. (Thats why windows has such a load of them ;p) Anyway, there will be wizards for the initial creation of projects. :P

I think wizards should only be used for the "new project…" dialog, other things should be easy enough to do without.

Couldn't wizards be the sort of thing that you could submit to some online directory (database), like a minimal plug-in almost? Say for instance after having played around with the game development environment for a long time I've figured out a really neat and straight forward way to create a physics-ready vehicle. I could then submit this wizard to the 'wizards directory'.



yes, no?

erlend_sh said:

yes, no?

NOOOOOOOOOOO...... }:-@  .......yes, it could... :'(
normen said:

erlend_sh said:

yes, no?

NOOOOOOOOOOO...... }:-@  .......yes, it could... :'(
I thought that would make you happy, since, now you don't have to create any more wizards yourself... I didn't know you cursed the very existence of wizards and tremble at the idea of them multiplying :P
erlend_sh said:

I thought that would make you happy, since, now you don't have to create any more wizards yourself... I didn't know you cursed the very existence of wizards and tremble at the idea of them multiplying :P

Death to all wizards and their creators *puts on "Witchfinder General" by Saxon*

d'oh.. Apple.. its Witchfinder

Thinking again about this "community snippet input" idea, what about some widget in the gde that presents a list of code snippets sorted by groups. On the jme-site there would be some web form for additions/changes to the snippets database. The gde updates the database on startup and voila, you got a db of code snippets and a useful gde addon…

normen said:

Thinking again about this "community snippet input" idea, what about some widget in the gde that presents a list of code snippets sorted by groups. On the jme-site there would be some web form for additions/changes to the snippets database. The gde updates the database on startup and voila, you got a db of code snippets and a useful gde addon..
I think this could even be integrated with any pastebin scripts' API, like the newly updated Pastebin.com.
Mysticpaste, another freely available open source script, even has a NetBeans plugin already.

Pastebin.com is seeing a lot of changes lately. I'm sure this is the perfect time to ask for particular features if we can come up with any requests.
erlend_sh said:

Pastebin.com is seeing a lot of changes lately. I'm sure this is the perfect time to ask for particular features if we can come up with any requests.

Hm, dont know if using an external site for that is really the way to go? Its another website to manage, new accounts etc.. And really its a simple thing, a properly formatted part of the wiki would probably be enough.. A php script could get the data for the gde update from the db from that, or maybe theres even some plugin for joomla that suits this taks? :-o ..
normen said:

Hm, dont know if using an external site for that is really the way to go? Its another website to manage, new accounts etc.. (...)
That's not really the case. Pastebin is more like Twitter in that sense. People can post code there without an account. The thing about a complete API (which it is heading towards) is that we could take advantage of the service while the end user might not ever have to visit the site! It's just used as the storage facility. For instance, provided the proper plugin, you could probably submit new widgets to the DB directly from the comfort of your IDE. I think they're also working on an embedding functionality for forums.

I understand your concerns about 'yet another webservice', and I'm still not entirely convinced myself, but this new Pastebin is one to watch :)

And really its a simple thing, a properly formatted part of the wiki would probably be enough.. A php script could get the data for the gde update from the db from that, or maybe theres even some plugin for joomla that suits this taks? :-o ..
Hmmm, I'll look into that.