You need to be more explicit conveying your philosophy because I'm absolutely confused. Are you saying that content creation should be done at run-time for highly non-linear games, such as Minecraft, or are you saying indie designers should follow this design philosophy for every possible game they create?

I would agree with this. Dynamically generated, player driven gameplay at runtime quite literally has limitless potential. It could also apply to any genre, but some are definitely more compatible with this than others.

For example, an RTS, almost by definition, is mostly player driven. In fact, most objects in the world are created by the players, and anything else is quite often still generated at runtime.

Now if you tried to apply this to something like an RPG, you might end up with something like an online RPG maker, where every single player could create their own RPG, that others could join and play. All the characters, NPCs, monsters, stories, items, quests, and maybe even combat systems, might be created by the players, for other players. Of course it would probably be quite hard to put together something like this.

The biggest problem I have found with these kinds of systems, is the bottleneck created by the encapsulation of objects in DM. These kinds of games practically need to have their own programming paradigm altogether. I discovered this the hard way, when I decided that I wanted to create an RTS in BYOND. In the typical RPG scenario, most features are pretty much directly coded into the source. The RTS is basically the exact opposite of that, where almost everything has to be generated at runtime. In an RPG, objects contain procedures for interacting with the world, but in an RTS, the world contains procedures for controlling all objects in the world! Once I became enlightened to this reality, I began to develop a massive engine, to effectively bypass DM's encapsulation, and handle the creation of all objects in the world. I have been working on this for a while now, and still am. I also think I now know why the Age of Empires engine was named the "Genie Engine". It was because it could grant the programmers their every wish.

Since I have started working on my all powerful engine, I have also started a side project, due to my own feature creep. It is a kind of utility, that when complete, it will parse the whole object tree at runtime, and allow for the direct creation of objects from any predefined type in the world. It will also parse through every variable of a given instance, update them in real time, and allow the user to directly modify them, all at runtime. Does it sound impossible? Well it's not, and it requires an interface so complex, that I have had to write a whole other engine just to handle the dynamically generated interface elements. Also, since I am doing the work anyway, I have decided that I might as well also take advantage of this engine to provide a means of manipulating every aspect of the interface at runtime. I won't be providing any more detail than that, this early in development, but what I can tell you is that this tool will be so incredibly powerful, that I can't even imagine everything it will be capable of, until it's completed and tested.

Slowly, I am chipping away and simplifying some of the more convoluted aspects of DM. Once these systems are complete, they should allow me to rapidly produce large, complex games in a matter of months, instead of years. I still have quite a ways to go, but due to how deep this project gets, into the core of DM, I am learning a lot more about the language than I ever would just making games with the built-in procedures. Also, any games that I make will be built on top of a strong foundation, that other games just don't usually have.

So, I have declared war on Dream Maker, the online RPG making tool, because I believe BYOND is capable of doing so much more than that, and once I create a working RTS, I will have a whole army to conquer it with!

A system that allows you to create objects at runtime, and edit the variables of each instance?

What's difficult about that?

--In response to the original post, what you're referring to is a 'sandbox' game.

What exactly are you trying to achieve?

Just a point I'd like to make: People often time confuse "randomly generated content" and "emergent-gamplay". You don't have to randomly generate the content of your game for emergent game-play to exist, But, emergent-gameplay is much more satisfying to the player and what sand-box games thrive off of.

In my opinion, random generation is a tricky thing because if it is done badly, it is that much more obvious - while well designed systems geared towards emergent-gameplay have the benefit of being well-designed.

Taitz wrote:

I'm not referring to items or objects, which have simple variables, which you can randomize, I'm speaking of more advanced mechanics, shape, material, weight, size - there are various things, which can affect things.

I see what you mean now. You are talking about simulating the natural properties of materials in the real world, and dynamically generating those to produce a far more realistic game. This is a much deeper level of dynamic generation than what I was thinking of. However, dynamic object generation is required as a prerequisite for this, since icons have to be attached to objects in order to actually be displayed in an object oriented environment.

Now you have to keep in mind that even the best supercomputers in the world cannot simulate reality 100%, so that's not going to happen of course. You listed a variety of properties that have to be looked at and defined separately, in terms of simulating them through code.

Size and color:
BYOND's built-in icon procs can handle changing the size and color of icons, although not as efficiently as we would like. As for size from a physical point of view, that can be handled well enough with the bounding boxes.

Material and shape:
These properties are absolutely full of math. They are generally only defined and used in complex 3D games, although it could work just as well in a flat, 2D world. I have to wonder though, how do you plan to generate materials? Typically, this requires some level of hardware rendering, and it is usually done by using different kinds of "fractal noise", which uses some very heavy algorithms, that BYOND generally doesn't handle very fast. I could be wrong on this though, since we are only talking about 2 dimensions, which would need much less processing than 3D objects.

