Stuff you won’t see in psi

It’s that time again ain’t it? This post follows a similar premise to “Stuff you won’t see in botania“: things that people keep asking/telling/demanding me to add, and that I have absolutely no interest in adding. I think it should be known by now that I love throwing wrenches in people’s plans. I believe that if everything always goes your way, you’re either amazing at the game, or the game is terribly put together. There has to be some sort of force pushing you backwards and requiring you to adapt, fight harder, or think outside the box. Whether that be quirky behaviour in some blocks in Botania, like the Crafty Crate, or purposely rough mechanics, like needing to order tricks properly for optimal execution in Psi.

Of course you can do this poorly. One of the examples that I’d point out would be Fire Emblem: Awakening, a grid based, turn based strategy game for the 3DS, if you weren’t aware. Halfway through battles in that game, the enemy may summon reinforcements, which can move in the turn they were summoned. Summoning reinforcements is a pretty standard thing that happens in Fire Emblem and other games of the genre, but allowing them to move instantly without the player having any time to react to it is a perfect way to showcase how not to throw wrenches in your plans.

Myself, I try giving the player info about how the system works, but introduce various quirky behaviours here and there to spice things up. Again, going back to how you have to put the tricks in order, which adds another layer of planning, not only do you plan what you want to do, but you also have to plan out how you’re going to fit it in.

Anyway, that was a bit of a tangent, but I thought I would put it out anyway, because it’s a bit of a view into some of the things I try to do to spice up the game. But moving on to Psi. Psi is, basically, a programming mod. However, it drastically varies from standard programming, which I think makes it more interesting. For one, there’s no explicit looping of actions (you can use Loopcast, but it loops the whole spell), no direct flow control via ifs/elses/switches, etc, no functions, no defined variables… basically, it throws all of the bread&butter programming concepts out of the water and delivers something much more simplified.

Now sure, you could make the argument that’s a negative, and it’s a fair argument. Definitely, by providing less tools it also lowers the flexibility of the system, but this ties back into the quirks. We already have “standard programming” mods in the scene, such as ComputerCraft, OpenComputers or Steve’s Factory Manager. So I wanted to try something different. I wanted to create a mod that would still work, and allow for the possibility to do all sorts of things, without invoking the need of “standard programming” features. Instead of what we have now, I could’ve just grabbed a Lua interpreter and made a mod where you actually write spells, in Lua, but at the end of the day, it would really just be a semi-magical ComputerCraft.

And that’s a background view into what I was trying to do with Psi, which should help understand the actual list of stuff you won’t see. So let’s move on to that.
Similarly to the botania list. Just because something is not on the list doesn’t mean it will get added or has a chance to, it just means that I don’t have it asked all the time. Furthermore, this list may be updated in the future if new things show up.


Any sort of automation
Just going to kick this massive archetype of content development out of here, yup. Give me a moment.

Ok, I’m done.
As you might know from Botania, I believe that Minecraft is a game more based around the world, and I much, much prefer that automation is done in the world, for the simple fact that what you create then translates 1:1 to what you end up with. That doesn’t make sense? Ok, imagine that Psi would have a “Caster Block”, a block that would, drum roll please… cast spells. You would write spells like “Harvest Pure Daisy” in there, which would break a donut in front of it and maybe also grab some stuff from the nearby chest. But in reality, what you see in the world is really just a box with a chest next to it that does all the work. You know why the box does all the work, you wrote it, but it’s nowhere near as interesting as a piston system, or a bunch of pipes with block breakers going around like an awesome looking factory. I like seeing things happen, you know? We play a game about being creative and creating awesome stuff, let’s not just subject ourselves to boring boxes.

And even if I did make them happen, like turned the “Caster Block” into an awesome looking drone or a robot thing, it suffers from another problem, the fact that Psi is too precise. You can tell it exactly where to place a thing, break a thing, you can make it vary exactly how you want. I think this is fine in the current context, because it really just ends up as an aid for repetitive manual creation (see my 9×9 spell, or Direwolf’s stairs spell). When in an automation context, it effectively negates many of the quirks of in-world automation, which just ends up making gameplay a bit more boring. And the little bits of “more boring” add up. Some instantaneous transport here, some auto ejecting there, a little config for exactly where to farm blocks over yonder and suddenly the game plays itself and the only thing left for you to do is grind out the materials.

