Couple of questions about using rube

General discussion about the R.U.B.E editor
Post Reply
Posts: 13
Joined: Wed May 27, 2015 1:59 pm

Couple of questions about using rube

Post by UKDeveloper99 »

1. The snap to grid only works from the center position, is there a way to get it to snap to the bottom left corner for example. I was trying to snap an image to 0,0 in the world but the only way I could find to do it was to position it manually with the translate [T] function.

2. Is it more efficient performance wise to use the n-sided polygon or the open ended chain shape for creating large levels? (more of a box2d question)

3. I'm finding the asset path functionality: "relative to .rube file", "relative to exported .json" really confusing. I'd much rather just be able to pass a path of my choosing, when I load images in cocos2d-x looking in the /Resources/ folder I just want to pass my path directory from inside there with the rube data. E.g. levels/ground.png. Is there an easy way to do this that I've overlooked?

4. I was wondering if it's possible to create simple functionality specifically within a rube scene to export as JSON, such as a kinematic platform moving up and down. Without having to do it in source code. I know if you want to work with the bodies/fixtures from the scene you have to getBodyForName("") etc. It would be nice to not have to worry about that for really simple functions, maybe some sort of script loader. Can I do this with scripts or would this be a pointless endeavor?
Site Admin
Posts: 861
Joined: Sat Dec 22, 2012 7:20 pm

Re: Couple of questions about using rube

Post by iforce2d »

1. Presuming you are talking about images only here, since that is the only item type for which "bottom-left corner" would make sense. There is a second method of "snap to" that might be more useful. By clicking the second-to-rightmost icon in the tool bar (magnet with dashed axes), you can make an item snap to a grid that is relative to the starting position. You would still need to position the image manually once, in the starting position, but thereafter you could move it to snap to a grid relative from that position. To set the size of the snapping grid, you can edit the "snap to grid cell size" in the Controls tab of the Options dialog.

2. Generally line/chain shapes will be more efficient, because each line will have a smaller AABB, especially for lines that are close to vertical or horizontal. A line check is only a single line check, whereas a polygon is potentially n line checks, where n is the number of sides of the polygon.

3. In the Export options tab of the Scene settings dialog, you can set the base path in the "Specify path" edit box. If you enter an absolute path there, none of the "relative to xxx" settings will apply. For cocos2d-x I do exactly as you are saying, and I enter the full path of the Resources folder there.

4. The problem with that is it depends on the platform, language and framework of the target application, and would need to be written and ported to multiple targets, a big job. The other problem is that it is extremely unlikely that a one size fits all solution exists - I think in almost all cases the end user will want to modify it, eg. perhaps the platform should have a switch to turn it on and off when the player approaches, maybe it should slow down linearly as it approaches the end of each range, maybe it should alter its speed at certain times etc. This kind of functionality lives deeper in the game loop and I think it belongs in the game engine itself, and I'm trying to avoid RUBE becoming a game engine :)

I have made a couple of systems which do something like you're asking for, but as I say, it was part of the game engine each time. One system was used to position static bodies in the corners of the screen as UI buttons, and was implemented by giving custom properties to the bodies, eg. marginLeft, marginTop etc. After loading, I used getBodiesByCustomFloat to get all bodies for which these custom properties existed, and move them as appropriate.

For the moving platform case, I would create a copy of the platform body and name it something like xxx_platformEnd. Place the original platform body and the copy at the ends of the range you want the platform to move between. After loading, you can do getAllBodies, then loop over all bodies and check if there is a corresponding bodyname_platformEnd body. If there is, record the position of it and then destroy that body. Then in you game loop you know where to move the platform between. That's pretty crude, and using custom properties is a more sophisticated way to do it - to add any extra data like movement speed etc, you would need custom properties in the body anyway.
Post Reply