~= Suggestion =~
Consider the following scenario: you wish to place a block in a corner of two blocks shown below:
The normal behaviour of the program is to generate a preview of the block like this:
And if you click, the block is added.
What I propose is a “add sloped block” mode. The player holds down a button, say “X” or something. The program looks at the vertices, connects them, to generate something that looks like this:
The player clicks, and the block is added.
~= Possible Implementation =~
I once started writing a 3d FPS which used Minecraft style maps, so I thought about adding a slope block system to my game. The way I thought about implementation is as follows:
+ Assign a variable for each vertex, ie TopLeftFront, TopRightFront, etc.
+ Each vertex is either “on” or “off”, ie 1 or 0.
+ When a block is drawn, connect the “on” vertexes.
Now a cube has 8 vertexes, and a byte has 8 bits. So you can take the mod of a byte by a power of two to get whether a vertex is “on” or “off”.
So, for one extra byte per block, a whole extra dimension of functionality!
~= Possible Player Interaction =~
A player should be able to walk right up a slope. This should make mobility a lot better, because players can climb structures without jumpin all the time.
~= Stair mode =~
Exactly the same as slope mode, but stairs are drawn instead. Players can walk right up them!
This is speculation on my part, so I have no idea regarding the legitimacy of this claim, but I think this would require an entire rewrite of the movement and collision detection engine, I assume it's currently set to work with a specific size of block, if notch were to add angles and stuff there'd be a lot more collision detection needed increasing the overhead drastically.
I do like the idea of slopped stairs though :wink.gif:
I was thinking about this, but this would possibly DOUBLE the amount of space blocks take up, because technically you are adding 28 more blocks.
But I don't know much about programming. Good idea.
Nah, It'll be just one block still, just drawn differently. What may take longer is checking which polys to draw, but this is clientside.
I *think* that this game uses OpenGl, which means that it'll be drawing with GL_POLYGONS instead of GL_QUADS. I'm not sure if there's any speed difference, but again, this is clientside, and most computers are pretty powerful these days.
Quote from citricsquid »
This is speculation on my part, so I have no idea regarding the legitimacy of this claim, but I think this would require an entire rewrite of the movement and collision detection engine, I assume it's currently set to work with a specific size of block, if notch were to add angles and stuff there'd be a lot more collision detection needed increasing the overhead drastically.
Not really, a sloped block can be treated as a normal block from underneath. On the sloped side(s), one only has to paramatise height vs x and y position on the block and act accordingly.
I *think* that this game uses OpenGl, which means that it'll be drawing with GL_POLYGONS instead of GL_QUADS. I'm not sure if there's any speed difference, but again, this is clientside, and most computers are pretty powerful these days.
I believe it uses the Lightweight Java Game Library
Nah, It'll be just one block still, just drawn differently. What may take longer is checking which polys to draw, but this is clientside.
No, he means storage space. Each one of these blocks will obviously need more space to store the information.
Quote from PokemonGuy »
Not really, a sloped block can be treated as a normal block from underneath. On the sloped side(s), one only has to paramatise height vs x and y position on the block and act accordingly.
It would require a reimplementation of the collision code. It currently uses axis-aligned bounding boxes and if you start allowing users to create arbitrary geometry (albeit limited), things can get messy. This won't necessarily increase performance overhead, it just will be difficult to write.
Also, alot of work will have to be put into preventing users from create illegitimate geometry (i.e. a single plane, only two points, etc.).
Rollback Post to RevisionRollBack
MineCraft Server Operator v0.3b
Votekick/voteban, remote access, automated backups, cross-platform and more.
Control your server.
No, he means storage space. Each one of these blocks will obviously need more space to store the information.
In my op I explain you can turn each vertex on or off using a bit. There are 8 vertecies, and thus you can store all this information in a byte. A normal block would have each vertex "turned on", and thus this byte will be set to 255. Yeah, assuming 1 byte is already allocated to each block, it would double space.
I see you criticism of adding collision detection code. (Personally, I would have used a cylindrical bounding box, but I see the advantage of a rectangular prism). It'll be tricky to implemnt, but no more difficult than the current code required to detect colision between the player's line of sight and the enviroment.
An easy work around would be to use only triangular sloped peices (ramps). Then extending the collision detection would be a simple case of factoring in a paramaterisation due to the slope.
Quote from dexter »
Also, alot of work will have to be put into preventing users from create illegitimate geometry (i.e. a single plane, only two points, etc.).
To prevent players adding invalid geometry (such as planes), a Ramp block should require at least 5 "turned on" verticies - all you have to do is count them - easy. :biggrin.gif:
maby you could add a tab to the invintory for ramp blocks they would be rotateable maby with the numpad?
pearsonaly i thing a building system simalar to Blocklands would be best http://www.blockland.us/index.asp
also a quote from the games creator
Good, now go forth and convert the non-believers TO RADIOACTIVE VAPOR
I have a simple suggestion: add sloped block.
~= Suggestion =~
Consider the following scenario: you wish to place a block in a corner of two blocks shown below:
The normal behaviour of the program is to generate a preview of the block like this:
And if you click, the block is added.
What I propose is a “add sloped block” mode. The player holds down a button, say “X” or something. The program looks at the vertices, connects them, to generate something that looks like this:
The player clicks, and the block is added.
~= Possible Implementation =~
I once started writing a 3d FPS which used Minecraft style maps, so I thought about adding a slope block system to my game. The way I thought about implementation is as follows:
+ Assign a variable for each vertex, ie TopLeftFront, TopRightFront, etc.
+ Each vertex is either “on” or “off”, ie 1 or 0.
+ When a block is drawn, connect the “on” vertexes.
Now a cube has 8 vertexes, and a byte has 8 bits. So you can take the mod of a byte by a power of two to get whether a vertex is “on” or “off”.
Ie,
TopLeftFront = Slope % 1;
TopRightFront = Slope % 2;
TopLeftBack = Slope % 4; etc.
So, for one extra byte per block, a whole extra dimension of functionality!
~= Possible Player Interaction =~
A player should be able to walk right up a slope. This should make mobility a lot better, because players can climb structures without jumpin all the time.
~= Stair mode =~
Exactly the same as slope mode, but stairs are drawn instead. Players can walk right up them!
Thoughts, opinions?
Cheers,
PokemonGuy
But I don't know much about programming. Good idea.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI do like the idea of slopped stairs though :wink.gif:
Nah, It'll be just one block still, just drawn differently. What may take longer is checking which polys to draw, but this is clientside.
I *think* that this game uses OpenGl, which means that it'll be drawing with GL_POLYGONS instead of GL_QUADS. I'm not sure if there's any speed difference, but again, this is clientside, and most computers are pretty powerful these days.
Not really, a sloped block can be treated as a normal block from underneath. On the sloped side(s), one only has to paramatise height vs x and y position on the block and act accordingly.
I believe it uses the Lightweight Java Game Library
http://lwjgl.org/
No, he means storage space. Each one of these blocks will obviously need more space to store the information.
It would require a reimplementation of the collision code. It currently uses axis-aligned bounding boxes and if you start allowing users to create arbitrary geometry (albeit limited), things can get messy. This won't necessarily increase performance overhead, it just will be difficult to write.
Also, alot of work will have to be put into preventing users from create illegitimate geometry (i.e. a single plane, only two points, etc.).
Votekick/voteban, remote access, automated backups, cross-platform and more.
Control your server.
In my op I explain you can turn each vertex on or off using a bit. There are 8 vertecies, and thus you can store all this information in a byte. A normal block would have each vertex "turned on", and thus this byte will be set to 255. Yeah, assuming 1 byte is already allocated to each block, it would double space.
I see you criticism of adding collision detection code. (Personally, I would have used a cylindrical bounding box, but I see the advantage of a rectangular prism). It'll be tricky to implemnt, but no more difficult than the current code required to detect colision between the player's line of sight and the enviroment.
An easy work around would be to use only triangular sloped peices (ramps). Then extending the collision detection would be a simple case of factoring in a paramaterisation due to the slope.
To prevent players adding invalid geometry (such as planes), a Ramp block should require at least 5 "turned on" verticies - all you have to do is count them - easy. :biggrin.gif:
pearsonaly i thing a building system simalar to Blocklands would be best
http://www.blockland.us/index.asp
also a quote from the games creator
Good, now go forth and convert the non-believers TO RADIOACTIVE VAPOR