The Second Playtest(s)

Since the last post, I’ve been able to hold a few different playtest with some success. I think the changes made after the first playtest were positive, and took the game in the right direction. However, I do think that I’ve over-swun (which somehow, doesn’t surprise me) and now things tend to ramp up a little too quickly. This causes a few problems. One of these is readablility. It becomes hard to know exactly how many ingredients you have (pantry and hand) and wether or not you can afford a recipe with those ingredients. The other problem, is that once your pantry gets really stocked, ingredient cards become irrelevant - you can simply buy whatever recipe you want and the game becomes uninteresting.

I do think I need to take a step back and rethink some things. After the first playtest, ideas were quick and obvious - but I’m not 100% sure which route will be the best. Here’s a bulleted list of my notes from the playtest:

• Some objectives are still kind of high - the ones like “Beef Brigade” which calls for 6 ingredients in the pantry feel especially high

• After a while, your pantry gets so full that you can finish almost any recipe on your turn.

• Costs/Payouts feel awkward - we’re constantly making change for transactions

• Maybe there should be some sort of boon when you place a star on an objective card (take another action this turn, or take a level 3 upgrade, etc)

• Everything scales really quickly, it gets hard to know what you’ve got in your pantry/hand and what you can/cannot afford

• Objectives feel niche and hard to focus on. 

  Kitchen upgrades felt cool, but almost too wide/complex

From here, I think the process will be the same - some iteration and then another playtest. I do think that I’m going to try and mess with fewer systems between now and the next playtest. As a game designer, I’ve always said it’s best to turn one (or maybe two) knobs at a time - otherwise you’ll never know what made the difference.

A Few New (minor) Systems

I think at this point, I’ve addressed (in some regard) the big feedback items from the playtest. There’s only one left that I think needs some attention:

• Players end up with lots of ingredients that they can’t use. There are times where available ingredients just don’t match up with the ones needed for recipes, Player are then stuck with a bunch of dead cards in their hands.

I’ve had this same feeling in games like Ticket to Ride, I’ve got a million cards in my hand and no way to use them. It can be a frustrating feeling. I’ve added a four simple, always available actions, that players can take on their turns - one in particular to adress the overabundance of “useles” ingredients is the recycle bin.

The idea being that players can discard ingredients on their turn, earning +1 coin for each. Currently, I also have this costing a player’s action for the turn, so you wouldn’t be able to recycle a bunch of ingredients and then complete a recipe or go to market. However, players still can spend their coins freely on their turn whenever they see fit.

New Shipment will allow players to spend 3 coins on their turn to clear the market row. This addresses another small annoyance as sometimes the market row just doesn’t have the cards you want/need. I wanted this to be somewhat affordable so players don’t feel like they shouldn’t do it. I also made sure this didn’t cost an action so players could take a chance on clearing the market row before they used their go to market action to pick cards.

Tonight’s Special is a little bit different, but stems from the same frustration of a recipe row with poor selections. Players can spend 3 coins to remove 1 recipe from the recipe row. When replenishing, players place 3 coins on the new recipe as an added incentive for whomever completes that recipe. I didn’t want players to be able to wipe the entire recipe row - I think that feels too chaotic for players trying to plan a few recipes in advance. But, I still wanted this to feel like something that could tip the scales in your favor slightly. Maybe you happen to have the ingredients for the new recipe and score the +3 coins? If not, then this action creates a bit of a race to see who can finish the bonus recipe.

Secret Menu is the last of the new, always available actions. This one is designed to help players that end up feeling stuck on objectives. Players can spend 18 coins (and thier actiong for the turn) to draw 3 new objectives, and keep one - returning the others to the bottom of the deck. I made this one much more expensive than the others. I didn’t want players simply drawing new objective cards unitl they get one that wins them the game. Considering the added cost of using a player’s action for the turn, I’m hopeful that this will be something done rarely, and toward the end of a game.

Aaaaannnnd, I beleive those are all of the changes that I will make before the next playtest! I’m hopeful that this next one will run smoother - and maybe we’ll actually be able to finish!

Cooking in the Kitchen

Last time, I talked about my plans/adjustments for fixing the slow start - the addition of the pantry and giving each player 4 starting ingredients. Today I want to talk about how I plan to address the next big issue (in my mind) from the playtest, kitchen upgrades. My note from the playtest was:

• Kitchen upgrades felt hard to obtain. The benefits offered by the kitchen upgrades felt good, it was just hard to pay for one.

Having had some time to think about this, I think there’s more to this than just that things were too expensive (which I still think is a big part of the issue). I think upgrade availability is also making it hard for players to pick one up. In the playtest, there were 5 upgrades available, when one was purchased, it was replaced with a new one from the deck. Only having 5 to choose from can be problematic in a number of ways - maybe a player doesn’t have a lot of coins and most of the upgrades are level 3, maybe the player has coins but the available upgrades don’t seem like they will help towards an objective. I have a new approach that I hope will make this easier!

In an attempt to solve this I'm first going to lower the cost of kitchen upgrades. Everything will come down by two coins across the board - from (8, 14, 20) to 6, 12, 18). I think I could take these discounts even farther, but I don’t want to overswing considering the other changes made to accelerate the game. Below is a peek at a few new kitchen upgrades with the updated costs.

Next, I’m going to change the way that cards are purchased in general. Instead of a faceup pool of cards to choose from (like the market), I’m going to seperate upgrades by level which players will purchase from a deck. When purchasing, players will draw 3 upgrades from the deck and select 1 to keep, returning the others to the bottom of the deck.

It feels like there should be less friction in this approach, and I’m hopeful this will encourage players to spend coins on upgrades earleir, and more often. Choosing from a shared pool of upgrades makes the choice feel like it has greater consequences - “Should I buy this one? Will something better come along?”, “Do I save my coins to try and get the level 3 upgrade or go for this level 1 card that I don’t really like?” To me, “Oh, I have enough coins for an upgrade - let’s see what I get!” is a much easier choice to make.

Solving the Slow Start

After the playtest, I’ve been working on ideas to help players feel like they’re able to start engaging with the game’s systems more quickly. One of the biggest issues from the playtest seemed to be tempo, overall. I think turns feel quick and snappy, but players aren’t really engaging until we’ve already made several trips around the table. I’ve created a new system I’m calling the pantry and redesigned the recipe cards to try and counter the slow start.

The most notable change here is the added pantry ingredient to the top of the card. This does not alter the ingredient cost of the recipe. After completing a recipe, players will now tuck the completed recipe at the top of their player boards - leaving the top row ingredient showing. That ingredient is now considered part of that player’s pantry. Pantry ingredients give players a permanent ingredient that can be used on their turn (and subsequent turns) to complete a single recipe. The aim here is to make players feel like their kitchen becomes more powerful as the game goes on - more pantry ingredients, mean more completed recipes, which means more money, more upgrades, and more completed objectives.

You’ll also noticed that I’ve made all recipe cards the same grey color. Before I had them colored by rarity, but it just seemed confusing - all of the kitchen and objective cards were all the same color, and it felt very orderly. I’m hoping that it’ll be easy enough to tell that the cards are more/less rare/valuable at a quick glance based upon the ingredients/payout listed.

