Final Thesis Project!

Finally this blog should start being normal updates on a single game, rather than a different game every other post.  So without further ado, let me introduce Sensory Overload.  A FPS with 360 degrees of vision.

Before I share the video, I would like to explain a few things.  In the center screen, you will see your main front viewing camera (normal 90 degree FoV).  This is all most FPS show you.  To the sides of that, you will have your left and right cameras, respectively.  Then the rear camera behind that.  Above and below are the top and bottom cameras, just as you might expect.  Alongside those cameras, we have wall walking and basic networking, which would be the other Unity Capsules you see.


Wall walking was the first iteration beyond the 360 degree vision.  With that vision, on a standard single plan of movement (asides from jumping) you don’t find yourself looking up or down that often, so a third of the screen became useless in our game.  With wall walking,  you have to make use of that information to check for enemies above or below you.


Next week is GDC, so I won’t be updating, but after that I hope to get into a regular routine of updating this blog with our progress.  GDC HYPE!

Jiggle It!

The game I will be working on for the next couple weeks is certainly an… interesting one.  In this game you are controlling a piece of jello, jiggling.  It’s more of a very broad concept we have right now, and it could go in a million different directions.

One of the reasonings we are currently working with is verbs in games.  In any given game you are given a set number of verbs you can use to interact with the game.  Run, jump, shoot, etc.  We want to try and introduce another verb with this game: Jiggle.  Because who doesn’t love jiggling jello or jello-like objects?

Here is some concept art we are working with right now.


Blanket Fort Game!

Here’s my pitch for the Thesis Pitches:

First-person survival blanket fort building.

Don’t Starve’s survival meets LittleBigPlanet aesthetics.

Here is the pdf of our one-page design document:

Blanket Fort


Unfortunately, the Blanket Fort game didn’t move onto the next stage.  That’s fine, I had fun churning out this concept, and designing a pitch for it – not to mention the valuable experience it came with.

Instead I will be joining another game for the prototyping phase.  I’ll write more about this game in my next post.

The Beginning of Game Projects (Thesis work)

Hello again!  I’ll use this post to outline how our Thesis projects are going to work, and then outline what I’m going to be doing in a later post.

From what I’ve gathered talking to other students and the like, every year the structure of thesis projects is handled a little differently.  This year, we are using what our professors are calling a “double Hunger Games model.”  There are three stages to it:

  1. The initial pitches.  Everyone in the Cohort has to have their name behind a pitch.  This means they can either pitch a game by themselves, or team up with someone else to create an idea for a game to pitch.  This involves coming up with a game idea, creating a 1-page game design doc, and then creating (and doing) the pitch in front of the rest of the class.
  2. After pitches, the professors will give us input on what they think the strongest 10 game pitches are.  We will form teams to prototype those games, and will have about three weeks to do so.  The only limitation is that each team must have 3 of the 4 tracks represented (Engineer, Producer, Artist, Tech Artist).
  3. We pitch the prototypes to a panel of Industry Professionals, who along with our professors will narrow down the games even further (probably around 4 or 5).  We will form final Thesis Teams around these games, and work for the next year and a half of our lives on this.

Let’s do it!

Rapid Prototyping 4.4 – Final Project and EAE day

Firstly, we definitely become a little uninspired towards the end, mostly because we are all wanting to be done prototyping and begin on our thesis game, which we will start in about a month.  However, we do, as we say, have a thing.

Below is a screenshot of our final game – TronCano


