The Critical Factor

Time. The critical factor in most everything is a deadline.

We’ve got a little under a month left to go, and we’re finding a balance between implementing gameplay bits and feedback bits. This past week was gameplay, here’s the rundown of all that I put in.

New hook type, loose. Doesn’t quite have the feedback, so no gif for this one, but what it does is that when you enter a painting on a loose hook and there is a hook underneath it, which does not have a gateway, and then fall with enough velocity, your gateway will fall down to the lower hook. A one-way downward travel system.

New frame type, wall scroll. Wall scrolls are the fun “paintings within paintings” meme that is brought up now and then. When you take a wall scroll into a painting, you have an in painting representation, and when you pop out, the painting comes with you. Fairly straight forward, but may add puzzle complexity if you need to handle multiple objects (still in debate).

Another technical new frame type (though technically the frame is really just an indicator, nor do we have the model in yet), Interactive. In an interactive painting, an object can be found that is linked directly to the real world. For example, we have a door on a pirate ship that when interacted with opens a door in the real world.

And the final bit was finally the implementation of our painting camera zooming in on the character and following them around, Mario style-ish. It stops on the left and right edges, but follows the player up and down as well, so the zoom is a little more close in than Mario. This was actually a bit I had held off for a few weeks, mainly because there were better things to do, but I’m also generally not a graphics programmer, so this area is less intuitive for me.

That said, this post is off the normal schedule, so I can update on a tiny few things planned for this week. It’s mostly feedback, because we need to clean up the transitions as well as add gameplay feedback for things like the loose hook. I also get to mess with transitions again (oh god) and create some invisible terrain that blocks the player from reaching paintings/hooks. Until next week.

When The Masses Ask…

The big area focused on this week was player feedback, as we got a lot of QA responses that wanted to know more information about the world and their physical relation to it, especially when travelling through paintings.

The big two areas that we improved feedback through was via a render texture mesh that we added to the gateways in the real world (this is of the forest landscape):


And by adding a camera transition in two parts: moving in/out of a painting, and between paintings:



The other bit of player feedback attempted to expand on was the narrative. Besides just fleshing it out in the week prior, we implemented a very basic NPC (can be seen as the red block in the gifs above – very creative I know), that when you walk past says a bit of dialogue to you. Nothing fancy for now, but paves the way for easy implementation later.

Finally, the two bits of functionality we threw in for this week were a new frame type, the latched painting, which is a frame that can be dived into but not moved from it’s location, and having interactive objects within paintings.

This is our latched painting:


The interactive objects, first off, replace the collider that it’s on the side of. For example, our snow painting has an igloo on the left side, which counts as our interactive object that disables the left collider travel option (you can still collide, you just won’t travel between paintings), and you will only travel upon hitting E (which later will be accompanied by an animation).


This next week’s focus is on improving gameplay, mainly in the painting world, but also adding new hook and frame types to add puzzle variety, so tune in then.

Infrastructure Is Key

We’ve taken our Painting game, which still does not have an official name, and are working toward fleshing it out considerable. Giving it pizzazz where we can, and working toward that final vertical slice for the end of the semester.

My main area of focus, being the first week of solely working on just this one game, was on improving the infrastructure of the areas I more quickly set up, and cleaning up our repository so it doesn’t take four centuries to download.

Repository cleanup went well, I’m somewhat anal in my organizational formatting for the folders that I use and access, so I like to have things easy to find and not all over the place. Helps me at the very least, I like to imagine it helps others too.

Matt (Designer) added a third, more complex puzzle, and a background piano track that he composed himself. It’s a little simple, but it’s only the start, I expect great things.

We got two bits of player feedback in. First, when you are holding a painting and are near enough to place it on a hook, the hooks glow. Considering our hook model is somewhat visually diminished, I found it pretty helpful when I was testing the levels. It does help that Tucker (Artist) put a nice background to accentuate the “You can place a painting here!”


The second bit is the frame’s give you a direct visual indication of where they’re connected to. Easier to show then tell so…


And that updates on the fly as you go.

Final bits worth noting are a variety of bugfixes and infrastructure improvements. Three of note:

  • Each painting type now has far easier designations of entrances and exits on all four sides.
  • Paintings would occasionally stay highlighted when they shouldn’t and only one object could be highlighted at a time, both of those are now fixed.
  • The distance at which you can pick up/put down a painting is differentiated from the distance at which you can dive into a painting. Good for some puzzles. Matt has a puzzle with a gate that enforces that limit. In the future we’ll have different painting and hook types so we don’t need direct physical barriers.

That’s this week. We’ve got a lot planned for next week, so check in then.

The Chopping Block

The pain of working with full 3D physics is over. Snails have defeated me.

But honestly I’m not sad at all. While it was a challenge, it taught me a lot about Unreal as an engine, both in blueprints and with their C++ code base. And I even went to a professor who was super helpful in terms of teaching me about quaternions and how they work (much thanks Dan).