I’ve also done a little bit of a redesign on the player’s boards. You can see that I’ve allocated spots along the top of the kitchen to tuck pantry ingredients. This should help players to keep their boards organized. I’ve also given each player four different starting pantry ingredients. I had toyed with the idea of giving players a starting hand of ingredients, but I opted (for now) to start players with pantry ingredients as they are permanent, and feel like they’ll make a more impactful start. I also think each player having a different set of starting pantry ingredients opens up some interesting choices on which recipes players will need to decide to work towards initially.

You’ll also notice that I’ve added a spot for objective star storage, and that there are now only 3 kitchen upgrades. I won’t get into it right now, but I’ll explain my plans for the upgrade adjustments in the next post!

First Playtest

Over the last month or so, I’ve been working on card designs, ideas, and mechanics for Food on Paper. Last week I had finally reached a state where I was ready to print out a bunch of the components. Over the weekend I was able to get Food on Paper to the table with some friends and my wife! This was very exciting for me as it was my first time ever conducting a playtest for a board game.

There was a lot to take in, and I received some great feedback. We didn’t actually finish the game, but I didn’t feel like we needed to - I have loads to process already. This is some of the common feedback I received:

• The game starts too slow. It takes quite a few turns before anyone has enough ingredients or coins to feel like they’re making any sort of meaningful decisions.

• Players end up with lots of ingredients that they can’t use. There are times where available ingredients just don’t match up with the ones needed for recipes, Player are then stuck with a bunch of dead cards in their hands.

• Objectives feel cool, but take too long to reach. We played for quite a bit an we only completed a few objectives each. The idea was that you’d be able to get all 5 objectives out in maybe 30-45 min.

• Kitchen upgrades felt hard to obtain. The benefits offered by the kitchen upgrades felt good, it was just hard to pay for one.

• Overall, it just took to long to get moving. This seemed to be the general consensus. There’s potential, but it just takes too long to get moving.

There’s a lot here for me to digest, but I already feel like I’ve got a bunch of ideas flowing that could potentially address each of these issues! I’ll follow up on changes I make in the coming weeks.

Food on Paper

I’ve always loved playing board games, but recently, they have started to garner more and more of my attention. My wife might even tell you that it’s becoming a problem (and she’s right - we are running out of space to store the collection). Working as a video game designer for last nine years has taught me a lot, and video games continue to be a huge passion of mine. But, I’m excited to see how much, or how well, my learnings from video game design actually translate to board game design. So what is this game?

Food on Paper (working title) is card drafting/engine building game in which players collect ingredients from the shared market in order to complete recipes. Completed recipes will earn coins that can be used to purchase kitchen upgrades. As players complete recipes and upgrade their kitchens they will be competing to complete “star” objectives. The first player to build a 5 star restaurant will be the winner!

This game borrows from other established games with well known mechanics and I’ve tried to keep it relatively simple. My goal is to finish this game, and as it is my first board game design, I think keeping the scope and complexity reigned in a bit will work to my advantage. I do have some ideas for a few mechanics that could be layered in (like a food fight!) if it feels lacking. But, I’m going to start simple, and build from there.

I’ll give a quick breakdown of each of the systems I have in place thus far, and a preview of what the components are looking like!

NOTE: I’ve designed all of these cards using AI art. This is meant to be temporary and will be replaced at a later time.

The Market

On a player’s turn, one of the actions they can take is to “go to market”. When a player does this, they will choose 2 ingredients from the market. These can be drawn from the five faceup market cards, or drawn blind from the top of the market deck. There is a “wild” ingredient (I’m calling all spice) that players are only allowed to draw one if drawn from the faceup market.

Recipes

After amassing some ingredients, players will be able to use those ingredients to complete recipes! A completed recipe will payout a certain amount of coins. The more ingredients used to complete a recipe, the greater the payout. Ingredients are dispersed equally (well, very nearly) across all recipes - so any one ingredient shouldn’t be more valuable than the next - all spice excluded.

Kitchen Upgrades

Players will be able to use the coins they’ve collected to purchase upgrades for their kitchen. These upgrades will allow players to draft more cards from the market, make more money for completed recipes, allow for substitutions in recipes, or more!

Star Objectives

Players will have a shared pool of objectives. If at any time during a player’s turn, they’ve satisfied an objective, they will place one of their 5 stars on the objective. The first player to place all of their stars will be declared the winner!

As Good a Time as Any

Well, it’s been a while since I’ve done this. The last blog post I created was in July of 2015 - and I’m pretty sure I was forced to do so as part of my classes at the time… But, perhaps as I’ve aged, I’ve also “grown up” a little. I’ve decided there’s merit to keeping a blog as a designer - if for nothing more than my own personal reference.

I’m not sure exactly where all of this will go, or what the content here will be like long term. But, for starters, I’ll be reporting on a game that I’m designing by myself. This is board game, which is something entirely new for me! I’ve already been working on this for several weeks, so the next few posts will be an effort to catch up to where I am currently.

The Adhesive Progress

With a couple meetings under our belts, things seem to moving along nicely! We've made a couple decisions early on that should really change the way our game will turn out. Everyone seems really excited moving forward with The Adhesive Project!

Unity 5

We are starting our build using Unity 5. Matt L believes they've made some changes to their physics engine that should make achieving what we want easier than it has been in the past. (so far corners have happened automagically!) 

3D! (on a fixed 2D plane)

Seeming as Matt B has been doing a lot of work lately with 3D, he really wanted to push for a 3D look. He has put together a few concept characters/scene props for us and so far everything looks great. We are really going to try and raise the bar visually this time around, and I think going 3D should allow us to make something that stands out. Now we are trying to decide on the best perspective for the game. Everything will be locked to a 2D plane, but we are playing with a few different angles... Hopefully we should be rolling on something soon!

The Backlog

This post contains essentially everything from my old blog at wordpress. It makes more sense to have everything contained here instead! Everything is here so feel free to have a look!

A New Hope

Having finished the semester, and graduation this coming Friday I thought I’d fill you in with what you’ll see from me in the near future. This Fall I will be attending master’s school at the U! I was accepted and I will be pursuing a master’s in game production! I’m super excited to start, and I’m sure you’ll be hearing much more from me on that soon.

Matt Lawton, Matt Barnes and I have decided that we are going to do a little work this summer building a game… or rebuilding I guess I should say. We had a project a couple semesters back which I had originally envisioned for mobile. We will be building “The Adhesive Project” starting this summer! We will be shooting for the App Store and Android marketplace!

This entry was posted on May 7, 2015.

A semester in review

Leave a reply

Week14

EAE FEST!

Well it happened. Everything went great! We showcased our game, We squashed all of our bugs, and we have a stable game free for download on Desura. Tons of people came through and played our game, and I talked myself completely horse again. I was really impressed with how well our finished product turned out. These last couple weeks have been tough, and I started to wonder if our game was going to be any fun (it was hard to tell since it had been mostly broken a lot), but it turned out! I’m really proud of our finished product.

