Level editor is not really needed…

Hello everyone. After a (really) long estimation on various engines and languages, I’m stickying with jME. I’m new to both Java and jME, but I already own a couple useful books wich I’m reading.

One of these books is called “the art of game design”, wich made me make the final decision: too much engines rely on polygonal data (aesthetics), sacrificyng logic and procedural (mechanics) to be bound to a fixed space.

When I choosen jME to be my engine of choice, it was for these main reasons:

  1. I was looking for an engine wich is not a prebuilt graphics solution in wich the developer (or team) relyes on a level editor, but can rather define what the graphics looks like in the code as well.



    This is a good choice, but there are several engines wich already provide that. What refined my search parameter is the reason 2:
  2. I was looking for an engine wich is scriptable, while such scripting allows “describing” a scene without the specific need to have “default” polygons created in an editor and can’t be “customized” in real time. This fantomatic scripting language were to be easy to use and learn, yet powerful like a C++ compiler. (in other words I was looking for a graphics library with some game-oriented features and rendering ability)



    Beside this, the engine would have need some real 3D engine features, not being just another graphic library (I would have choosen something like glBasic or simply Java3D otherwise). This leads us on to reason #3:
  3. jME is based on “3D game engine architecture”, wich I already know as I bought the book some years ago. The screenshots for the latest version are very good and I see 2 major features of interest: 1 - portability (jME runs wherever Java does) and 2 - the bullet physics integration (on wich I need more info: is it a port to the Java language for the library or just a binding?)

    jME lacks for some relatively minor graphic features, but is not a real problem.



    I would like to address a sigle issue about jME here, the presence of a level editor. I know it sounds ridicolous, but you’re going to make he same mistake most engines already did (if you haven’t aleady): I just read on devmaster.net jME provides a level editor (or is going to do so).

    Instead of a level editor, think about some kind of language or library to describe 3D scenes.

    Such language should define what a scene contains (like furnishes) and what is it about to contain (like a player character) in the future.

    But the most important feature this language will have to have is relativity: being able to describe chunks of a scene and combine them togheter (reuse them eventually) in a bigger picture.



    Ending, I’ll post an example: let’s say I have a house (and I have), the house contains furnishes, my computer, rooms, various devices, etc.

    The language could describe my house like:

    house
  • downstairs

    . - kitchen + living/dining room
  • upstairs

    . - hallway

    . . - parent bedroom

    . . - my bedroom

    . . - bathroom

    in a spatial description, where each room has its own propertyes (how is it wide, how tall is the roof, but more important: what the rom already contains!) Going on with the same example, I would further describe the space like:

    house
  • downstairs

    . - kitchen + living/dining room

    . . - cooking place

    . . - dishwasher

    . . - …



    This is what my house already contains, but what about each room’s attributes?

    house
  • downstairs

    . - kitchen + living/dining room

    . . + 5 by 7 feet wide

    . . + 6 feet roof tall

    . . + .5 feet thick walls

    . . + …

    (don’t care about measurement, I’m Italian and I don’t even know how feets are compared to meters)

    I’m allowed to be in my house (*). But there are some people wich aren’t (/).

    house
  • myself
  • my family
  • whoever I decide to be in my house

    / people I don’t know

    / criminals

    / whoever I decide to exclude



    And I could insert more stuff later (*), like novelty devices or new furnishes, or trash what I already have (/).

    house
  • new microwave oven

    / old dishwasher



    So, do you see my house is constantly evolving?

    Let’s conclude with a final example: let’s say I’m not happy with my house, I wish to change the rooms order. In the real world this would involve reconstructing the house from scratch (or almost), in the virtual world would require a new 3D model for the house. But what if I had described some rooms before, and I’m now going to change theyr order in the hierarchy?

    My house would become a totally different house without the need to overload my gpu with polygons.

    See:

    house
  • downstairs

    . - parent bedroom

    . . * myself

    . . * my family
  • upstairs

    . - hallway

    . . * myself

    . . * my family

    . . - my bedroom

    . . . * myself

    . . - bathroom

    . . . * myself

    . . . * my family

    . . - kitchen + living/dining room

    . . . - cooking place

    . . . - dishwasher

    . . . + 4 by 3 feet wide

    . . . + 4 feet roof tall

    . . . + 1 feet thick walls

    . . . * myself

    . . . * my family



    Every “object” inside another “object” of course will have a position, wich is relative to the space (the dishwasher is against the north wall, in the middle), and may be it can be moved around. Plus, every object have attributes wich may change or not and some other kind of object wich either are or aren’t allowed to be in that place.

    This way I can also describe a template once and then customize it for more specific rooms/houses/etc, stating I have a “generic” living room with a couch, I could re instantiate the “generic living room” class specifyng a different position for that couch and evenually adding a carpet.



    If I look level design from this perspective, I would state “every kitchen (or almost) have a cooking place”, so I would make a kitchen class (derived from the room class) wich contains “cooking place” as attribute, deriving it to a specific kitchen wich also has “dishwasher” attribute.

    Last, the representation of each attribute may vary (there are several dishwashers to choose from).



    This being sayd, I truly hope jME will provide such kind of scene description out of the box instead of a static level editor.



    Bye, Berserk.