On the positive note, we have decided to move forward with the Painting game (name still pending), our Gothic themed puzzler!

To show off some highlights, here is our starting room:


And when you near the paintings, they glow to signify that you can carry them!


So far, our first two painting types, forest and snow:


The little copper-ish capsule (placeholder) is your character, who moves around the paintings and bumps into walls to switch between paintings.

And finally I’ll show off the (technically second) puzzle, where you have to grab the two paintings on the walls and move them to the hooks (which are the stone squares on the wall right now). That allows you to dive into the bottom painting, maneuver your way into the upper painting (by using the tree and cloud in the foreground of the forest painting) and then go right to appear in the painting on the balcony, which you can then pop out of, and you’ll have solved it!


Overall, super happy with the progress made, it’s a fairly solid initial prototype. We’ll be looking to challenge this week, so ideally that will succeed and put us into deep dive where we can take this game and push forward with it even farther (though we’ll end up doing that anyways, but professors’ blessings are always nice).

Final bit, if you want to try out the prototype, it can be foundĀ here!

More to come in another seven days!

Iterations Galore

Just a quick update for this week’s progress.

I worked on our puzzle painting game and the snail racer. The puzzle painter had far less to add, I dropped in a node system that the paintings hook up and talk to each other through, so instead of the paintings being directly linked to each other, the static hooks on the walls are the jumping points, and the paintings just the means by which you move from point to point.

The snail game got much more attention as I attempted to write my own physics engine. That went alright, the big challenge being that the snail has to move up walls as well, so trying to get it to stick to walls was a problem (but a solved one).

The snail game initially also had some trouble with moving up slopes (this was before I even attempted vertical walls), but I fixed it initially by adding the up vector, and then by actually rotating the object. In hindsight it sounds rather simple and plain, and maybe it is, I did forget that I could get the angle between the impact normal and my own location because I thought I only had the impact normal vector (and forgot to use my own location’s vector).

Overall, I don’t know exactly where we’ll go. Earlier I was leaning toward the snail racer, but these last few hours have been tough. I’m beginning to think that all these minor issues will keep cropping up and the movement will never feel fluid. There aren’t any good guides for the specific problems I want to solve, and while I’ve figured out a lot on my own, with some guidance here and there from the thoughts of others, I’m not sure I can keep it up.

Either way, we’ll decide our final game on Thursday, and then work on polishing that for the Monday after this Monday, but its at least notable that I haven’t had any real issues with the painting game (although I’m sure they’ll appear) which may just make it far more appealing at this rate.

More to follow next week as we determine which game we shall move forward with!

The Snail Prototype

What a disaster.

I’m personally just really disappointed with what I was able to get done this week. Not because of time constraints or anything else, but because of how difficult it is to work with Unreal’s vehicle movement system.

For some clarity, this week our team made two prototypes, one of which I worked on, which was a snail racer, and one that our designer worked on, which was a ladder-climbing party brawler. My snail racer project went less than optimally.

At the end of almost 10 hours of work solely on movement, we made a car that we disguised as a snail who’s movement is… well it’s not bad, but it doesn’t feel good. I didn’t expect it to be perfect, but given that my entire time was effectively dedicated on trying to set up the snail to move, and then actually moving it, I feel like loads of time was wasted.

I think that mostly stems from the fact that in an optimal scenario, even if I don’t quite get things as I want, I at least have an idea of how to move forward – the feeling that I learned from my time.

With this prototype, I genuinely don’t feel like my grasp on Unreal’s physics and vehicle system was vastly improved. Sure, I learned a bit more about how it all works, and tweaking with variables has visible effects that I can tune, but I don’t feel like I obtained a grander understanding of how in the hell it all works, and that’s what really bothers me right now.

I like to understand the systems I’m working with. If, for example, my friend Tyler were to have created a physics engine, and I was confused on how it worked, my first choice would be to look in the documentation. If I can’t find what I need from that, or I have a lack of comprehension on a topic, I would absolutely go right to Tyler and ask how it works.

But I can’t do that with what I need. Despite Unreal and Unity both having forums, I’m on a time clock. If I have a problem, I’m either solving it, devising a pseudo-solution that solves it for the situation I need, or moving past it and calling it a learning experience. There are numerous questions on there that go unanswered for long stretches of time, and maybe my thinking is flawed here, but taking the time to write out and explain my problem in full could very well be a larger waste of my time than solving it another way or just moving on.

We were supposed to challenge this week (tomorrow), which meant pitching our three game ideas and prototypes, so that we could move on to the next stage. While I don’t mind another week of working on all 3 games, I feel as if I’ve let my group down, as if this failure is my fault, despite Matt (the designer) and Tucker (one of the artists) putting in a large amount of time of their own to the snail prototype.

