I’m new to jmonkeyengine (~ 1 month), I would like to know what is your partices for level design with jmonkeyengine ?
Do you use Scene visual tools (SceneComposer + Scene Explorer + Properties Panel) to create scene or only to view ?
Do you use j3o to store scene and use userData + Control for game data, or use a side files ?
Where do you define Physics’s properties, via code (AppState) ???
What is your process, advices ?
My history begind the question (can be skip) :
Currently, I’m porting a game prototype (you can ask why). The prototype was a webgl+dart ( http://vdrones.appspot.com/ ).
For the prototype I used a Entity-Component-System. Levels are defined in a json OR in a svg file created from inkscape + some xml attribute.
From the level definition, a factory create Entities+Components.
When I start with jME, I used Zay-ES and I began to convert. Later, I saw video about SDK’s SceneComposer & C°. I though “Hey, Control+UserData+AppState can match my needs, and I will be able to make quicker / friendler level with Scene’s visual tools”.
But the scene visual tools are far from my image, I didn’t expect Unity or UDK. But a place where I can place Spatial attach Control, set dimension of spatial, physics body, trigger area (GhostControl) , …
I had some issues, and interrogation. I submit questions and path (via PR), thanks to @normen for help. But after discussion with him, may be I’m in the wrong way (how to use tools, Control, AppState). So my question.
Well, my opinion is that the entity system is still a strong candidate. (I am biased since I wrote Zay-ES and I’m a big fan of ES.) You already have gotten past the learning curve and that’s the biggest negative of an ES.
AppStates and controls can be great for connecting the view (the scene graph) to the model (the ES). For prototyping, it can sometimes even be convenient to treat scene graph objects like the game objects too but I think ultimately it leads to trouble.
In case you didn’t notice, you can run AppStates in the SceneViewer too. So you can run an AppState that initializes your ES which in turn loads models you prepared with Controls into the scene. As you might have found out by now, you can design your game any way you want using any of the provided tools you want. Exactly because there is no predefined way for doing anything theres no tools like in other editors like “place player” or “place trigger” because none of these things exist conceptually in the engine. You define what a “player” or a “trigger” is.
For example, your Ghost Control could be a simple Control extending or managing a Ghost Control with a setting for a size of the trigger zone. Or you make it a simple distance check with only one distance parameter instead of using physics. Then you add it to your scene and make your AppState use/activate it as appropriate.
@pspeed said:
AppStates and controls can be great for connecting the view (the scene graph) to the model (the ES). For prototyping, it can sometimes even be convenient to treat scene graph objects like the game objects too but I think ultimately it leads to trouble.
In my experiement with Zay-ES, I create a Component+AppState to host Spatial+RigidBody, (bad practice from one of your post), because I didn’t understand how/when you “connect” Spatial to Entities. And the entities spawn every things at zero, I didn’t port the load of level from svg.
@normen said:
So you can run an AppState that initializes your ES which in turn loads models you prepared with Controls into the scene
But how ES kown where to spawn models in the Scene ?
I planned to use SceneViewer to place traps, spawn point, exit points, bonus, lights, walls, enemies … (level design)
@normen said:
Exactly because there is no predefined way for doing anything theres no tools like in other editors like "place player" or "place trigger" because none of these things exist conceptually in the engine. You define what a "player" or a "trigger" is.
Because there is no predefined way, is nice but generate lot of question like “which way to choose ? where is the guide ?”. and may be time loose to experiment, ask, reply,…
@david.bernard.31 said:
But how ES kown where to spawn models in the Scene ?
Because there is no predefined way, is nice but generate lot of question like “which way to choose ? where is the guide ?”. and may be time loose to experiment, ask, reply,…
You can place placeholders (for example predefined Nodes stored in j3o files with some UserData like “spawn type” or “NPC name”) in the SceneComposer and later use a SceneGraphVisitor after loading the j3o file to load the spawn points into the ES. You could use a separate AppState for editing and in-game or make the AppState switchable between editing and game behavior. For example the editing AppState could place visual cues at the location of the Nodes you place so you see them. If it attaches them to the rootNode of the scene and not to the loaded level node you don’t have to save them along with your scene either.
Yeah, jME is not a “game maker” type of tool and isn’t intended to be, really. Its like asking for how to place a player in Apples SceneKit or in Java3D. There is no “typical jME game” like the typical UDK games. That said, we do plan to add some templates for game types like FPS, RTS etc. but it really only makes sense when theres some form of framework that can be used to combine such functions, else it just restricts the user. ZayES is a good start for future game-specific templates and might form the core of these kinds of extensions for the engine so investing into that surely won’t hurt.
Thanks, it’s this kind of advice I ask for. This morning, I though 1) will be the next way to explore (as I over/misse use control + Scene), but I prefer to ask before this time.
In my case I also use SceneViewer to tune and to configure behavior (like displacement of mobile wall). Using Control for those behavior, allow +/- interactive tuning, allow to save in the j3o the configuration,… It was a big plus versus storing values in a Component (need a way to store, and “manually” sync, or reload, …).
Other tips, advices or ways to make level design ?
Anything thats more or less “mesh editing” should be done in a 3d editor. Its such a vast topic, it wouldn’t make sense to try and replace that with SDK functions. Stuff like “engine specific material tuning”, “metadata editing” and “compositing” can be done with the tools in the SDK and/or with code.
But if I use the mesh to define zone used as game data (place holder, area of effect, trigger zone). IMHO it should be define in SDK tools, to be able to quickly test it with AppStates. AppStates use it as input data to create level (or other stuff like slot, hit zone on charactere).
Such zone can be box, sphere, disc, line,… free surface.
Wrong way ?
EDIT : Can I add in SceneExplorer “Add Spatial …” > “Add Geometries…” > “Box” / “Sphere” / “Line” ?
@david.bernard.31 said:
But if I use the mesh to define zone used as game data (place holder, area of effect, trigger zone). IMHO it should be define in SDK tools, to be able to quickly test it with AppStates. AppStates use it as input data to create level (or other stuff like slot, hit zone on charactere).
Such zone can be box, sphere, disc, line,… free surface.
Wrong way ?
EDIT : Can I add in SceneExplorer “Add Spatial …” > “Add Geometries…” > “Box” / “Sphere” / “Line” ?
Again, you could simply make a Control that represents a trigger that creates a Geometry/Mesh with such shapes and attach it to a Node, save that as a j3o and add it to any scene you want. To add primitives like boxes, create one in Blender and add it the same way.
You can easily make your own commands for the “Add” menus as well, but adding box geometries via that menu when for any real game you will either import models from artists or create geometry procedurally really makes no sense.
The goal of thoses boxes is to define placeholder/zone :
where to procedurally generate content (or avoid to generate)
mesh like walls, labyrithm, …
rigid body
trigger area (I don’t understand “Control that represents a trigger that creates a Geometry/Mesh with such shapes”)
where to load/display model from artist, usefull for dynamic display (??)
So it make sense for real game (IMHO)
I tried your solution, I create a cube in blender, save it, convert into j3o, add/link multiple time into test scene. it’s less usefull and heavier than having “Add Box” into SceneExplorer. (need to remove parent node, link to .blend,…).
@david.bernard.31 said:
In my experiement with Zay-ES, I create a Component+AppState to host Spatial+RigidBody, (bad practice from one of your post), because I didn't understand how/when you "connect" Spatial to Entities. And the entities spawn every things at zero, I didn't port the load of level from svg.
But how ES kown where to spawn models in the Scene ?
I planned to use SceneViewer to place traps, spawn point, exit points, bonus, lights, walls, enemies … (level design)
So your question isn’t really about how to spawn entities as much as it is how to give entities an initial Position component, etc.?
Normen has done this before with the scene editor by placing dummy spatials that identify what they are by name or something. (I think) when loading a level he uses those to create the entity but otherwise drops the placeholders. He could probably explain more.
@david.bernard.31 said:
Right, how to place, configure entities to create a level ? (include how to save/load)
Just like I explained. You can do that now. Either put in nodes that you preconfigure in j3o files and adding them to the scene by right-clicking and selecting “add to scene” or add Controls that you make yourself. Then Run an AppState in the scene (right-click->run AppState) to connect it to your ES.
How to share my 2 commands for SceneExplorer to create “Geometrie : Box” and “Geometrie : Sphere” :
as PR for SDK
I have to create my own nb module suite
?
IMO this should be directly in the SDK not as a plugin. It’s been discussed many times in the core chat or on the forum : being able to add primitive shapes in the scene composer directly.
We agreed in the core team that was a marginal case and that usually user would load models and most probably not use cubes spheres or quads.
But in practice I often found myself needing some primitives (especially quads for effects). I always end up in blender making a quad with texture coordinates and import it into the sdk, so basically…having the possibility to add primitives could make user’s life easier (which is IMO the point of the SDK).
So IMO : PR for the SDK is the best way, with a discussion post on the forum, pretty much as you did for the others PR
