What Remains: Jam Development Breakdown

One of our Minion Studios team members stumbled across a game jam called the Asylum Jam. It takes place over Halloween and is themed around horror settings which do not involve negative mental health or medical stereotypes.

Mostly because it sounded fun, and slightly because all of us were a little burned out on our Skurvy project, we decided to take a break and enter the jam. We had a fantastic time working on Minimalist Horror Story, our first game and game jam participation, so working on another horror adventure in such a short time seemed like a great diversion.

We kept the concept very loose and simple. There was no real story revealed to the player, though we had decided amongst ourselves that the player’s character had been at a party where someone had summoned some sort of Lovecraftian horror into the house. All the other party members had been killed or injured. The player wakes up alone in the mansion, and has to explore the darkness to survive. This end goal turned into a fetch quest for pages of a mystical tome that could banish the creature and allow the player to escape.

Most of these details ended up on the cutting floor due to time constraints for the jam, but we have developed the game quite a lot further after the jam was over to add many of them back in. In the final jam entry, you could explore the mansion, finding keys to unlock doors, restoring power to the electrical system, and finding pages to the book. Once you took the completed book to the library where the ritual began, you could reverse the ritual and end the game.

While exploring, you are threatened by the horror as it manifested as 3 different entities. I’m not sure who came up with this idea, but each of the entities has a different attack method, patrol route, and behavior. The original intention is that each of these would spawn and de-spawn randomly around the house, so you weren’t sure what you what you would be dealing with all the time.

The player was to have gameplay options for avoiding the entities, including crouching to sneak and a hold-breath mechanic when hiding. We wanted to add hiding-in-object mechanics similar to games like Amnesia or Alien: Isolation, but did not have time to complete this.

Because of the loose rules of the jam, we decided to take advantage of a large library of assets we had created for a previous project we had abandoned. Eric still had to clean these assets up quite a bit, but it did save a lot of time for putting the mansion together. He did a fantastic job of producing new assets at an insane rate as well.

Sonny took care of all of the AI for the game, including tackling a lot of problems with how they move up and down the 3 different staircases. He used the RAIN Unity asset to create the behavior trees and pathfinding.  Damon handled the player movement, 1/2 of the environment interaction, and setting up the player object.

I set up all of the game menus, created the other half of the environment interactions, and did a lot of work on the level, such as occlusion culling baking, after Eric populated the mansion with his assets. I’m going to restrict most of the of rest of this post to the the work I did.

You can play the game here:

 

http://gamejolt.com/games/adventure/what-remains/37075/

A Small Glimpse

How much fun is walking through a scary mansion that you can’t interact with? None at all. This was going to be my largest contribution to the project, but I still had to build the menus as well as all the test/completed builds of the game(I am the only one of us with a Pro Unity license). So, I tried to build something that would be extensible but also simple to up and running quickly.

We knew we wanted most of these interactions to make our jam deadline:

  • Open/Close doors
  • Key/Page/Item pickups
  • Unlockable doors
  • Light switches
  • Fuse box switch
  • Summoning Circle

Damon and I have worked these two sides of the interactive coin before. First with The Brass Bastards, then later with “Multi-Horror”, then aforementioned abandoned project. Each time we had settled on a class type that the player script would look for in order to interact with an object.

Basically, one of our player scripts would raycast from the camera forward into world space. If the raycast hit an object with an Interact tag, then the script would check for input from the player. If the player clicks, then the script checks for the Interactor component on the hit game object. If found, it then calls the prescribed DoAction method on that object.

We like this method for simple projects like this. It keeps the work of the two systems separate, and it’s easy to communicate where the systems will intersect and how that will be implemented. Even though we use Git for source control, in most situations we prefer not to step on each other’s toes, especially during jams when code, levels, and assets change so quickly.

A major downside to this is that it’s difficult to test completely. Until he has a player he can share and I have an “Interactor”, we can’t really test a lot of the gameplay until late in the jam. This is compounded by the varying schedules most of the team members keep during the jams. Some of us stay up late at night, while others are more day people. Finding good times to integrate and test code and other assets presents a challenge.

This isn’t probably the best way to do this or the easiest, but it works for us on these quick projects.

For this game, we had an added problem of inventory. The player should be able to pick up different keys and multiple pages. In The Brass Bastards, you could only really pick up a single cog “key” at a time, so the design stayed simple. To address this issue, we decided that the player would maintain a list of items that he was carrying, and would pass this list to the DoAction systems every time interaction occurred. We also split the system into to parts, Items and Interactors. Items were anything you could pick up, and they had their own tag, classes, and method call. Interactors were everything else, including doors, light switches, and the fuse box.