I also showed our game to several people that were on the industry panel that I pitched our game to. It was really awesome to see how excited they were with how it turned out! I also got to describe some of the design challenges we had along the way and illustrate how we overcame them. There were others that had played before at EAE day last semester as well. Some of them had left us good feedback before, and they were happy with the changes we had made to the game. Success!

Parting ways with the team was kind of sad. I wasn’t really expecting it to be that way, but I think that was because I had absolutely no time to think about it… and when it happened it kind of caught me off guard. I really enjoyed working with these guys, and I honestly hope to stay in touch with them. There’s always a possibility that we could work together again in the future.

Week13

BACK ON TRACK!

Christian was able to get in touch with our contact at Desura and we have secured our original publish date of April 28th! This is good news. Everything is lining up for us. EAE fest will coincide with our publication and we will be officially out in the wild… it’s almost like we planned it that way…

That being said, we have some serious work to do still. Sunday is our VERY LAST day. No changes will be made after then. In order to squash all of the remaining bugs… Matt Lawton, Calvin, Ethan, Aaron and I will be meeting at high noon in the undergrad lab. Hopefully everything will go smoothly. I’m so naive.

Week12

So we’ve had an interesting development… Desura has accepted our game for publication, but they’re going to publish it in two days. That’s not exactly enough time for us to ramp up any sort of social media or media media push for publicity (and also the game is super buggy right now). Christian is trying to contact them to see if they can switch our date back to the 28th like we had originally requested.

Also, here’s the mock up I made for Aaron. I think it should make a lot more sense than what we’ve had in the past. Aaron seems pretty confident he can get it in.

Week11

Another successful showing! Matt’s AxeMan minigame was pretty killer! It’s been awhile since we had the entire class laughing out loud about our game during presentation. They were there for sure again.

Rog seemed to think that the voice work that I did for the AxeMan was pretty solid too! He said that usually student game makers are terrible voice actors! Ego stroked! Ha! Anyway… I digress.

Another thing that Rog mentioned was our UI. It needs some work. I’ve known for a long time that it doesn’t read well, and I had Matt Barnes redesign us something, but it ended up taking up way too much screen real estate. Aaron has offered to implement something if I can get him some sort of mock up and some assets… guess what I’m doing this weekend?

The team also had a little discussion today about publication dates. We’ve decided to push back to the 28th. This happens to be the same day as EAE fest. We need the extra time to wrap up.

week10

April 7th is right around the corner and I think this is the beginning of what they call crunch time? Yeah that sounds familiar right? Things are coming together better than ever before, but I still feel like we’ve got a ways to go.

I spent most of this last week RE-building the levels I had already built. Jeff and Richie have made a huge push creating shadowed assets for the game… Which honestly adds a lot to our game. Our assets don’t look so much like they’re simply floating around a shaggy green matt. It’s been a lot of extra work, but It’s been worth it.

I’ve been working with Aaron a lot as well. We are trying to get the multiplier functioning properly. It’s almost to the point that it makes sense.

This weekend I’m meeting with Kevin, and later with Matt Lawton. Kevin has been having some troubles with building his level (we scrapped the minigame level he was going to make as well). Hopefully He we will be able to get it all figured out. Matt and I are going over the AxeMan minigame. Matt seems pretty excited about it… and when he gets excited about something, it’s usually good!

Week9

Not a lot to report on this week.. We met for our recording session, which I think went great. I hope the recordings turn out. If they do, there should be some funny stuff in there… and if not, we had a good time recording it.

It’s also time to finish up the maze level. I need to talk with Calvin about AI behavior inside the maze… right now its… well it’s not good.

Week8

I felt a lot better about today’s presentation. We had a lot more positive feedback, and the game is starting to resemble something closer to finished. Rog emphasized that we need to start focusing on “juicing” up our game. We need to make it sexy… We need to find “cheap” ways to make it sexy. I think I’ve got a few things planned that should make it a bit more sexy. I’ve been talking to Matt Lawton about the dreaded AxeMan… He should make the game more interesting.

Meanwhile, GDC is coming up. Colton and Aaron will be going to present our game. I would have liked to make it, but I was unable to schedule enough time off. Those of us that are left behind are planning on meeting thursday to record NPC sounds. I’m pretty excited about it. I think we could have a good time with it.

Week7

We are officially business owners! Sort of…  I have registered us as a company. Questionable Roots LLC is real. After some research I have also decided to submit paperwork to get us registered as an S-corp instead of just an LLC. This should give us more “protection” if anyone should try and sue us. They won’t be able to come after us individually. They can only come after company assets (of which we have none).

In other news, we have decided that we are going to try and publish on Desura. We are shooting for April 7th. After looking into E&O insurance for publishing on Xbox (Xpensive), we have decided to shoot for Desura first. If we are able to pull that off pretty easily AND our game seems to be popular, we will make a move toward Xbox or possibly look for a steam greenlight.

Week6

After presenting today we got some really great feedback from Ryan Bown. It was great to get a some feedback from someone who hadn’t seen our game at all yet, AND someone that comes from an art background. He pointed out a few things that we could address in order to improve our game.

1. Line Weight: This is actually a HUGE problem for us. There hasn’t been any consistency in the size of the assets that the artists have been making. When I have imported textures and created prefabs, I’ve had to resize a lot of things in order to make everything fit and make sense (I realize we are talking about a game centered around a man eating tree). I sort of feel like I was made out to be some sort of asset resizing tyrant… but I stand by my changes. I really hope that Jeff can get all of the artists on the same page. We really should have set a standard size for everything BEFORE we started pumping out assets. Lesson learned… hopefully.
2. Art style consistency: We’ve had some style issues. We’ve got some great artists, but they definitely have different styles. We need to find something that everyone can emulate.
3. Possessor logic?: I have been thinking about this one and I think Ryan is right. Right now our “spirit” can possess benches, lamp posts, and trash cans. Ryan thinks that it would make more sense if the spirit could only possess living things, or plants… something that is closer to the tree. I think evil bushes make a lot of sense.

Week5

CRITTERS!

So we had a pretty awesome get together this week and I am excited with the route that we have decided to go. We have decided to address one of the complaints (not quite enough gameplay variety/stuff to do) of our game with a power up system. Matt Barnes suggested different types of critters that could be wandering around the map that the tree could eat. We had discussed power ups last semester, but we never had anything solid for implementing them. I’ve always pushed for more of an arcade like experience given the short scope we have. This should spice things up a bit. We nailed down 5 that we want to try and implement.

1. Invisibility or cloak
2. Bounty spawn increase
3. Multiplier boost
4. Wipe your noteriety (skunk)
5. Poisionous for and instant eat!

Week4

This weekend I spent several extra hours trying to finish up the quadrant level. I want to have something significant and new to show Bob and Rog next time we present our game. I have it mostly finished, but I’ve still got a little left to have it working smoothly. By the time we show it should all set. I’ve tried to make this level a little more “dense” as far as stage props go. I’m not sure if this is going to be better or worse as far as gameplay is concerned, but we will see. If it doesn’t function well, I can always thin it out.

