Advice Needed: Complexity of a 2x2x2 Box Creation System

[RPG 0]

Hey everyone, RPG here again with another riddle that has stumped me so I came here to ask you all for some help.

 

Now this time it's something a tad unusual to ask (nothing newbie related) but I am trying to revive and old game of mine known as Team Buddies. To give you a fair moment to staying on the same level as me, I present to you a quick "Let's Play" video on it's simple game play.

 

 

http://www.youtube.com/watch?v=Y7vXE-BeWSM

 

 

Now I'm sure by now you know what I'm about to ask. I need help developing that block system right there that allows you to stack blocks in any way possible with the 2 width x 2 height x 2 length.

 

There's always ways to do it with scripts but I also like to get around it with events and what not. (At this point I'm not sure which way is even easier.)

 

Solutions

Solution 1: Scripting

 

A script would do just nicely for something like this and save me time from having to build it with pure events. Anyone know how to even start scripting something like this?

 

Solution 2: Eventing + Call Commands

 

Could anyone explain how to solve this by eventing, even I'm at a loss for it.

 

I was thinking of using-sprite-on-sprite possibilities but I can't even begin to think where I would start. (You know it's bad when I ask for eventing and call commands because this is my first time ever asking for something like this via eventing.)

 

 

 

Besides that I can practically do everything else like all the HUDs you see there and I guess I can use some form of battle system with that. Thank you all who read this for taking up your time and I hope you get back to me.

 

PS:The radar would also be helpful but that's not the issue at the moment.

Edited July 7, 2012 by RPG

[senior 0]

i havnt used RGSS in a long time, and never really used the RMXP command line event system. However using pesudo logic, you could use a single byte, 8 bits, and compare each block to a bit, where the first 4 bits are lower blocks, and next 4 bits are top level.

 

what I would do is assign each bit to a quadrant on the 2x2 block, eg the first 4 bits are lower left, lower right, upper left, upper right;

 

so that if the upper left block was set, it'd look like 0010; and if the lower left block was set after that it'd look like 1010;

 

same with the top level, in the same format where the upper left and lower right might look like 0110; so all together 10100110

 

that naturally wouldnt make sense because ur blocks are suppose to stack on one another, and from what I've said so far you should know that the top upper level of quadrants there would show that the lower right block is floating.

 

lets say you wanted the logic to do 2 things, a) check if a block is set, and b) set a block if not, and finally c) check the results and call script based on result;

 

blockposition(nearest to player) = 0-3

if(mybyte&(1<<blockposition) == 1) then BLOCK IS SET ON LOWER LEVEL

if(mybyte &(1<<blockposition+4) == 1) then BLOCK IS ALSO SET ON UPPER LEVEL

else mybyte ~=(1<<blockposition+4);

else

mybyte ~=(1<<blockposition);

end

 

now to check the layout of the blocks it becomes very simple because of how we did this(and ultimately all of this is very fast because binary operations are not slow, and also very spacious, as in 8 bits is not a lot of memory);

 

so, lets say we wanted to know up there is a 1x2 block set on the north side of the cube, then based on the way we structure our byte, in the order

of lower left, lower right, upper left, upper right for top and bottom levels, we can easily check that with mybyte equals 00110011

or mybyte equals 51(value of 00110011) for short;

 

where a completed cube would look like 11111111 or 255 for short;

 

if you're not yet experienced enough to understand this response I apologize, but someday I hope you will. its hard for me to come up with solutions i would've come up with 7 years ago when I was fairly new to all this stuff

Edited July 23, 2012 by senior

[Moonpearl 32]

I don't understand your request. What do you call a "block system"? What part of the sample gameplay do you need help with? And how do you plan to render a 3D gameplay in RMXP (which is hopelessly 2D)?

[senior 0]

I don't understand your request. What do you call a "block system"? What part of the sample gameplay do you need help with? And how do you plan to render a 3D gameplay in RMXP (which is hopelessly 2D)?

 

uh, you could easily do 3d in 2d(perhaps not very fast), for example by creating a matrix and vector3 class, then using the perspectie/project matrix in conjunction with modelview matrix to transform 3D points into 2D points, then from connecting the points to form a triangle.. via lines, or a filled polygon, its super easy.. just not nec fast that way..

[RPG 0]

What do you call a "block system"?

I guess an example picture should be in order. We all know (or should know) that 3D consists of 3 Dimensions: X, Y and Z. In the picture below that is shown how it works. With that said, the block system works just as easily as it sounds.....by stacking them in any way of those order. I asked for a 2x2 which looks like and is labeled as "Full Space Used".

 

 

 

 

