See summary below.

Promotional Campaigns

We’ve been doing a lot of research on ways to promote our game next year, including the Indie MEGABOOTH at PAX, Kickstarter and Steam Greenlight.

It’s an extensive process to get accepted into the Indie MEGABOOTH. They look at not only your game but also your company, its members, and how you contribute to the community.

It’s currently too early in development to come up with a solid plan, but here are some preliminary goals:

• Launch a Kickstarter campaign in the summer. The funding and publicity will allow us to extend development, add more features, and build a larger follower base in preparation for release.
• Attend PAX in August.
• Release game at the end of August. Selling in August means we avoid the hot beds for AAA studios to release their games, which is around the September to December time frame. Selling in August also allows us to take advantage of seasonal and holiday promotions, such as Thanksgiving and Christmas.

Our artist, Conrad Fay, will be joining us around February. Artwork will be a huge marketing point for us and will influence our plans significantly. In case you didn’t know, Conrad designed the knights. You can check out more of his work here. It’s the kind of art that makes you feel all giddy inside.

New Camera Controller

The camera controller for the Epic MegaJam prototype was very simple. Since the game was played locally, the camera was always centered because the screen was shared between all players. Unfortunately, you would have issues where the camera view stretched out if the players were really far apart.

One idea we had was taken from the Super Mario Bros. game for the Wii, where any one player that fell behind would be encapsulated in a bubble and float towards the other teammates. If similarly applied to our game, this would help deal with trolls, people who refuse to progress with the other players, and players who are struggling to make it through the dungeon.

Other the other hand, if the players decide to move backwards as a group, e.g. explore a hidden pathway, the camera removes the constraint and moves with them.

This new camera controller has two components: the camera itself and a giant box collider that keeps track of the players. If a player walks out of the collider, the blueprint activates the kill switch and teleports that player directly above another player. It’s currently very crude; eventually, we’ll have respawn points on the ground.

The camera controller determines the “forward” direction for the players using the information provided by the level. As you may have seen in a previous post, the level is comprised of sections (pathways and minigame rooms). Each section has an entrance point and exit point. The camera uses the exit point as a way to determine which direction the players should be heading—the “forward” direction.

As the camera moves with the players, each new room that is entered by a player updates the camera with a new exit point to track as the forward direction.

New Enemy AI Using Navmesh

UE4’s visual behavior tree is really simple and works amazingly. That being said, our little eyeball chain chomp fella from the prototype now uses Unreal’s “Behavior Trees” rather than just following a script that tells it to move towards the players using a Lerp function (which causes it to move through walls and floors). All we did was follow a simple tutorial here, which fit our needs perfectly.

One thing to note though, is that you need to be careful when inputting coordinates for using the “Move To,” or “AI Move To” node in the AI system. That is, if you input a coordinate that is slightly above the ground, the AI will refuse to input that Move To command and instead stands still. It took me an hour to realize that the AI wasn’t returning home because I put him a couple units too high above ground in the scene.

Procedural Generation

Procedural generation went through a slight tweak in order to make it more efficient. As it currently is, the procedural generation works by spawning the room, having the room run it’s construction script (which changes the variables the procedural generator needs to place the room correctly), calculates the positions it needs, and moves the room to it’s final position. With this version of procedural generation, every single mesh in the room needs to be dynamic, and as I’ve learned recently this can cause performance drops if we use dynamic meshes instead of static meshes for things like landscape and scenery.

So to fix this, we split the spawning and moving part of the procedural generation into two parts. We first spawn a blank game object that has the construction script with all the important variables needed, then we calculate the positions of the entrance and exit, and lastly, we spawn the room directly at the final position calculated. This allows us to remove the “move the room” step, which static meshes wouldn’t normally allow us to do.