I’m not entirely confident moving forward with the snail game, but I want to be. In our vision of the game’s completion, it can be loads of fun, and if we can get past the initial hurdle that is physics movement, then we’ll only have all of networking and multiplayer to hate ourselves with. But actually, this game could be really exciting to play and develop. I’m reserving final judgments for next Sunday, after we’ve given the games another week of tweaks.

More to come then.

The Painting Prototype

Let me tell you, I am actually excited for this game, or at least working with Unreal’s blueprints.

At first, I was worried when I looked at Unreal’s C++ side, and while I could take the time to figure it out, the blueprints system is packaged so nicely. Plus, even though you can use it without having coding knowledge, coding knowledge makes the entire system make much more sense than trying to learn it from scratch.

But enough of that, more importantly is the prototype. First off, Painting Game (as we have so affectionately labeled it as of now) is a first person puzzle game wherein you as a character are trapped in a Gothic/Victorian mansion, and aside from the mansions strange use of locked doors and gates (which prevent easy access throughout the mansion), there are an abundance of paintings scattered around.

You also have the convenient ability to dive into paintings and from a 2.5 dimensional sidescrolling perspective, can navigate through them to travel to surrounding paintings, such that you have the ability to get around those pesky gates and locked doors. Eventually, you’ll even be able to travel through walls using this painting network.

So I had to develop the ability to a) move paintings around, b) dive into paintings (which was the bulk of the work, and c) travel between paintings.

Moving paintings was the beginning, and after I had finished, I had this to give to my team:


Which was pretty basic, but only the start (to be fair everything in a prototype is basic, but you gotta have fun with it).

I messed with line casting and impact normals to get the paintings in the proper positions they were supposed to be in.

The big part came when I wanted to dive into paintings. I realized I had to create a mini-me and give it a different control scheme, which wasn’t actually that bad. The part that caused me a while of trouble (incoming trigonometry), was getting the mini-me to move left/right in the proper direction I wanted based on the rotation and normal of the painting. I won’t go super deep into the math, but there were some conditionals and a lot of taking the rotation around Z (up/down axis) and converting it into a useful sin/cos unit circle type values so “moving right” was always the players right, despite right not being the same as it was previously.

Then I had to let players travel between paintings, and for that I decided on a simple node system (which turned out to work with an advancement we chose later on), wherein each painting knows what paintings are around it, and hitting a given panel of each panel will take you to the next one (e.g. Hitting the right panel of a painting will travel you to the painting to its right, fairly straightforward).

This works with a hook system we’ll implement later, where painting hooks will always be static, and while paintings may move, the hooks will not, so the hooks will always know who their neighbors are, and we’ll be able to access two paintings information by asking their hooks to contact each other.

To wrap up, here’s a slightly more comprehensive version of what I was able to get done by the end of the week (and it’s not too bad if I say so myself):


More to come next week!

Delving into Unreal Engine 4

For my first week back, we were immediately tasked with coming up with 50 different game ideas. Luckily, our group had prepared, and over the summer we had generated about 35 ideas of our own, well before realizing we’d need 50. Thankfully, this made the remaining work relatively minimal.

Then of those 50 ideas, we as a group decided which select few ideas that we particularly enjoyed. On a scale of 1 to 4, with 1 being, “No one likes this,” and 4 being, “We all like this,” we narrowed it down to 5 game ideas that we ranked as a 4, and then chose another 4 or 5 that we ranked as a 3.

Immediately the artists set off doing concept art, and our designer began to work on the visual design documents. With so many ideas, we concluded that creating a prototype for any of them would be less than optimal, on top of the more important fact that I have yet to deal with Unreal as an engine before. Thus it was decided that I would dedicate this week to learning the ins and outs of Unreal, or at least the basics to get me started.

And I think it went pretty well. I spent effectively 10 hours of my Saturday just tinkering around, seeing how all the syntax works, and how everything is organized.

I talked with a friend of mine who had graduated, and we agreed, Unreal’s blueprint system would be a better candidate for the quick prototyping that my team will be doing over the next coming weeks, as opposed to writing C++ code.

Additionally, Unreal’s blueprints make networking simpler, as the code is done for you (and while I am one who desperately likes to know what is occurring on the back end, all of Unreal’s code is available to peruse, should I need to), and I did spend approximately 5 of those 10 hours just trying to determine the networking code.

We may not even do a networked game, but it is a topic I have an interest in. I spent last semester mostly doing networking for our game 2plicity, despite the dumpster fire that Unity’s networking system (or lack thereof) caused.

But in the event that we end up creating a multiplayer networked game, I wanted to be familiar. I did get a solid start, having a replicated object spawned and destroyed by the server, but I wasn’t quite able to get the client object to move, only the server. My friend from before clued me in that Unreal’s playercontroller is likely the reason for that, and the next time I have a go at it I will take a look in that direction.

For now there’s class tomorrow. We’ll see what ideas people take interest in, and how we decide to move forward.