I will point out multiple things in the picture.  One, we changed the objective from escaping the volcano to a collection game, where you want to collect all the gems (in the center of the screen).  We found that the main fun in our game was the exploration-eske fun of floating around everywhere while using the push and pull mechanic to stay alive and moving.  Secondly, there are sparks flying out of the glove.  This happens when you use an ability, and wherever you are pushing or pulling off of also create sparks (which is hard to see in this screenshot, but it is happening right under the gem.

Thirdly the platforms in the volcano are Tron boxes (hence the name TronCano).  We had more volcano looking rocks earlier, but it was decided that those rocks were far harder to see, and we wanted something that stuck out far more and were easier to see.  So we went with Tron boxes, which certainly fixed that problem.


This game was shown at EAE day (along with No Gamer Left Behind – see prototype 3 blog posts) today.  EAE day was a day where all the graduate students (C4 and us – C5) along with the undergraduate students presented their games to the community in an open house event.  for close to four hours we presented our and each others games to everyone that showed up.  The people that came ranged from people in the industry to various people in the community interested in our program and what we were doing.

This was a really cool experience, in that it not only allowed us to show off what we were doing, but it helped us learn how to talk about our games to all sorts of people.  We had to talk about our game to non-gamers, gamers, and people in the industry of gaming.  Both of the games that were presented that I worked on went over really well, and seemed to get positive reviews by everyone.  Although the level we had for No Gamer Left Behind was quite difficult (I did see at least one person manage to get the parity bonus however).


I’ll be back posting more on this blog in less than a month hopefully, when we start working on our main project – our thesis game!

Rapid Prototyping 3.3 – Problems with Blueprints

This will be a short post, with a short rant on Blueprints.

I think the majority of our engineers, if not all, agree that Blueprints is not a fun system to work with.  Firstly, and probably the worst part of it, there is little to no documentation.  It’s a new system, and it seems that not many people have used it.  In stark contrast to Unity, which has amazing documentation, and the community has solved nearly every problem I have encountered with it.

It took me and another engineer close to three hours to figure out how to make a simple main menu that would send the user to the first level.  We ended up stealing a blueprint from one of the sample projects in Unreal that already had a menu, and to be honest, I’m still not sure how it works.


Rapid Prototyping 4.2 – With every pitch comes a new iteration

Last Thursday we pitched our idea to only our instructors (a closed pitch, instead of in front of the rest of our peers), and we came back with a modified version of our game.  Mainly, we removed networking.  While it was easy to do, and actually already done, it didn’t add anything to our game.  A key concept that was pointed out with co-op games, was you have to be careful where the fun in a co-op game is.  Is the game itself fun, or is it fun because you are doing an activity with another person?  Furthermore, multiplayer games are harder to playtest and show off.  It’s hard enough to get someone to play your game, let alone get someone to find someone else to play your game with them.

Maybe our game would be a lot of fun with another person, but to lower our scope and first test the mechanic itself in a single player game.

Now, as far as Unreal goes, it seems there are two different ways to use it as an engineer.  We can use the C++ language to code it.  Or we can use their Blueprints system, which is a Scratch-like systems where you connect nodes to create scripts.  It seems like we are going to attempt to use Blueprints.

So here is where our current game concept stands:  We are going to make a single player, 3D, puzzle platformer where the player can push and pull off of objects to navigate the level.  We are planning on making the level inside a volcano that you are trying to escape.

Rapid Prototyping 4.1 – Dream Team Assemble

As you may be able to tell from the title, this prototype we get to pick our own teams.  I got lucky last prototype with an awesome team, and this team will be just as awesome.

We are using Unreal Engine, which is also extremely exciting.  I am hoping that it will be better to work with than Unity (but am doubting this).  And keeping with the theme of dropping us off on our own, we simply have to “make a game.”  That is our only design restriction (aside from Unreal).

We formed a team of about 6 people, and began pitching ideas.  This is all we did throughout our meeting time, and eventually were trying to pick between a couple different ideas.  It was at this time that another small group approached us, of about four people.  They were looking to join a group, and as it happens they were wanting to make a game very similar to one of the games we were currently thinking about.

The game is a 3D co-op puzzle platformer, utilizing a push-pull system.  One player will be able to push on objects (including the other player) at range, and the other will be pulling.  They will use this to navigate through our level.  Now, if you’re reading this and coughing out the word “scope”, seeing as how we have to tackle networking, multiple mechanics, work in 3D, learn unreal, AND do a ton of level design.  However, Unreal makes networking trivially easy, and one of our producers has a bunch of experience with level design.  We think we can pull this off.

Rapid Prototyping 3.4 – This went better than expected

So, to sum up the previous post, we basically spent the first two weeks of this prototyping getting nothing accomplished.  After that we finally decided on a game.  And you can see that game in the following gameplay trailer!

I am happy with where we ended up with on this prototype, especially after such a rough start.

Many things were learned, such as how to properly use a design box, the true beauty of iteration and prototyping.  And there are plenty of goals to be achieved on the next round, primarily for me: being more available during non-work hours.