Top SDK features

What are your most important features for an SDK? What must it have? What would you like? What would turn your head in giving it a try…?

1 Like



Asset management features like sdk has.



Integrated with IDEA. At this point I use IDEA almost exclusively as I need the database and JavaEE tools for my server side jme apps.

1 Like

excluding default IDE features like Gradle/Debugging/Docs/etc?

Well, SDK should speed up development.

so generally asset managment i think.

For more advanced games anyway i think your “plugin based devkit” lib is preferable.

edit: to below(3.2 experiences):

  • i agree, often using SDK i had crashes related to editor.
    Try use single model with 2/3 4k textures, it will just break…

  • also selecting texture via menu each time going folder->folder->folder->folder->file is ANNOYING :slight_smile:

A working editor that doesn’t crash


As far as gradle goes, it would be nice to be able to create a jme gradle project right from the sdk.

Like integrating a bootmonkey type feature into the sdk. With the same ability to add more build templates like bootmonkey does.

Edit: One of my goals for the wiki is to make it sdk agnostic so the user can just copy a gradle file and be able to get started using the IDE of their choice as long as it has gradle.

Note that in 5 years, this might read “Integrated with VSCode”, that’s part of our problem

1 Like

Both aren’t reported to the SDK really, right? :wink:

1 Like

VSCode personally is great, and so is IDEA
Imo we need to focus more on an editor, and let the user code with his IDE of choice

1 Like

Would be nice to include a project template generator that can package to all supported platforms (desktop, android, iOS) with gradle.

1 Like

Is this code editor / IDE thing only problem in Java world? Or that jME is coder heavier than many of the others?

I mean, how does Unity tackle this? Or people use Unity with VSCode/VS/Rider/whatevs? Just curious.

A game editor for me should include:

  1. Asset manager
  2. Level/Scene editor
  3. Code editor
  4. Build pipeline for multiple platforms
  5. All in one editor. Don’t want to open multiple editors like, code editor on its own, asset editor on its own, etc.
  6. Game/ app preview/run feature.
  7. Help system/code references.
1 Like
  • Keep the IDE to its strengths: Editing Code. We will never be able to replicate the many features of asset editors like Blender, Gimp, Audacity, etc. so I would advise to keep that complexity completly out of the equation.
  • Instead I would wish to have some kind of automated Hot-Reload Everything: Code, Models, Textures, etc. That would speed up development a lot (e.g. change a few vertices in blender, save and have the engine somehow reload it immediatly in a running game). But I guess that would probably be more of an engine feature…
  • One-Click Git Integration (or other version control systems). Or maybe even an option to auto-push changes on save? Not a git expert though…
  • A very light memory and CPU footprint (more like Notepad++ or something) for less power consumption on laptops etc.
  • Quick startup times.
  • Instant auto-complete / intellisense for code (variables, classes, functions, etc.) and asset paths.
  • Instant quick info about a function / variable on mouse hover with sensible links to the official docs.
  • One-Click Build Process that produces distributable executables.

I recently “switched” from jme SDK/Netbeans to IntelliJ mostly because the integrated profiler crashed HotSpot (AdoptOpenJDK).
Memory and Method Profiler is important to me. IntelliJ with VisualVM seems buggy and slow however. Netbean’s profiler is great (and free).

And I miss the scene composer. I like to create compound assets there with visual Controls. And I like the ability to convert to j3o. But I prefer separate tools for such tasks.
And I miss text completion for asset paths (not sure if this really exists in the jme SDK).

I like code-minimaps as scrollbars in the editor.

ShaderNodes editor seems very interesting, but I haven’t used it yet.

The most annoying thing in IntelliJ is that it keeps the output window open when I run a project, and that window doesn’t close automatically after returning focus to the code editor directly (need to focus the output window first). The SDK shouldn’t get in the way.

Probably irrelevant here, but the reason why I chose Netbeans years ago was because remote compiling and debugging for C++ worked out of the box.

1 Like


And I miss the scene composer. I like to create compound assets there with visual Controls. And I like the ability to convert to j3o. But I prefer separate tools for such tasks.

You can use it even when coding in IntelliJ.

Well, you can just have 2 projects, one for Code(Ant/Gradle in IntelliJ) and second for Assets(Ant project for SDK). If code Gradle based, you can automate pulling assets to project without any compiling them into Jar. (for development)

for example:
runtime files("..//AntAssetsProject/assets") // for develop

1 Like

Preview versions of the SDK should even support gradle projects, so using the exact same project should work.

Unity has it’s Editor and then you can run VS/MonoDevelop and probably the others too.

Desktop and Android yes, I think that should be central to the engine itself though, not only an SDK. In fact this should only be a matter of a gradle multi-project setup with some android bootstrapping.
iOS is a completely different problem, though. You need a Mac and need to build with XCode, not Gradle, you need to embed a jvm etc (not sure if the Mac requirement still holds today) and you need a developer account to run it on your phone anyway.

1 Like

Sample projects library

The point was that everyone uses a different IDE, what ever tools we have should be ‘compatible’ with any IDE, which basically means it should be standalone so that we can use any IDE with it.

1 Like

thats why i told before we need “external toolset”, but some people idk why prefer tools within IDE.

im not against SDK as i anyway treat it more as this kind of “toolset” and use it only for assets anyway.

There is never problem of having more than 1 toolset :slight_smile: some people like SDK, some dont.


Yes, I mean to have something like LibGdx project builder

they have a Gradle sub-project for each platform including iOS and android with all configurations.

And yeah for iOS it needs to be done on Mac I guess.