Capstone Part 4 - The First Casualty

Dramatic title aside, this week’s sprint planning meeting did include the major decision to scrap our third, yet to be started, prototype: the beat-’em-up. Really, it was my idea, but everyone else was onboard with no convincing needed. I appreciate the trust a lot, especially having often found myself pressured into taking on too much work, by people with no idea how long it takes. As a matter of fact, everyone was on board so fast that I don’t think I even had time to state my reasons, so I’ll do that now. First, is the fact that all our prototypes were pretty sizeable efforts, and we only had so much time. It made very little sense to spend so much of our semester on them, especially when we’d be completely scrapping 2/3rds of the work we did. So why this game? Well, there’s the simple fact that we’d started work on the other two, but not this one. Along with that, I thought it just wouldn’t prototype well with time constraints. A beat-’em-up without animations is never gonna appeal to anyone. But we don’t have an animator. Our artist can, and will have to make some animations for any game we do, but they’re most important, urgent and simply the highest amount, for this game. So bye-bye you go, maybe we’ll encounter each other again in the future…

With that deed complete, I did still have two games to work on. I’ll start with my struggle against Project Nugget.

When I last left off with my chickens, they were refusing to move. I decided to abandon the AI system, and get the nuggets to move with basic interpolation. I’ve done it dozens of time before in Unity and from the ground up. It’s second nature to me, and easy. RIght? Wrong. After a bit of reading, I learned how to move things with a lerp (and timeline) in Unreal. Okay, why is only the last member of the chicken array moving? I think this is the first time I’ve gotten upset with Blueprints, because I was genuinely left the dark about what was going on, and no easy way to see what was going on. After more reading, I think the issue appeared to be how timeline inside the built-in for-loops work: they don’t. So I think I’ve figured out the issue, or I’m blaming the completely wrong thing. Either way, this is another thing I take issue with. I don’t want to call it a problem, but more of an inevitability about engines: they want you to do things their way. I originally made this realization when I was abstracting functions for my Game Architecture class, and it’s stuck with me since. When an engine has a specific way of doing something, you generally have to accept it, even if it doesn’t align with how you’d normally do it. Worst case scenario, it simply doesn’t allow something you want to do, and you have to find an over complicated work-around. In my case, I just made the chickens teleport. Whoops.

As for the paint game, I had an easier time this week. First, I spent some time cleaning up the combination of spouting paint and placing decals on the floor. Like, not doing those things when you’re just standing still. Then, I started to mess around with wall riding. That was the first of multiple special movement options I’ll be implementing over the coming weeks. Ultimately, this would largely be visually demonstrated through the character animation. I was just using the basic 3D “Unreal Dude” that comes with the starter content. So to demonstrate him riding on the wall, I just turned him over 90 degrees. It looks ridiculous, and occasionally he’ll start spinning around back and forth. People like it a lot. In addition to riding on the wall, paint should also be placed on the wall. And it did so just fine… until you went into a corner. Corner paint decals got all sorts of stretched and mangled. I don’t think it’s important at the moment, but I hate it. It bothers me on a deep internal level, and I vow to fix it next week.

So, I shall return next week, to tell the tale of my battle against corner decals…