I work on some kind of point & click game. Point & click is working to move around. The player do have a bag for items he can collect. The items in that bag are displayed with the nifty gui. I also can click those itmes i.e. box of matches and the player light a match. Or an old cell phone which spends some light.
So far everything is fine and works. But now I have some room items which lay somewhere in the room or are attached to the room like a light switch. The switch is initally off. The switch is as well an item. I made the room with blender including a shelf, a chair, a door and a light switch.
I think enough background to describe my design question
What would be best way to store the state of items in a room. A of course those items can leave the room not all but most of them. My room is a j3o file and in the end I have a node.
My current idea is to store the loaded node again with state of the items in it. If I add items by the player to the room there is most probably no other way. But initially I have to place the items with its state or add a state to the items already placed by blender. Maybe I need a room constructor to enhance the state/control/what ever of the items in that room.
Are there any good design practice for this. Maybe somebody already had this problem and was able to apply a nice solution? Maybe there is already a thread about this (I did not found but maybe I used the wrong keywords).
One idea I have is a description file for every room and its items, where I write down the state, which control and so on. But a little unsure if I head into the wrong direction.
If Iām understanding your question correctly and what you have implemented so far, I would say your first mistake is having the room and the (initial) objects in the room as part of the same blender model. I would have a model for the room in blender. Then, I would have separate models for each object that can be picked up from a room and moved/taken elsewhere. Objects that can be interacted with, but, cannot leave or move around the room (except by some program logic) could be a part of the blender model of the room and you would only need to attach controllers to those nodes that represent interactive spatials within the room. Objects that can be picked up/moved/leave the room by the player should be there own blender models and should be placed in the correct (initial) locations programmatically.
I canāt tell you exactly how to do all this in JME yet (Iām just beginning with JME - and 3D game programming/modeling in general), but, Iām an experienced Java programmer and in reading the documentation for JME/Blender (and with what Iāve learned so far) that is the approach I would take.
Does that help? Sorry I canāt be more specific at this time.
It sounds like one of the things that is holding you back is thinking of JME Spatials as if they are game objects. It is better to have separate game objects and just let the Spatials be the visualization of that.
Whenever I hear someone imply that they will save a Spatial as a j3o in order to save the state of a light switchā¦ I throw up a little in my mouth. There is much pain down that path and it physically hurts to imagine someone else going through that.
Thanks for the advices so far. Helps me in deciding something So if I get @pspeed right itās better to have the room with its representation and a ghost room for the holding the state of the room and its objects in it.
If I get @gerald_edward_butler correctly you would go with room and objects separated and place the objects by codeing. But it is easier to place them visual than within code. Isnt that very static and maybe not so handy. If I want to change things or even move them I would then have to recode it. But maybe I got you wrong.
@pspeed how would you link then the invisible āghostā room with its graphical representation? By naming convention? I know the name of the meshes inside a room or I can at least list them. Or is this as well a bad painfull way? I was thinking of using nodes and user data for that but may be I should design own game objects implementing savable?!
There are a few different ways that you can do this with varying levels of performance, flexibility, and ease-of-use.
On one end, you have an approach where you do all of your editing and object placement in Blender and give everything custom names (probably unique and including an object type ādoor:123ā or whatever). Then you fix up the names with real objects when you load the level. The down sides are that the scene may not be very optimal. Itās unclear if submeshes are shared in this case but I suspect not.
In the middle, you have an approach where you create your scene in blender but then load it and tag it in the JME scene composer. At this point you can place objects also but the point is that you can click on objects and add user data to them. This could include type, ID, as well as initial state and stuff (for things like light switches). You still use code to fix up the references to game objects at runtime once the level is loaded.
At the other end, you have a case where you have everything separate, rooms, objects, etc. and you place them all in the scene composer and tag them as needed as described above. Where this approach differs is that for a lot of objects you can just put placeholder markers with the appropriate attributes. So you can put a chair marker or a table marker down with the right user data attributes and then at runtime when you load the level and are fixing up your objects, you can swap the placeholder āflagsā with the real spatials. This approach ensures that you get optimal mesh sharing and it also easily lets you swap out table or chair models for something better later without having to redo your whole level.
I made an ingame system that I could use for any project letting me place stuff like this. I saved every detail as setUserData, boring to make but works well enough. Really useful to be able to just load stuff in and change the way everything behaves. I recommend making some sort of adaptable system though because itās really neat for using in a variety of projects. Having trigger boxes that can trigger multiple other placements instantly is really useful ^^
Hey thanks a lot for your advices As Iām in the very beginning of my game dealing with the game mechanic, it is now easy for me to try out all your proposals.
I will first give the scene composer a try, before I start my own level composer, as this sounds like a lot of work
One more question: Game objects which hold state are they of type Node? As then my game state would be savable without any additional coding, as I would use setUserData, getUserData and a control to have getters and setters? Or shall I do my own game objects and implement the Savable interface? I personaly thought that using Node is not that bad, but maybe it is overkill to use them just for having a logical game objects?
Donāt use Node for a game object. Itās like using a giant dump truck just to keep some things in the glove compartment.
I wouldnāt even use the savable interface for your own stuff. Either use some debug-friendly format like JSON or just use standard Java serialization.
Just want you let know: I have now game objects and I can easily connect them with objects in a blender created room, as every object is a node with a geo inside. Very handy. I just did a simple naming convention and have factories for the game objects. just call them by name.
I even can connect with this naming convention the lamp with a button Just automagic.
I do not need more than that.
not all but most of them. My room is a j3o file and in the end I have a node.
There is much pain down that path and it physically hurts to imagine someone else going through that.