For this sprint, our focus is on level completion and art. Our designers are working hard to complete our levels and our artists are scrambling to create new assets to fill the world and improving the pieces we already have in them. We need a lot of work done on NPCs specifically, but our artists are confident that they’ve got a workflow now.

On the production side of things, we decided to have standups like we did previously, but I volunteered to add the activity and updates to our paperwork (they weren’t really being done anyway). We’ll see how this goes for the future. Not every bit of Agile is valuable or mandatory to every team’s work process, so hopefully we find a niche that we can maneuver most efficiently in.

Week3

After showing this week, we were encouraged to start getting finalized art assets into our game. Bob and Rog seem to think that we need to be closer to something representative of our final build… (at least closer). We had some discussion, and Christian and were able to convince the team that we need to make some cuts. Mostly to NPCs that Jeff had planned. It is a shame that we have to abandon some of these, but I think that if we don’t, we won’t have something we can be as proud of. I think we will be much happier with 5 or so POLISHED NPCs rather than 8 or 10 that aren’t so good. Everyone seems to agree.

Also we went through everyone’s level mock ups and decided on 6 that we will build.

1. Basic Tutorial
2. Intro Level
3. Quadrant Level
4. Bonus Level
5. Bridge Level
6. Maze Level

At this point, I have offered to build the quadrant and maze levels (I’ve already built the intro level). Kevin will build the bonus level and the bridge level. Matt Lawton and I will work together on the tutorial level as it will be a little heavier on the programming.

Week2

I spent a lot of time with Matt Lawton this week, describing how the hollow trees on the map should work. He doesn’t seem to think that it should be too difficult a task to complete as he has already built the main character tree. The way he plans to tackle this would be with “active” and “inactive” states for the three trees that we will have on each map. All I will need to do when building the levels is designate ONE tree as the active tree. The others should be inactive by default.

I also talked with the entire team about the levels that we have “planned” for the game. Initially, we had talked about everyone building a level or so on their own… the problem with this is that not everyone knows how to build them. I had planned a weekend get together to teach those who didn’t know… but I think that this might not be the best course of action. I suggested that, instead, everyone bring me some sort of paper mock up of their best couple ideas. We will then “consolidate” the best ideas and I will build the levels for the team. Everyone seemed to respond really well to the idea, so next week I hope to have an idea of how many ideas I need to build.

Week1

Well, here we go again. It’s time to start another glorious semester laboring away at Creeping Willow. I was very pleased with the response to our game from EAE day, but there were some glaring issues that I feel need to be addressed… and with some time off, I believe I’ve come up with a decent solution.

The two biggest complaints we received stem from what I believe to be the same problem: The tree is too slow, and there aren’t enough NPCs to eat… Rather than jack up the speed on our tree and increase the number of NPC spawns (like the people THINK they want) I’ve a solution that should allow us to keep the stealth feel we are shooting for.

Possessable Trees! Placing multiple “hollow” trees around key areas on the map will allow players to traverse more quickly. If I am at the bottom left of a level and I kill or scare away all NPCs, I no longer have to slowly and painfully drag my roots to another hunting spot… I can simply enter possession mode, jet my way to a new tree, take control of it and let the feeding frenzy resume. I will spend some time writing this up in greater detail for the team.

This entry was posted in Uncategorized on May 7, 2015.

12/11 Alpha is finished, and EAE day!

Leave a reply

This was an exciting week! Everyone finished all of their tasks and we presented our final alpha to the class on 12/11. We were able to see what we wanted to fix/tweak before we showed the public on 12/12. Thursday night and Friday morning were a crazy blur of emails, tweaks to the game, builds, rebuilds to add just one more change, and then uploading them to our website/drive. We got it handled though, and we had a stable build ready oncreepingwillow.com and a spare .exe up in the drive just in case.

Tons of people showed up for EAE day, and everyone seemed to really enjoy our game! It was awesome to see so many people laughing and enjoying what we had spent so much time/love creating. We got a lot of good feedback! The one biggest complaint we encountered is the movement speed of the tree. We knew before hand that this was one of the challenges we would have to overcome, but I think we have an idea now of how to fix this. I’ll post more about it when I’ve written up something to describe it in depth, but I think it’s going to work. But to summarize, EAE day was a huge success for us! I spent so much time talking about our game that I totally lost my voice… and it was AWESOME!

Now I’ve just got a few things I’ve got to submit for class: a post-mortem, and a “wrap kit” for our alpha. I’ll be making a 90 second gameplay video with some commentary for the wrap kit. Christian will be typing up the rest of the documentation required, and Richie will be making a trailer for the game. We need to submit all of this along with an executable by Wednesday 12/17.

Over the break I plan on first taking a break, then I’m going to type up documentation for the change I talked about earlier, and also work on some new level designs. I think we’ve all earned a break! We will pick back up on 1/13!

This entry was posted in Uncategorized on December 14, 2014.

12/4 Tobiah Marks plays our game and THE ONE WEEK SPRINT!?!?

Leave a reply

On 12/2 we had a special guest come to class, Tobiah Marks. Tobiah works for Microsoft as a “Game Evangelist”. Which sounds like it should have a pretty confusing job description. Basically, he does everything he can to promote games and help game developers. He played our game and gave us some feedback, most of which was quite discouraging. He had a hard time knowing what was going on, which is understandable as we don’t have a tutorial. He also didn’t see any reason to play our game creatively like we have intended for our players. He wants something that is faster, and plays with more action… which is exactly what we shied away from earlier to focus on making a stealth game. Perhaps it is my fault, and I didn’t communicate well enough to him that this is supposed to be a stealth game. Or maybe he’s just not a fan of the stealth genre and needs more action? Either way, we aren’t going to be able to heed most of his suggestions, as they conflict with the core elements of the type of game we are trying to build. We will make sure that we make a tutorial that adequately describes why, how, and what the player should be doing.

On 12/4 we sat and discussed what we needed to accomplish before next week when we will be showing the alpha of our game at the EAE open house. The team seems to be feeling pretty good about where we are. We basically are feature complete as it is. We want to get a few other things in, and tweak the rest. The biggest feature we want to add is a high score system. Aaron is going to tackle that, and he seems pretty confident that it can be done before Friday! Here’s the email I sent out to the team that details all of their tasks.

For those of you who missed class today, be sure and read the assignments below to see what we need done for the final sprint! If you have any questions or need more detail, send me an email and I’ll do my best to elaborate.

PROGRAMMING:

Calvin – AxeMan tweaks/searching

Ethan – Alert NPC bar/tweaks

Aaron – NPC collision avoidance/High Score presentation

(You three know the details we discussed in class.)

Devon- When an object is possessed, we need buttons indicating the players possible choices displayed. Below is the mock up I made earlier. We don’t need the X and Y buttons displayed, and instead of “Noise” for the A button we want it to say “Activate”.

Also, can you apply the old particle system you had for the possession mechanic to the Bounty NPC? This way we will have an indication of which NPC is the bounty NPC.

Colton- Start planning/building an overreaching framework for the menus in our game(TitleScreen>LevelSelect>”HowTo”>ControllerMap>LevelObjective>Gameplay>Fail/Win>HighScore)

