Archive post from the old blog. Original Post Date, March 1, 2016


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).