Prism Postmortem - 7 Days of Tough Work

Game Design on a tight schedule is hard, rewarding work.

This was my first Game Jam to enter, though I've been using Unreal Engine for many years now. Most of the things I work on never see the light of day; they're more technical exercises where I tackle a question I have, such as a mechanic to implement, and when I get it right I shelf it. That's essentially what I did with this Game Jam, but instead of asking myself how to implement a mechanic I sought to flesh out an entire game.

So in the end, what went right with the project?

• As soon as the theme was announced I started brainstorming. I was actually brainstorming the night before the Jam theme was announced, wondering "oh, what if it's this theme? I could do this and this-- but if it's this theme? Maybe this;" and, actually I thought up the idea for Prism the day before. If the theme involved puzzles I wanted to do something where you could flip colors to move through a level. When the theme of "Reality is often Inaccurate" was announced I had new thoughts of what to do: I pictured Don Quixote fighting "Dragons;" I dreamt of a game where you had to balance between an idyllic, utopian upper crust life with grueling, back-breaking labor to power it all; but through it all I came back to this. It's safe to say that, when you know a project is coming up, even if you don't know the specifics, tackle it before it even reaches you.
• Fortunately before this project began I was working on an exclusively UI game. That was an area I wasn't very comfortable in, but I built a guessing game with dynamic images on buttons, it had a timer, it did everything I would need UIs to do. I took the experience from that into this project. I kept most calls for menus in the Player Controller, which not only let me re-use pre-drawn menus instead of re-drawing them but also have a reference to the menu in case I needed to reference a variable it had, or an event it was in charge of.
• I learned a lot about inheritance and parents, and I don't think this project would have been in nearly the state it's in now without me picking up on it. So much of my game relies on instanced objects, with major code in a Parent actor where each instance could have something unique to help it perform as it should. For instance: every single one of the colored areas the player is supposed to be blocked by or move though depending on what color is active is all done in a parent actor and each instance is told what color it is and where its boundaries are. I'll explain more on that in "what went wrong" below.
• Ultimately 2D was the best choice for this project. It was one less dimension to worry about, but the effects are really spectacular in 2D. I tried to make the background as close to the graphic color as I could (it seems Unreal is a little wonky about colors), but giving every color-coded section its own unique design also helped the elements stand apart from the world, despite them supposing to blend in with it. I also used a Translucent shader on my tile maps to let the puzzle elements become this nice semi-transparent opacity. I knew I wanted to see the player through the color, and instead of letting the glasses overlay tint the entire image I wanted the player to know when they were inside of a color. At first I was going to make a "sparkle" effect on the volume the player was within; then I thought about making the edges sharp, contrasted and obvious; but I knew I wanted the red areas (the first colored puzzle pieces) be like a gemstone, so I sought to just give them a tiling texture and let the character truly become trapped in the color with an overlay on top of them.
• I made a colored run cycle animation for this project and that really came through well. When I put it in the game and got it working it just looked like it fit. I wanted the character to have a lot of color, but also enough whites, that he would blend in with the environment, especially when colors flipped. Though he doesn't have any red he looks good running through levels. Of course I wish I could have spent more time on it, but given only seven days and it took me more than one of those to get his run ready it had to suffice. I had to sacrifice on his other animations and, honestly, his design (I had to have an animation and needed a design that I hadn't even thought of before I sat down to animate) but it looks slick in the game.

I learned a lot through this project; deadlines really make me feel like a train going full steam. But, of course, along with the good comes the bad. What went wrong on this project?

• Although I had the idea of what to make and knew exactly how it should look at the end I had no clue how to translate that into the game engine. I spent a day and a half (so this is leading into day 3) contemplating, blocking out test levels, racking my brain for how to best approach this. 2.5D would have been really cool; the backgrounds could be a lot more elaborate than in 2D, but I could never get the camera to look good. I didn't want the blocks the player ran through to show over the ground: I didn't want it to look like there was a hole in the floor and I couldn't think of a way that 2.5D would work properly. Lowering the camera to foot level would make it look like there's a hole in the ceiling; pulling it back REALLY FAR and setting the view angle down REALLY LOW would have been the same effect as 2D at the end of the day, so why should I build things in 3D if they were only going to look flat? I went back and forth for a day and a half from 2D to 2.5D. I had it in my head that I couldn't control 2D like I could 3D, I couldn't tell things not to collide with the player. ...Or could I? It's only from this struggle that I came up with using a parent object which instances reference its code to do unique things. Like I said, you can't have good without the bad.
• It was on the final day that I hit a roadblock with gamepad testing: I suddenly realized, I've never used the gamepad to navigate menus. I try it and I find that it isn't doing a thing! I scour the internet for an answer on how to solve this problem, and fortunately it was a video from Unreal themselves that showed how to do it, but it isn't as straightforward as it maybe ought to be. It sure would be nice if Widgets could get a "prioritize gamepad/keyboard inputs" node to forcibly allow input simply and quickly. The backdoor way I found to do it required essentially telling the game what button you're on for it to change its state- even though it knows what button you're on without all the code! That was a headache, but now it's another tool in my arsenal. Once I get it polished. I don't think it's 100% in my game yet.
• As I mentioned before, all of the color areas are custom instances of blocking volumes. The gist of it is: they all inherit from a parent which lets them each define what color they are, and depending on what color they are their volumes either block or don't. Well, each and every volume had to be hand-shaped to meet their awkward styles and every instance needed to correctly say what color they were. For the most part it's easy, yeah, you just run through the list and make sure they all are the color they should be. Well my last level, which I finished the last day (the last hour) had 65 such instances in it, each one sculpted just to shape, and, ashamed to say it, a couple of them are wrong. The final level branches two ways at the beginning, and the way which I marked as the "easy" way is probably unbeatable now because I mislabeled some colors, and poorly misjudged what a player could be expected to do in confined spaces. I designed the route to be a jumping section where the player would be able to jump up into the next color, then up to the roof of that color, and repeat to climb up like a ladder. Well, there is absolutely no way a player, unless they have lightning fast reflexes, could manage to make a good jump in a space as tall as they are! So that was bad... and that was in the uploaded version :(
• I didn't start on sounds until the day before the deadline. I needed more and planned on recording them all myself but, thanks to Unreal organizing subscriptions to services like Soundly, I got them from a repository instead. I did get some good ones, but I did not get very many at all. If I devoted more time I would have put it into SFX and BGM.
• Balancing life and work can be very difficult. I was lucky to be able to spend 2+ work days ('paying job' work) at home working on this project, but I still tried to keep a balance in my life between being on the project and off of it. But there's always so much to do! So much I want to do, so much I feel like I could do. I put everything I had into this game and, though I stumbled a bit and spent extra time looking things up that I probably should have known, I feel like it turned out really well.

This was a lot of fun and I can't wait for the next one. I feel like my scope was very big on this one: I practically did make a game since it has 3 levels (only one is a little buggy...). Next time I enter a competition like this I may try to slim it down, especially since I hear that we got a lot of time on this one.

Although I've always felt like I knew Unreal, I knew it enough to make some things, I feel like this project and the weeks leading up to it I have been learning a lot more. It seems like that's how it always is, there's always more to learn. Especially when it comes to game engines, and games in general: the only one who can make it do what you want is you.

Good job everyone, we did it! Mega Jam in the bag!