When you pick up a page or a key, the player script stores a reference to the item in its inventory list, then calls the PickUp method on the item. Depending on the item, different things occur in this method. Some send messages to the UI, such as “You still need to find 4 more pages.”; others may trigger sounds and/or animations. All of them disable the renderer of the item so it no longer appears on the floor or table or wherever you found it.

The most important part of this system is that besides adding the item to the player’s inventory, the player script doesn’t care what the item does with itself. This is even more important for Interactors, because they do so many more things.

Interactors are called by through the DoAction method from the hit game object in the player script. After processing the action, the DoAction method returns an ActionResult, which handles things like error messages or flag if an item was consumed with use. The player object passes a list of Items that represent the inventory the player is currently carrying. Some Interactors, such as a light switch or unlocked door, don’t care about what you are carrying. Locked doors and Summoning Circles do.

For those that do, the first thing many of them did is search through the list of items for the necessary carrying requirements, such as a particular key or all of pages of the Tome. It then carries out the action, which usually involves playing sounds and animations, then returns the ActionResult.

All of the Interactors in the game extended this base abstract class:

 

As we continued to work on the game, I think I can actually remove two of the DoAction declarations. Damon actually always passes an inventory list to the DoAction method, whether it’s empty or not. I can’t really think of any use cases with our current system where we would need to call these without an inventory list or with just a single item.

For the most part, this is very simple stuff. Of course, because I wrote so much of the system before properly testing it with the actual player code, there were a myriad of bugs, though most of it were in the UI systems we pieced together last minute. Still, if we do another jam like this, my goal would be to get a lot of this core gameplay code written and integrated in the first 12 hours. This leaves the other 36 to test and polish.

Overall, the environment work I did turned out pretty well, and I’ve continued to improve the code and functionality over the last two months.

Successes

  • We released the game, albeit a bit late.
  • Most of the systems came together easily without a lot of bugs. Monsters eat you and doors open.
  • The visuals are impressive and atmospheric.
  • Occlusion culling seemed to work great for this level. It reduced draw calls and improved performance. Eric has since optimized a lot of meshes, so the payoff isn’t as great, but still it was a simple system to get up and running during the jam and helped us shave some corners.

Failures

  • Real life interfered on some level for all of us. It’s frustrating, but I don’t see how you can change this. We are adults with busy lives, and it’s hard to commit a full 48 hours to a single event like this.
  • Communication breakdowns occurred frequently. Mismatched schedules, sickness, family…all of these made it difficult to coordinate the project.
  • No early build. We keep talking about doing earlier builds that we can test and play, but it seems like gameplay gets finalized as the game entry is being submitted. This has to happen much sooner.
  • Builds that supported low quality settings made it into the wild. There’s a fantastic video of the game running without proper lighting/shadows. Looks terrible.
  • Too many gameplay features hit the cutting floor, including hiding, true sneaking, and breathing mechanics.
  • Jump scares and a lot of atmosphere didn’t make it into the game.

 

Here’s the gameplay video on low quality settings:

Final

While our ambitions fell short, we still made a good start on a game that we will continue to develop into the near future.  Our hopes are to release a new version with Physically Based Shading and a large amount of added content. We have been working on a lot of these improvements and hope to bring them out soon. I will be working on a follow up article about the new power grid system that I wrote for the new release.

 

Review: Unity Multiplayer Games by Alan R. Stagner


Disclosure: I was sent a free review copy of this e-book by the Publisher.

Format:

I made use of both the PDF & Kindle versions of this book while reading it. The PDF version displayed well on a Nexus 7 as well as my PC, where I used it to type in the many examples provided. The few graphics used in the book were mostly for configuration of Unity components, but all of them were in color in the PDF version.  I did most of my reading through the Kindle version.  It read smoothly on my Kindle Touch, and the code snippets displayed about as well as they can in that format.

Source code as well as errata are available for the examples in this book from the publisher’s websitePackt Publishing.  All examples are in C#.

Audience

This book is best suited for developers who have a working knowledge of the basics of Unity as well as experience using C#.  The author, thankfully, does not spend much time reviewing these two tools.  There are hundreds of other resources for learning Unity, and those should be explored before covering the topics in this book.  This book is a great introduction to multiplayer programming.  While a few intermediate and advanced topics are covered, it’s mostly geared toward beginners.
Continue reading Review: Unity Multiplayer Games by Alan R. Stagner

Knowyo.org Facebook Application

Client: Wyoming Department of Health

Where: The app primarily lives on knowyo.org and the Facebook page.