I’m going to build a few “how to” slides that we will want displayed when the player starts the level (for now). I will try and get those to you by this weekend along with a controller map that should go in the pause menu as well as be the last slide in the how to slides.

Matt L- Can you build a slightly different version of the mini game for when the AxeMan contacts the tree? Basically it needs to be the button mashing, then the sticks to the center, and then the last round of mashing. We are going to have the AxeMan go tree to tree when he is searching for the player and take a swing at each tree. If he swings at the player, then the first button mash will be to get the axe out of the tree. If the player succeeds at this, then the rest of the regular mini game will commence (with a higher difficulty). Hefe should have an animation of the AxeMan swinging his axe soon. Send me and email and let me know that makes sense.

Matt or Devon? Can one of you guys work on getting some small arrows for the control sticks in the eating mini game? We want them to always point toward the center to give players an indication of what to do.

ART:

Hefe – More NPC work. (Axe swing)

Richie – More trees/environment (Tree similar to player tree)

Kevin – Level Props/Repair existing level

Jon – Tiles/Water

Matt B – More Tree Work?

Evan – How to screens/button mash animation

I think that about covers it. Keep us posted on your progress, and let me know if you have any issues or need clarification. Christian will be sending follow up emails to harass as needed. This is it boys! THE FINAL SPRINT!

This entry was posted in Uncategorized on December 14, 2014.

11/27 Thanksgiving Break/Dark Side of the Moon

Leave a reply

We have decided that we will not be meeting as a team until the Sunday before sprint 3 is due for showing. This will be the longest that we will have gone without actually touching base with everyone twice a week. Christian has committed to harass everyone thoroughly to be sure their stuff is getting done until we meet again. With the document I created from last time, everyone has a clear task. Everyone seems to know what it is they need to do before Sunday 11/30.

Chapter 1 : Tilesets from Hell

Kevin and I met at the library on Sunday 11/23 to create a level each using the tilesets that Jon had created for us. Little did we know, we were in for a long night. We spent the evening building large prefab tiles from the smaller assets that Jon had created, and creating a snapping grid for them. This was fairly simple, but time consuming. After we had everything created as prefabs, we started building our levels for sprint 3… The problem was that we DESTROYED the frame rate of our game. Unity didn’t seem to be able to handle that many individual tiles on screen at once. After working for about 6 hours, we called it a night.

The next day, I spent a few more hours building larger textures in Photoshop to try and help the frame rate. I replace each prefab with a single texture, and I could see that the frame rate had improved, but it was still bad… Really bad.

On Tuesday, I was boarding a plane with my wife and 17 month old son to fly to Oklahoma for Thanksgiving with my in-laws.

Wednesday, I was back at it. I spent another 4 or 5 hours trying to make prefabs/assets that would improve the frame rate of our game, but I had little luck… I sent out an email to our programmers letting them know what was going on (a few were already aware). Before leaving Oklahoma on Saturday, I received an e-mail from Aaron… He fixed the frame rate! Apparently it had nothing to do with the assets. There was an infinite debug loop that was running for some unknown reason, and it was killing our frame rate. I opened our project, and it now runs as smooth as butter… or silk… or your favorite smooth substance.

Chapter 2: Welcome to my Home

On Sunday 11/30 I had a lot of the team over to my house to stitch together all of the pieces of sprint 3. Matt Lawton, Matt Barnes, Christian, Ethan, Calvin and Jeff commandeered my living room to devour chips, salsa, bean dip, and a delicious jalapeno raspberry jelly (and make our game function). I think this was a huge success for us. Before we showed our game for sprint 2, we didn’t really have the opportunity to make sure everything was in order. This time, a lot of problems we would have encountered were solved on the spot. A lot of conversations about what needed to be fixed were able to happen immediately, and in person.I think that our progress will be more obvious this time around.

This entry was posted in Uncategorized on December 1, 2014.

11/20 Plans for Sprint 3

Leave a reply

This week I spent a lot of time detailing the design plans for sprint 3. I’m hoping that with more detailed documentation there will be less guess work for our programmers (provided they read the documentation!). Below is what I presented to the team on Thursday 11/20.

Sprint 3

Programming:

Possession:

Press and hold A to activate. While holding A, the player will see a translucent indicator/cursor (eventually particle effects?).  The camera will leave the tree and follow the cursor.

The cursor will move much faster than the tree. The cursor will have a maximum radius in relation to the tree, similar to what we have in place with the lure now.

When the indicator is over an object, the player will release A to possess the object. The camera will then be locked to the object the player has chosen to possess. The played will see a small UI (top right corner?) that will list the actions the player can perform from this object. For now, A will “Noise” (which will activate the lure and cause the object to shake every few seconds until the lure’s timer expires), and B will “Return”, which will snap the camera back to the tree.

For now, let’s allow players to possess lamp posts, trash cans, and benches.

Notoriety:

When an NPC hits the panicked state, we need them to run off screen and escape. After the NPC has escaped, we need the player’s notoriety to increase by one. For now, when the player has increased their notoriety to 3, we will release an AxeMan. We can release an additional AxeMan for each additional notoriety point the player gains. We should also test a Notoriety cool down. Maybe you lose 1 point for every 3 minutes an NPC doesn’t escape.

AxeMan:

Enemy NPC that will need to behave differently than what we currently have. The AxeMan needs to behave like he is actively searching for the tree. For programming I’m not sure how best to approach this. What if he randomly chooses a point somewhere on the map, and then does a sort of sweep of that area. If he turns up with nothing, then he chooses a new point, and does another sweep? We could also make it so if someone on the map enters the alert state, that spot immediately becomes his new point to sweep?

The AxeMan would have the same alert state as the other NPCs, but instead of going into panicked mode after the alert question mark is filled, he would go into “KILL” mode. Kill mode would send the AxeMan straight to the player and trigger the fail state. For now, he can’t be eaten. For a later build, we could make it so the tree could grab the AxeMan and attempt to eat him, but we could make the eating mini game very difficult.

Camera:

Do we need to change the camera? I think the “Kill Cam” could be zoomed tighter. Maybe we add the bird’s eye camera that was suggested? Down on the D pad could zoom out, Up would zoom back to normal camera.

Other NPC tasks:

Right now we have a set path, wanderer, and a sitter? Which do we want to make next (excluding AxeMan)? How can we make improvements to how the NPCs are currently behaving? They seem a bit floaty?, and tend to get hung up on obstacles.

Rules for sprint 3:

Win state: Eat 5 NPCs without death by AxeMan. We should allow players to continue after 5 NPCs to try for a high score. Loss state: death by AxeMan

Colton, can you program something in the pause menu that allows players to see their high score? I’m thinking very old school arcade. Maybe even enter initials?

Scoring? 60pts for stationary NPC, 80 for path NPC, and 100 for wandering NPC.

6x multiplier “Stealth Kill” (NPC was never alerted)

3x “Dropping like flies” (Killed an NPC within 30 seconds of the last kill)

2x “Streak” (after killing one NPC, player killed another without panicking an NPC or raising notoriety)