There is no “level editor” in jme3. The scene composer is simply a tool to visualize and modify a stored scenegraph, nothing more but also nothing less. The logic for games, levels etc. the user has to implement himself in a game. jMP only visualizes what is already in jme: the scenegraph. What you do with it and if you call your Spatials chair or monster is completely up to you. With LinkedNodes you can even extend one scene file with something else like you described.



As for “scene description”… We are working on an entity system in which you can have entites that can be any kind of object really. They have components that define their variables and functions. This way completely flexible design is possible. You dont have class hierarchies that restrict you and you can extend any entity, be it a level or npc or anything else.



Cheers,

Normen

Thanks. Can you give me more info about this entity system?



Bye, Berserk.

.

Hello.



I would like to share the idea how I use scripting and scene descriptions.



Java starting with version 6 includes a pretty powerful JavaScript VM. It is extremely easy to use. It works on any platform that is supported by openjdk/jdk 6. (I’m using FreeBSD).



Using JavaScript, I created several libraries (in JavaScript) that provide API to create terrain, create second view camera (RenderToTexture), create and use first person controller, e.t.c



The class that extends SimpleApplication supports command line arguments like --execute file.js.

So you can run the program and provide starting script (scripts) to run automatically.

(Something like the scene to start with).



Also I have a JavaScript API to access a motion capture system that I have access to and WII remotes.



The reason why I’m creating this tiny small JavaScript API libraries (usually it’s a class with 2-4 methods) is that if there are some changes in JME3 API or architecture, I dont need to change all my scenes and logic.



The class that extends SimpleApplication also provides a console with history and word completions, so If you type something like client.getRootNode().getChild(“character”).getLocal and press a tab key twise, you will see on the screen a list of methods that start with getLocal.



Potentially you can create JavaScript libraries for different 3D objects and later aggregate them into scenes (levels) and do some logic also using JavaScript.



P.S. I also have a crazy idea to create a common JavaScript API between JME3 and Unity3D to do dynamic scene interactions and logic. But that might be a little bit challenging because Unity3D sucks … I mean is not flexible.

berserk said:
Thanks. Can you give me more info about this entity system?
Bye, Berserk.

You have a class called entity, it contains a list of components. If you want to check if your entity is a monster, you check if its got the monster component. The components also contain the relevant data and methods (moster_strength, attackPlayer(player) ). Another component could be the "container" component for example, such an entity can store things and the component contains the list of stuff inside, methods to add stuff etc. The real implementation of the methods will probably be moved into a "system" for easier replacement. So your entity will probably have a navigation component, an animation component etc.
Cheers,
Normen

Sounds good. Looking toward it, jME is going to be more serious than C/C++ industry used engines.



Bye, Berserk.

.