It is expected that you have read the previous sections, and have some experience with basic construct creation and programming. If you do not meet the expectations please correct this, it is doubtful that this will be very helpful to your practices otherwise.
This article is aimed at novices with some experience and low-intermediate psions and discusses the importance of, practical concerns regarding, and how to design constructs. It is only assumed that the reader can easily make very basic constructs and that they wish to make more complex ones.
To start this off I will define design as: “the use of long or short range planning to improve aesthetic presence, objective functionality, or other aspects of a construct, or amending these aspects after creation, rather than making a construct with little thought or on a whim.” This definition may sound a little complicated, but it only means that you logically plan out one, or several, aspect(s) of a construct to improve its ability to fulfill its purpose.
There are many things to consider in the design of a construct. Not all of them will be important to all projects, and may carry only symbolic significance in some cases, however all are worth considering before undertaking, or while remodeling, a construct. The elements of design are simple individually, but they come together to form complex creations which can serve an infinite number of purposes.
The shape of a construct doesn’t have to relate to its purpose at all. However, for psychological purposes, it is beneficial to make the two correspond. Allow me to illustrate the point. A spherical construct meant to act as a link between two minds will, with proper programming, do its job fairly well. However, a construct shaped like a cable between two heads will, by the mere symbolic value, do a better job, even with very poor quality programming. Similarly, if a shield has visible holes in it, it may still protect you if it is programmed to function equally with or without holes in it. However, a shield with no holes needs far less complex and thorough programming to do an equal job of protecting you because of the symbolic protection your mind assigns a solid barrier as opposed to a Swiss-cheese-like shield.
Additionally take into consideration how the shape of a construct will impact the impressions others have of your construct. A gun shaped construct or sword shaped construct will be assumed a weapon… even if they are intended for healing. This is doubly true when those viewing your constructs are inexperienced and do not look at intent in constructs, rather than appearances. You can use this to your distinct advantage in many arenas. For example, if you want a very dangerous construct to not be seen as a threat, make it shaped like a bunny, or other cuddly animal.
Color, in my experience, is sometimes entirely symbolic. So, if someone programs a construct to be purple, and they strongly associate the color purple with flowers, a scanner will sometimes get the impression of the construct as the color they most closely associate with flowers, rather than the intended color. Why this is can only be speculated upon, but it is my assumption that the programmer uses the ideas they closely associate with colors to program them into a construct, rather than the color itself. Keeping this in mind colors are most important in terms of what you associate them with. If ‘white’ is closely associated with purity to you, and you program a construct to be white, subsequent viewers will either see white, or the color they most closely associate with purity.
Basically, actual colors are more important as a component of an entire appearance than as an individual factor. You need not be overly concerned with what colors things are, but rather what feelings you associate with what colors they are. The exception is when colors are a part of a complete disguise. For instance, if you wish to disguise your construct as a rubber ducky… Most rubber duckies are not blue with orange polka dots, but yellow with orange parts. Therefore you want the construct to be yellow, regardless of your emotional and mental associations with yellow. In fact, you want to try to be completely non-reactive to the given color, or think about what yellow is (a certain energy-level of photon, which vibrates at such a frequency that your occipital lobe interprets them as yellow) and not how the color looks to you.
The size of a construct is relatively irrelevant in every regard. A giant psi-ball is really no different from a tiny one. It is the “quantity of energy” not the volume it occupies which matters. Size affects functionality in terms of psychological perceptions. Ideas like “that construct is huge, it can’t pass through that door/opening.” Act as psychologically provided limiters that are not inherent in the construct itself. Likewise, ideas such as “That tiny construct can’t possibly affect that large one.” Act as imposed limitations, which are not inherent to the construct itself. If your subconscious cannot accept that an event is possible, you will not see it happen. There are numerous examples of this. For instance: when Columbus sailed to the Americas many Natives could not see the ships because they could not conceive of the possibility, their minds assumed it impossible that huge ships from across the ocean were coming, and so they literally could not perceive it. Similarly, even if your construct is utterly destroyed by a construct a fiftieth its size you may not realize it for some time, if you cannot believe it is possible. This doesn’t so much restrict the occurrence from occurring; it merely limits your own ability to perceive the event.
With this in mind, size matters when trying to control the perceptions of onlookers. Instincts say that small things are more sneaky but less powerful, whereas large things are less coy and more brutish. By reversing this natural trend to hide the purpose of your construct, or using it to help play up the strengths of your constructs in the minds of onlookers, you can make your construct more effective in its interactions with others.
Novices will find appearances useful in putting the instincts and practical logic of viewers at odds to confuse them. Conversely a novice can make the appearance and actual focus/purpose of an article match up perfectly to reinforce the programming in the perceptions of others.
Advanced programmers may even give a construct many different potential shapes, changing shape, or appearance of shape, based on who is viewing the construct. This requires setting up mechanisms which change the construct’s shape, or how the shape is perceived. The simplest way to do this is to set up a basic sensory capability in the construct and give it a set of “If, Then” scenarios, such as “If someone hostile views you, then change your appearance to that of a rubber ducky.” Or “If anyone but myself views you, then appear to be ambient energy.”
Appearances, in the metaphysical world, are either very important or very unimportant. They give first impressions, and lead people to conclusions. Design your constructs to either guide folks in the right direction, or astray. That is completely up to you as the designer.
Dividing complicated (and even simple) constructs into many parts can improve their functionality. The idea is to create ever simpler constructs that work together to accomplish ever more complicated tasks. Most people think that having many components to a single construct is overtly detrimental to the construct’s stability. I find this untrue, as very simple constructs are infinitely more stable than more complex ones. Let’s use an example. You want to make a construct that makes psi-balls until the end of time because this amuses you. So you create two. The first is one big blob of energy programmed to gather energy and create psi-balls. The second is several constructs combined. The first gathers energy exclusively, it just pulls in ambient energy, then provides it to the second construct. The second compresses the energy into a ball shape; a third then adds programming to this compressed ball to hold together and swirl slowly, forever.
The first takes less thought, planning, and time. The second is much more effective and acts almost like a conveyor belt system. This is what I term a construct system. The combination of several of these simple systems is what I term a system series.
Construct systems and system series are more efficient and less likely to break down of their own accord than simple one-size-fits-all constructs. They do take more time and effort, but if you practice making them long enough, and apply them to varied enough purposes, they become second nature. Once they are second nature all your constructions will by systems of smaller constructs, which eventually will all be systems of smaller constructs, each of which is actually a series of yet smaller constructs. Having grown exponentially simpler your constructs cease to be possible to tamper with because there’s no programming to change.
Another thing to be considered with this approach is that it becomes increasingly more difficult to consciously conceptualize how your constructs work and much of your actual designing becomes unconscious. This is a disadvantage in that step-by-step instructions become increasingly vague and difficult to give, making specific advanced ideas using this method difficult to put into words. This is however a great thing for your personal practice, as it makes your work infinitely more effective, and eventually faster, because your subconscious mind conjures up every level of design from memory.
It is always useful to divide constructs into simpler components which work together. That is the bottom line.
As with previously discussed aesthetics the practical functionality of your construct can be dramatically affected by the use of things symbolic to both you and others. Specific examples are the use of “hollow tubes” or “wires” to transfer energy, the use of a “mirror” to reflect energy, and the use of “fiery” energy to destroy. Things which posses a symbolic value to you are valuable both in programming and in setting the traits of your construct. Making the outside of your construct a dark “color” can make it grow warmer than making it a light color if the colors carry that significance to you. It is infinitely useful to understand your subconscious mind for a variety of reasons, add this to the list of them.
It is usually best to use as many programming methods as you can in a construct. Redundancy is stability. Using several forms of visualization is better than one. This should be obvious. What may not be obvious is what methods of programming lend themselves best which purposes and functions.
When a construct is meant only for your personal use, and won’t be interacting with other people much, it is very effective to use completely symbolic programming. This is particularly true because the symbols will only need to be relevant to you, in particular. If a hunk of meat is happiness to you, then by all means, if the construct is for you alone, make it look like a piece of meat to cheer you up. If the symbols are effective for you this form of programming will be the most potent in regards to yourself. It does require an understanding of your subconscious associations, however.
When a construct will be interacting with many individuals, especially when it will function transpersonally, it is best to use intent/will based programming. This is because visualization and symbolism are particular to individuals but direct will is not. A statement such as “Be round” will not likely be perceived as “Be flat” by another person. Likewise when your intention is to cause annoyance, without any allusion to the details of how this is done, is unlikely to cause someone pleasure. It is this very unambiguous nature which lends will and intent based programming to being the most effective method for interpersonal constructs’ creation.
Constructs with very complicated goals and purposes are well-served by the use of conceptual visualization, which avoids too much assumption on the part of the programmer. This is useful because as much as you may think you understand how your construct ought to act, leaving blanks will probably work as well, or better, as there are then no direct restrictions on how goals are accomplished.
It is worth restating at this point that using methods in addition to that most suited to the task at hand can only help your construct’s effectiveness, so long as your programming does not become ambiguous.
For now this is all. Try to incorporate these concepts when designing your constructs, and eventually you’ll find that trying is no longer required. I wish you luck in your endeavors.