2x “Over here!” (Killed an NPC affected by a lure)

Spawn Point Generator?:

This is something I think we should start thinking about. If this “survival” mode is fun, we need a way to increment the game’s NPCs in a way that keeps the game feeling fresh, and doesn’t allow for players to manipulate spawn points. Can we make the spawn points produce random NPCs?

Art: (I defer to Hefay if any of this doesn’t seem right)

Tree improvements:

• More menacing walk cycle
• Hinged arms for eating
• Work on colors near the seams for better blending
• Visual representation of the possession cursor

NPCs:

• More
• Maybe try to get one “complete”.

UI

• Soul consumed/other text assets
• Notoriety Bar
• Visual representation of cone of vision/circle of perception (very minimal opacity of the basic shapes these represent… we want them barely visible)

Environment

• What more do we need right now?

Design:

Kevin and I will build a new, bigger level. We will learn to create the paths/spawn points as well so we can have more control over what’s actually happening in our scene.

This entry was posted in Uncategorized on December 1, 2014.

Week of 11/13 : Refocusing and making a stealth game.

Leave a reply

These last two weeks have been interesting and awesome. We sat down as a team and talked about what direction we actually wanted to take our game. Everyone was really receptive and ready to make a stealth game —  “this is what we signed up for”. I read through the ideas I posted last week and everyone was on board and excited to move forward. After we had this discussion, the leadership in our team had a similar chat with Bob and Roger. They suggested we focus on taking the most bare bones version of our game that could still be fun and then build on that. We decided that for our next playable we would try to have the NPC “alert/panic” states fully functional, so our game will actually play like a stealth game. The scenario will be very basic: Eat an NPC without sending any of the other NPCs into panic mode. Matt Lawton also agreed to take on programming the new eating mechanic which should be in by Tuesday.

As far as design goes, I met with Kevin on Sunday 11/8 and we built a mock up for what would become the level for our next playable. I also met with Matt Lawton to have a look at what he had built for the eating mechanic. I was kind of surprised with how much fun it was, and I think the rest of the team was as well.

After the mock up was made, I took all of the “props” that our artist have made and turned them into prefabs so building levels later on should literally be as simple as click and drag.

(click to enlarge!)

I also had the programmers make some adjustments to the scale and speed of a lot of the assets in the game. The tree now moves very slowly like I had originally envisioned and the NPCs have been slowed quite significantly as well. This makes the game feel closer to the single screen feel that Roger imagined when we first pitched our game.

This weekend I didn’t have as much to do. I had to make some adjustments on the prefabs after Matt Lawton changed their pivot points in order to ensure that when the tree or NPCs pass behind an object on screen… they actually go behind it. Other than that, I also created some art assets for the NPCs. I created a ? and an ! to indicate NPC states. Calvin is going to try and get the yellow ? to fill with red in lieu of a separate gauge to indicate their awareness. If he’s able to figure this our I think our UI will be much cleaner. I will also make other indicators that we could flash above NPC’s heads to give direction, such as “EAT” followed by “LT and RT”.

I’ve also been doing a bit of reading to try and find inspiration/guidance on 2D stealth games. I found these two articles:

http://gamasutra.com/view/news/185860/Stealth_in_2D_Design_lessons_from_Mark_of_the_Ninja.php

http://gamasutra.com/view/news/175212/Reinventing_stealth_in_2D_with_Mark_of_the_Ninja.php

Calvin also sent me this video, which has a lot of good info:

This entry was posted in Uncategorized on November 17, 2014.

11/5, Showing our first playable

Leave a reply

Today we showed our build to the class for feedback. Here’s a link to the buildhttp://capstone.mattlawton.org/playable/ , and here is a quick summary of what the class thought sent out by Christian.

Notes:
–Floaty Movement
–Lasso aiming doesn’t seem intuitive
–James: “eating” is not fun. Looks and plays like “fishing”.
–Focus/Design: Stealth lure/trap game? Or ARPG? Better to focus the game style or accommodate others?
–Art style seems to top-down. Have you considered top-down?

Roger’s feedback really got me thinking. What is our focus? Our game seems to have morphed a bit into an ARPG and has lost some of what made it unique from the pitch. I think we are better off “taking a risk” as Roger said, and try to make something that is more focused on stealth. I think he might be right when he says that we have fallen into ARPG gameplay because it is what we know. I would much rather focus our efforts on making this something that is unique and stealth based rather than making “Tree-ablo 3”. I don’t necessarily think that we are way off the mark… but there are some things I think we could look into to make this closer to what we pitched.

• Abilities that aid in stealth, camouflage, invisibility, diversion etc. INSTEAD of abilities that turn you into a killing machine.
-One of my original ideas was to have a “mode” that the tree can enter where the tree has to mimic the movement of the other trees that are being blown in the wind in order to avoid being spotted. If an NPC has entered the alert state, blending in with the other trees’ movements would allow the NPC to return to neutral more quickly, or escalate them toward panicked if the movement clashes.
-Maybe a whistle? A common stealth mechanic that can alert/draw attention. This could draw in curious NPCs and scare off others.
-A cloud of spores that could temporarily incapacitate attacking NPCs and allow for a slow creeping escape to nearby trees. If players could then blend with the surroundings for enough time, then the enemy NPCs would go back about their business.
• Focus on making NPCs more interesting/challenging to eat.
-Variables for how quickly they go from alert to panicked
-Differences in “cone of vision” based on NPC type
-When entering “alert” state, some NPCs become more aversive, while others (like the AxeMan) become investigative.
-NPCs of different types could stop and converse for a minute?
-Groups of NPCs
• Revisiting the eating mechanic
-How can we make the eating mechanic something that won’t become mundane or boring? If our game is a “fishing” game then this needs to be the portion that we reel in our prey. I thought a lot about this, and how we could make it more closely reflect what is actually going on. If a living tree grabbed me and tried to eat me I would struggle. I would do everything I could to try and get free. Our prey needs to feel like they are trying to get free. I still like the idea of mashing one of the buttons for actually “eating”, but I thought it could be more interesting. I imagine pulling LT and RT to grab the prey that is in front of you. After this happens I still think we need to zoom in for a “kill cam”, but what if you had to use the left and right sticks to wrestle your prey into your mouth before you could start munching? I imagine an icon for each stick that has to be moved into an area near the trees mouth, and then the correct button to mash would be displayed. The icons would resist and try to move away from the center constantly, much like a struggling victim would. If the sticks move outside the area, then the player would have to move them back inside before they could resume mashing the button. We could change the button each time one of the sticks leaves to keep players on their toes. The sticks could easily exit the area several times in the devouring of one victim, since mashing a button quickly would require you to abandon at least one stick. I think this will make it so each kill is more rewarding, and instead of sending players out to eat 50 NPCs that aren’t challenging, we can send them out to eat 5 that are really challenging.

Mock-up of possible eating scenario.

This entry was posted in Uncategorized on November 6, 2014.

Super Ultra Mega Update

Leave a reply

Super Ultra Mega Update Disclaimer:

So I’ll be completely honest. It’s been a while since I’ve made a post… and A LOT has happened since then. I’m going to do some digging through my notes and bring you all up to speed. To honor the sacred blog format and to avoid (or create) confusion… I will start with this week’s “post” and work backward in time! This should be interesting…

10/28 – Halloween Week

This morning, to represent our group, I went to a presentation given by Scott Paul. I took notes and sent them out to the team. He gave some really great insight/info on using social networking to advertise for games… FOR FREE! Here is the bullet point summary I sent out to the team:

• Connecting with people that have a big following (influencers) is a good way to spread your game, however, we are never going to get “Pewdiepie” to do a video on our game.Instead of finding one person with 30 million followers, find 30 people with 1 million followers.
• Without social network promotion, most games won’t get much notice.
• Get youtube/facebook people involved early if possible. If we offer something (an NPC, voice or something in the game) then a lot of them are willing to promote games for free.
• Create a game that organically spreads itself. This can be done with a win screen that allows you to share. Flappy Bird is an example of how an arguably shitty game can be spread like wildfire using this method.
• We shouldn’t plan on a “grand unveiling”. Games are much more organic now, and it’s better to get SOMETHING out and repair/iterate later if we must

Another thing that was suggested is that we pull someone off of development toward the end of the road and put them exclusively on marketing. Just something to think about.

In class today, we touched base with Roger and Bob on where we plan to be for next Tuesday’s build. We plan on having movement/eating mechanics in place for the tree, five basic abilities, and five different types of NPCs up and running in some form or another. They seemed like they think we may have bitten off a little more than we can chew for this sprint… I hope we can prove them wrong.

10/24 – Organize and get to work!

This week was kind of crazy, and it felt a little disorganized… but I think it was necessary in order to get the team on one page and working. After some discussion we decided on what our key features would be. A LOT of stuff got sent to an “ideas backlog” so we could focus more on what is core to our game. Once we have something that serves as a good base, we will be able to consult this backlog and add new features as we continue to iterate on our game. After deciding on these features, Christian sat down with the programmers to discuss and give assignments. I did the same with the artists. Below is the schedule that Christian put together for us. He and I will be editing this as we move along and assignments change.

Jeff also threw us together a “secret” Facebook page. It’s going to serve as a platform for the artist to post new things they’ve created, and as a way for us to try and build a little hype for the game. So far everything I’ve seen from the artists has me excited for more!

10/17 – Fall Break

We have decided as a team to take the week of fall break to brainstorm and come up with ideas and concepts for our game. Hopefully we can come back ready to rock and roll!

10/10 TEAMS ARE DECIDED! (and so are roles!)

This was a very exciting week, and it would seem as though all our hard work has paid off! Our game was selected as one of the ones going forward! We met with our new teams and I think we’ve got an awesome crew! We were able to keep our original team (which Bob and Roger said wasn’t guaranteed) and added a bunch of new guys that seem as excited to make this game as we are. Here’s the roster:

Evan Orton (myself) – Design Lead

Christian Merrill – Team Lead/Scrum Master

Aaron Zettler – Engineering Lead

Jeff Jackman – Art Lead

Matt Barnes – Artist

Jon Kamerath – Artist

Kevin Conley – Artist

Richie Selfridge – Artist

Ethan Hayes – Engineer

Matt Lawton – Engineer

Calvin Kern – Engineer

Colton Lillywhite – Engineer

Devon Winkler – Engineer

And then there were 13…

10/3 Pitching to an industry panel

This was a crazy awesome week! This is was the week that we pitched our prototype presentation to an industry panel. I volunteered to prepare our pitch and a “one sheet” to present to the panel, which consisted of about 15-18 people that actually work in the games industry. They hailed from EA, Disney, Eat Sleep Play, and a couple other indie studios here in the Valley… I would be lying if I didn’t say I was excited. We were able to finish basically what we had planned for our rapid prototype, and Christian put together a demo reel which I used for the power point presentation. He also made some edits to my one sheet Matt Barnes also supplied me with some awesome concept art to add. We were really well prepared and I think our presentation left the panel excited and enthused. I felt like I did an awesome job with the presentation. Roger said that if we can get the panel to riff on our ideas, then we have got them… They were riffing on our ideas.

Link to Presentation: https://drive.google.com/file/d/0B8TJ3lkf3D3EcjNfaHNtdkNWOW8/view?usp=sharing

Link to Demo Reel: https://drive.google.com/file/d/0B8TJ3lkf3D3ELVcwZzU1UjQwaVU/view?usp=sharing

Link to One Sheet:

https://drive.google.com/file/d/0B8TJ3lkf3D3EVkxENWxwbzIyRWs/view?usp=sharing

9/26 Rapid Prototype shown to Bob and Roger

After playing our prototype, Bob and Roger had a few concerns. Roger said that our game in the current state feels more like a toy… which I’d agree with. It doesn’t quite function like a game. I do think we captured our “wow” moment pretty well (based on their giggling), but we need more for sure. I’m hoping that when we implement the stealth mechanic, that it will feel more like a game. Roger also suggested having an environment obstacle that we could corral NPCs in. I’m confident we can make the changes we need to get this thing where it needs to be.

9/19 Rapid Prototype

We have started to work on our rapid prototype. We are aiming to capture what we think is our game’s wow moment… a tree consuming the soul/body of a human being. So that’s been… interesting. I think we’ve done a few tweaks to this presentation to make it more interesting. Colton suggested that when the tree eats someone, that we should have the camera zoom in on the tree for a sort of “kill cam”. Matt Lawton went ahead and ran with that idea and made it a reality. Now we currently have player movement, a grab mechanic, and eating mechanic, and a couple different types of NPCs for the tree to rampage on! Hopefully Bob and Roger will have some good feedback next week.

9/12 Plant Food moves forward!

This was an exciting week for me! After giving my pitch to the class and some voting, my game idea is moving forward! I’m really excited, and I think we have an awesome team! I think that they are as excited as I am about the game, which is really reassuring. They all seem to like the fact that our game is crazy, and doesn’t really need to make any sense. They think it’s hilarious, and that we could really do some awesome stuff! I am really excited that I’ve got a few people that I’ve worked with in the past on our team, and the new guys seem great! Here’s our team:

Evan Orton (myself) – Designer/Art/Producer

Christian Merrill – Producer/Sound/Design

Matt Barnes – Art

Matt Lawton – Engineer

Calvin Kern – Engineer

Ethan Hayes – Engineer

Colton Lilywhite – Engineer

I’m a little concerned that Matt, Christian and I are the only artists on the team… mostly because Christian has said that he’s not the best artist, and I am absolutely in a similar boat. I’m hoping that if we move forward, that we can acquire a few more artists so Christian and I could assume the more design/producer roles that we are comfortable with.

Christian sent out this email detailing what we plan to accomplish for our rapid prototype:

Design Notes+Rapid Prototype

Win/Loss

Win Condition: Full Soul Meter

Loss Condition: Time up

(Colton will be working on UI and Win/Loss conditions)

Player Behavior

Slow movement, eat NPCs
(Matt Lawton is working on player creation)

NPC Behavior

Wander – No set path or reactions, mostly random