Purpose:  Increase STD risk awareness and encourage Wyoming citizens to get tested.

What I Did:  I built an interface using the Facebook SDK in PHP & javascript with artwork by our team at Adbay.com.  This project came together pretty quickly.  A user should login to the app through the Facebook canvas page or a standalone mobile version.  The application reads their friends list and compiles a “most likely had/have STDs” friend counter based on Wyoming STD statistics.  Due to privacy concerns, the application does not look at profile information for the user friends, nor does it make any assumptions about your friends and their STD status.  It is a very loose estimator that will hopefully encourage awareness about the users risk.

The primary challenges were addressing changes in the Facebook SDK between the creation of the app and launch.  This application went through many rounds of approval before launch, and Facebook changed not only how their developer management panel works, but also the pathways for deploying a canvas application on mobile devices.  Because of this, I had to create a stand alone web version of the application for mobile devices.

Ludum Dare 27 Entry: 10 Seconds of Night

Entry Link: 10 Seconds of Night

10 Seconds of Night was my second game jam entry.  The Minion Studios team and I decided that we had so much fun the first time around, we would give it another shot.  The theme this time around was “10 Seconds”.  We settled on the idea of being a werewolf for 10 seconds of gameplay, then switching to a human player for another 10 seconds.  During the werewolf period, the player would have no control over his character.  Instead, an AI would direct the werewolf to consume nearby villagers.  There would be a day/night cycle that reflected this.

I was in charge of getting the human player off the ground with camera/controls, some level design, and programming the interactivity in the environment.

Ludum Dare 27 Game Jam Entry Development Screenshot
After the first day of development

I initially started to design a world that was similar to Super Mario Galaxy.  I imagined that the whole level would be round and the player could run infinitely around this little globe that contained the village and the mountains.  I built a small demo of this, including a full character controller, but we weren’t getting the look/feel we wanted with that, so we opted for a flattened bowl, with the mountains forming a natural boundary for the player.

After the first day, Eric had create a huge number of models for me to work with including a character with animations.   I set up the animations for the characters in Unity, hooked them up for the player to our control system, and we were off and running around!  I also started working on picking up items.  I will admit I did waste some time here on making the smoke on the houses and the snow particle effects.  It was a lot of fun, and I couldn’t help myself.

Ludum Dare 27 Game Jam Entry Development Screenshot
Another shot of our hero in the woods outside the village.

The original concept involved a lot of interactivity, including collecting items that would allow you to cage or inhibit your werewolf self.  The only working item in the game is a Hemlock plant which will basically poison you.  This is considered a winning outcome in the game.  I also created little word bubbles that would pop up over the villagers heads with randomized phrases stored in a text file.  These would hopefully give hints as to how to win the game.  We did add a lamb shank.  You can pick it up, but you can’t use it.  It was supposed to allow you to prevent the werewolf from feeding on villagers by distracting him for the night with the shank you drop.  We also envisioned having game mechanics for if the player is spotted while transforming into the werewolf.  Any villagers left alive after you transformed back into a human would try to kill you.  We unfortunately did not have enough time to implement this.

Ludum Dare 27 Game Jam Entry Development Screenshot
Problems, Problems, Problems

We built this project before our team was really comfortable with using a version control system and Unity.  We have since corrected this by teaching the whole team, including our artist, how to use Subversion correctly within the Unity workflow.  Not having this in place for any of our jam entries has been a huge hindrance.  We’ve had problems like in the screenshot above when migrating assets.  The materials on the body parts and blood particles from the werewolf kills were disconnected from their game objects during the transfer.

We also ran into a multitude of other stumbling blocks:

  • Lighting: I wasted quite a bit of time by trying to mix dynamic and baked lighting.  During a game jam was not the time to play with this.
  • 10 Seconds:  10 seconds was a great amount of time for the werewolf to slaughter villagers, but it was not good from  a player time standpoint.  So, we adjusted the human time to be 30 seconds and the werewolf time to be 10
  • The majority of the gameplay did not make it into the game.  We wasted time on other pieces that should have gone into making a fun game.  Instead, it’s kind of boring to play.
  • The werewolf & villager mechanics were created by another team member.  He and I did not collaborate much until the last minute.  If we had combined our work earlier, we would have been able to accomplish a lot more.  Also, he lost 24 hours worth of work in a computer crash, so that sucked.
  • We should have tightened the design to begin with.  We make this mistake constantly on jam projects and regular projects.

Overall, I had a great time making this game.  I had higher hopes for it, but I learned so much I definitely don’t regret the work we did.  We really grew as a team with this one.

Ludum Dare 26 Entry: Minimalist Horror Story