Standard programming behaviour
Talking about those that I mentioned in the fifth paragraph, features like adding If statements, variables, so on, would, in my opinion, whilst definitely making the mod more versatile and usable, also drastically hurts its identity. I feel like I’m repeating myself, but adding these things would lower the quirkiness factor, which I do believe is in a pretty good level right now. Plus, there’s already a method of conditioning: the “Trick: Die” piece, which by itself is reasonably quirky, due to the lack of existence of boolean values (true/false).

If booleans existed, you could have something like “Trick: Die” attached to “Operator: Equals” and a number. With the current system, you have to think outside the box a bit to get a working condition, which I think does add to gameplay, rather than remove from it. You have to think that more features doesn’t equal better gameplay. You also have to keep the quality of the features up to par, and make sure no content gets killed by new stuff (nobody is going to bother using suboptimal content), so with those reasons, I believe standard programming behaviour would end up taking away from the experience more than it would add.

A “Direct Damage” piece
I’m going to be honest with you, Direct Damage is the most boring thing I could possibly add. If you want to damage a mob I have a great option for you: use a sword. You got all these awesome things you can do to a mob: chuck them in the air, set them on fire, dig them down and place blocks where they are 4 ticks later to suffocate them, and many more, and you want a piece that does nothing else than lower a health value? And don’t give me the excuse that some of these things are impractical, if you want practicality I have a great option for you: use a sword. Heck, you can even have spells on your sword!

A non-visual programming interface
There’s actually no design-centric reason why I wouldn’t add this. It wouldn’t replace the visual interface if I did, of course. The problem here lies in the implementation of the spell system, which relies on the grid-type pattern to function. Implementing a non-visual interface for a system that is built to be visual from the ground up really wouldn’t work too well, and would be very subpar to use. But hey, if you can find a proper way to do it, tell me about it. But please don’t come to me with “ideas” when you have no idea how the spell system code works. Please, just save yourself the effort.

Any sort of mod integration
By which I mean first party. Psi has a working API, so if anyone else wants to do it, it’s on them, but I’m not doing it. I don’t want to add mod integration for two reasons, the first is the lack of material balance in Psi. You can do a lot with the mod with very few resources, if you know what you’re doing. That’s intended. I don’t really want to put you through a 4 hour grind collecting all sorts of materials to create a CAD. That doesn’t add anything worthwhile to the experience.

However, pretty much every major mod relies on some sort of material balance, be that a lot of power, a lot of items or just a lot of time and effort. Allowing Psi to be used to do tasks put up by those mods could potentially break their gameplay, and I think it’s fairly known that I hate when my mod’s gameplay is broken by weird interactions, so I wouldn’t want to inflict that on anybody, much less on purpose.

The second reason being the fact that the mod is structured in a somewhat linear system. While you can pick which things you want to learn, you can only proceed to the next one after you’ve made use of it. If I was to start adding mod integration features, it would mean that I’d either have to lock all of them past level 25 so they don’t break progression, or rely on players caring about all the mods in the pack, which in many cases they don’t. You would be pissed if you hated Blood Magic, were having fun with Psi and suddenly were forced to do something in Blood Magic because you locked yourself in a group that uses it.

In-depth configuration
One of the goals in Psi is to easily allow people to share spells. This is evidenced by elements such as each parameter having a different color, and parameters not being able to share a side, so you can copy a spell given only a screenshot. There’s also the built-in import/export feature, which is the backbone of places like /r/psispellcompendium. In sum, the mod has always been designed with sharing and community interaction in mind. If every modpack had their own config and their own costs and a few pieces disabled, then sharing spells would be much harder, as you’d have to say which pack you were on. Requesting spells would be even harder, as you’d have to go see which features are disabled. All and all, while it is a feature that could definitely allow for pack authors to better balance their packs, it also has definitive negative connotations outside the game, which also matter.

Multiple inputs in one side
As stated in the last section, being able to reproduce and share spells is one of the main goals of Psi. That’s the main reason why spell parameters each have different colors, so if you see a screenshot or video, you can reproduce the spell without the author publicizing their spell. Having multiple inputs on a single side of a piece would either prevent that, or make it much harder, and that’s why I don’t want to do it.

And there you go. I’m done for now. Hopefully this almost 2000 word post (the botania one was 1175 words!) enlightened you about how I tend to work on things and gave you a better idea of what I’m trying to create. Now go have fun with Psi. Or don’t, up to you :p