What part of the sample gameplay do you need help with?

If you watch the video that was given, it shows the characters using "blocks" or "crates" to create their weapons, vehicles and other companions. The "blocks" are shown as yellow boxes with either red or blue outlines around them. How they use it is what I need.

 

 

And how do you plan to render a 3D gameplay in RMXP (which is hopelessly 2D)?

Rendering is not hard. It is possible to make a game in 3D using RMXP believe it or not. Take a look at this topic which is another topic from another site about it. I recommend you download the 2nd release. http://rmrk.net/inde...p?topic=32921.0 make sure to read everything as this demo locks your computer up and can only be unlocked by pressing both CTRL + F4 to quit.

 

 

 

To Senior:

It's alright, I got a bit of it. If I were to convert that into RMXP logic I would suppose it would make sense if I set each of the 8 blocks as a switch. I can check with conditional branches to see if the block in that position in either [On or Off] or [There or Not There] and use picture possibilities.

 

Example: 1-4 are the lower half of the stack pad. 5 - 8 are the top half.

 

Red Base Block Pad 1: [On]

Red Base Block Pad 2: [On]

Red Base Block Pad 3: [Off]

Red Base Block Pad 4: [Off]

Red Base Block Pad 5: [On]

Red Base Block Pad 6: [On]

Red Base Block Pad 7: [Off]

Red Base Block Pad 8: [Off]

 

This basically means that we have 2 blocks on the left side, bottom half and 2 blocks on the left side on the top half on top of the bottom half, also known as the 2x2 portion.

 

If say had 1 block on top and there wasn't a block underneath it then I would probably do something like:

 