Entry: Minimalist Horror Story

Minimalist Horror Story is our entry into the Ludum Dare 26 Game Jam.  The theme of the jam was “Minimalism”, and required our team at Minion Studios to create a game around this theme in 72 hours.  I am not sure what ideas we passed up for this one, but I know Sonny suggested doing a horror game at some point.  All of us jumped at the chance to design this game.

I was in charge of level design and the character controller.  Sonny was in charge of the monster as well as creating a random spawn system for pickups.  Eric was our amazing artist on this one, doing animation and all of the models.  Damon added the particle effects in the house and the candle lighting.

I began the first night by working on level design.  Eric had made a rough sketch of the house when we initially started the jam.  I took his sketch and mocked it up in Autodesk Homestyler.  I am not sure where we can up with the idea to greybox the level.  I almost feel like it just sort of happened without us thinking about it.

Once I had the floors laid out in Homestyler, I built the level in Unity using the default cube game objects scaled to the size of my walls and floors.  This was my first time doing this in Unity, and also only the second time we had used Unity to make anything.   The levels came together very quickly, and we found out some problems with our layout right away.  Once we had adjusted the layout and scale, I used a script I had found on the Unity Wiki to export the layout as an .obj file.  Eric then imported this into 3ds Max and cleaned it up to create the final levels.

He added the basement and the attic, then exported them back to me to place in the game along with all the furniture.  One problem I ran into is that all of the furniture was exported as subobjects of the house.  I did not know a lot about prefabs back then, and I royally screwed up by not using them to create all of our duplicate objects.  We use almost everything more than once in the house, but many objects do not retain their scale.  I also should have used prefabs to create more interactive items like the dressers, etc…  After this project I learned a lot about Unity and how to maximize your output with things like prefabs.

I created the character controller in an empty environment on just a plane, then move it into our level once the basic features were completed.   I messed up some math as some point, as I made it very unforgiving when trying to interact with the environment.  Often times, you have to be very far away to interact with an object, as up close it just doesn’t happen.  I did not have time to fix this before we finished the jam.

I wired up the scares.  I would have done a lot of these far differently.

  • The footsteps scare at the bottom of the stairs needs to happen sooner.  I was hoping it would be a queue to go back up the stairs to check it out.  Most people just ignore it.  As such, many miss out on the attic.
  • The rocking chair scare happens too far away from the chair itself.  With the limited lighting, players don’t often see the chair moving and can’t figure out what the sound is without the visual context.
  • The furnace needed to have sound added to it.  We just ran out of time to hook it up.
  • The bats took way too long, though they are effective.  I wish I would have known how to use the animator in Unity.  Instead, I hand coded all the vector points the bats should follow and interpolated them along the points.

There were a lot of other mishaps, like the candle burning sideways instead of down and the wrong control scheme being listed in the instructions, but I am still very pleased with how this game turned out.  We placed 7th in the Jam’s mood category, and received hundreds of comments, both positive and negative.  Eric posted an entry for the game on GameJolt.  We never posted the game itself, but discovered that even 9 months later a lot of people were still playing it and were interested in what we were up to.

This was the first game I ever completed.  We had a lot of false starts before this, but this game had a beginning, end, and a fun/scary in-between.  I am very excited about the feedback we got on this.  From comments on our social media channels, to youtube videos of people getting scared and jumping out of their chairs.  It was an incredible experience and sealed my pursuit of a game development career. 

Here are videos we’ve found of people playing our game:

MuviStar Rewards Program

ClientMuvico Entertainment, L.L.C.

Where: muvistar.muvico.com

Purpose: Design customer facing software that would interact with the Ticketsoft Loyalty API to allow theater customers to access their earned rewards.  Also, provide theater management with a content management system for editing users data and collecting reports on loyalty usage.

What I Did: I used the CodeIgniter PHP framework to design a complete content management system for this client’s loyalty program.  It interfaced with the Ticketsoft servers to provide customer data, to allow managers to add points and rewards to customer cards, and to show a transaction history for each customer.   I also integrated Facebook Connect for customer logins.

muvico2

I also designed a javascript animation for the rewards bar as well as a popcorn bucket that fills up with popping kernels based on your point level.

Challenges included dealing with one of the largest theater clients we’ve worked with as far as transactions per day.  The client required a large number of additional features beyond our usual Ticketsoft integration.  This meant tuning the database and PHP configurations to optimize the implementation of these features.  We also moved this site to cloud hosting.  It was the first of our loyalty clients on this type of hosting.  This required changing the application to work in a Linux environment versus the Windows server it originally ran on.