Curious – Investigates activities, paranoid, explores

Action – Set routine with variation (frisbee, mow lawn, sweep area)
Mission – Set path (jogger, commuter)

All will have a cone of vision. If they see tree moving or doing actions they will go into an alert state and move faster and away from player.

(Calvin and Ethan are working on NPCs)

Aesthetics

2D Isometric. Discussed other possible settings than a park. Park will be used for rapid prototype.
Rapid Prototype will have:

NPC Alert/Calm State

Player Eat/Idle

Level Scenery
Dog + Frisbee

(Matt and Evan are working on placeholder art and concepts)

Sound

Meaty, crunchy, over-the-top (but not gruesome gory nasty). Placeholder sound and effects for rapid prototype.

(Christian is working on sound and production)

Other Notes and Post Prototype Discussion

We discussed having the player in a variety of settings and “possessing” a variety of inanimate objects to snare people. Paranoid, faster, and fatter NPCs would be worth more points than normal. Faster player hits nourishment objective and more difficult NPCs mean more points. Stealth mechanic was moved to NPC based observation instead of a player status meter. Discussed a “skill tree” that would allow you to learn abilities that can be used to lure, distract, or snare specific types of NPCs, or provide other benefits.

Prototype Level Mockup

Not isometric, just the quick sketch from class slapped into Illustrator:

It’s ugly and not representative of either the prototype or final product, just a good idea to layout what we discussed in a simple format

9/5 Let’s Get Pitching!

So I’ve got a decent idea now of how this class will run (at least for now). We started this week by coming up with FIFTEEN game ideas each. Obviously not all of these were expected to be gold… but I helps with the creative process. Here are the fifteen I came up with:

1.       Robot Legs: An endless runner/adventure where your character (augmented with robot legs) must continuously run and jump. When the player jumps they go super high into the air, so high that the ground will not be visible. Upon approaching the ground, the player will have to double jump if they are about to land on a hazard.
2.       Birthing Suite: Players play an up and coming gynecologist in a labor and delivery unit. This will be a resource management type game vs a computer or human controlled opponent. Players will have to beat their opponent (deliver more healthy babies). Players will need to start epidurals, administer pictocin to speed up labor, check dilation, and deliver the babies. At then end of each level, you can get promoted to a bigger hospital (the last level would be Orem, Utah).
3.       Space Rescue 3: A top down space rescue game! Controls similar to asteroids, but instead of blasting asteroids, players will need to rescue wayward astronauts from an explosion at the space station. Arcade style, players will navigate space debris while collecting astronauts for points.
4.       Dinosaur Rodeo: Players ride dinosaurs in a tournament style rodeo. Each ride will get progressively harder until eventually players will ride the King of Dinosaurs: T-rex. Players will ride for 8 seconds (balance mechanic similar to Tony Hawk) then dismount, (sort of a quick time event with a chance to perform tricks in the air), and then escape (reflex testing similar to the jet bike section of battle toads, only not impossible).
5.       Demo Technician: A physics based puzzle game that involves players demolishing buildings using various tools (dynamite, C4, wrecking balls). Players will have limited resources and in later levels, they will have to plan carefully to keep the falling debris from landing outside of the designated “blast zone”.
6.       Celestial Ascent: Brick Breaker meets Katamari Damacy. Controlling a paddle, players will need to bounce an infant star into other cosmic matter to make it grow large enough (or gain a certain power) in order to break through the “ceiling” and reach the next level. Levels could be randomly generated and scoring could be arcade style.
7.       Exterminator: a tower defense style game where players must set up traps for insects that are trying to make their way into his home. Defenses could include fly paper, bug bombs, poison pellets, those electric zappers etc. If a bug makes it into the house, his wife will scream uncontrollably and make him get up to kill it.
8.       Mail Room: similar to a twin stick shooter, where players control a mail sorter from top down. The player will run with the left stick, aim with the right, and toss mail with the right trigger. There will be symbols on each receptacle that the player will need to match with the symbol on the mail. Arcade style high scores. (Maybe a paperboy like delivery level after each sort?)
9.       Going Deep: players pilot a small submarine that is constantly descending in search of treasure. The constant descent will make it play sort of like an endless runner. As players get deeper and deeper, there will be more hazards to avoid (rocks, sea monsters, old WWII mines) and it will get darker.
10.   Plant Food: Players control a man eating tree in a park. The tree will be able to move around very slowly, make noise to lure people, and devour them. Eating more people could level the tree up, with new powers. Getting caught will cause the townsfolk to set you on fire.
11.   For the Colony: an RTS game with ants that will involve only three unit types. Workers, Soldiers, and Queens. Workers tend the ant larvae, the queen, and maintain/expand the colony. Soldiers gather resources (automated) and act as units for attacking other colonies. Queens are special units and you can only have one per colony. If you plan on taking over another colony, you will need to hatch another queen first (which will cost resources/workers). The objective is to take over the entire park. Maybe PvP?
12.   Space Wizard: players control a wizard riding a kraken through space in a side scrolling flight shooter. Meant to be silly as possible… players would shoot bright and colorful spells at hordes of griffons, sharks, dragons, flying monkeys etc.
13.   Gus: Alaskan Ranger: A top down sandbox game similar to (old) GTA set in a small town in Alaska. Players will respond to random emergencies like: bears raiding campsites/grocery stores, poachers, avalanches, people falling through thin ice, wolves, lost tourists, caribou holding up traffic, moose attacks etc. As players level up, they will get new equipment: patrol truck, snowmobile, tranquilizer gun, real guns. All of Gus’ heroic exploits could be to impress a homely girl he has a crush on?
14.   Recess Reclaimer: A side scrolling Beat ‘em Up where players choose a character from their favorite clique to battle through different levels and overthrow a corrupt principal who has outlawed recess. Players can choose from: Nerds, Goths, Popular Kids, Drama Kids, Jocks, Band Geeks etc.
15.   Renovation Show Champion: Players will be given a house and a budget to plan a renovation for. The money can be spent reconfiguring/adding rooms, new appliances, tile, carpet etc. In the end they will see how much value they have added to the home.

After coming up with these ideas, we did some sort of crazy game pitch/speed dating hybrid activity and presented these to a few classmates… narrowing our 15 after each round. By the end we had to decide on ONE game idea to create a “one sheet”, or a one page pitch for. Then on Thursday, we presented these ideas to groups. I decided to move forward with my idea for a game called PLANT FOOD. Below is the one sheet I created for the group presentations:

After pitching to the group, we did a couple rounds of voting, and my game idea went forward! Bob and Roger are going to review the ideas and decide which should be given teams for rapid prototype/preparations for the industry panel.

This entry was posted in Uncategorized on October 29, 2014.

First Post!

Leave a reply

Hello everyone, and welcome to my blog.

Over the next nine months or so I will be recounting my journey through my Capstone course at the University of Utah in Entertainment Arts and Engineering. I am attending this course in order to become a Master Game Builder. I know the road will be long and full of hardships, as well as Red Bull…. but I am excited for the task. My Body is ready.

This entry was posted in Uncategorized on August 27, 2014.