if block 5 is [On] and if block 1 is [Off] then change the switches from 5 to [off] and 1 to [on] (so it's like a physics effect.)

Edited July 24, 2012 by RPG

[Moonpearl 32]

The "blocks" are shown as yellow boxes with either red or blue outlines around them. How they use it is what I need.

So in short the important feature is the arrangement of blocks? Or their orientation? Or both? And can red blocks be combined with blue ones?

 

Rendering is not hard. It is possible to make a game in 3D using RMXP believe it or not.

Oh, I do believe it alright. You can even make a vertical scrolling shooter or a FPS with RMXP. And I know how to compute matrices and to render 3D scenes using ray-tracing and stuff. I'm not asking if you have the technical possibility to do it, I'm asking how you wish to do it. Are you using RMXP's tilemap? Or are you building your own 3D rendering system? And most importantly, do you need help with the block stuff in a computational perspective only, or also with how to render them on-screen?

 

My first question was not quite insignificant. Your request still seems a bit fuzzy to me, and I think some sort of diagram showing precisely how you see things as rendered in your actual game would help to outline exactly what your target script should include or not.

[ForeverZer0 44]

RMXP makes a horrible medium for 3D. Sure it can be done, but only after you strip away pretty much everything that makes RMXP what it is, and simply use native Ruby to hook into the operating system to render to the Window. The same can be achieved with simply downloading Ruby, and forgetting RMXP altogether. Or better yet, use a 3D game creation tool to make 3D instead of a 2D one.

 

Staying on topic, though, I think you need to explain better what the end goal is. Stacking blocks is simply a matter of creating a 3D matrix, and doing some logical operations as to what such as "can block be placed at X, Y, Z". A simple bit operation as senior suggested would be easy enough to implement. I imagine what you are attempting to do is a bit more complicated, and there goals to try and make, layouts or sequences to try for, etc., etc. These determine what exactly how you create the system, not so much just a matter of "stack blocks".

[RPG 0]

RMXP makes a horrible medium for 3D. Sure it can be done, but only after you strip away pretty much everything that makes RMXP what it is, and simply use native Ruby to hook into the operating system to render to the Window. The same can be achieved with simply downloading Ruby, and forgetting RMXP altogether. Or better yet, use a 3D game creation tool to make 3D instead of a 2D one.

 

I agree with this, I'm just being a lazy programmer attempting to see if I can implement 3D with RMXP or even getting this particular game to work without having to learn any more tools. Seeing the demo that demonfire created made me really want to push the limitations for RMXP.

 

 

 

Staying on topic, though, I think you need to explain better what the end goal is. Stacking blocks is simply a matter of creating a 3D matrix, and doing some logical operations as to what such as "can block be placed at X, Y, Z". A simple bit operation as senior suggested would be easy enough to implement. I imagine what you are attempting to do is a bit more complicated, and there goals to try and make, layouts or sequences to try for, etc., etc. These determine what exactly how you create the system, not so much just a matter of "stack blocks".

 

 

True, then let me try to explain more by explaining the game itself. The game I'm trying to replicate uses the "block system" which allows you to stack up to the possibility of 8 blocks (2x2x2). Think of Minecraft where you are given the ability to place blocks or materials anywhere at any given time. This is similar except for the fact that this old game only restricted you to such possibilities as the (2x2x2).

 

The games goal is to create your army and destroy the other opposing teams. Say if I wanted to build another partner to join in, I must stack 1 block on top of another (1x2 vertically). Then I can "break" the following boxes and thus, summon another partner. This also applies to weapons and vehicles.

 

• If I wanted a pistol-type weapon, I would only stack 1 block and nothing else.

• If I wanted a medium-type weapon, I would stack 2 blocks next to eachother (1x2 horizontally and it can be set either through the x axis or the z axis)

• If I wanted a vehicle, I must stack all blocks into the full (2x2x2)

 

 

Multiple System

This feature can be applied up to 4 teams at once. Sayif I'm in the process of finding blocks and stacking them to build a weapon, the other opposing teams are also developing their weapons and partners and vehicles.

 

 

Capping

There is an obvious cap for things, only 4 partners can be made for each team but making the vehicles can be unlimited. Weapons are also unlimited but they follow an overlapping system.

 

 

Weapon Overlap

Weapons overlap each other, if you are holding a pistol and you make a large, stronger weapon, you equip the larger weapon and ditch the weaker one. If you are using a larger and you try to equip the smaller, it will just give you extra ammo.

 

 

Red vs. Blue Blocks

Blue blocks are the superior blocks, they carry "advance" technology inside which allows you to make the same things but in their stronger state. Say 1 of the weapons was a semi-automatic pistol where its fire rate is a tad slow. Using a Blue block instead of a red block gives you the possibility of using an automatic pistol instead and of course since it's better, it overlaps the regular pistol but does not overlap the more larger and powerful guns. In general, if you have a bunch of red blocks on your stack pad, the 1 blue block will force all the red that it's connected with to turn blue.

 

 

Physics

These blocks have physics to it. If you are stacking a block on your stack pad and you are trying to stack it in the specific area that already contains 2 blocks vertically, it will slide across that and land on the next area and fit in there (assuming that there isn't anything in that area either, other wise it will just slide across the blocks and land and do absolutely nothing.) If I were to throw a grenade and it exploded next to a block, that block will go flying and roll around until it lands on one of it's sides. If it lands on a corner it will bounce.

 

 

Creating & Destroying

Blocks can be created and destroyed. The way they appear is from falling straight out of the sky (No realism here.) But they can be destroyed on spot for ammo and health or can be picked up and placed on your stack pad. There you can also destroy it on the stack pad but obviously you will get a weapon or something because you completed part of it's recipe.If you have a block on your stack pad and it's diagonal to another block on your stack pad, then destroying one of them will only destroy that one block since they do not connect diagonally.

 

 

Pulling

Vehicles can "pull" blocks (this isn't meant to be realistic). Say you run over blocks, they will float and follow you in a chain behind your vehicle. Specific vehicles can chain and pull certain amount (Tanks can pull 2 blocks max then the rest get destroyed if you attempt to run over blocks with the pull at its cap. Airplanes can pull 3 blocks.)

 

 

 

 

Oh, I do believe it alright. You can even make a vertical scrolling shooter or a FPS with RMXP. And I know how to compute matrices and to render 3D scenes using ray-tracing and stuff. I'm not asking if you have the technical possibility to do it, I'm asking how you wish to do it. Are you using RMXP's tilemap? Or are you building your own 3D rendering system? And most importantly, do you need help with the block stuff in a computational perspective only, or also with how to render them on-screen?

 

My first question was not quite insignificant. Your request still seems a bit fuzzy to me, and I think some sort of diagram showing precisely how you see things as rendered in your actual game would help to outline exactly what your target script should include or not.

 

 

I hope the following above, answering zero's post explains what I wanted the blocks to do. As oppose to how it's made, that can be debatable. If someone were to create something like this without having me do it, then it's their choice practically.

 

The way I've seen it made was using RMXP's 3 layered map.

1. The bottom layer as the bottom part of the box's texture.

2. The 2nd layer is the sides of the box.

3. The top layer is the top texture.

 

But of course this was the level design and not the box themselves.

 

For creating a 3D box itself with texture, I'm sure it wouldn't be hard to create a box and then just use 1 picture as it's texture for all sides of the block.