Today's update isn't very exciting, so instead you get a ramble on game design! Yay!
I think all of these points on dragging are totally valid. In the end I think it wouldn't do thaaaat much of a difference, because it's a very slow and deliberate action in a very chaotic game. Any cunning plan like that is pretty much doomed. It's like that guy who'd try to punch a crate across half the map to block a door in a halo match - cool idea bro, but a million rockets and grenades and burning vehicles are going to wreck your day, and the rest of the game plays in 100 times the pace of your plan and will already have played out when you get there. Rain World is about planning and analyzing, but it's mostly on a 0.5-5 second scale rather than up in the twenties, or minutes. There are some minute-scale decisions in single player, such as "which area will I go to", but once those are taken the sub-goals will be much smaller chunks of decision making.
Also the game is fairly unpredictable. I know I've mentioned this as an issue before (I want the player to be able to feel at least somewhat in control of a situation) and I will work on it, but on a bigger scale it's such an integral part of the game design that it will just have to be dealt with. Which is something I don't necessarily view as a bad thing, because I think fun stems from a good combination of random and controllable. Think about tetris, it's random what blocks you get, but how they behave is completely deterministic. Rain World has a similar dichotomy I think, what creatures are where is hard to know, but how they behave and interact can be learnt and manipulated (or, it will be like that, once I clean out some of the weirdness and randomness).
I'm kind of aligned with fizmats idea of animal-level and human-level intelligence here, and that kind of reflects what I mentioned above - the slugcat is intelligent in split second decisions, but doesn't necessarily prepare elaborate traps. Definitely not crafting. That said though, the slugcat
is the player's avatar, and whatever the player is able to think of the player is able to think of, you can't get in the way of that.
The third factor is something I think of as "world self containedness". Hmmmm examples. A self contained game world would be Pac Man. In pac man the little pac man creatures are what they are, and they are what they do. Ghosts chase, pac man eats. You don't really question why they don't do anything else, because they
are what they do and all they are is what they do. You don't ask yourself why pac man doesn't try to talk to the ghosts for example, that's just not in the scope of that world. A non-self contained game world would be GTA. GTA attempts to mimic the real world, and thus its
canon suggests more possibilities than its
mechanics can provide. In GTA you can find yourself thinking "god why doesn't he just push the box with his hands" or "if I just had the option to say this thing to this character I could've solved this mess" or "why can't I open the trunk of the car! I want to open the trunk!" or an infinite amount of other things. GTA suggests a world where you could become a painter and spend your days painting abstract art (namely our world, where you can do that) but it doesn't provide the mechanics. Pac Man suggest a world where only eating is possible, and eating is also what you do.
I get the point of both ideas, when doing something movie-inspired like GTA the latter option is obviously preferable. But personally I prefer self-contained worlds. A computer game object is only its actions, and in a self contained game world it should ideally only represent those actions as well. Pac man eats, ghosts chase. I have a bit more technical resources than pac man, so I can make a slightly more complex world, but I want that same tightness of design. I want my creatures to be the things they do, and to be pretty much only that. The slugcat is quick, jumpy, climby, stealthy, nervous, always on the move, hunting and desperate to stay alive at the same time. The lizard is lazy and slow until it spots prey, then suddenly determined and persistent, making every single move in order to achieve the goal of reaching the other creature. The fly is a bit goofy, concentrated on its own business which is kind of obscure what it is, but suddenly panicking in order to preserve itself, especially when the behavior is amplified throughout a group.
Those concepts are realized through the actions - jumping, climbing, running, flying, chasing. The animation is then intended to amplify these hinted personalities further, but is always based on the actual game-relevant interactions. The slugcat for example has a nervous gaze switching from object to object, similar to the personality its behavior suggests - never really focused on a goal, but always determining the situation in this very now. "Was I one millimeter from death half a second ago? That's irrelevant now, because now I have a 0.3 second window to catch this prey, so I better give it a shot!" The lizard on the contrary is goal focused - staring down its target with tunnel vision, only giving other creatures a quick glance as they appear in order to make a swift calculation whether it might be worth it to switch target.
The idea is that interactions added should be in line with these personalities - further defining the creature using the things it
does as building blocks. The slugcat shouldn't play basket ball, craft a gun or run for president. It would be out of character. And worse, it would break the self-containedness. If you can craft a gun, why can't you make a car? Suddenly it becomes obvious that the limitation is not the edge of this
world, but of what I could be bothered to code when making this
game. Willing suspension of disbelief punctured!
Dragging a corpse as a bait? Maybe! It could definitely be a part of the slugcat skill set. It's not vastly out of character, just maybe a little, as it suggests thinking several minutes ahead, which we haven't seen much of so far. But if it does add to the game, or if it could be done as a more on-the-spot action rather than a lengthy and deliberate one, it could even be a welcome nudge in a new direction for the character. Giving it more depth! But, as you can tell if you made it this far, there are several things to take into consideration when adding something like this.
That's what's going on in my head when I think about what new features might be like!
Update 335Sent an email to UnityVS guys and got an answer that they simply don't support break on exception, so it wasn't that weird after all
In other news, creatures carrying other creatures (and inanimate objects) through abstract space, into abstract space, and out of abstract space, is now done! It's actually a pretty huge step, but it's not really the gifable kind - it looks like leaving a room and then when you go back into it everything is where it was and nothing has happened.
The system supports carrying of creatures carrying creatures carrying creatures etc. So you might see a lizard carrying a lizard carrying a slugcat carrying two flies hahaha!
There was some trickyness to this, because when a creature carrying another creature exits a room, it pulls that creature with it. This means that I wasn't able to resort to the classical iterate-over-the-list-backwards solution when updating creatures in rooms, because they were not certain to only remove themselves, but could pull any random chunk of other creatures with them from both before and after themselves in the list. You code people, if you could give my solution a quick glance and tell me if it looks OK?
private List<AbstractWorldEntity> entities;
private bool evenUpdate;
private int roomIndex;
public void Update(int timePassed)
{
evenUpdate = !evenUpdate;
bool allEntetiesUpdated = false;
while (!allEntetiesUpdated) {
allEntetiesUpdated = true;
foreach (AbstractWorldEntity ent in entities) if (ent.evenUpdate != evenUpdate) {
ent.evenUpdate = evenUpdate;
ent.Update(timePassed);
if (ent.pos.room != roomIndex) { allEntetiesUpdated = false; break; }
}
}
}
This is in the room class. What I want to do is update each entity in entities
once, but what I need to account for is that the update call might remove the entity and any number of other entities from the list.
In English, my solution is this: I iterate over the entities list and update each entity, setting a bool in them so I know I've updated them this frame. After each, I check if it's still in this room, or if it has moved out. If it has moved out, I break the loop, and start it all over again, once again iterating over all the entities. But because those already updated has the bool set, they don't get a second update command. I repeat this until I have been able to iterate over the entire list without any breaks.
Should about do it, right? Let me know if there's any problem I didn't think of.
— 
I think that if you're doing anything per-pixel, it has to be done in a shader. If you do that stuff on the processor, it's just too slow. Oh and you don't need to thank me for bragging about my game haha! 
Keep in mind though that I hit record until it looks good - there are some ultra wonky or problematic recordings before I get a really good one, so there are still problems to sort out before the game looks good every time.
Microsoft! 
