OK, so I have been spending the past few days on finals and familiarizing myself with Panda3D. I have started on a basic 3D object editor using it. Attached is a screenshot. Yes, I know it is very primitive, but until 2 days ago, I knew nothing of 3D programming or modeling (and now I can model a cube and texture it, woo!).
My current intent is to let people click to place blocks, and then I'll export the entire collection of blocks out as an XML file or something and then import that into the server as a template.
Link to pic: https://picasaweb.google.com/101878754950292033544/ObjectEditorPics?authkey=Gv1sRgCNqnm-DX7vbErQE#5601051239965436482
Wednesday, May 4, 2011
This was much easier than i thought...
So, there is now a 3D coordinate grid to walk around on, made of blocks. And blocks can now be seen in a field of vision. Right now, the field of vision is:
y+3, and x +/- 2
This will be extended significantly, but right now, there's a basic command to add blocks to the world, and the blocks move in and out of visibility. Haven't coded in occlusion yet, but it shouldn't be really hard.
I decided to go with ZODB, just because it is so very easy to use. I may code in support for MySQL later. We'll see.
I'm also going to open up the bitbucket repo for anyone to clone, in case they want to check out the code.
https://bitbucket.org/fhaynes2/slithermud-3d
Be warned: my focus is on functionality, not neatness right now.
I think I'm going to end up coding a custom object builder using Panda3D or somesuch. I'm thinking a text only interface might be really difficult.
Adelante!
So, there is now a 3D coordinate grid to walk around on, made of blocks. And blocks can now be seen in a field of vision. Right now, the field of vision is:
y+3, and x +/- 2
This will be extended significantly, but right now, there's a basic command to add blocks to the world, and the blocks move in and out of visibility. Haven't coded in occlusion yet, but it shouldn't be really hard.
I decided to go with ZODB, just because it is so very easy to use. I may code in support for MySQL later. We'll see.
I'm also going to open up the bitbucket repo for anyone to clone, in case they want to check out the code.
https://bitbucket.org/fhaynes2/slithermud-3d
Be warned: my focus is on functionality, not neatness right now.
I think I'm going to end up coding a custom object builder using Panda3D or somesuch. I'm thinking a text only interface might be really difficult.
Adelante!
OK, some database stuff.
These are my initial thoughts on how to handle storing the world in a MySQL db. Having never attempted to do something like this before, they may not be very good ideas. So, feel free to chime in if you want.
An initial thought is to have a table with, at a minimum, the following data:
x-coord
y-coord
z-coord
field that holds a reference to the block id that occupies it
Of course, this also requires us to have a massive table of the blocks available in the world.
As you can see, a simple 100 meter x 100 meter x 100 meter "section" would require 1 million records.
One option is to divide the world into logical "areas" - that is, have two tables for each area, one with the coordinate triplets and one with the blocks. This would require flagging all the blocks at the perimeter of the area, so that we could know when to switch tables.
Another thought is that since the Z space is not going to be used nearly as much as the X and Y space, it might be possible to fake it. Most the air blocks are identical, and I don't see a need to duplicate them thousands of times. We could just reference one standard air block, which would significantly reduce the size of the block table. If someone wanted to build a floating castle or something, then we can just generate some unique blocks as needed.
The block table will contain all the details for the blocks...type, ambient messages, etc.
Another table would be used for objects. If a block is part of an object, we put a reference to the object ID in each block. Then, when we need to interact with the object as a whole, we look up the object to get the face descriptions, etc.
These are my initial thoughts on how to handle storing the world in a MySQL db. Having never attempted to do something like this before, they may not be very good ideas. So, feel free to chime in if you want.
An initial thought is to have a table with, at a minimum, the following data:
x-coord
y-coord
z-coord
field that holds a reference to the block id that occupies it
Of course, this also requires us to have a massive table of the blocks available in the world.
As you can see, a simple 100 meter x 100 meter x 100 meter "section" would require 1 million records.
One option is to divide the world into logical "areas" - that is, have two tables for each area, one with the coordinate triplets and one with the blocks. This would require flagging all the blocks at the perimeter of the area, so that we could know when to switch tables.
Another thought is that since the Z space is not going to be used nearly as much as the X and Y space, it might be possible to fake it. Most the air blocks are identical, and I don't see a need to duplicate them thousands of times. We could just reference one standard air block, which would significantly reduce the size of the block table. If someone wanted to build a floating castle or something, then we can just generate some unique blocks as needed.
The block table will contain all the details for the blocks...type, ambient messages, etc.
Another table would be used for objects. If a block is part of an object, we put a reference to the object ID in each block. Then, when we need to interact with the object as a whole, we look up the object to get the face descriptions, etc.
Thanks!
All objects will consist of the blocks, so for now, everything will be a cuboid. The "builder" will need to approximate the shape of the object using that.
So, to create an object, you can specify a length, width, and height, and specify an origin from which to construct the rest of the object.
For example:
createobject 1x1x1 5x10x50
This would create a cuboid of 5 x 10 x 50, with the lower leftmost corner (from the creator's perspective) being at 1x1x1.
This object will exist in the DB, and will have a set of descriptions. For example, the builder could give a separate description for each of the 6 faces of the cuboid, for certain distances (similar to how KaVir's idea for distance-based descriptions works), etc.
It is important to note that the cuboids will be hollow, to allow for interior building. I am not exactly sure how effective a text based OLC will be for creating interiors. At the very least, the user would have to have very good visualization skills...
To create a door to the previously created building, it could be, perhaps:
delete 3x1x1 2x5x1
Which would create a "hole" in the wall of the building.
Hmm, I can see this getting very difficult with more complex structures. The building view would need to have a great deal of technical detail about the coordinate system, obviously.
I don't intend for any 3D modelling tools to be used, although integration with them could be cool. I wonder if Blender could be used somehow...
All objects will consist of the blocks, so for now, everything will be a cuboid. The "builder" will need to approximate the shape of the object using that.
So, to create an object, you can specify a length, width, and height, and specify an origin from which to construct the rest of the object.
For example:
createobject 1x1x1 5x10x50
This would create a cuboid of 5 x 10 x 50, with the lower leftmost corner (from the creator's perspective) being at 1x1x1.
This object will exist in the DB, and will have a set of descriptions. For example, the builder could give a separate description for each of the 6 faces of the cuboid, for certain distances (similar to how KaVir's idea for distance-based descriptions works), etc.
It is important to note that the cuboids will be hollow, to allow for interior building. I am not exactly sure how effective a text based OLC will be for creating interiors. At the very least, the user would have to have very good visualization skills...
To create a door to the previously created building, it could be, perhaps:
delete 3x1x1 2x5x1
Which would create a "hole" in the wall of the building.
Hmm, I can see this getting very difficult with more complex structures. The building view would need to have a great deal of technical detail about the coordinate system, obviously.
I don't intend for any 3D modelling tools to be used, although integration with them could be cool. I wonder if Blender could be used somehow...
I should actually talk about Objects some...
An Object is anything that takes up one block-size area or greater. It could be a car, represented as, perhaps, 6 blocks. Seen from the side:
***
***
A semi-truck might be...
* * * * * *
** * * * * * *
** * * * * * *
Point being, an Object is a collection of arbitrary blocks, that the builder can give unique descriptions to, etc.
Potentially, we could do things like build a wall, and let users blow holes in walls, etc. I.e., destructable terrain of sorts.
In the semi truck example, a player could hop on top, tear through the "blocks" that represent the top, and drop down into the cargo area. Theoretically.
An Object is anything that takes up one block-size area or greater. It could be a car, represented as, perhaps, 6 blocks. Seen from the side:
***
***
A semi-truck might be...
* * * * * *
** * * * * * *
** * * * * * *
Point being, an Object is a collection of arbitrary blocks, that the builder can give unique descriptions to, etc.
Potentially, we could do things like build a wall, and let users blow holes in walls, etc. I.e., destructable terrain of sorts.
In the semi truck example, a player could hop on top, tear through the "blocks" that represent the top, and drop down into the cargo area. Theoretically.
More details
The Physical World
------------------------
The physical world is the simulation of the world and the objects that exist within it. Terrain is considered part of the physical world, as are objects and mobiles.
Blocks
----------
The world will, initially, consist of “blocks”. These blocks represent a 1x1x1 meter cube. Terrain will consist of blocks of terrain strung together. Blocks will have two fundamental properties for interacting with the physical world: that of opacity and solidity.
Opacity will determine if the block actually blocks line of sight, just as in real life. Opacity will be able to be set to various percentages, to allow for partial visibility.
Solidity determines if the block is something like air, or if it is a stone. A solid block will prevent other items from existing in the same coordinate triplet as it, while a non-solid block will not. We can use non-solid blocks to represent effects like air, water (which might be semi-solid), by changing how fast people can move through it.
Ambient Descriptions
------------------------------
Blocks are also going to be able to provide ambient descriptions. For example, a forest block, (or a block making up one of the trees, whatever) could provide a descriptive line of text as the player walks over it. It could even gather ambient descriptions from other nearby blocks and combine them all into one description.
Movement
--------------
The world will exist on a 3D Cartesian Grid, with 0,0,0 being the origin. The entire world will be contiguous; no areas, no zoning. However, the goal is to hide as much of coordinate system as possible.
Landmarks
-----------------
Rather than exposing the user to the coordinate system directly, navigation will be by a Landmark system. Players will be able to memorize the location of certain structures (perhaps a building, mountain, store in a town, whatever), and then just type go landmark, and we’ll automatically pathfind them a route there (for a game, this could be influenced by skills, I suppose).
Alternatively, you could give people the option of walk “heading” and let them specify a degree parameter, if they just want to wander.
Line of Sight
-------------------
Descriptions
------------------
LoS will be handled rather simply, at least at first. Blocks (and thus objects) will have an opacity factor. To start, fully opaque or fully transparent. LoS will be checked using a modified version of bresenham’s algorithm to check for occlusion.
The real challenge is going to be combining the descriptions of all visible objects into one coherent text paragraph.
For example, if Bob is standing at 1,1,1, and there is a building, 30x30x30 building at 25,1,1 but also a, let’s say...a cow standing at 5,1,1, we have to incorporate the descriptions from both. One possibility would be:
Approximately 25 meters ahead of you stands.... 5 meters in front of you stands a .
It would basically be a matter of keeping a list of all objects in a AxBxC radius and checking each for visibility and sending the descriptions.
Descriptions of Objects under various conditions
-------------------------------------------------------------------
So, one of the advantages this system has is the ability for an object to be viewed from different perspectives. A building, represented as a cube, has 6 faces. Theoretically, a player could be viewing it from any side, above, or below. And a player viewing it from one side could not very well see the face on the opposite side. With a 3D system, we have the ability to determine what face they are viewing.
Assume we have a 25x25x25 building. On the Eastern face, we have the main entrance. Bob is facing the Eastern face, and sees...
You see the main entrance here.
But if he moves around to the West face, where the loading/unloading docks are, we might see:
You see the loading/unloading docks here.
Not only can we change descriptions based upon the face being viewed, but we can change it based upon other conditions. If it is dark, then it might have another description. If it is foggy, we could have a partially obscured description.
So, building becomes less creating an endless series of rooms and typing descriptions as it does constructing objects and describing it from various perspectives.
--------------------
I've got more, but it is getting into tl;dr territory. More later.
------------------------
The physical world is the simulation of the world and the objects that exist within it. Terrain is considered part of the physical world, as are objects and mobiles.
Blocks
----------
The world will, initially, consist of “blocks”. These blocks represent a 1x1x1 meter cube. Terrain will consist of blocks of terrain strung together. Blocks will have two fundamental properties for interacting with the physical world: that of opacity and solidity.
Opacity will determine if the block actually blocks line of sight, just as in real life. Opacity will be able to be set to various percentages, to allow for partial visibility.
Solidity determines if the block is something like air, or if it is a stone. A solid block will prevent other items from existing in the same coordinate triplet as it, while a non-solid block will not. We can use non-solid blocks to represent effects like air, water (which might be semi-solid), by changing how fast people can move through it.
Ambient Descriptions
------------------------------
Blocks are also going to be able to provide ambient descriptions. For example, a forest block, (or a block making up one of the trees, whatever) could provide a descriptive line of text as the player walks over it. It could even gather ambient descriptions from other nearby blocks and combine them all into one description.
Movement
--------------
The world will exist on a 3D Cartesian Grid, with 0,0,0 being the origin. The entire world will be contiguous; no areas, no zoning. However, the goal is to hide as much of coordinate system as possible.
Landmarks
-----------------
Rather than exposing the user to the coordinate system directly, navigation will be by a Landmark system. Players will be able to memorize the location of certain structures (perhaps a building, mountain, store in a town, whatever), and then just type go landmark, and we’ll automatically pathfind them a route there (for a game, this could be influenced by skills, I suppose).
Alternatively, you could give people the option of walk “heading” and let them specify a degree parameter, if they just want to wander.
Line of Sight
-------------------
Descriptions
------------------
LoS will be handled rather simply, at least at first. Blocks (and thus objects) will have an opacity factor. To start, fully opaque or fully transparent. LoS will be checked using a modified version of bresenham’s algorithm to check for occlusion.
The real challenge is going to be combining the descriptions of all visible objects into one coherent text paragraph.
For example, if Bob is standing at 1,1,1, and there is a building, 30x30x30 building at 25,1,1 but also a, let’s say...a cow standing at 5,1,1, we have to incorporate the descriptions from both. One possibility would be:
Approximately 25 meters ahead of you stands...
It would basically be a matter of keeping a list of all objects in a AxBxC radius and checking each for visibility and sending the descriptions.
Descriptions of Objects under various conditions
-------------------------------------------------------------------
So, one of the advantages this system has is the ability for an object to be viewed from different perspectives. A building, represented as a cube, has 6 faces. Theoretically, a player could be viewing it from any side, above, or below. And a player viewing it from one side could not very well see the face on the opposite side. With a 3D system, we have the ability to determine what face they are viewing.
Assume we have a 25x25x25 building. On the Eastern face, we have the main entrance. Bob is facing the Eastern face, and sees...
You see the main entrance here.
But if he moves around to the West face, where the loading/unloading docks are, we might see:
You see the loading/unloading docks here.
Not only can we change descriptions based upon the face being viewed, but we can change it based upon other conditions. If it is dark, then it might have another description. If it is foggy, we could have a partially obscured description.
So, building becomes less creating an endless series of rooms and typing descriptions as it does constructing objects and describing it from various perspectives.
--------------------
I've got more, but it is getting into tl;dr territory. More later.
Subscribe to:
Posts (Atom)