Jul 3 2013, 7:18 am
|
|
Xerif
 |
It's the most uselessly complex thing I could find. Like me pointing out the fusion powered quantum headlight the mech uses to illuminate the road-- in an effort to express how needlessly complex it is.
|
What's funny is that such an engine would be so powerful, that you wouldn't even have to make a game for it. The engine would be a game just by itself! Any "game" you add to it might just be stories or quests or something. You simply generate a random world with random laws of physics, and let the players join and do whatever they want. Let them make the game what it is. That's your philosophy. It would be like the ultimate MUD.
For example, let's say a player wants a sword in the game. How would that be generated in this kind of engine? Well normally, the sword's icon would just appear from out of the resource, but in this case, you would have a metal material object, that gets its color changed to the type of metal, cut into the shape of the sword, and gets a different color or material added for the hilt. So essentially, the sword would be "forged" by the code itself, at runtime. I just can't imagine that happening during gameplay though. I think it would have to be generated at the start of the game, and saved as a file. For something like this, you would have to have "cookie cutter" icons or something like that to provide base shapes for icons to take. These templates would be the only type of icon saved in the resource. | |
I think the game you're looking for, here, is life.
| |
That's what the OP seems to be looking for, not me, and if I wanted to do something on that scale, I would make sure that I had full hardware access, so BYOND would be out of the question.
| |
The moral here is--
"If you can't explain it simply, you don't understand it well enough." | |
Is there anything in the universe that anyone understands "well enough"? I think not. There is an unlimited amount of knowledge to be gained from anything that you can already name, therefore nothing really has a simple explanation, when you look at all the fine details.
| |
Dynamic content of this sort can be incredibly enticing. Many designers and gamers (myself included) would absolutely love a world of this level of customization.
The problem, though (and the reason that this "Holy Grail" has really never been fully realized) is that such a system requires a HUGE amount of effort up-front. It's not even so much an issue of the processing needed at runtime (though that is also a concern), it's an issue of simply hammering out the million-and-one rules that are necessary to define and control such an open system. You need to define a very large set of very specific attributes and physics rules. The real world basically boils down to a set of basic building blocks (sub-sub-subatomic particles and energies) and a HUGE and incredibly complex set of rules that governs how they all interact and intertwine. To replicate reality, you then need to mimic that. Obviously, mankind is likely to never be able to reach the same level of complexity. It is theoretically possible, but the programming effort and the computing power needed to handle trillions of variables and procedures on trillions-of-trillions of individual objects is far beyond anything we're likely to ever reach. So the key is to find the sweet spot where your building blocks, and the rules that govern them, are small enough with a level of complexity that will allow for the desired amount of customization, without completely overwhelming you with up-front work. For custom weapons, maybe you'd be satisfied with a set of basic materials (wood, metal, stone, etc.) with all of the necessary properties defined so they can interact within your physics engine, and then a limited set of pre-defined shapes and ways to connect them? This is still a large amount of work, but not anywhere as close to the amount of work that would be involved in setting up a level of customization down to an "atom" by "atom" level. It also wouldn't allow for as much customization. You could go crazy and define a material (a metal, for instance), then create individual units of that material (your game's "atoms"; in BYOND and other 2D engines, a good spot for this basic block is likely a single pixel), and then you can control those "atoms" individually, programming all of the necessary rules for them to interact (I.E. metal "atoms" next to each other tend to stick together, unless forced apart, so your metal objects might bend, but only break under very high stress, or if they've been stretched very thinly) Then, you can let your player gather a certain number of the metal "atoms" (generally in a lump of many of them together), then give him the tools to mold that lump of atoms into whatever shape he desires. Your engine, then, needs to be able to handle all of the various physical interactions that this material can undergo. (if it hits or is hit by another material, how does it respond? how are forces acting on one point travel to and affect other points? what effect, if any, does the shape have on how it interacts with the world around it? etc, etc, etc) All of this is possible, but it takes an awful lot of thought to make sure you cover all of the necessary bases, and then the work to program them all in. No one (to this point, anyway) has gone this far. They tend to stop at a relatively high level of basic blocks. Minecraft's world is made up of meter-cubed building blocks... not exactly a high resolution, but it offers one of the most customizable worlds of any game to date. Minecraft also offers a limited crafting system, with a relatively small set of pre-defined item/material combinations to generate a relatively small set of pre-defined generic objects, but even in this area, it's still ahead of many other games with the ability to craft items. Spore is a pretty good example of handing the player a set of building blocks, and the tools to mold them to create custom content, but a game could go even further by refining the building blocks down to a smaller level, with a greater variety and greater range of combination. The problem, of course, is simply of not wanting to put in the immense design and programming effort to get to a more detailed system. | |
Xerif wrote:
The moral here is-- I beg to differ in this case, if you want to summarize something with a few sentences and it having this amount of content and specifications, you will be overlooking a lot of required information and detail. Rather it would be the opposite of not knowing, when you are able to bring out specific aspects and it all working on conjunction with the previous, you'll have something you know well enough to talk about. I love to explore new systems and possibilities. Even though the potential resource requirements and massive amount of thinking power you have to input into the whole system take some time and energy, when you have it done, you will have a huge base/platform to build on and add key elements with relative ease. Before labeling this "pointless" and "impossible", do think of the possibilities and potential uses, while all of it might not change your way of thinking, some parts might change. If something is build on a solid base and fundamental principles, it will stand strong. We can dumb things down and think of things on pixel level, might even dumb it down to the level of each pixel representing one particle of a material if need be. Placing the particles and then running an analysis at run-time for it's properties; materials, shape, size and other attributes. You could calculate various things like: strength needed to wield(carry) the item, it's range based on the position of the grip, movement momentum, potential swing speed and so forth. In general a shield, dagger, sword, spear are pretty much the same, the difference lies in their shape and usage method and as well as it's range, and material usage. I could go on and on with this. | |
I like this topic. It's starting to get interesting.
There's no way you can keep everything running as clumps of single pixel material atoms. That would literally be millions of objects. However, they could possibly start out like that, but would need to be combined into single icons, for each item, before use, unless they are broken, in which case they can be split up again. This made me think of another idea. What if we don't need any objects at all!? What if we just had icons? What you could do is analyze the color of all the pixels in an icon to dynamically determine exactly what the material is. For example, a certain amount of brown and black is likely to represent wood, so all the variables will be set accordingly. If there are large variations of color mixed with white and gray, it might be steel or iron. This could be a whole new method to store information. The material data could actually be found in the pixels, not hard coded as text. In this way, you could even mix materials together in all sorts of crazy ways. You just have to ask yourself, "What does this material look like?", and go from there. The only problem with this is that the analyzing algorithm would have to be really good at figuring this out. It would mostly just be a bunch of if() or preferrably switch() statements though. If you think about it, most things in the natural world can easily be defined by an array of colors. You would have to deal with a whole lot of GetPixel() though, so that might be pretty slow. | |
Or, perhaps the data can be stored as a list of the pixels within the object, and where they are within the object.
You then have one object, made out of all of the pixels that went into making it, and it can then react to collisions based on which pixels were hit (your sword can get a dented/notched edge, which might make it less sharp; a jagged line of "metal" pixels vs. a smooth one will negatively affect the ability of the object to cut other objects), or you can use the materials to calculate its weight and center of mass for the appropriate physics, etc. You could even have "thickness" on an object, by "stacking" pixels of the material (sort of treating pixels as voxels, but only conveying them in 2D) The pixel at (5,5) might be stored as being 3 units thick, while it's neighbor might only be 1 thick (this could lead to putting sharp edges on metal objects; a slope of thickness down to a single-unit thickness along the edge would denote something sharp) | |
Dwarf Fortress is far, far more complex than mine-craft ever will be.
Talking about things on a pixel by pixel basis is stupid, as BYOND and many other systems don't have the power to do such a thing consistently with many, many objects. | |
I'm not sure you could go that far either. If it could be proved that BYOND can somehow run an efficient particle engine, then I will believe that this is possible, and if client-side processing is implemented some day, definitely so. This is because the mechanics of what is being described here are surprisingly similar to a particle engine. As long as objects remain intact, they exist, and are treated as solid objects, but if they are broken, or their form is altered somehow, then there would essentially be a particle engine that takes over. The engine would only need to work with the largest chunks necessary, depending on the severity of the damage.
We can't realistically talk about this happening until someone figures out a way to get a particle engine to work fast. For example, it would have to be able to demonstrate a pane of glass shattering into a thousand pieces and crashing to the ground. How would this core particle engine function efficiently enough to handle fully destructible objects? How would it be implemented? Currently, most particle engine demos in BYOND create a bunch of little image objects and move them around. What if that is not the best way to go about it? Could a better solution be found in the icon procs, by blending the particles directly into the icons? Could maptext be fast enough to do something like this, with pixel sized square characters moving around? Honestly, I don't see this happening in a usable form, that could work well enough for use in multiplayer games. | |
Xerif if you don't have anything intelligent to say then please, do not say anything and just observe or ignore. Going on about how stupid it is, it is just disgraceful.
In any case, I had reached the same conclusion as you guys, either to take advantage of pixel colors within the icon or make an array/list of the pixels or even both. Also stacking pixels on each other, good that you noticed, to be honest with you guys I had started a system to handle things like this in a very dumbed down way, to actually give the objects hit-boxes based on where most of the object mass is present, to try to make collision based on individual pixels at this point wouldn't be very efficient. Items getting damaged based on where they are hit while also taking account the shape of the object used isn't bad either, calculating the strike pattern and taking into account the materials hit and their properties. Then of course also taking account the person's body-parts who is hit. | |