The other option to generate the material is to make a whole library, or palette of base materials, that can be blended together in different ways to produce a fairly large variety, although this could use up a lot of the resource, and the results might not turn out as good. One advantage of this method though, is that you could take advantage of BYOND's native alpha rendering (opacity), to produce results much faster.

The problem of shape itself might also be tricky, depending on the rendering method. If you used fractal noise, then the algorithms would already conform to any shape, but if you used base materials, the resulting icon might have to be cut into pieces, or stretched and distorted in different ways to fit the needed shape, which much like the fractals, BYOND wouldn't do that very fast.

Now of course, that was only the visual side of this problem. Materials and shapes are more than just visual. Materials come in many complex forms, which cause different results upon collision with other objects. Real materials have widely varying strength, and a splash, crumble, break, shatter, shake, bend, or almost nothing might result. Of course it's probably rediculous to talk about effects as general as this, for an engine built in BYOND, since this would have some serious hardware requirements, to manipulate materials on that kind of level, which so far, has only come up to a reasonable degree in the new PS4 games coming out, because the system has the kind of insane power needed to pull it off. Now for shapes from a physical point of view, I'm not sure if BYOND can effectively handle collisions that are not square. You would have to come up with some kind of hack to make your own virtual bounding shapes, to handle collisions on the pixel level, but that would probably use a lot of CPU.

Mass:
This property might be fun to define, and ironically, BYOND would probably handle this one just fine. It's mostly because it's not associated with anything visual. It just works in terms of movement speed, and direction. The more massive an object is, the harder it is to move, or stop moving, due to inertia. This property works really well if you also define the gravity of the world or area, and the friction of the materials that are moving. This property is especially useful in platformers and racing games.



Overall, these properties can be very complicated, and may require a great deal of math. This is essentially just simulating the natural geometry and physics of the real world, only to the degree necessary to produce something that looks and acts somewhat realistic. I'm not even sure that I have seen a game that thoroughly covers all of these properties equally. I would be worried about how much time it would take to produce an engine as well-rounded as this. Such an engine might take 5 times longer to develop than the game it was built for. If I were so ambitious to create an engine that's so based on the real world, I wouldn't want to use BYOND. The real world is not flat, and BYOND is not designed for making games that look like reality. I think the best kind of graphics you can get in a BYOND game are pre-rendered ones. Take 3D, pre-rendered icons, then use overlays to put them together in different ways, and that's about as far as you can get with BYOND, graphically. If you can render something that looks like wood or rock from scratch using fractal noise with icon procs, in just a few seconds, let me know. That's just not generally how sprites are made for BYOND games.

Also, I will quote this again.

I'm not referring to items or objects, which have simple variables, which you can randomize

That may seem to be the case at first glance, but if I designed an engine that defined all of the above properties, it would be so powerful that those properties would basically just be simple variables that I could set, and even randomize, but if it became that easy, the procs supporting that would have to be very complex.

Finally someone who gets it. In any case, considering that we are mostly limited to the 2D, this allows us to take advantage of the dynamics requiring less processing. I'm not attempting to make something, which simulates the real world, not by a long shot, but for the world to have core mechanic, which the players can work with.

A lot of the systems can be brought down a few levels and simplified in a use-able form, which is not as resource consuming. Materials can be brought down to less complicated in their function. While materials don't necessarily need a huge library to work with, the support to get wide variety of materials with their unique properties would be brilliant. In items the properties could be handled by it's usage and volume in the material used and of course how it covers the body, as well as where it covers the body.

While in the end it comes down to a few use-able variables, which are used in calculations for the usage, they are by no means some completely random numbers taken from thin air, they would have their limitations and restrictions.

Taking a step down from insanely high resource usage, we can go on and simplify the mechanics to a level of more efficient processing. We'll be making a world, which has it's own laws of physics by which it ticks by, however they'll be in a way less complex form. Never the less, it can produce quite interesting results. Probably?

It's not complex but the degree of complexity for such a system they're discussing Minecraft doesn't even attempt to simulate; that's the point.

It's so that the textures of the materials are dynamically generated, obviously they would have to use an algorithm(e.g., fractal noise) to accomplish this, right? Either way, such a system the OP is describing can't be done with BYOND.

Randomly generating textures client side is possible using javascript.

As to why you'd want to do it, I don't understand. It seems stupidly overcomplicated, and unpractical. It's like building yourself a seven meter mech to deliver pizza over hazardous terrain, rather than building a road.

Randomly generating textures client side is possible using javascript

Really? Because I could've sworn there would've been more raytracers if that were the case.

As to why you'd want to do it, I don't understand. It seems stupidly overcomplicated, and unpractical. It's like building yourself a seven meter mech to deliver pizza over hazardous terrain, rather than building a road

Would you prefer to, by hand, draw the textures for 500 objects or dynamically generate them at run-time? You choose.